Ebook - GESTÃO DE PROJETOS - REFORMULADO

Prévia do material em texto

Gestão de Projetos 1
1
Didática no Ensino
Auditoria Contábil Tributária 1
Navegue entre os capítulos
Volte ao Sumário
GESTÃO DE PROJETOS
GRUPO ESTRATEGO
Gestão de Projetos 1
1
Didática no Ensino
Auditoria Contábil Tributária 1
Navegue entre os capítulos
Volte ao Sumário
Cutrim, Herberth; Vanzeler, Thany Elly, 2020.
Gestão de Projetos - Belém, PA: Faculdade Estratego.
44 páginas.
Palavras-chave: 1. Projeto; 2. Gestão; 3. Planejamento.
Gestão de Projetos 2
s
SUMÁRIO
SOBRE O PROF. HERBERTH CUTRIM, MSC, PMP. ...................................................................3
APRESENTAÇÃO ............................................................................................................................................4
1. DESENVOLVER O TERMO DE ABERTURA DO PROJETO.................................................6
2. A IDENTIFICAÇÃO AS PARTES INTERESSADAS .....................................................................9
3. PLANEJAR A ORGANIZAÇÃO E O GERENCIAMENTO DAS MUDANÇAS ............12
4. DEFINIR O ESCOPO ................................................................................................................................14
5. CRIAR A ESTRUTURA ANALÍTICA DO PROJETO – EAP ....................................................18
6. DESENVOLVER O CRONOGRAMA ...............................................................................................21
7. DETERMINAR O ORÇAMENTO ........................................................................................................23
8. PLANEJAR A QUALIDADE ...................................................................................................................25
9. DESENVOLVER O PLANO DE RECURSOS ................................................................................27
10.PLANEJAR AS COMUNICAÇÕES ..................................................................................................29
11.PLANO DE GERENCIAMENTO DE RISCOS .............................................................................31
12.PLANEJAR AS AQUISIÇÕES ..............................................................................................................37
13.ORIENTAR E GERENCIAR A EXECUÇÃO DO PROJETO .................................................39
14. MONITORAR E CONTROLAR O TRABALHO DO PROJETO .........................................40
15. ENCERRAR O PROJETO .....................................................................................................................41
REFERENCAS BIBLIOGRÁFICAS ........................................................................................................42
* 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
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 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
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
O PMBOK 
É um guia prático de projetos, visando estruturar processos e passos 
necessá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.
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 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 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 definido 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 fechar formalmente um projeto, fase ou contrato.
Fotografia 1: Grupo de Processos
Fonte: bloge.luz.vc.com.br
Gestão de Projetos 6
1. DESENVOLVER O TERMO DE ABERTURA DO PROJETO
Desenvolver o Termo de Abertura do Projeto é o processo de desenvolver 
um documento que formalmente autoriza 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, um 
contrato formal é normalmente a forma preferida de estabelecer um acordo. 
Também pode ser usado paraestabelecer 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.
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 
Gestão de Projetos 7
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 custo-
benefí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; u Risco 
geral do projeto;
Gestão de Projetos 8
• Resumo do cronograma de marcos;
• Recursos financeiros pré-aprovados;
• 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 projeto);
• Critérios de término do projeto (ou seja, quais são as condições que devem 
ser cumpridas 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
2. A IDENTIFICAÇÃO AS PARTES INTERESSADAS
O gerenciamento das partes interessadas do projeto inclui os processos 
exigidos 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 pessoa ou 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
- Sponsor/Patrocinador: Pessoa ou organização, dentro ou fora da 
organizaçã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 vaiser 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
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
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 
atualizados. E, finalmente, deve-se informar como toda a documentação do 
projeto será organizada.
Gestão de Projetos 13
• 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 de 
mudanças no projeto; 
- Inclua como as mudanças poder ser solicitadas. Isto vai desde o 
preenchimento de uma formulário padrão criado especificamente para isto, a 
solicitações por email, quando o projeto for pequeno, memorando, carta, sistema 
de 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; pode-
se 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 
necessidades do projeto. A autorização pode seguir 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 responsá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
4. DEFINIR O ESCOPO
Este processo faz parte do grupo de “Planejamento e é da área de 
conhecimento “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.
4.2 CRITÉRIOS DE ACEITAÇÃO:
Gestão de Projetos 15
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áxima 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. 
4.5 PREMISSAS: 
São eventos ou condições consideradas verdadeiras pela equipe do 
Gestão de Projetos 16
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 projeto
- 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. 
Não se assuste, é comum se ter uma certa dificuldade quando se começa a 
Gestão de Projetos 17
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 presente ou no futuro e riscos, 
apenas, eventos futuros; 
Fique Atento:
Gestão de Projetos 18
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.
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 
uma visão macro do que vai ser feito;
Gestão de Projetos 19
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. 
Ou seja, esta coluna tem este intuito, deixar claro o que vai ser feito e como;
Gestão de Projetos 20
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 menos 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 substantivas;
- 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 atividades que serão inseridas no cronograma;
- Para fazer uma EAP é neces ário checar modelos de EAP’s de outros projetos 
semelhantes que já foram feitos pela organização ou outras, consultar e pecialistas, 
discutir com a equipe de gerenciamento do projeto e, acima de tudo, procurar 
entender o trabalho que se precisa realizar.
Gestão de Projetos 21
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.
Gestão de Projetos 22
Fique atento:
- 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;
- Note que todos os elementos da EAP são inseridos no cronograma. Em 
seguida, inclua as atividades embaixo da linha de cada pacote;
- Nunca use “X” no lugar do gráfico de barras. Isto é um erro. Inclua, apenas, 
barras para demonstrar quando as atividades serão realizadas;
Gestão de Projetos 23
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 sido feito 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, 
Gestão de Projetos24
é 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.
Fique atento:
- Utilize os pacotes de trabalho da EAP para melhorar a sua estimativa do 
orçamento;
- 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;
Gestão de Projetos 25
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 26
Fique atento:
- 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;
- 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 qualidade do projeto. Lembre-se de 
consultar também outros projetos semelhantes realizados;
Gestão de Projetos 27
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. u 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, 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.
Gestão de Projetos 28
• Treinamento. Estratégias de treinamento para membros de equipes. u 
Desenvolvimento de equipes. Métodos para desenvolver a equipe do projeto. 
u Controle de recursos. Métodos para garantir que recursos fí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 29
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 
manterinformados 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 
as datas já estarão devidamente programadas, oportunizando a cada participante 
se preparar com informações necessárias e se agendar corretamente, diminuindo 
Gestão de Projetos 30
as possibilidades de ausências imprevistas. Veja modelo de calendário no slide 
disponibilizado da aula.
Fique atento:
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.
Gestão de Projetos 31
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 
Gestão de Projetos 32
advindas. 
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:
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 causas-
raiz. 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: 
Gestão de Projetos 33
impacto e probabilidade, respectivamente. E uma série de quadrantes oriundos 
do cruzamento destes fatores. Os quadrantes podem 
ser risco nulo, baixo risco, médio risco e alto 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 deriscos:
Gestão de Projetos 34
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:
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 
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édio 
e 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 
Gestão de Projetos 35
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 
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 
Gestão de Projetos 36
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.
Fique atento:
- 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 avaliação de riscos. Ou seja, enquanto você está utilizando 
a matriz de avaliação para cada risco, concomitantemente vá preenchendo o 
quadro de análise de riscos.
Gestão de Projetos 37
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 entregues aos 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:
É 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.
• 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. 
Gestão de Projetos 38
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.
Fique atento:
- 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.
Gestão de Projetos 39
13.ORIENTAR E GERENCIAR A EXECUÇÃO DO PROJETO
Este processo fazparte 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 40
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 o 
cumprimento dos contratos. Assim como, liberar os pagamentos.
Gestão de Projetos 41
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 42
REFERENCAS BIBLIOGRÁFICAS 
Project Management Institute, editor. Título: Um Guia do Conhecimento 
em Gerenciamento de Projetos (Guia PMBOK)/Project Management Institute. 
Outros títulos: Guia PMBOK, 6ª Edição, 2017.
Gestão de Projetos 43
1
Didática no Ensino
Auditoria Contábil Tributária1
Navegue entre os capítulos
Volte ao Sumário
Desenho Instrucional: Tiago Lobato
Design editorial/gráfico: Watson Junior
Revisão pedagógica: Aline Ramos
Revisão ortográfica: Adriana Morais
2020
	Sumário
	Introdução
	Sobre o prof. Herberth Cutrim, Msc, PMP. 
	APRESENTAÇÃO
	1. Desenvolver o Termo de Abertura do Projeto
	2. A identificação as Partes Interessadas
	3. Planejar a organização e o gerenciamento das mudanças
	4. Definir o escopo
	5. Criar a Estrutura Analítica do Projeto – 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
	REFERENCAS BIBLIOGRÁFICAS 
	Botão 616: 
	Botão 617: 
	Botão 618: 
	Botão 619: 
	Botão 620: 
	Botão 621: 
	Botão 622: 
	Botão 623: 
	Botão 624: 
	Botão 625: 
	Botão 626: 
	Botão 627: 
	Botão 628: 
	Botão 629: 
	Botão 630: 
	Botão 631: 
	Botão 632: 
	Botão 633: