Modelo de Guia de Plano de Projeto - Metodologia Desenvolvimento de Sistemas - Documentos Fase Concepção

Prévia do material em texto

Guia de Plano de Projeto 
Versão 1.0 
 
 
 
 
Novembro 2021 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Guia de Plano de Projeto 
 Página 2 de 23 
 
 
 
LISTA DE REVISÃO DO DOCUMENTO 
 
 
 
 
 
 
 
AVISO DE LIBERAÇÃO DE DOCUMENTO 
 
Aprovado por Data da Aprovação 
Escritório de Processo 16/11/2021 
 
 
 
LISTA DE DISTRIBUIÇÃO DO DOCUMENTO 
 
Enviado para Endereço 
Colaboradores da sua empresa Nome do servidor na rede 
 
 
Elaborado por Versão 
No. 
Data Descrição No. Página 
Escritório de Processo 1.0 14/11/2021 Criação do Documento 
 
 Guia de Plano de Projeto 
 Página 3 de 23 
 
SUMÁRIO 
 
 
INTRODUÇÃO 4 
1. Planejamento do Projeto 5 
2. Plano de Projeto Unificado 5 
3. Ciclo de Vida do Projeto 6 
3.1. Objetivos do ciclo de vida 6 
3.2. Custos durante o Ciclo de Vida 6 
3.3. Tipos de Ciclo de Vida 6 
3.3.1. Cascata Simples 7 
3.3.2. Iterativo e Incremental 9 
3.4. Escolha do Tipo de Ciclo de Vida 11 
3.5. Tamanho do Projeto 11 
3.6. Grau de Dificuldade do Projeto 12 
4. Cronograma
 13 
5. Lista Mestre
 14 
6. Planejamento de Recurso.
 14 
7. Gerenciamento de Riscos
 15 
8. Capacitação
 16 
9. Processo Operacional
 16 
10. EAP - Estrutura Analítica de Projeto
 16 
10.1. Níveis de EAP 17 
10.2. Identificação única 18 
10.3. Definindo Pacotes de trabalho 19 
11. Gerenciamento dos Envolvidos
 20 
12. Reunião de Kick-off
 21 
13. Estabelecer Estimativas de Projeto
 21 
 
 
 Guia de Plano de Projeto 
 Página 4 de 23 
 
INTRODUÇÃO 
 
Este documento tem como objetivo orientar o Gerente/Líder de Projetos no 
Planejamento do projeto. Este Guia deve ser observado sempre que houver um 
planejamento ou replanejamento do projeto. Nele são abordados aspectos quanto à 
escolha do ciclo de vida, definição do Processo Operacional, Planejamento de Recursos, 
Planejamento de riscos e outros itens que direcionam a execução do projeto. 
 
 
 
 
 Guia de Plano de Projeto 
 Página 5 de 23 
 
1. Planejamento do Projeto 
 
Em linhas gerais o planejamento do projeto consiste em estimar, com base num 
escopo definido, o Tamanho (PF/HH), o Esforço (HH), Prazo (Dias) e o Custo (R$) do 
produto que será desenvolvido. Todas as estimativas devem derivar de um escopo 
previamente acordado com o cliente. Além dessas estimativas, o plano de projeto 
também é composto pelo planejamento da qualidade, configuração, riscos, 
comunicação, ciclo de vida e gerenciamento dos envolvidos. 
1.1. Tipo de Projeto 
 
A [Nome da sua empresa] como uma empresa integradora de soluções, disponibiliza 
para o mercado várias linhas de serviço na área de TI, sendo assim os projetos a 
serem realizados pela empresa podem ser dê: 
 
• Alocação; 
• Consultoria; 
• Desenvolvimento; 
• Infra-Estrutura; 
• Suporte; 
• Integração: Seria a combinação de um ou mais tipos acima definidos. 
 
 
2. Plano de Projeto Unificado 
 
Um importante processo da disciplina de Planejamento de Projeto consiste na 
elaboração do Plano de Projeto Unificado. Este documento é o guia para o 
gerenciamento do projeto. Ele destaca informações tais como: o cronograma, 
necessidade de recursos, padrão para nome de documentos, configuração, gestão de 
qualidade, entre outros. O público alvo do plano é o Gerente/Líder de Projeto, Equipe 
do Projeto e Cliente. 
 De posse das estimativas de tamanho, esforço, custo e prazo para o projeto, 
Gerente/Líder de projeto inicia a confecção do Plano de Projeto Unificado a partir do 
modelo encontrado no Escritório de Projetos. 
 
 
 
 Guia de Plano de Projeto 
 Página 6 de 23 
 
3. Ciclo de Vida do Projeto 
 
A escolha da melhor abordagem para o ciclo de vida do projeto tem como objetivo 
determinar qual será o melhor encadeamento de atividades de projeto, levando em 
consideração vários fatores, tais como: tamanho, complexidade e tecnologia envolvida. 
Estes fatores são decisivos na escolha do ciclo de vida. 
 
3.1. Objetivos do ciclo de vida 
 
• Definir o sequenciamento/ paralelismo das fases do projeto; 
• Manter consistência entre os sistemas desenvolvidos na empresa; 
• Viabilizar pontos de controle para a gerência. 
 
 
3.2. Custos durante o Ciclo de Vida 
 
O nível dos custos e de utilização de pessoal durante o ciclo de vida do projeto, tem 
o seu pico nas fases intermediárias do projeto, quando da maior utilização de equipes 
de desenvolvimento e testes, como mostra o gráfico a seguir. 
 
Tempo
Nível de 
Custo e 
Pessoal
Fase 
Inicial
Fases 
Intermediárias Fase 
Final
Tempo
Nível de 
Custo e 
Pessoal
Fase 
Inicial
Fases 
Intermediárias Fase 
Final
 
 
3.3. Tipos de Ciclo de Vida 
 
 
 Guia de Plano de Projeto 
 Página 7 de 23 
 
Existe uma grande quantidade de tipos de ciclo de vida. Abaixo seguem alguns 
exemplos e suas características, que devem ser consideradas ao se escolher um 
determinado tipo de ciclo de vida: 
Tipos de ciclo de vida: 
• Cascata; 
• Iterativo e incremental. 
 
 
 
 
3.3.1. Cascata Simples 
 
Descrição: O modelo de Cascata Simples é um modelo de engenharia projetado 
para ser aplicado no desenvolvimento de software, onde as etapas de desenvolvimento 
seguem uma seqüência em que as atividades a serem executadas são agrupadas em 
tarefas e são realizadas de forma seqüencial. Desta forma uma atividade só pode ser 
realizada ao termino de outra. 
 
 
Análise 
Requsitos
Projeto
Construção
Teste
Implantação
Produção
 
 
 
 
 Guia de Plano de Projeto 
 Página 8 de 23 
 
Características 
• Fases do desenvolvimento de software são seqüenciais; 
• Entregas apenas no fim do projeto. 
 
Indicação para utilização: 
• Requisitos bem definidos e estáticos; 
o Necessidades do usuário são bem conhecidas; 
o Automatização de processos já definidos e documentados; 
• Metodologia de desenvolvimento de software madura 
• Projetos de tamanho pequeno ou médio: 
• Projetos de pequenas manutenções; 
• Tecnologia utilizada conhecida. 
 
Problemas: 
• Alta dependência de uma fase para outra; 
• Projetos reais raramente seguem o fluxo seqüencial; 
• Dificilmente o cliente declara todos os requisitos explicitamente; 
• O cliente só vê resultado nas entregas finais, uma vez que não existem 
entregas parciais do produto. 
• Devido à características das entregas, os erros são detectados de forma tardia, 
o que pode ocasionar retrabalho 
 
Observações: 
• Extremamente estruturado, fácil visibilidade e controle; 
• Omissão de fases: 
o As fases de Estudo de Viabilidade e Pós-Implantação podem ser omitidas em 
função das características do projeto. 
• Documentação do Projeto: 
 
 Guia de Plano de Projeto 
 Página 9 de 23 
 
o A documentação deve ser realizada ao longo do ciclo de vida para garantia 
da qualidade do projeto. 
 
 
3.3.2. Iterativo e Incremental 
 
Descrição: O modelo de ciclo de vida incremental e iterativo foi proposto como 
uma resposta aos problemas encontrados no modelo em cascata. Um processo de de-
senvolvimento segundo essa abordagem divide o desenvolvimento de um produto de 
software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as 
fases de análise, projeto, implementação e testes. Essa característica contrasta com a 
abordagem clássica, naqual as fases de análise, projeto, implementação e testes são 
realizadas uma única vez. 
Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos são 
desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No 
próximo ciclo, um outro subconjunto dos requisitos é considerado para ser 
desenvolvido, o que produz um novo incremento do sistema que contém extensões e 
refinamentos sobre o incremento anterior. 
Assim, o desenvolvimento evolui em versões, através da construção incremental 
e iterativa de novas funcionalidades até que o sistema completo esteja construído. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Guia de Plano de Projeto 
 Página 10 de 23 
 
 
 
Características 
• Entrega do produto por fases; 
• Cada fase é uma iteração/incremento à funcionalidade já implantada; 
• Pode-se haver mais de uma iteração em uma fase; 
• Custo: 
o custo 1ª fase << custo total. 
• Fácil de controlar (phase-driven); 
• Visão: 
o É preciso ter a visão completa do produto; 
o A arquitetura global deve estar pronta antes da construção da 1a. fase; 
o A 1ª fase deve implementar a infra-estrutura para as seguintes. 
• Documentação é realizada em paralelo. 
• Tempo de desenvolvimento: 
o Rápido retorno para o usuário; 
o Diminui a ansiedade do usuário; 
 80% das necessidades dos usuários são satisfeitas por 20% do sistema; 
 
Indicação para utilização: 
• Requisitos podem estar ou não bem definidos; 
• Projetos de tamanho médio ou grande; 
• Tecnologia nova ou desconhecida. 
 
Problemas 
• Visão: 
o Dificuldade de definir a arquitetura global; 
o A infra-estrutura pode “pesar” muito na 1a fase; 
 
 Guia de Plano de Projeto 
 Página 11 de 23 
 
• Retrabalho: 
o A cada nova fase a fase anterior deve se revisada e, possivelmente, alterada; 
o Soluções intermediárias jogadas fora; 
• Tempo de desenvolvimento: 
o Tempo total > tempo não faseado; 
• Custo: 
o Tusto total > custo não faseado. 
 
Observações: 
• Este tipo de ciclo de vida pode ser utilizado para grandes manutenções; 
• É ideal para Sistemas novos; 
• Desenvolvimento com novas tecnologias se adapta muito bem a este tipo de 
ciclo de vida. 
 
3.4. Escolha do Tipo de Ciclo de Vida 
 
Fatores que influenciam a escolha do tipo de ciclo de vida a ser adotado no projeto: 
• Tamanho do Projeto; 
• Complexidade técnica; 
• Complexidade funcional; 
• Estrutura do problema; 
• Fatores políticos. 
 
3.5. Tamanho do Projeto 
 
O Tamanho do Projeto na [sua empresa] é medido em Pontos de Função ou em 
Homem/Hora. Caso o tipo de medição seja em Ponto de Função, é necessário que seja 
convertido para Homem/Hora. A taxa referencial de utilização para conversão é 14 
horas/PF. A tabela abaixo mostra a caracterização dos tamanhos dos projetos. 
 
 
 Guia de Plano de Projeto 
 Página 12 de 23 
 
Medida Pequeno Médio Grande Muito Grande 
Pontos de 
Função 
300 301 – 1000 1001 – 2000 > 2000 
Homem Hora 
(HH) 
4200 4201 – 14000 14001 – 28000 > 28000 
 
As estimativas de tamanho devem ser refletidas no planejamento do cronograma. 
 
 
 
 
3.6. Grau de Dificuldade do Projeto 
 
Um projeto pode ter o seu grau de Dificuldade estimado em: 
• Simples; 
• Médio; 
• Complexo. 
O Grau de Dificuldade do Projeto também deve ser levado em consideração antes 
da escolha do tipo do ciclo de vida. Pode-se dizer que o grau de Dificuldade de um 
projeto é estabelecido em função dos seguintes atributos: 
• Tipo de problema (escopo): 
o Mal estruturado (não sabe o que se quer ou como fazer); 
o Estruturado (sabe-se o que se quer); 
o Bem estruturado (sabe-se o que se quer e como fazer); 
• Tamanho do projeto: 
o Pequeno; 
o Médio; 
o Grande; 
o Muito grande. 
Após avaliação dos atributos acima a tabela abaixo deve ser levada em 
consideração para determinar o Grau de Dificuldade. É importante lembrar que se a 
 
 Guia de Plano de Projeto 
 Página 13 de 23 
 
tecnologia envolvida for desconhecida, não for de domínio da [sua empresa], o 
Gerente/Líder pode optar por elevar o grau de dificuldade do projeto, de Simples para 
Médio ou de Médio para Complexo. 
 
Tamanho 
Problema 
Pequeno Médio Grande Muito 
Grande 
Bem 
Estruturado 
Simples Simples Médio Complexo 
Estruturado Simples Médio Complexo Complexo 
Mal 
Estruturado 
Médio Complexo Complexo Complexo 
 
4. Cronograma 
 
A fim de facilitar a elaboração do cronograma do projeto é importante seguir alguns 
passos. Estes passos são descritos a seguir: 
• Criar um novo cronograma a partir do template padrão da [sua empresa]; 
• As atividades obrigatórias do cronograma padrão devem ser preservadas, para 
retirar alguma destas atividades é necessário consultar o escritório de projetos. O 
Gerente/Líder de projeto pode acrescentar atividades necessárias e que não estejam 
contempladas no modelo; 
• Todas as atividades a serem executadas no projeto devem ser estabelecidas e 
lançadas neste cronograma; 
• Criadas as atividades, o Gerente/Líder de Projeto deve acrescentar as 
precedências entre elas. Deve ser dada prioridade às precedências com atividades de 
menor nível, evitando as precedências entre macro-atividades (ou atividades 
agrupadoras); 
• Posteriormente, deve ser observado se a coluna denominada “Trabalho” (work) 
está sendo exibida. Esta coluna deve ser preenchida com as horas planejadas para a 
realização da atividade; 
• Logo após a atribuição do trabalho, deve ser preenchida a coluna “Duração” 
(Duration). Esta coluna deve ser preenchida usando a unidade de dia. 
o Exemplo: uma atividade com o trabalho de 2 horas equivale à duração de 
0,25 dias. 
 
 Guia de Plano de Projeto 
 Página 14 de 23 
 
• Os recursos podem ser atribuídos assim que as atividades anteriores forem 
realizadas. Neste momento, devem ser observados os dias de execução das atividades, 
pois é comum que o Project acrescente uma diferença entre o término de uma 
atividade e o início da outra. Este ajuste fino deve ser realizado pelo Gerente/Líder do 
projeto; 
• O cronograma deve refletir as estimativas de horas previstas para o projeto, 
conforme disponibilizadas pela Área Estimation Center, quando da preparação da 
proposta; 
• Para finalizar o cronograma, o Gerente/Líder de Projeto deve salvar a linha de 
base do mesmo; 
• Após a finalização do cronograma, o Gerente/Líder de Projeto deve enviá-lo 
para o Escritório de Projetos para que seja publicado do EPM; 
• O Gerente/Líder de Projeto deve disponibilizar o cronograma para sua equipe e 
solicitar que as horas efetuadas sejam reportadas; 
 
5. Lista Mestre 
 
A Lista Mestre, anexo do Plano de Projeto Unificado, documenta quais os artefatos 
devem ser produzidos obrigatoriamente durante o projeto, identifica quais artefatos 
devem sofrer revisão, quais são itens de configuração, quais compõem baseline e os 
que devem passar por revisão de qualidade. 
O modelo da Lista Mestre traz preenchida uma lista mínima com as informações 
que devem ser geradas durante o ciclo de vida do projeto. Se algum artefato marcado 
como obrigatório ou qualquer outra opção (revisão, baseline) não for aplicável ao 
projeto, o Gerente/Líder de projeto deve fazer uma solicitação de concessão para que 
o mesmo não seja produzido ou que não sofra revisão, se for o caso. 
Para projetos em que há a necessidade de outros artefatos serem criados ou que 
passem por revisões ou componham baselines, o Gerente/Líder de projetos deve 
informar na Lista Mestre.6. Planejamento de Recurso. 
 
 
 Guia de Plano de Projeto 
 Página 15 de 23 
 
O Gerente/Líder de Projeto deverá planejar e solicitar os recursos-humanos do 
projeto conforme as necessidades de conhecimento para o desenvolvimento da solução 
e conforme os níveis de habilidade do colaborador para cada competência necessária. 
 
A [sua empresa] define cinco níveis distintos de conhecimento para as habilidades 
de seus colaboradores. O Gerente/Líder do Projeto deverá realizar o planejamento de 
recursos do projeto baseado nos níveis descritos abaixo: 
 
 
Nível de 
Habilidade Descrição 
Iniciante Teve treinamento, mas não atuou em projetos. 
Junior Trabalhou em projetos que utilizaram o produto/tecnologia. 
Pleno 
Trabalhou especificamente com o produto/tecnologia em 
projetos por dois anos ou mais e é reconhecido no projeto 
por sua capacitação técnica no produto/tecnologia. 
Sênior 
Trabalhou especificamente com o produto/tecnologia em 
projetos por três anos ou mais e é reconhecido na 
empresa por sua capacitação técnica no 
produto/tecnologia. 
Especialista 
 
 
Trabalhou especificamente com o produto/tecnologia em 
projetos por cinco anos ou mais e é reconhecido no 
mercado (clientes e parceiros) por sua capacitação técnica 
no produto/tecnologia. 
 
 
7. Gerenciamento de Riscos 
 
As premissas e restrições do projeto devem ser listadas no plano do projeto. Já o 
cadastro e monitoramento dos riscos e a estratégia de seu gerenciamento devem ser 
feitos através da Matriz de Risco, anexo do Plano de Projeto Unificado. 
 
Além das informações acima, a Matriz de Risco também deve conter a priorização 
dos riscos, que devem ser priorizados através da severidade que é resultante da 
fórmula: probabilidade x impacto. 
 
A probabilidade poderá variar entre os valores de 0,1 a 0,9. Os possíveis valores 
são: 
 
 Guia de Plano de Projeto 
 Página 16 de 23 
 
• 0,1 – muito baixa 
• 0,25 – baixa 
• 0,50 – moderada 
• 0,75 – alta 
• 0,90 – Muito Alto 
 
O impacto terá o intervalo de 1 a 10. Os possíveis valores são: 
• 1,0 – muito baixo 
• 2,5 – baixo 
• 5,0 – moderado 
• 7,5 – alto 
• 10,0 – muito alto 
 
De acordo com a classificação descrita acima haverá uma distribuição na matriz 
conforme exemplo abaixo. O resultado desta distribuição são os graus de severidade 
atribuído a cada risco identificado. 
8. Capacitação 
 
Durante o Planejamento e a execução do Projeto, o Gerente/Líder de Projeto deve 
identificar as necessidades de conhecimento dos integrantes das equipes. Elas serão 
identificadas como um Gap de Conhecimento e endereçada à Área de Treinamento da 
[sua empresa], que irá providenciar uma solução para resolver as necessidades. 
 
9. Processo Operacional 
 
O Processo Operacional pode ser customizado conforme a atividade “Definir 
Processo Organizacional - Estabelecer Critérios de Adaptação”. 
 
10. EAP - Estrutura Analítica de Projeto 
 
 
 Guia de Plano de Projeto 
 Página 17 de 23 
 
De acordo com o PMBOK (www.pmi.org) EAP é um agrupamento de componentes 
de projeto (orientado para a elaboração de subprodutos - deliverable-oriented) que 
organiza e define o escopo total do projeto: o trabalho que não está incluído na EAP 
está fora do escopo do projeto. De forma simplificada, a EAP é uma hierarquia 
orientada a elaboração de subprodutos que define todo o trabalho a ser executado no 
projeto. 
A EAP deve detalhar todo o escopo do projeto fazendo com que a estimativa do 
projeto seja realizada de forma eficiente podendo contemplar prazo, esforço e custo. 
Não existe uma forma “correta” de se construir uma EAP. Na prática, a estrutura 
de árvore (que lembra um organograma) é amplamente utilizada, mas a EAP pode ser 
feita também utilizando um plano (ex.: Microsoft Project) ou com outra ferramenta na 
qual o Gerente/Líder de projeto julgue adequado. 
O conteúdo da EAP é organizado em níveis, geralmente em uma ordem 
seqüencial que define todas as tarefas a serem executadas para a realização do 
projeto. 
10.1. Níveis de EAP 
 
Mesmo o Gerente/Líder de projeto sendo livre para determinar a quantidade de 
níveis na estrutura EAP baseada na complexidade do projeto, o primeiro nível (mais 
alto) é considerado o próprio projeto. Este nível é seguido de sub-produtos, que devem 
ser entregues para a conclusão do projeto, e respectivas atividades a serem 
executadas. 
O exemplo a seguir demonstra os níveis 1 e 2 para o projeto denominado “Projeto 
Web”. O nível 2 demonstra os produtos que devem ser entregues ao cliente. 
 
 
 
O nível 3 de uma EAP pode conter os produtos do gerenciamento e o nível 4 as 
iterações para realização do produto. 
 
http://www.pmi.org/
 
 Guia de Plano de Projeto 
 Página 18 de 23 
 
 
 
 
O objetivo dos níveis é dividir o trabalho em tarefas (ou unidades de trabalho) 
que possam ser atribuídas aos membros do time com prazo e esforço definidos. 
 
 
10.2. Identificação única 
 
Cada elemento da EAP deve ser identificado de forma única na estrutura (de acordo 
com o PMBOK (www.pmi.org). Esta identificação é tipicamente um número utilizado 
para rastrear o objeto na estrutura EAP. 
 
Exemplo: 
10 Projeto WEB 
 10.1 Administração 
 10.1.1 Planejamento 
 10.1.2 Execução 
 10.1.2.1 Iteração I 
 10.1.2.1.1 Caso de Uso 1 
 10.1.2.1.2 Caso de Uso 2 
 10.1.2.1.3 Caso de Uso n 
 10.1.2.2 Iteração II 
 10.1.2.2.1 Caso de Uso (n+1) 
 10.1.2.2.2 Caso de Uso (n+2) 
 
10.1.3 Controle e Monitoramento 
 10.1.4 Encerramento 
 
http://www.pmi.org/
 
 Guia de Plano de Projeto 
 Página 19 de 23 
 
10.3. Definindo Pacotes de trabalho 
 
Conforme já mencionado, o Gerente/Líder de projeto tem a liberdade de determinar 
a quantidade de níveis existentes na estrutura EAP do seu projeto, de acordo com sua 
complexidade. É necessário incluir níveis suficientes para se conseguir estimar 
corretamente o projeto, mas ao mesmo tempo deve-se observar que uma quantidade 
exagerada de níveis pode dificultar a distinção das atividades e o trabalho do 
Gerente/Líder /Líder do projeto. 
 
Os pacotes de trabalho devem ser distribuídos ao time do projeto com objetivos e 
prazo claramente definidos pelo Gerente/Líder de projeto. É recomendado que um 
pacote de trabalho não tenha a duração superior a 40 horas, permitindo que todas as 
atividades possam ser gerenciadas adequadamente pelo Gerente/Líder de projeto. 
 
O nível onde são identificados os pacotes é utilizado para se estimar esforço, prazo 
e custo do projeto. 
 
Cabe ao Gerente/Líder definir a necessidade de dividir os pacotes de trabalho em 
atividades ou não. O PMBOK (www.pmi.org) não define nenhuma regra em relação a 
necessidade ou não de se incluir atividades para cada pacote de trabalho. 
http://www.pmi.org/
 
 Guia de Plano de Projeto 
 Página 20 de 23 
 
 
 
11. Gerenciamento dos Envolvidos 
 
O gerenciamento dos envolvidos deve contemplar o planejamento e 
acompanhamento do comprometimento com as pendências e ações corretivas 
apontadas para o projeto, durante todo o ciclo de vida. 
Neste sentido, deverão ser planejadas e acompanhadas as atividades de cada 
envolvido no projeto. Além das atividades específicas dos colaboradores, o 
Gerente/Líder de Projeto deverá discutir com os envolvidos, pendências relativas a 
riscos, gestão de configuração, qualidade, métricas, requisitose treinamentos. 
O gerenciamento dos envolvidos contempla o acompanhamento dos compromissos 
assumidos e o gerenciamento das expectativas dos stakeholders, que pode ser 
realizado por meio das reuniões de acompanhamento e por meio do reporte das 
informações nos relatórios de status e desempenho com o respectivo feedback das 
informações reportadas. 
Desta forma, o Gerente/Líder de Projeto deverá planejar as reuniões com os 
respectivos envolvidos que acontecerão no projeto; planejar a periodicidade dos 
relatórios (status e desempenho) e se há necessidade de reporte de informações além 
daquelas previstas no modelo dos relatórios. 
 
 Guia de Plano de Projeto 
 Página 21 de 23 
 
 
12. Reunião de Kick-off 
A reunião de Kick-off marca o fim do planejamento do projeto. A reunião 
caracteriza o comprometimento de todos os envolvidos internos à [sua empresa] no 
projeto. 
O Gerente/Líder de Projeto deverá identificar quem são os interessados e as 
interfaces da [sua empresa] que devem estar presentes no Kick-off. Todas as áreas de 
apoio dos projetos como: RH, Treinamento, Controladoria, Infra-estrutura, 
Administrativo, entre outras devem participar desta reunião. Durante a reunião o 
Gerente/Líder de Projeto e os Grupos de Apoio deverão identificar os responsáveis 
para cada necessidade apontada. Na ausência de alguém na reunião o Gerente/Líder 
de Projeto deverá posteriormente reunir-se com este colaborador e explicar-lhe o 
contexto e a atuação do colaborador no projeto. 
O prazo para a realização da reunião de kick-off e para a entrega da primeira 
versão do Plano de Projeto Unificado é o mesmo e irá depender do tamanho do 
projeto. Caso o projeto seja pequeno, este prazo será de no máximo 7 dias após a 
data de oficialização do projeto na [sua empresa], que é feito através do documento 
Nota de Iniciação. A Nota de Iniciação estabelece a data de início do projeto, a qual 
deve ser considerada para contagem destes prazos. Para projetos de médio, grande e 
muito grande porte este prazo será de no máximo 20 dias também após a data de 
oficialização do projeto. O Gerente/Líder de projeto deverá seguir o 
documentoChecklist de Kick-off para validar a apresentação de kick-off. Caso alguma 
pendência seja identificada, ações corretivas devem ser tomadas para corrigi-las e 
assim finalizar esta apresentação. 
13. Estabelecer Estimativas de Projeto 
Dentre as restrições que se aplicam aos projetos, o custo do projeto e o prazo 
para entrega de produtos são as mais comuns. O esforço total previsto para o projeto 
deve estar especificado em Contrato e distribuído na Planilha de Formação de Preço. 
Esta Planilha traz uma distribuição do esforço nos perfis utilizados pela [sua empresa] 
para projetos de desenvolvimento de software. O Gerente/Líder do Projeto deverá 
realizar o planejamento do projeto com base nestes documentos. 
 
 Guia de Plano de Projeto 
 Página 22 de 23 
 
É imprescindível que o Gerente/Líder de Projeto distribua o esforço total do 
projeto nas atividades previstas para cada perfil descrito na Planilha de Formação de 
Preço. Esta distribuição possibilitará o acompanhamento do esforço e do custo previsto 
para cada perfil utilizado no projeto. 
 As técnicas utilizadas pela [sua empresa] para estimar o esforço do projeto são 
a Análise de Pontos de Função ou estimativa Homem/Hora. 
Caso a técnica de contagem por pontos de função for escolhida, existem dois 
tipos de contagem: a Estimativa e a Detalhada, conforme descrito abaixo: 
 
A contagem Estimativa fornece um valor estimado da quantidade de pontos de 
função do sistema proposto sem a precisão do grau de complexidade das funções. 
Pode ser usada na fase inicial da proposta de desenvolvimento, quando não se têm 
detalhes do processo, mas somente informações preliminares e o modelo de dados. 
A contagem Detalhada fornece a quantidade de pontos de função do sistema, 
obtido a partir do grau de complexidade das funções levantadas. Pode ser utilizada em 
qualquer fase de desenvolvimento, desde que se possua detalhes do processo e do 
modelo de dados, como descrição de telas e relatórios ou um protótipo do sistema. 
Caso a técnica de Homem/Hora for escolhida, o método de PERT deve ser 
aplicado: 
PERT - Técnica de Avaliação e Revisão CPM - Método do Caminho Crítico - 
Uma técnica de análise de rede orientada para eventos, utilizada para calcular a 
duração de um programa quando existe incerteza nas estimativas de duração da 
atividade individual. A técnica PERT aplica o método do caminho crítico usando 
durações calculadas por uma média ponderada das estimativas de duração otimista, 
pessimista e mais provável. A técnica PERT calcula o desvio padrão da data de 
conclusão com base na duração das atividades do caminho. Também conhecido como 
método de análise de momentos. 
Para o preenchimento dos parâmetros (Otimista, Pessimista e Provável), deve ser 
considerado o esforço de 1(uma) Pd/Dia, ou seja, o tempo necessário para realização 
da determinada tarefa por uma pessoa 100% alocada. 
 
 
 Guia de Plano de Projeto 
 Página 23 de 23 
 
Formula: (Estimativa Otimista + (4x Estimativa Provável) + Estimativa 
Pessimista)/6. 
O Gerente/Líder de Projeto deve estabelecer a “estimativa provável” e a equipe 
do projeto as estimativas “otimistas” e a “pessimista”. Como por exemplo: 
A equipe do projeto define: 
 Estimativa Otimista: 24 HH; 
 Estimativa Pessimista: 51 HH; 
O Gerente/Líder de projeto define: 
 Estimativa provável: 36 HH. 
A estimativa será = (24 + 4(36) + 51)/6 = 36.5 
 
	INTRODUÇÃO
	1. Planejamento do Projeto
	1.1. Tipo de Projeto
	2. Plano de Projeto Unificado
	3. Ciclo de Vida do Projeto
	3.1. Objetivos do ciclo de vida
	3.2. Custos durante o Ciclo de Vida
	3.3. Tipos de Ciclo de Vida
	3.3.1. Cascata Simples
	3.3.2. Iterativo e Incremental
	3.4. Escolha do Tipo de Ciclo de Vida
	3.5. Tamanho do Projeto
	3.6. Grau de Dificuldade do Projeto
	4. Cronograma
	5. Lista Mestre
	6. Planejamento de Recurso.
	7. Gerenciamento de Riscos
	8. Capacitação
	9. Processo Operacional
	10. EAP - Estrutura Analítica de Projeto
	10.1. Níveis de EAP
	10.2. Identificação única
	10.3. Definindo Pacotes de trabalho
	11. Gerenciamento dos Envolvidos
	12. Reunião de Kick-off
	13. Estabelecer Estimativas de Projeto