_ebook-gestão-de-projetos--herberth-cutrim

Prévia do material em texto

Gestão de Projetos 1
Volte ao Sumário
GESTÃO DE PROJETOS
Gestão de Projetos 1
Volte ao Sumário
Cutrim, Herberth; Vanzeler, Thany Elly, 2021.
Gestão de Projetos - Jupiter Press - São Paulo/SP
42 páginas.
Palavras-chave: 1. Projeto; 2. Gestão; 3. Planejamento.
Gestão de Projetos 2
Volte ao Sumário
s
SUMÁRIO
SOBRE O PROF. HERBERTH CUTRIM, MSC, PMP. ....................................................................3
APRESENTAÇÃO ............................................................................................................................................4
O PMBOK ............................................................................................................................................................5
1. DESENVOLVER O TERMO DE ABERTURA DO PROJETO.................................................6
1.1 DOCUMENTOS NECESSÁRIOS: BUSINESS CASE. ..................................................7
1.2 ITENS NECESSÁRIOS PARA COMPOR O TERMO DE ABERTURA ...............7
2. A IDENTIFICAÇÃO AS PARTES INTERESSADAS .....................................................................9
3. PLANEJAR A ORGANIZAÇÃO E O GERENCIAMENTO DAS MUDANÇAS ............12
3.1 A PLANO DE ORGANIZAÇÃO E GERENCIAMENTO DAS
 MUDANÇAS TEM AS SEGUINTES INFORMAÇÕES EM SEU CONTEÚDO: ..12
4. DEFINIR O ESCOPO ................................................................................................................................14
4.4 RESTRIÇÕES: .................................................................................................................................15
4 .5 PREMISSAS: ...................................................................................................................................16
5. CRIAR A ESTRUTURA ANALÍTICA DO PROJETO – EAP ....................................................18
5.1. DICIONÁRIO DA EAP ...............................................................................................................19
6. DESENVOLVER O CRONOGRAMA ...............................................................................................21
7. DETERMINAR O ORÇAMENTO ........................................................................................................22
8. PLANEJAR A QUALIDADE ...................................................................................................................24
9. DESENVOLVER O PLANO DE RECURSOS ................................................................................26
10.PLANEJAR AS COMUNICAÇÕES ..................................................................................................28
11.PLANO DE GERENCIAMENTO DE RISCOS ..............................................................................30
12.PLANEJAR AS AQUISIÇÕES ..............................................................................................................36
13.ORIENTAR E GERENCIAR A EXECUÇÃO DO PROJETO .................................................38
14. MONITORAR E CONTROLAR O TRABALHO DO PROJETO .........................................39
15. ENCERRAR O PROJETO .....................................................................................................................40
*
* A navegação deste e-book por meio de botões interativos pode variar de funcionalidade dependendo de cada leitor de PDF.
Gestão de Projetos 3
Volte ao Sumário
SOBRE O PROF. HERBERTH CUTRIM, MSC, PMP.
Administrador com pós-graduação/MBA na Universidade de São Paulo 
- USP, especialista em gestão e mestre em administração pela Fundação 
Getúlio Vargas – FGV/Rio de Janeiro (EBAPE) e especialista em gestão 
pela Universidade Lusíada de Lisboa, Portugal. Foi Project Management 
Professional - PMP pelo Project Management Institute – PMI, do qual era 
integrante.
É professor universitário, palestrante e consultor de empresas. Foi 
coordenador de empresa júnior, coord. de cursos de graduação e pós-
graduação e diretor de instituições de ensino superior no Brasil. 
Larga experiência em nível nacional e internacional. No Brasil atuou em 
Belém, Fortaleza e São Paulo, além de coordenar treinamentos em Curitiba, 
Porto Alegre, Brasília, Vitória e outras cidades. Prestou serviços de treinamento 
in company e consultoria para várias empresas de renome, tais como: Microsiga, 
Grupo Edson Queiroz, Terra, Tramontina, Hiléia, UOL, Televisão Verdes Mares 
e muitas outras.
No exterior atuou como diretor de marketing da Yes Computadores, 
Estados Unidos. Atualmente, é presidente do Conselho do Grupo Estratego e 
é presidente da International Association of Business Coaching.
Reformulado por: Thany Ely Vanzeler Pereira, Administradora, MBA em 
Logística e Produção, Pós em Gestão Educacional e Projetos. Atua há mais 
de 11 anos na área da gestão, docente de cursos profissionalizantes, técnicos 
e de nível superior e componente há 08 anos da banca de examinadores de 
Projetos dos MBA’s da Faculdade Estratego.
Gestão de Projetos 4
Volte ao Sumário
APRESENTAÇÃO
No intuito de criar um material prático sobre as explanações feitas em sala 
sobre o gerenciamento de projetos utilizando o P15, metodologia baseada no 
PMBOK 6ª. Edição, nasceram estas notas explicativas. Com isto, imagina-se que 
o aluno poderá atentar para os diversos detalhes que foram discutidos em sala e 
complementar seus conhecimentos, consultando diretamente o PMBOK, que é 
o livro texto deste módulo de seu MBA. Portanto, estas notas explicativas não têm 
o caráter e nem o intento de ser a bibliografia básica para o assunto. Seu objetivo é 
tão somente ser uma fonte rápida e concisa sobre os assuntos abordados em sala, 
de forma complementar. A ideia de escrever estas notas explicativas tem em seu 
cerne o desejo de usar uma linguagem simples e informal, tal qual é conduzida 
a aula. Criando, desta maneira, uma ligação das notas, com o que foi debatido e 
explanado em sala. Este texto foi escrito tendo em mente o reforço dos principais 
conceitos apresentados ao longo do seu módulo (disciplina) “Desenvolvimento 
de projetos”.
Gestão de Projetos 5
Volte ao Sumário
O PMBOK
É um guia prático de projetos, visando estruturar processos e passosnecessários 
para que as organizações tenham sucesso no desenvolvimento de seus projetos. 
Segue abaixo os itens necessários para que você crie projetos e tenha sucesso em 
sua execução.
Iniciação
Encerramento Planejamento
Execução
Monitoramento
e controle
Fotografia 1: Grupo de Processos
Fonte: bloge.luz.vc.com.br
Um Grupo de Processos de gerenciamento de Projetos é um agrupamento 
lógico de processos de gerenciamento de projetos para atingir os objetivos 
específicos do projeto. Os Grupos de Processos são independentes das fases do 
projeto. Os processos de gerenciamento de projetos são agrupados em cinco
Grupos de Processos de Gerenciamento de Projetos:
• Grupo de processos de iniciação. Os processos realizados para definir um novo pro-
jeto ou uma nova fase de um projeto existente, através da obtenção de autorização 
para iniciar o projeto ou fase.
• Grupo de processos de planejamento. Os processos realizados para definir um novo 
projeto ou uma nova fase de um projeto existente, através da obtenção de autoriza-
ção para iniciar o projeto ou fase.
• Grupo de processos de execução. Processos realizados para concluir o trabalho de-
finido no plano de gerenciamento do projeto para satisfazer os requisitos do projeto.
• Grupo de processos de monitoramento e controle. Os processos exigidos para 
acompanhar, analisar e controlar o progresso e desempenho do projeto, identificar 
quaisquer áreas nas quais serão necessárias mudanças no plano, e iniciar as mudan-
ças correspondentes.
• Grupo de processos de encerramento. Os processos realizados para concluir ou fe-
char formalmente um projeto, fase ou contrato.
Gestão de Projetos 6
Volte ao Sumário
1. DESENVOLVER O TERMO DE ABERTURA DO PROJETO
Desenvolver o Termo de Abertura do Projeto é o processo de desenvolver 
um documento que formalmenteautoriza a existência de um projeto e fornece ao 
gerente do projeto a autoridade necessária para aplicar recursos organizacionais 
às atividades do projeto. Os principais benefícios desse processo incluem o 
fornecimento de um vínculo direto entre o projeto e os objetivos estratégicos da 
organização, criar um registro formal do projeto e demonstrar o compromisso da 
organização com o mesmo.
Esse processo é realizado uma vez ou em pontos predefinidos no projeto. 
O termo de abertura do projeto estabelece uma parceria entre a organização 
executora e a organização solicitante. No caso dos projetos externos, umcontrato 
formal é normalmente a forma preferida de estabelecer um acordo. Também 
pode ser usado para estabelecer acordos internos no âmbito de uma organização 
para garantir a entrega apropriada nos termos do contrato.
O termo de abertura do projeto aprovado inicia formalmente o projeto.
O gerente do projeto é identificado e designado o mais cedo possível, 
preferivelmente enquanto o termo de abertura do projeto está sendo 
desenvolvido e sempre antes do início do planejamento. Pode ser desenvolvido 
pelo patrocinador ou pelo gerente do projeto em colaboração com a entidade 
iniciadora. Esta colaboração permite que o gerente do projeto tenha uma melhor 
compreensão da finalidade, objetivos e benefícios esperados do projeto. Esta 
compreensão permitirá uma designação de recursos mais eficientes para as 
atividades do projeto. O termo de abertura do projeto fornece ao gerente do 
projeto a autoridade para planejar, executar e controlar o projeto. Os projetos 
são iniciados por uma entidade externa ao projeto, tais como um patrocinador, 
programa, escritório de gerenciamento de projetos (EGP) ou dirigente do órgão 
diretivo do portfólio ou o seu representante autorizado. O responsável pela 
iniciação do projeto ou patrocinador do projeto deve estar em um nível apropriado 
para captar o financiamento e dedicar recursos para o projeto.
Os projetos são iniciados em virtude de necessidades internas de negócio da 
empresa ou influências externas. Essas necessidades ou influências normalmente 
provocam a criação de uma análise de necessidades, estudo de viabilidade, 
business case, ou descrição da situação que o projeto abordará. A abertura de 
um projeto valida o alinhamento do projeto com a estratégia e o trabalho em 
progresso da organização. Um termo de abertura do projeto não é considerado 
um contrato, porque não há pagamento, promessa ou troca de dinheiro envolvidos 
na sua criação.
Gestão de Projetos 7
Volte ao Sumário
1.1 DOCUMENTOS NECESSÁRIOS: BUSINESS CASE.
O business case aprovado, ou similar, é o documento de negócio mais 
comumente usado para criar o termo de abertura do projeto. O business 
case descreve as informações necessárias do ponto de vista de negócio, para 
determinar se os resultados esperados do projeto justificam o investimento 
necessário. Ele é comumente usado no processo decisório pelos gerentes ou 
executivos acima do nível do projeto. Normalmente, a necessidade de negócio 
e a análise de custobenefício estão contidas no business case para justificar e 
estabelecer os limites do projeto.
O business case é criado como resultado de um ou mais dos seguintes fatores:
• Demanda de mercado (por exemplo, uma companhia automobilística autoriza um 
projeto para produzir carros mais eficientes e econômicos em resposta à escassez 
de gasolina);
• Necessidade organizacional (por exemplo, em virtude das altas despesas indiretas, 
uma companhia pode combinar as funções de equipes e simplificar os processos 
para reduzir os custos);
• Solicitação do cliente (por exemplo, uma companhia elétrica autoriza um projeto 
para construir uma nova subestação para atender um novo parque industrial);
• Avanço tecnológico (por exemplo, uma companhia aérea autoriza um novo projeto 
para criar passagens aéreas eletrônicas em vez de passagens em papel, com base 
em avanços tecnológicos);
• Um requisito legal (por exemplo, um fabricante de tintas autoriza um projeto para 
estabelecer diretrizes para o manuseio de materiais tóxicos);
• Impactos ecológicos (por exemplo, uma companhia autoriza um projeto para reduzir 
o seu impacto ambiental), ou;
Necessidade de natureza social (por exemplo, uma organização não 
governamental de um país em desenvolvimento autoriza um projeto a fornecer 
sistemas de água potável, esgoto e educação sanitária às comunidades vítimas de 
altos índices de cólera).
O termo de abertura do projeto incorpora as informações apropriadas para o 
projeto a partir dos documentos de negócios. O gerente do projeto não atualiza 
nem modifica os documentos de negócio, uma vez que não são documentos de 
projeto; no entanto, o gerente do projeto pode fazer recomendações.
1.2 ITENS NECESSÁRIOS PARA COMPOR O TERMO DE ABERTURA
• Finalidade do projeto;
• Objetivos mensuráveis do projeto e critérios de sucesso relacionados;
• Requisitos de alto nível;
• Descrição de alto nível do projeto, seus limites e entregas-chave;
• Risco geral do projeto;
• Resumo do cronograma de marcos;
• Recursos financeiros pré-aprovados;
Gestão de Projetos 8
Volte ao Sumário
• Lista das partes interessadas chave;
• Requisitos para aprovação do projeto (ou seja, o que constitui o sucesso do projeto, 
quem decide se o projeto é bem sucedido e quem autoriza o encerramento do pro-
jeto);
• Critérios de término do projeto (ou seja, quais são as condições que devem ser cum-
pridas para encerrar ou cancelar o projeto ou fase);
• Gerente do projeto designado, responsabilidade e nível de autoridade; e
• Nome e autoridade do patrocinador ou outra(s) pessoa(s) que autoriza(m) o termo 
de abertura do projeto.
Gestão de Projetos 9
Volte ao Sumário
2. A IDENTIFICAÇÃO AS PARTES INTERESSADAS
O gerenciamento das partes interessadas do projeto inclui os 
processosexigidos para identificar todas as pessoas, grupos ou organizações 
que podem impactar ou serem impactados pelo projeto, analisar as expectativas 
das partes interessadas, seu impacto no projeto e desenvolver estratégias de 
gerenciamento apropriadas para o engajamento eficaz das partes interessadas 
nas decisões e na execução do projeto. Os processos apoiam o trabalho da equipe 
do projeto para analisar as expectativas das partes interessadas, avaliar o grau em 
que afetam ou são afetadas pelo projeto, e desenvolver estratégias para envolver 
com eficácia as partes interessadas em apoio a decisões, ao planejamento e à 
execução do trabalho do projeto.
O processo de identificar as partes interessadas faz parte da área de 
conhecimento “Comunicações” e integra os grupos de processos “Iniciação. Sem 
dúvidas, este é um dos processos mais vitais para o sucesso do projeto. Pois, é nele 
que o GP irá identificar quem são os stakeholders do projeto, suas expectativas e 
necessidades.
Se o GP não levantar adequadamente as necessidades e expectativas das 
partes interessadas do projeto, jamais conseguirá entregar um produto que 
atenda aos requisitos para o qual foi criado.
Pense comigo, para quem o projeto é feito? Para os stakeholders é a resposta. 
Isto inclui, mas não se limita aos: sponsors, clientes, usuários, fornecedores e 
até membros da equipe. Se o GP não consegue identificar as necessidades e 
expectativas relacionadas ao projeto, o que ele fará será mera adivinhação, pois 
não saberá o que se espera do projeto.
Portanto, se o processo de identificação das partes interessadas for mal feito, 
todo o resto será. Conhecer muito bem o que cada parte interessada no projeto 
quer dele é um fator crítico para o sucesso projeto. Fique atento a isto. Quando 
for desenvolver um projeto, use o seu tempo para fazer um bom levantamento. 
Veja a classificação dos principais stakeholders de um projeto, quanto ao 
tipo:
Gerente do projeto: responsável maior pela condução do projeto, integra 
todas as partes em um todo coeso, a fim de alcançar os objetivos do projeto;
- Cliente: segundo o PMBOK do Project Management Institute - PMI, é a 
pessoaou organização que solicitou o produto ou o serviço;
- Membros da equipe: pessoas que vão participar do gerenciamento e 
realizar o trabalho do projeto; 
Gestão de Projetos 10
Volte ao Sumário
- Sponsor/Patrocinador: Pessoa ou organização, dentro ou fora 
daorganização executora que provê recursos financeiros ou apoio institucional;
- Usuário: quem vai utilizar o resultado do projeto;
Neste momento do projeto, o gerente deve entrevistar cada stakeholder e 
registrar as informações cuidadosamente para poder elaborar posteriormente o 
documento “Registro das Partes Interessadas” que é o local em que as informações 
serão agrupadas e organizadas.
Algumas dicas interessantes para conduzir a entrevista é começar com a 
pergunta “Por que este projeto vai ser realizado?”, ou seja, resolve qual problema 
da empresa? Em seguida algumas perguntas ajudam também, tais como: “Como 
será o produto do projeto, quando ele terminar?”, “Como deve ser conduzido o 
projeto?”, “O que se espera do projeto?”. 
Muitas outras perguntas são necessárias e podem surgir ao longo da entrevista 
ou serem elaboradas previamente pelo GP e sua equipe de gerenciamento, 
levando em consideração o contexto do projeto.
Como dito, após terminada a identificação e entrevistas dos stakeholders, 
as informações devem ser compiladas no documento “Registro das Partes 
Interessadas”, para posteriores consultas.
O registro dos stakeholders (partes interessadas) tem as seguintes 
informações em seu conteúdo:
Para efeito desta nota explicativa, todos os documentos apresentados 
possuem uma barra de identificação, um quadro de alterações e uma folha de 
aprovações, além dos itens abaixo apresentados.
Stakeholder:
informe neste espaço o tipo de stakeholder, de acordo com a classificação
adotada no projeto, como por exemplo: sponsor, usuário, cliente etc;
Nome: informe o nome do stakeholder.
Cargo: Informe o cargo que ele ocupa na organização.
E-mail: Informe o e-mail para facilitar a comunicação.
✓Telefone: informes os telefones, a fim de facilitar o contato ao longo do 
projeto.
Necessidades e expectativas:
Informe quais as necessidades e expectativas que o stakeholder tem em 
Gestão de Projetos 11
Volte ao Sumário
relação projeto. Estas informações devem ter sido levantadas anteriormente em 
entrevista específica para isto. Importante ressaltar que não há a necessidade de 
separar as necessidades, das expectativas, a não ser que você queira classificar 
desta forma.
Influências:
Avaliando o cargo, o poder do stakeholder na organização, o prestígio dele 
juntos aos colegas de trabalho, as normas e procedimentos, suas necessidades e 
expectativas, a sua possível participação nas atividades do projeto, assim como, 
a cultura da empresa, informe quais influências o mesmo terá no rumo que o 
projeto terá.
Uma outra forma de identificar as influências é conversar com colegas de 
trabalho do stakeholder e levantar suas influências em projetos anteriores que 
possivelmente constam nos computadores ou arquivos da organização.
É importante entender a influência de cada stakeholder, a fim de gerenciála 
ao longo de todo o projeto, pois alguns vão afetar positivamente e outros, até 
negativamente. Estando o GP informado, poderá se antecipar a problemas 
futuros, assim como, proveitar oportunidades.
Classificação:
Para a classificação quanto a origem o stakeholder pode ser: interno ou 
externo; quanto a classificação quanto ao interesse, pode ser: apoiador, neutro ou 
resistente.
Esta informação é importante, a partir do momento que a forma como o GP lida 
com cada stakeholder vai ser diferente para quando ele for interno a organização, 
em relação aos externos; também vai ser diferente fundamentalmente quanto ao 
interesse. Isto exige estratégias diferentes para cada stakeholder.
Se você errar na identificação dos stakeholder, nada que fizer posteriormente 
salvará o seu projeto. Pois, a essência do que o GP faz, depende do que os
stakeholders querem do projeto. Portanto, levante o máximo de informações
no processo de identificar os stakeholders;
Fique atento
Gestão de Projetos 12
Volte ao Sumário
3. PLANEJAR A ORGANIZAÇÃO E O GERENCIAMENTO 
DAS MUDANÇAS
Este processo faz parte da área de conhecimento “Integração” e do grupo 
de processos “Planejamento”. A partir deste momento, o projeto que foi iniciado, 
passa a ser planejado.
O sucesso de qualquer projeto será afetado pela forma como ele se mantém 
organizado durante todas as suas fases e, ainda, a maneira como todas as mudanças 
são feitas.
Nenhum plano de projeto, por melhor que tenha sido elaborado, vai 
permanecer intacto ao longo de todo o projeto. Visto que, o contexto organizacional 
é dinâmico. Por isto, o próprio plano deve prever como todas as mudanças que 
ocorrem serão gerenciadas, a fim de garantir que todos os membros da equipe 
sempre tenham em mãos a cópia mais atualizada do plano a ser seguido, além de 
uma clara ideia de todo histórico de mudanças que ocorreram
O plano de organização e gerenciamento das mudanças contempla todas as 
normas e procedimentos que serão seguidos, no intuito de manter o projeto e 
sua documentação organizada, de forma que qualquer participante saiba onde 
guardar e recuperar a informação que precisa de forma rápida e eficiente.
3.1 A PLANO DE ORGANIZAÇÃO E GERENCIAMENTO DAS 
MUDANÇAS TEM AS SEGUINTES INFORMAÇÕES EM SEU 
CONTEÚDO:
Para efeito desta nota explicativa, todos os documentos apresentados 
possuem uma barra de identificação, um quadro de alterações e uma folha de 
aprovações, além dos itens abaixo apresentados.
Organização do projeto:
Neste item deve se deixar claro como cada documento que compõe o 
projeto será identificado. Isto pode mudar de projeto para projeto. Mas, a forma 
de identificação da documentação deve ser padronizada e conhecida por todos. 
Para ver um exemplo, verifique o slide de aula.
Neste campo informa-se também como suas alterações (mudanças) serão 
registradas. No P15, como padrão, recomenda-se utilizar um quadro de alterações 
em cada documento.
Registra-se como as mudanças realizadas serão comunicadas aos 
stakeholder’s e como eles terão acesso aos documentos mais recentes e 
Gestão de Projetos 13
Volte ao Sumário
atualizados. E, finalmente, deve-se informar como toda a documentação do 
projeto será organizada.
Gerenciamento das mudanças:
Neste parte do plano é importante definir todos os procedimentos que 
serão adotados para quando houverem necessidades de mudanças. De forma 
que qualquer participante do projeto entenda como deve proceder para realizar 
alterações no projeto.
Não existe um procedimento padrão para mudanças. Ou seja, a forma de 
gerenciar mudanças, difere de projeto para projeto, tendo em vista que cada um 
tem suas próprias necessidades que devem ser respeitadas.
De qualquer forma, algumas orientações importantes podem ser oferecidas:
• Informe quais são as partes interessadas que podem fazer solicitações demudanças 
no projeto;
• Inclua como as mudanças poder ser solicitadas. Isto vai desde opreenchimento de 
uma formulário padrão criado especificamente para isto, asolicitações por email, 
quando o projeto for pequeno, memorando, carta, sistemade gerenciamento de 
projetos da empresa, por meio da intranet ou qualquer outra forma. O importante é 
deixar claro como as mudanças serão solicitadas.
Defina quem vai avaliar os pedidos de mudanças. Pode ser uma única 
pessoa ou até um comitê. O papel da avaliação das solicitações de mudanças 
é compreender de que forma a mudança afeta as diversas áreas do projeto, 
como por exemplo: se for pedido mais dois meses de prazo para findar o projeto; 
podese avaliar de que forma isto vai impactar no escopo (produto), nos custos, na 
qualidade etc. Esta avaliação deve ser feita por escrita e emitido um parecer;
• Informe quem autoriza as solicitações de mudanças que, neste caso, novamente 
pode ser feita por uma única pessoa ou por um comitê. Isto depende das necessida-
des do projeto. A autorização podeseguir nível de autoridade e é feita com base no 
parecer que foi emitido na avaliação da solicitação de mudança;
• Indique, ainda, os procedimentos para registrar as mudanças e quem será o respon-
sável.
 Os procedimentos de organização e gerenciamento das
mudanças podem variar de projeto para projeto. O importante
é que os mesmos fiquem formalmente esclarecidos.
Fique atento
Gestão de Projetos 14
Volte ao Sumário
4. DEFINIR O ESCOPO
Este processo faz parte do grupo de “Planejamento e é da área 
deconhecimento “Escopo. Portanto, trata de como o projeto vai ser realizado e o 
que especificamente vai entregar nas suas diversas fases e ao término. O processo 
(passo) de definir o escopo gera como saída/resultado o documento Declaração 
de Escopo do Projeto
É importante que fique claro para você o termo escopo. Se der uma olhada no 
dicionário, vai perceber que escopo tem haver com limites, abrangência. Ou seja, 
este passo do projeto, tem o intuito primário de assegurar que todo o trabalho do 
projeto seja feito e somente o trabalho necessário para realizar o projeto. A ideia é 
não desperdiçar esforço.
Quando o GP cria mais requisitos (características/condições) do que 
foi solicitado, chama- se a isto de Gold Plating, trabalho supérfluo. Pois, é 
responsabilidade do GP atender exatamente aos requisitos do projeto. Nem 
mais, nem menos. Quando o gerente entrega mais do que foi pedido, de fato, ele 
desperdiçou tempo e dinheiro de seu cliente e/ou sponsor.
Quando se fala em escopo está-se tratando do produto do projeto e do 
esforço para construí-lo. A declaração de escopo, resultado do passo definir o 
escopo, tem as seguintes informações em seu conteúdo:
4.1. DESCRIÇÃO DO ESCOPO DO PROJETO:
Este campo, a fim de facilitar o entendimento, pode-se considerar que é um 
refinamento detalhado do campo “Requisitos de alto nível e descrição do projeto” 
do termo de abertura. A diferença singular é que agora a descrição precisa ser 
bem mais detalhada.
Descreva como o projeto vai ser realizado e como será o produto do 
projeto com todos os seus requisitos/características identificados. Para que os 
requisitos do projeto sejam descritos a contento. É necessário que o GP traduza 
as expectativas e necessidades levantadas que constam no documento “Registro 
dos stakeholders” e inclua neste campo as informações como requisito.
Ao redigir a descrição do escopo do projeto, o GP pode retornar aos 
stakeholders, a fim de obter mais detalhes sobre as suas necessidades de requisitos, 
assim como, esclarecer dúvidas. De forma, que a descrição seja um retrato fiel do 
que se deseja para o projeto e seus resultados.
Gestão de Projetos 15
Volte ao Sumário
4.2 CRITÉRIOS DE ACEITAÇÃO:
Os critérios de aceitação são todas as exigências para que o projeto seja 
aceito.
Inclua todos os critérios, ou seja, os requisitos essenciais para que o projeto 
seja aceito ao seu final. De fato, este item também é semelhante a item do termo 
de abertura denominado “Requisitos para aprovação do projeto”. Mais uma vez, 
ele deve conter mais detalhes do que os constantes no termo de abertura.
4.3 EXCLUSÕES DO PROJETO (ESCOPO NÃO INCLUÍDO):
É comum na maioria dos projetos que muitos pontos do escopo fiquem 
obscuros ou não estejam completamente claros para todas as partes. Requisitos 
que para o cliente ou sponsor sejam parte implícita da entrega do resultado, 
podem não ser para o time do projeto.
Nestas situações, a melhor medida que o GP deve tomar para evitar 
confusões e atropelos quanto ao que faz ou não parte do projeto, é indicar as 
exclusões do mesmo. Em outras palavras, deixar claro o que não será feito e nem 
entregue. Dirimindo todas as dúvidas possíveis. Veja exemplos nos slides de aulas 
disponibilizados.
4.4 RESTRIÇÕES:
São fatores que, de alguma forma, limitam ou dificultam a realização projeto. 
E que, portanto, precisam ser conhecidos, para que possam ser eficazmente 
gerenciados.
As restrições pode ser das mais diversas formas, mas não se limitando a: 
tempo, recursos humanos, físicos ou financeiros. Como exemplo, pode-se citar: 
cronograma extremamente apertado para ser cumprido, normas e políticas da 
organização ou governamentais.
É importante lembrar que as restrições são fatores que já estão acontecendo, 
desta forma, ocorrem no presente. Diferente dos riscos que ocorrem no futuro. 
Além do que as restrições são uma constatação do que já está acontecendo, 
enquanto que os riscos são uma possibilidade.
Exemplos de restrições:
• O tempo para a realização do projeto está muito apertado, em função da data máxi-
ma de entrega do projeto, solicitada pela diretoria, para o dia xx/xx/xxxx;
• Não há mão-de-obra qualificada, na cidade, para a implementação da tecnologia 
base do projeto.
Gestão de Projetos 16
Volte ao Sumário
4 .5 PREMISSAS:
São eventos ou condições consideradas verdadeiras pela equipe do 
projeto que servem para identificar o cenário do projeto com o qual a equipe de 
gerenciamento terá que lidar.
São vitais para entender o contexto do projeto, o que está acontecendo em 
seu entorno, de forma que as ações que serão definidas para o projeto, dependem 
do entendimento destas premissas. De fato, por meio das premissas, o GP pode 
entender o cenário que o projeto está inserido e com isto tomar decisões acertadas.
Um exemplo interessante para entender melhor o conceito é avaliar as 
seguintes premissas para um projeto de construção de uma casa: a) “O cliente 
entregará o terreno limpo na data X para o início da obra”, b) “O cliente não 
entregará o terreno limpo na data X para o início da obra”. Veja que a forma como 
o projeto será conduzido depende da premissa. Caso a premissa para o projeto 
seja “a”, o GP não precisará contratar mão de obra e recursos para fazer a limpeza 
do terreno, visto que o mesmo já será entregue pronto para o início das obras. 
Entretanto, caso a premissa seja a “b”, as decisões para o projeto e, portanto, a 
forma como ele vai ser conduzido é totalmente diferente, tendo em vista que o 
terreno precisará de uma limpeza completa, antes que a obra seja iniciada.
Desta forma, conhecer as premissas do projeto é fundamental para o GP 
conduzir o andamento do projeto. Pois, o caminho a ser seguido deverá estar de 
acordo com as premissas levantadas.
Caso o GP e sua equipe não venham a compreender eficazmente quais as 
premissas que circundam o projeto, com certeza incorrerão em erros, pois as 
mesmas são base para a tomada de decisão coerente do que vai ser feito e como 
vai ser feito.
Outros exemplos de premissas:
• O departamento de RH fornecerá, dois estagiários até o dia XX/XX/XXXX, para que 
sejam utilizados pela equipe de projeto;
• A equipe do projeto estará motivada e participativa durante toda a execução do pro-
jeto
• O departamento de T.I. da empresa disponibilizará o seu laboratório para a realização 
dos testes com o protótipo;
• A taxa de câmbio está muito alta;
• Estamos em período de chuvas torrenciais que se estenderá até o mês X.
Verifique que estas informações apresentadas nos exemplos acima são 
determinantes para as decisões que serão tomadas. Veja que se ao contrário do 
que foi colocado, o departamento de T.I. da empresa não disponibilizasse seu 
laboratório, a forma como os testes com o protótipo seriam realizados, mudariam 
a forma como o projeto seria conduzido, inclusive obrigando o GP a alugar ou 
mandar o protótipo para teste em laboratórios terceirizados.
Gestão de Projetos 17
Volte ao Sumário
Não se assuste, é comum se ter uma certa dificuldade quando se começa a 
usar premissas. Tendo em vista, a falta de costume com o conceito. Entretanto, 
a prática continuada deixará você mais seguro. Procure, apenas, lembrar da 
importância que elas tem e use sempre para refinar o seu nível de compreensão.
Não confunda premissas com riscos. Premissas são certezas, ou pelo menos, 
condições consideradas verdadeiras pela equipe do projeto, enquanto
riscos são incertezas; Além do que, premissas podem estar no presenteou 
no futuro e riscos, apenas, eventos futuros; 
Fique atento
Gestão de Projetos 18
Volte ao Sumário
5. CRIAR A ESTRUTURA ANALÍTICA DO PROJETO – EAP
Este processo (passo) faz parte do grupo de processos “Planejamento” e da 
área de conhecimento “Escopo”. E como saída tem dois documentos: a própria 
EA da EAP.
PROGRAMA DE CAPACITAÇÃO 
GERENCIAL
LNT
Metodologia
Aplicação
Diagnóstico Organizacional
Datas/Carga horária
Escolha dos facilitadores
Metodologia da divulgação
Aprovação
Ação
Logística
Aula Inaugural
Prestão de Contas
Relatório Final
CONSTRUÇÃO 
DO PCG
DIVULGAÇÃO EVENTO ENCERRA-
MENTO
A EAP é uma das ferramentas mais importantes para o GP e sua equipe. 
Pois, possibilita um entendimento visual do que vai ser feito, de forma que todos 
possam compartilhar e compreender o produto que vai ser entregue ao longo do 
projeto. É uma apresentação gráfica de todo o trabalho que vai ser realizado ao 
longo do projeto, mostrando suas as fases e sua decomposição em componentes 
menores e, portanto, mais fáceis de gerenciar e entender.
É a base para uma série de estimativas, tais como: na criação das atividades 
do cronograma e nos custos do projeto.
Para que você possa compreender uma EAP, vou lhe apresentar a forma 
como se faz a leitura:
a) Primeiramente, uma EAP é dividida em níveis. Fazendo a leitura de cima 
de para baixo, temos mais acima o nível 0 (zero), também chamado de nível de 
projeto. Deve ser representando normalmente pelo título do projeto ou o produto 
que será entregue;
b) O segundo nível (de cima para baixo) é composto pelas fases do projeto. 
Lembre-se, assim como as pessoas, que passam por diversas fases em sua 
vida, os projetos também tem suas fases. Veja no exemplo acima, para o projeto 
de um “Ciclo de Palestras”, há as seguintes fases: Local, Programação, Inscrição, 
Divulgação, Evento e Encerramento. Cada fase representa um esforço necessário 
a ser empreendido para a realização do ciclo de palestras. As fases apresentam 
Gestão de Projetos 19
Volte ao Sumário
uma visão macro do que vai ser feito;
c) Ao último nível de uma EAP, chama-se pacote de trabalho. As atividades 
que serão incluídas no cronograma, uma ferramenta que discutiremos mais a 
frente, são tiradas de dentro dos pacotes de trabalho da EAP. Cada pacote tem 
pelo menos duas atividades;
d) Entre o nível 1 (fases) e o último (pacotes de trabalho), podem haver diversos 
níveis, denominados de subfases ou entregas. A quantidade de níveis que uma 
EAP pode ter, depende da necessidade de entendimento da equipe do projeto. 
Pois, cada componente é decomposto o quanto for necessário para melhorar o 
entendimento do que vai ser feito, ou seja, o trabalho que será realizado.
Agora que você já sabe como fazer a leitura de uma EAP, lhe apresentarei 
algumas regras que são necessárias compreender, portanto, preste atenção a:
a) Cada componente de uma EAP (os retângulos que representam as fases, 
entregas e pacotes de trabalho) deve ser escrito com palavras substantivas. 
Quanto menor a expressão usada para descrever o componente, melhor;
b) Uma EAP não precisa obrigatoriamente ter para cada fase o mesmo número 
de níveis. Uma fase pode ser decomposta mais de que outra. Por exemplo, para 
a fase local, você poderia decompor em dois níveis, já a fase evento poderia ser 
decomposta em 5 níveis;
c) Cada componente deve ser decomposto em pelo menos dois ou mais 
novos componentes;
5.1. DICIONÁRIO DA EAP
É o documento que tem como finalidade principal explicar a EAP, por meio 
da descrição de uma série de informações dos pacotes de trabalho.
Em um dicionário da EAP só deve entrar pacotes de trabalho. Não se coloca 
fases e subfases. Visto que, ao se explicar um pacote, por consequência se estar 
explicando o seu nível mais acima.
Basicamente, um dicionário da EAP, utilizando a metodologia P15, tem 4 
colunas:
a) A primeira é o número que id ntifica cada pacote de trabalho, de acordo 
com a EAP;
b) Na segunda coluna temos o nome de cada pacote, da mesma forma como 
está escrito na EAP;
c) A coluna descrição é o local em que vai ser informado como a atividade deve 
ser desempenhada, os cuidados a serem tomados, orientações a serem seguidas. 
Imagine que você peça a alguém para alugar um casa para a sua moradia, o que 
você diria para que o encarregado da tarefa fizesse da forma que lhe agradasse. 
Gestão de Projetos 20
Volte ao Sumário
Ou seja, esta coluna tem este intuito, deixar claro o que vai ser feito e como;
d) Na última coluna, critérios de aceitação, deve-se informar quais os 
requisitos (condições) para que o pacote executado seja considerado aceito. Ou 
seja, quais os critérios obrigatórios que devem ser atendidos, sem quais o pacote 
não será aceito como terminado.
Fique atento:
• Sempre que decompor uma EAP, divida o componente decomposto em pelo me-
nos mais dois, mas pode ser três, quatro e assim por diante. Mas, não menos que 
dois. Memorize isto;
• Lembre-se que em uma EAP os seus componentes são escritos com palavras subs-
tantivas;
• Em um dicionário da EAP só se coloca pacotes de trabalho. Deixe as fases, subfases 
e entregas do lado de fora;
• Em uma EAP não se apresenta atividades, apenas os pacotes que contém as ativida-
des que serão inseridas no cronograma;
• Para fazer uma EAP é neces ário checar modelos de EAP’s de outros projetos seme-
lhantes que já foram feitos pela organização ou outras, consultar e pecialistas, discu-
tir com a equipe de gerenciamento do projeto e, acima de tudo, procurar entender o 
trabalho que se precisa realizar.
Gestão de Projetos 21
Volte ao Sumário
6. DESENVOLVER O CRONOGRAMA
Este processo (passo) faz parte do grupo de processos “Planejamento” e da 
área de conhecimento “Tempo”.
Após concluída a EAP e o seu dicionário, é possível, finalmente, desenvolver 
o cronograma do projeto que é um gráfico que apresenta as atividades que serão 
realizadas no projeto ao longo do tempo. Para efeito do P15, o modelo que é 
utilizado também é conhecido como Gráf co de Gantt ou gráfico de barras.
Repare que o nosso modelo tem 4 colunas. Na primeira, assim como no 
dicionário da EAP, há o número que identifica cada elemento do cronograma: 
fases, subfases, pacotes e atividades.
Na segunda coluna, denominada de atividade, de fato, há mais que atividades. 
Aqui, coloca-se além das atividades, todos os componentes da EAP. Estando as 
atividades aparecendo dentro dos pacotes.
A coluna seguinte é a do responsável pela atividade. Isto não quer dizer que é 
a pessoa que executará a atividade, e, sim, quem responderá pela mesma.
Se você desejar, pode abrir mais uma coluna na sequência para colocar os 
executores. De fato, este é um modelo simplificado de cronograma que atende 
ao nosso objetivo. Mas, é passível, de acordo com a necessidade do projeto, da 
inclusão de mais informações.
A última coluna ou área é o local em que aparece os períodos que as atividades 
serão executadas. É nesta área que aparece o gráfico de barras indicando quando 
cada atividade começa e termina.
As atividades que aparecem no cronograma são pensadas com base nos pacotes de trabalho que 
constam na EAP. Para cada pacote de trabalho deve haver duas ou mais atividades no cronograma. 
De fato, coloque quantas atividades forem necessárias para que o pacote seja realizado a contento
Fique atento
Note que todos os elementos da EAP são inseridos no cronograma. Em seguida, inclua as atividades 
embaixo da linha de cada pacote; 
Fique atento
Nunca use “X” no lugar do gráfico de barras. Isto é um erro. Inclua, apenas, barras para de-
monstrar quando as atividades serão realizadas;
Fique atento
Gestão de Projetos 22
Volte ao Sumário
7. DETERMINAR O ORÇAMENTO
Este processo (passo) faz parte do grupo de processos “Planejamento” e da 
área de conhecimento “Custos”.
Todo projeto necessita de recursos financeiros para que possam ser realizados. 
Portanto, a elaboração de um orçamento é fundamental para que os requisitos 
sejam cumpridos.
Apesar de já ter sidofeito um orçamento sumarizado no Termo de Abertura 
do Projeto, agora se faz necessário refinar as informações. Incluir detalhes 
não previstos no orçamento sumarizado. Entretanto, lembre-se que o custo 
total indicado no termo de abertura deve bater com o valor total encontrado 
no orçamento do projeto. No caso de haver uma diferenciação, o orçamento 
sumarizado que consta no Termo de Abertura, deve ser atualizado.
O orçamento do projeto deve conter todos os custos que serão incorridos. 
Para tanto, o GP e sua equipe deve ter como base os custos de cada pacote de 
trabalho. Ou seja, para facilitar e melhorar a estimativa de custos, assim como 
as atividades que foram retiradas dos pacotes de trabalhos, os custos seguem 
os mesmos exemplos. Pois, é mais fácil pensar nos custos olhando para os 
componentes decompostos da EAP.
Cheque os custos de outros projetos semelhantes feitos na sua empresa 
ou em outras que você tenha acesso, busque opinião especializada, consulte 
potenciais fornecedores e estime os custos dos seus projeto tendo como base 
o esforço que será desprendido analisando cada pacote de trabalho da EAP. 
Pois, é muito mais fácil, por exemplo, descobrir quanto será gasto com material 
de expediente em um pacote do que no projeto todo. Desta forma, você pode 
somar os gastos com material de expediente de cada pacote para ter o custo total 
da conta no seu orçamento. Simples, assim.
Para cada custo presente no seu orçamento, veja a figura exemplo acima, 
você deve incluir os seus gastos levando-se em consideração quando os mesmos 
serão, de fato, efetivados. Repare que se somar as linhas horizontais, terá o custo 
total por conta e se somar as linhas verticais, terá o custo total por período.
Utilize os pacotes de trabalho da EAP para melhorar a
sua estimativa do orçamento;
Fique atento
Gestão de Projetos 23
Volte ao Sumário
O modelo proposto para uso de orçamento no P15 apresenta uma formatação simplificada. Para 
projetos que requeiram mais detalhes, você pode incluir novas especificação necessárias.
Fique atento
Gestão de Projetos 24
Volte ao Sumário
8. PLANEJAR A QUALIDADE
Este processo (passo) faz parte do grupo de processos de “Planejamento” e 
da área de conhecimento “Qualidade”.
O primeiro ponto para entender o planejamento de qualidade é compreender 
como o Project Management Body of knowledge - PMBOK define qualidade. 
Para o mesmo, qualidade é atender aos requisitos do projeto. Ou seja, é cumprir o 
que foi prometido. Nem mais, nem menos. Quando o GP entrega um produto com 
requisitos a mais do que foi solicitado, ele está praticando Gold Plating (trabalho 
supérfluo) e, portanto, desperdiçou recursos desnecessários dos stakeholder’s.
Para garantir e controlar a qualidade do projeto e com isto atender aos 
requisitos propostos, você deve criar o “Plano de Gerenciamento da Qualidade”, 
um documento que tem como base um quadro denominado de “Requisitos da 
Qualidade”. Basicamente contém 4 colunas, a saber:
a) A primeira coluna trata dos aspectos da qualidade que serão gerenciados. 
Ou seja, os principais aspectos que irão afetar decisivamente a qualidade do projeto 
empreendido. No caso do projeto exemplo “Ciclo de Palestras”, alguns aspectos 
importantes a serem gerenciados são: palestrantes, segurança, auditório que será 
realizado a palestra, estacionamento etc. A lógica é reunir a equipe do projeto e 
definir quais os principais aspectos a serem tratados no projeto em questão, a fim 
de garantir que os requisitos sejam plenamente atendidos;
b) Para cada aspecto definido na primeira coluna, é necessário informar 
na segunda coluna, “Requisitos de Aceitação”, quais os critérios mínimos para 
aceitação dos aspectos. Por exemplo, se o palestrante é um aspecto importante 
para a qualidade do projeto, deve-se definir qual o requisito para aceitar o 
palestrante. Neste caso, pode dizer que todos devem ter nível de pós-graduação 
ou experiência de X anos no temas que vai proferir. Ou seja, o GP e sua equipe 
precisam definir os requisitos de aceitação para cada aspecto definido;
c) Não basta ter o aspecto e o requisito de aceitação, é necessário, sem 
dúvida, definir, ainda, qual o método de verificação (terceira coluna) será utilizado 
para checar se os requisitos estão sendo cumpridos. Não basta informar que o 
projeto pede um palestrante com X anos de experiência, é fundamental informar 
que será mensurada a informação. Para este exemplo do palestrante, o método 
poderia ser checar o seu currículo de os documentos com cópia autenticada;
d) E, por último, deixa-se claro quem será o responsável por verificar e 
controlar se o requisitos de aceitação do aspecto estão sendo atendidos 
Gestão de Projetos 25
Volte ao Sumário
 Você pode repetir um mesmo aspecto várias vezes e definir para cada um
os seus requisitos de aceitação. Veja o exemplo do palestrante no quadro acima;
Fique atento
Reuna (no caso de você ser o GP) com a sua equipe, por meio de um brainstorming ou ouvindo 
opinião especializada, para relacionar os principais aspectos a serem considerados para a qualida-
de do projeto. Lembre-se de consultar também outros projetos semelhantes realizados.
Fique atento
Gestão de Projetos 26
Volte ao Sumário
9. DESENVOLVER O PLANO DE RECURSOS
O plano de gerenciamento dos recursos é o componente do plano de 
gerenciamento do projeto que fornece orientação sobre como os recursos 
do projeto devem ser classificados, alocados, gerenciados e liberados. Pode 
ser dividido em plano de gerenciamento da equipe e plano de gerenciamento 
dos recursos físicos, de acordo com as especificidades do projeto. O plano de 
gerenciamento dos recursos pode incluir, mas não está limitado a:
Identificação dos recursos.
Métodos para identificar e quantificar os recursos físicos e de equipe 
necessários.
Adquirir recursos.
Orientação sobre como adquirir recursos físicos e de equipe para o projeto.
Papéis e responsabilidades:
Papel.
A função assumida ou a ser designada a uma pessoa no projeto.
Exemplos de papéis de projeto são engenheiro civil, analista de negócios e 
coordenador de testes.
Autoridade.
O direito de aplicar recursos do projeto, tomar decisões, assinar aprovações, 
aceitar entregas e influenciar outras pessoas para executar o trabalho do projeto. 
Exemplos de decisões que precisam de autoridade clara incluem a seleção de um 
método para concluir uma atividade, critérios para aceitação da qualidade e como 
responder às variações no projeto. Os membros da equipe atuam melhor quando 
seus níveis de autoridade individuais correspondem às suas responsabilidades 
individuais.
Responsabilidade.
As obrigações e o trabalho que se espera que um membro da equipe do 
projeto execute para concluir as atividades do projeto.
Competência.
A habilidade e a capacidade necessárias para concluir as atividades designadas 
dentro das restrições do projeto. Se os membros da equipe do projeto não têm as 
competências necessárias, o desempenho pode ser prejudicado. Quando essas 
incompatibilidades são identificadas, respostas proativas tais como treinamento, 
Gestão de Projetos 27
Volte ao Sumário
contratação, mudanças no cronograma ou mudanças no escopo são iniciadas.
Organogramas do projeto.
Um organograma do projeto é uma exibição gráfica dos membros da equipe 
do projeto e suas relações hierárquicas. Pode ser formal ou informal, altamente 
detalhado ou amplamente estruturado, dependendo das necessidades do 
projeto. Por exemplo, o organograma do projeto para uma equipe de resposta a 
desastres com 3.000 pessoas terá mais detalhes do que um organograma de um 
projeto interno com 20 pessoas.
Gerenciamento dos recursos da equipe do projeto.
Orientação sobre como os recursos da equipe do projeto devem ser definidos, 
mobilizados, gerenciados e, por fim, liberados.
Treinamento. 
Estratégias de treinamento para membros de equipes. Desenvolvimento de 
equipes. Métodos para desenvolver a equipe do projeto. Controle de recursos. 
Métodos para garantir que recursosfísicos adequados estejam disponíveis 
conforme necessário e que a aquisição de recursos físicos seja otimizada para as 
necessidades do projeto. Inclui informações sobre gerenciamento de estoques, 
equipamentos e suprimentos durante o ciclo de vida do projeto.
Plano de reconhecimento.
Quais reconhecimentos e recompensas serão concedidos aos membros da 
equipe, e quando estes serão concedidos.
Gestão de Projetos 28
Volte ao Sumário
10.PLANEJAR AS COMUNICAÇÕES
Este processo faz parte do grupo de processos de “Planejamento” e da área 
de conhecimento “Comunicações”.
Talvez a maioria dos projetos negligencie o gerenciamento eficaz da 
comunicação. Um erro que pode custar caro. Pois, a comunicação eficaz está 
na base do sucesso do projeto. Portanto, deve ser planejada e adequadamente 
executada além de controlada, a fim de que todos os stakeholders tenham suas 
expectativas atendidas.
O plano de gerenciamento das comunicações, resultado do passo planejar 
o gerenciamento das comunicações, tem as seguintes informações em seu 
conteúdo:
Matriz de comunicação do projeto:
A matriz de comunicação do projeto tem as seguintes informações em cada 
uma de suas colunas:
a) Documento: informe o tipo de documento que será gerado para manter 
informados os stakeholders do projeto. Alguns documentos comuns que 
normalmente qualquer projeto utiliza são: Status Report, Cronograma de marcos 
de controle, Relatório de Avaliação de Desempenho, Relatório de Encerramento 
do Projeto e Atas de Reunião. Muitos outros podem e devem ser criados. Estes 
são apenas algumas sugestões padrões;
b) Formato: nesta coluna defina como será a apresentação do documento 
que poder ser: impresso (forma tradicional) ou digital (e-mail, página web na 
intranet da empresa, arquivos PDF etc);
c) Responsável: defina quem será o responsável para que elaboração e o 
envio das informações sejam feitas de forma adequada e no momento estipulado;
d) Destinatário; informe o nome ou o cargo/função dos stakeholders que 
receberão as informações;
e) Periodicidade: inclua quando cada informação deverá ser enviada.
Calendário de reuniões:
É comum, ao iniciar a execução de um novo projeto, que muita das reuniões 
que acontecerão sejam previstas. A estas chamamos de reuniões ordinárias. Sendo 
assim, crie um calendário específico para informar quando, a pauta, o responsável 
e quais os participantes de cada reunião. Pois, com um calendário previamente 
criado, as chances de sucesso nas reuniões aumentam consideravelmente, pois 
Gestão de Projetos 29
Volte ao Sumário
as datas já estarão devidamente programadas, oportunizando a cada participante 
se preparar com informações necessárias e se agendar corretamente, diminuindo 
as possibilidades de ausências imprevistas. Veja modelo de calendário no slide 
disponibilizado da aula.
Para saber que informação mandar para cada stakeholder, você precisa conversar com cada um e 
perguntar. Não existe outro jeito mais eficiente! Portanto, pergunte, pergunte e depois pergunte 
novamente. Ajude-o a descobrir quais informações precisa ao longo do projeto.
Fique atento
Gestão de Projetos 30
Volte ao Sumário
11.PLANO DE GERENCIAMENTO DE RISCOS
Este processo faz parte do grupo de processos de “Planejamento” e da área 
de conhecimentos “Riscos”.
O gerenciamento eficaz dos riscos do projeto é vital para que o GP aproveite 
melhor seus recursos evitando ou mitigando ameaças potenciais e aproveitando 
adequadamente oportunidades que possam economizar recursos como tempo, 
dinheiro e mão de obra. Apesar da necessidade de lidar com riscos seja uma 
necessidade preemente, são é comum ver projetos que usam ferramentas e 
técnicas para tratar os riscos de forma proativa. Um erro que pode custar caro ao 
GP e a todos os stakeholders envolvidos.
Se gerenciar riscos é tão importante, aproveite para aprender um pouco mais 
sobre o assunto. Primeiramente, entendendo o seu conceito.
Riscos são eventos futuros que podem ou não acontecer e, portanto terão 
consequências positivas ou negativas no projeto. Os riscos do projeto são sempre 
futuros. Por isto, não confunda com restrições. Estas últimas são fatores que estão 
no presente. Já existem.
A finalidade do gerenciamento de riscos é aumentar a probabilidade e o 
impacto das oportunidades no projeto (eventos positivos), enquanto reduz a 
probabilidade e o impacto de ameaças ao projeto (evento negativo). 
Portanto, podemos concluir que o gerenciamento de riscos é todo o esforço 
de planejar, identificar, analisar, responder e monitorar os riscos ao longo do 
projeto, no intuito de aumentar a probabilidade e o impacto das oportunidades 
no projeto (eventos positivos), e reduzir a probabilidade e o impacto de ameaças 
ao projeto (evento negativo).
Talvez, quando você pense em risco, a primeira coisa que venha em sua mente 
é uma situação ou evento de cunho negativo. Entretanto, assim como existem 
riscos negativos, aqui chamados de ameaças, também existem riscos positivos, 
então chamados de oportunidades. Veja abaixo exemplos de riscos positivos:
• Se pudermos combinar os pedidos do equipamento xyz para comprar mais de 20 
itens de uma só vez, ficará 20% mais barato que o planejado;
• ●Se oferecermos um treinamento para melhorar a eficiência, o pacote de trabalho 
número 3.4 poderia ser completado dois dias antes do esperado.
Repare que assim como o esforço de mitigar ou evitar que um risco negativo 
aconteça, o mesmo esforço deve ser aplicado para aproveitar oportunidades ao 
longo do projeto e com isto gastar um pouco menos, ganhar tempo, melhorar a 
qualidade e a satisfação do cliente e do sponsor e muitas outras benesses advindas.
Gestão de Projetos 31
Volte ao Sumário
Para que você possa gerenciar os riscos de seu projeto, entenda o conceito 
de fatores de ricos, pois eles serão vitais no seu planejamento. Todo risco tem pelo 
menos dois fatores importantes a saber: probabilidade e impacto. A probabilidade 
tem a haver com a possibilidade do risco acontecer. Vejamos o caso de um voo 
de avião, qual a probabilidade de acontecer uma queda? A resposta poderia ser 
baixa, média ou alta. Ou ainda, 1%, 5% e assim por diante. Mas, os riscos além de 
probabilidade tem outro fator a ser levado em consideração, o impacto. Se vier a 
acontecer de que forma vai afetar o andamento do projeto? Neste caso, de acordo 
com a avaliação, pode-se dizer: baixo, médio ou alto. Ou ainda, ser mais específico 
e dizer que caso o risco X venha a acontecer terá um impacto nos custos do projeto 
em 5 mil reais, ou um impacto no tempo provocando um atraso de 3 meses na 
atividade Y e assim por diante.
O plano de gerenciamento dos riscos, resultado do passo planejar o 
gerenciamento dos riscos, tem as seguintes informações em seu conteúdo:
Riscos causas-raís
[inserir riscos neste espaço] [inserir causas-raíz neste espaço)
idem idem
Matriz de riscos x causas:
Nesta parte de seu plano, inclua todos os riscos levantados por você e sua 
equipe. Para tanto, comece com a revisão de toda documentação de seu projeto, 
procurando por potenciais fontes de riscos, verifique outros projetos semelhantes 
e seus riscos incorridos, consulte especialistas da área, publicações e termine com 
um brainstorming com sua equipe. Todos os riscos levantados devem ser postos 
na matriz de riscos x causas, informando também, além dos riscos, suas causasraiz. 
Ou seja, a situação que pode ocasionar o risco. Isto será importante mais a frente 
quando você precisar criar ações para responder aos riscos.
Matriz de avaliação de riscos:
Inclua no seu plano esta mesma matriz de avaliação de riscos, apresentada 
a você neste material. Existem outros modelos, mas para o nosso objetivo esta é 
suficiente.
Como o próprio nome diz, ela serve para que você avalie cada risco registrado 
na matriz de riscos x causas, apresentada há pouco.
Repare que ela tem na vertical e horizontal os fatores de riscos representados: 
impacto e probabilidade, respectivamente. E uma série de quadrantes oriundos 
do cruzamentodestes fatores. Os quadrantes podem ser risco nulo, baixo risco, 
médio risco e alto risco.
Gestão de Projetos 32
Volte ao Sumário
IM
PA
CT
O
PROBABILIDADE
ALTO
MÉDIO
BAIXO
Baixo
Risco
Médio
risco
Alto
risco
Médio
risco
Médio
risco
Risco
Nulo
Baixo Médio Alto
Baixo risco
O que será feito é o cruzamento dos fatores probabilidade vs impacto. Como 
resultado teremos o nível do risco, dado pelos quandrantes. Rememorando, 
quando você cruza probabilidade com impacto, encontra o nível do risco que de 
fato é o que se quer saber (mais à fente explico o porquê, fique calmo!!!
Pegue cada risco da matriz riscos x causas e juntamente com a sua equipe de 
gerenciamento do projeto, identifique a probabilidade (baixa, média ou alta).
Para o mesmo risco, indentifique o seu impacto (baixo, médio ou alto) e cruze 
traçando uma linha imaginária na vertical para a probabilidade e na horizontal 
para o impacto. O quadrante que as linhas imaginárias se encontrarem, você 
terá o nível de risco. Vamos ao exemplo: No caso do risco de acidente no voo de 
avião discutido anteriormente; suponha que sua probabilidade seja baixa (como 
de fato é mesma) e que o seu impacto é alto (imagine o porquê do impacto ser 
alto ), ao cruzarmos as linhas imaginárias, o quadrante que as linhas se encontram 
infoma que o nível deste risco é “baixo risco”. Então, repita o procedimento para 
cada risco identificado e inclua as respostas no “quadro de análise de riscos” que 
vou explicar, em seguida.
Quadro de análise de riscos:
RISCO PROBABILIDADE IMPACTO PROBABILIDADE
Não conseguir autorização 
da faculdade para montar 
os stands na quadra pronci-
pal da faculdade
Baixa Alta Baixa
Atraso na montagem dos 
stands
Alta Médio Médio
Idem Idem Idem Idem
Gestão de Projetos 33
Volte ao Sumário
Preencher este quadro é muito fácil, simplesmente inclua o resultado de sua 
avaliação de riscos feita com base na matriz de avaliação de riscos já explicada e 
inclua suas informações no quadro apresentado acima.
Matriz de respostas aos riscos:
Riscos Níveis Estratégia Respostas
Ausência dos palestrante 
durante o ciclo de palestras
Alto Mitigar - Definir palestrante subs-
tituto
- Negociar contrato de so-
breaviso
- Entrar em contato para a 
substituição, para o caso de 
ausência de palestrante
Falta de energia elétrica 
durante a realização do 
evento
Médio Transferir - Negociar cláusula con-
tratual com o fornecedor 
do espaço alugado para a 
realização do evento, a fim 
que fique na sua responsa-
bilidade a contratação de 
equipamento gerador de 
energia
Atraso na confecção do 
formulário de inscrição
Alto Evitar - Solicitar impressão de 
formulários para a gráfica 
com prazo de antecedência 
de um mês do início do 
período de inscrição
Atraso no serviço de coffe-
-break
Médio Aceitar passivamente
Insatisfação com a qualida-
de da exposição de algum 
palestrante convidado
Alto Aceitar ativamente - Oferecer desconto no va-
lor pago para os próximos 
evento
 
Muito bem, neste momento de seu planejamento, você já tem todos os 
riscos identificados e avaliados, por isto tem conhecimento do nível de cada risco, 
visto que usou a matriz de avaliação de risco. Mas, é hora de seguir adiante. E na 
verdade, precisa fazer algo muito importante, criar ações (respostas) para os riscos 
com nível médio ou alto. 
ATENÇÃO, VOU REPETIR PARA QUE VOCÊ MEMORIZE: 
não inclua riscos de nível baixo na matriz de respostas aos riscos. Só entram 
riscos de nível médio e alto.
Se, de fato, houver alguma curiosidade dentro de você. Daquelas que 
trazemos desde a infância, estaria me perguntando por que não respondemos 
a riscos de baixo nível? E a reposta à sua curiosidade é mais simples ainda: se for 
Gestão de Projetos 34
Volte ao Sumário
respondido todos os riscos de nível baixo existentes para um projeto, os recursos 
gastos com ele serão maiores que os benefícios advindos. Muito tempo e esforço 
serão empregados para pouco resultado. Então, como técnica adequada para 
lidar com eles, por ora, simplesmente, esqueça-os!
Seguindo em frente, para que possa responder aos riscos de nível médioe 
baixo, é necessário conhecer os tipos de estratégias disponíveis que podem ser 
usadas:
a) Estratégias para riscos negativos:
a.1) Mitigar: quando não é possível evitar que um risco ocorra, pode-se pelo 
menos trabalhar arduamente para reduzir (mitigar) as suas probabilidades de 
ocorrência ou os danos de seu impacto;
a.2) Evitar: esta estratégia é usada quando é possível, por meio de ações 
proativas diretamente nas causas do riscos, evitar que ele aconteça;
a.3) Tranferir: passe para outros, fora do projeto, o dever de gerenciar os 
riscos. Ou seja, terceirize os riscos. Um bom exemplo é caso do seguro do seu 
carro. O problema no caso de uma colisão ou outro tipo de sinistro fica por conta 
da seguradora que recebeu para ficar responsável no caso de ocorrência do risco.
a.4) Aceitar passivamente: é uma estratégia de, simplesmente, deixar que o 
risco o ocorra, pensando no que será feito apenas quando o mesmo acontecer;
a.5) Aceitar ativamente: é uma estratégia de, simplesmente, deixar que o 
risco o ocorra, mas tendo pensado na ação que será desempenhada, logo após 
seu impacto.
a) Estratégias para riscos positivos:
a.1) Ampliar: é exatamente o contrário da estratégia negativa “mitigar”. Ou 
seja, quando não é possível garantir que o risco positivo ocorra, você pode, pelo 
menos, ampliar as chances de acontecer e o impacto de seus resultados;
a.2) Explorar: é uma estratégia para criar ações que garantam que o risco 
aconteça;
a.3) Compartilhar: é uma forma de unir esforços com terceiros para que o 
risco ocorra e seus resultados sejam benéficos a ambos;
a.4) Aceitar passivamente: é uma estratégia de, simplesmente, deixar que o 
risco o ocorra, pensando no que será feito apenas quando o mesmo acontecer;
a.5) Aceitar ativamente: é uma estratégia de, simplesmente, deixar que o 
risco o ocorra, mas tendo pensado na ação que será desempenhada, logo após 
Gestão de Projetos 35
Volte ao Sumário
seu impacto.
Para preencher a matriz de respostas aos riscos, incluar os riscos, seu nível, 
tipo de estratégia que será adotada e a respectiva ação que combine com a 
estratégia adotada.
Depois da matriz de respostas aos riscos tiver sido elaborada. Volte ao seu 
cronograma e inclua as ações de respostas ao riscos. Para tanto, Crie uma fase em 
sua EAP chamada “Gerenciamento do projeto” e inclua o pacote “Riscos”, dentro 
dele, no cronograma, coloque as respostas como atividades, definindo os seus 
respectivos responsáveis.
Não se assuste, o processo de planejamento é extremamente iterativo. Tem 
suas idas e vindas. Você pode voltar para processos já feitos, quantas vezes for 
necessário para ajustá-los. Lembre-se, você ainda está no grupo de planejamento.
Já na fase de execução, deve-se evitar o excesso de mudanças no plano, 
apenas o necessário para manter o projeto no caminho do alcance de seus 
objetivos.
Nunca inclua riscos de nível baixo na sua matriz de respostas aos riscos;
Lembre-se que o quadro de análise de riscos e feito com base nos riscos avaliados na matriz de ava-
liação de riscos. Ou seja, enquanto você está utilizando a matriz de avaliação para cada risco, conco-
mitantemente vá preenchendo o quadro de análise de riscos.
Fique atento
Gestão de Projetos 36
Volte ao Sumário
12.PLANEJAR AS AQUISIÇÕES
Este processo faz parte do grupo de processos “Planejamento” e da área de 
conhecimento “Aquisições”.
Acredite, mas se você planejar todos os outros processos de forma adequada 
e, ainda sim, falhar nas aquisições, o seu projeto irá por água a abaixo.
Os equipamentos, materiais e serviços que seu projeto vai necessitar, 
precisa chegar pelo custo certo, nas especificações exatas e no momento que 
for necessário. Caso uma destas variáveis não aconteça, tudo pode ficar parado, 
atrasar o projeto, estourar os custos, reduzir escopo e, por conseguinte, diminuir 
a qualidade dos resultados a serem entreguesaos stakeholders. Eu sei, eu sei... fui 
um pouco dramático, mas as vezes é necessário para chamar a sua atenção . De 
qualquer forma, atento as aquisições.
O plano de gerenciamento das aquisições, resultado do passo planejar as 
aquisições, tem as seguintes informações em seu conteúdo:
• Especificações de equipamentos, materiais e serviços a serem adquiridos:
Quantidade Equipamento/material Especificações
É necessário que todo equipamento, material ou serviço que será adquirido 
para o projeto, seja minuciosamente descrito com todas as suas especificações 
(veja quadro acima), caso contrário o produto pode vir fora das especificações, 
comprometendo o andamento do projeto.
Sendo assim, não basta apenas informar que deve ser adquirido, por exemplo, 
um computador desktop, é necessário indicar cada detalhe da aquisição, tais como: 
tipo de processador, placa mãe, vídeo, o HD e a sua capacidade, memória, drives, 
acessórios e muitas outras informações determinantes para que o responsável 
pelas aquisições possa fazer da forma correta. Lembre-se que as aquisições 
incluem tanto equipamento, material quanto serviço.
Gestão de Projetos 37
Volte ao Sumário
Condições de fornecimento:
Ter a relação do que será adquirido e suas especificações, sem dúvida, é meio 
caminho andado, mas não é suficiente. É preciso, ainda, deixar claro quais são as 
condições de fornecimento das aquisições. Por exemplo, não basta dizer que tipo 
de computador será adquirido, Também e necessário deixar claro que a aquisição 
deve atender às condições de fornecedores com mais de 10 anos na praça, com 
loja física na cidade, garantia de 2 anos, assistência técnica em 24 horas em caso 
defeito etc.
No exemplo do computador, deixar claro as condições vão garantir que o 
equipamento certo será comprado e quando der problema, em menos de 24 horas 
estará consertado. Notou como as condições de aquisições são tão importantes 
quanto as especificações? Pense nisto, quando tiver planejando o seu projeto.
Depois do seu plano de aquisições tiver sido elaborado. Volte ao seu 
cronograma e inclua as atividades de compra/aquisições, informando quando 
vai ser feita e quem será o responsável. Para tanto, Crie uma fase em sua EAP 
chamada “Gerenciamento do projeto” (se não tiver criado antes) e inclua o pacote 
“Aquisições”, dentro dele, já no cronograma, coloque as atividades, como por 
exemplo: “Adquirir computador XYZ para o teste do protótipo” e assim por diante.
Levante todos as aquisições necessárias e detalhe suas especificações de forma a não 
deixar dúvida quanto aos atributos do que vai ser adquirido. E, lembre-se, as condições 
de fornecimento são tão importantes quanto.
Fique atento
Gestão de Projetos 38
Volte ao Sumário
13.ORIENTAR E GERENCIAR A EXECUÇÃO DO PROJETO
Este processo faz parte do grupo de processos de “Execução” e da área de 
conhecimentos “Integração”.
Gosto sempre de dizer que a execução e consequência dos processos de 
planejamento. Se você planejou correto, não deve ter problemas para colocar em 
prática o que foi decidido.
De forma bem resumida, pode-se dizer que a execução é o processo de 
transformar o plano do projeto no produto/serviço que será entregue.
Para tanto o gerente do projeto – GP deve:
Fazer cumprir o plano do projeto, orientando a equipe, distribuindo as 
atividades do cronograma para todos os membros da equipe e cobrar diariamente 
a sua realização, verificando se o prazo está sendo cumprido dentro do padrão de 
qualidade definido;
Para projetos de menor porte, pode indicar um membro da equipe para 
fazer uma auditoria, a fim de identificar se os padrões de qualidade estão sendo 
cumpridos por meio dos métodos de verificação que constam no item Requisitos 
da qualidade do Plano de Gerenciamento da Qualidade do Projeto.
Cumprir o programa de treinamento previsto no Plano de Gerenciamento 
de RH.
É papel do GP evitar e resolver conflitos ao longo do projeto e cumprir a 
avaliação de desempenho da equipe, repassando o feedback necessário.
Cobrar o envio dos relatórios/documentos previstos na Matriz de Comunicação 
do Projeto que faz parte do Plano de Gerenciamento das Comunicações
Acompanhar os stakeholders para avaliar se suas expectativas estão sendo 
cumpridas. Caso contrário. Solicitar mudanças no projeto.
Providenciar todas as compras e/ou contratações de terceirizados, de acordo 
com o Plano de Gerenciamento das Aquisições.
Gestão de Projetos 39
Volte ao Sumário
14. MONITORAR E CONTROLAR O TRABALHO DO 
PROJETO
Este processo faz parte do grupo de processos de “Monitoramento e controle” 
e da área de conhecimentos “Integração”.
Para monitorar e controlar o trabalho do projeto o GP deve: Acompanhar se 
todos os controles do projeto estão sendo realizados a contento, por exemplo: o 
orçamento do projeto, o cronograma, a matriz de requisitos da qualidade etc.
Manter a documentação do projeto organizada e seguir os procedimentos 
previstos para as mudanças que se tornarem necessárias, de acordo com o Plano 
de Organização e Gerenciamento das Mudanças.
Verificar se o escopo está sendo cumprido. Ao final de cada fase, ir até o 
cliente e/ou sponsor e receber o aceite das entregas formalmente.
Periodicamente, por meio da declaração de escopo, EAP e o dicionário da 
EAP, avaliar se o escopo que está sendo produzido é o escopo que foi planejado. 
Nem mais nem menos.
Diariamente, de preferência, checar se o cronograma está sendo cumprido. 
Caso contrário, providenciar ajustes. Registrar o seu andamento, anotando as 
atividades que estão sendo cumpridas e em andamento.
Registrar todos os custos que estão sendo efetivados ao longo do projeto e 
comparar com o que foi previsto. Em caso de desvio, fazer ajustes no orçamento.
Cobrar a elaboração dos relatórios previstos no plano de gerenciamento das 
comunicações. Identificar continuamente novos riscos e criar planos de respostas. 
Analisar o desempenho das aquisições, os conflitos com os fornecedores e 
ocumprimento dos contratos. Assim como, liberar os pagamentos.
Gestão de Projetos 40
Volte ao Sumário
15. ENCERRAR O PROJETO
Este processo faz parte do grupo de processos de “Encerramento” e da área 
de conhecimentos “Integração”.
Para que o encerramento do projeto seja feita da forma correta, o GP deve: 
Fazer uma auditoria para avaliar se todos os contratos foram cumpridos e, então, 
encerrar os contratos pendentes, se for o caso.
Entregar o produto final ao cliente, receber o aceite e elaborar o relatório de 
encerramento do projeto, arquivando de forma organizada todos os documentos 
gerados ao longo do projeto.
Gestão de Projetos 41
Volte ao Sumário
Desenho Instrucional: Veronica Ribeiro
Supervisão Pedagógica: Laryssa Campos
Revisão pedagógica: Camila Martins / Cássio Lima
Design editorial/gráfico: Darlan Conrado
2021
	Sumário
	Introdução
	SOBRE O PROF. HERBERTH CUTRIM, MSC, PMP.
	APRESENTAÇÃO
	O PMBOK
	1. DESENVOLVER O TERMO DE ABERTURA DO PROJETO
	1.1 DOCUMENTOS NECESSÁRIOS: BUSINESS CASE.
	1.2 ITENS NECESSÁRIOS PARA COMPOR O TERMO DE ABERTURA
	2. A IDENTIFICAÇÃO AS PARTES INTERESSADAS
	3. PLANEJAR A ORGANIZAÇÃO E O GERENCIAMENTO DAS MUDANÇAS
	3.1 A PLANO DE ORGANIZAÇÃO E GERENCIAMENTO DAS MUDANÇAS TEM AS SEGUINTES INFORMAÇÕES EM SEU CONTEÚDO:
	4. DEFINIR O ESCOPO
	4.4 RESTRIÇÕES:
	4 .5 PREMISSAS:
	5. CRIAR A ESTRUTURA ANALÍTICA DO PROJETO – EAP
	5.1. DICIONÁRIO DA EAP
	6. DESENVOLVER O CRONOGRAMA
	7. DETERMINAR O ORÇAMENTO
	8. PLANEJAR A QUALIDADE
	9. DESENVOLVER O PLANO DE RECURSOS
	10.PLANEJAR AS COMUNICAÇÕES
	11.PLANO DE GERENCIAMENTO DE RISCOS
	12.PLANEJAR AS AQUISIÇÕES
	13.ORIENTAR E GERENCIAR A EXECUÇÃO DO PROJETO
	14. MONITORAR E CONTROLAR O TRABALHO DO PROJETO
	15. ENCERRAR O PROJETO
	Sumário 51: 
	Página 1: 
	Página 2: 
	Página 3: 
	Página 4: 
	Página 5: 
	Página 6: 
	Página 7: 
	Página 8: 
	Página 9: 
	Página 10: 
	Página 11: 
	Página 12: 
	Página 13: 
	Página 14: 
	Página 15: 
	Página 16: 
	Página 17: 
	Página 18: 
	Página 19: 
	Página 20: 
	Página 21: 
	Página 22: 
	Página23: 
	Página 24: 
	Página 25: 
	Página 26: 
	Página 27: 
	Página 28: 
	Página 29: 
	Página 30: 
	Página 31: 
	Página 32: 
	Página 33: 
	Página 34: 
	Página 35: 
	Página 36: 
	Página 37: 
	Página 38: 
	Página 39: 
	Página 40: 
	Página 41: 
	Página 42: 
	Botão 628: 
	Botão 629: 
	Botão 630: