Apostila 3 Se o Planejamento

SEJA PMP ®
Apostila 3
Seção Planejamento
Grupo de processos de Planejamento
Qualquer atividade humana realizada sem qualquer tipo de preparo é uma atividade aleatória que conduz,
em geral, o indivíduo e as organizações a destinos não esperados, altamente desastrosos e via de regra à situações
piores que aquelas anteriormente existentes. Ou seja, é por conta justamente da falta de planejamento que
muitos projetos fracassam.
Dessa forma, o planejamento é a função administrativa que determina antecipadamente as atividades que
devem ser desempenhadas, além de quais objetivos serão alcançados. Ou seja, planejar significa visualizar
antecipadamente as ações que irão ocorrer e que visam alcançar os objetivos propostos.
A equipe de gerenciamento de projetos usa este grupo de processos para planejá-lo de forma bem sucedida
para a organização. Ele envolve a determinação do escopo (o que deve ser feito), a definição da equipe e suas
funções e responsabilidades (quem deve fazer), o desenvolvimento do cronograma (quando deve ser feito),
do orçamento (a que custo), a determinação de padrões e métricas de qualidade, a identificação de riscos, a
determinação do que deve ser comprado ou elaborado internamente entre outros.
O planejamento apresenta as seguintes características:
• É um processo permanente e contínuo, ou seja, a função de planejar é realizada a todo momento

durante o projeto e não somente nas semanas iniciais.
• É sempre voltado para o futuro, isto é, o planejamento visa antecipar as ações que irão ocorrer em um
momento futuro, pois as ações e atitudes que acontecem no presente não necessitam de planejamento,
já que estão sendo executadas. Dessa maneira, o planejamento só é eficaz se desencadear ações que
irão acontecer em um momento futuro, para assim, poder antecipar essas ações diminuindo os riscos
de erro.
• Preocupa-se com a racionalidade da tomada de decisões – é o aspecto que torna o planejamento uma
ferramenta importante, visto que as atitudes e tomadas de decisão são feitas de modo racional, sem se
basear no empirismo ou em decisões emocionais.
• Visa relacionar, entre várias alternativas disponíveis, um determinado curso de ação, em decorrência de
suas consequências futuras e das possibilidades de interferência em sua execução e realização.
• É interativo, isto é, o planejamento deverá ser flexível para poder fazer ajustes e correções que
forem necessárias em função do momento e das ações que desencadeiam. Dessa forma, se as ações
modificarem e interferirem no planejamento de forma diferente do previsto inicialmente, este deverá
se adaptar a essas alterações.
Assim, é por aqui que o planejamento do projeto se inicia, ou seja, é a partir do grupo de processos de
Planejamento que a equipe de gerenciamento do projeto começa a delinear o plano do projeto.
Já dizia Albert Einstein: “Uma pessoa inteligente resolve um problema, um sábio o previne.” Essa frase
resume exatamente qual deve ser a postura do gerente de projetos em relação ao planejamento.
Observe que a criação do plano de gerenciamento do projeto se estende por 24 processos do grupo de
processos de planejamento como mostrado na tabela a seguir:
Processo Área de conhecimento
Desenvolver o plano de gerenciamento do Gerenciamento da integração
projeto (4.2)
Planejar o gerenciamento do escopo (5.1) Gerenciamento do escopo
Coletar requisitos (5.2)
Definir o escopo (5.3)
Criar a estrutura analítica do projeto (EAP) (5.4)
Planejar o gerenciamento do cronograma Gerenciamento do
(6.1) cronograma
Definir as atividades (6.2)
Sequenciar as atividades (6.3)
Estimar as durações das atividades (6.4)
Desenvolver o cronograma (6.5)
Planejar o gerenciamento dos custos (7.1) Gerenciamento dos custos
Estimar os custos (7.2)
Determinar o orçamento (7.3)
Planejar o gerenciamento da qualidade Gerenciamento da qualidade
(8.1)
Planejar o gerenciamento dos recursos Gerenciamento dos recursos
(9.1)
Estimar os recursos das atividades (9.2)
Planejar o gerenciamento das Gerenciamento das
comunicações (10.1) comunicações
Planejar o gerenciamento dos riscos (11.1) Gerenciamento dos riscos
Identificar os riscos (11.2)
Realizar a análise qualitativa dos riscos
(11.3)
Realizar a análise quantitativa dos riscos
(11.4)
Planejar as respostas os riscos (11.5)
Planejar o gerenciamento das aquisições Gerenciamento das aquisições
(12.1)
Planejar o gerenciamento das partes Gerenciamento das partes
interessadas (13.2) interessadas
Veja na figura a seguir como é o consumo de recursos previsto para este grupo de processos.
Fonte: Guia PMBOK® (com adaptações)
Desenvolver o plano de gerenciamento do projeto
(4.2)
O principal objetivo deste processo é integrar a criação do plano de gerenciamento do projeto que engloba
a determinação do escopo (o que deve ser feito), a definição da equipe e suas funções e responsabilidades
(quem deve fazer), o desenvolvimento do cronograma (quando deve ser feito), do orçamento (a que custo), a
determinação de padrões e métricas de qualidade, a identificação de riscos, a determinação do que deve ser
comprado ou elaborado internamente e como as partes interessadas serão gerenciadas.
Segundo o Guia PMBOK®, desenvolver o plano de gerenciamento de projeto é o processo de documentação

das ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares. Ou seja, um plano
de gerenciamento é um conjunto de planos auxiliares.
É durante este processo que o gerente do projeto e sua equipe devem realizar o “tailoring”, isto é, escolher
quais processos, ferramentas e técnicas serão aplicáveis ao projeto, caso não exista uma metodologia de
gerenciamento de projetos na organização que indique o que deve ser feito.
A “única” saída deste processo é o plano de gerenciamento do projeto. Destacamos “única” saída, pois na
verdade o Plano de gerenciamento do projeto é a integração de vários outros planos e documentos. A figura a
seguir mostra uma possível combinação de documentos que podem formar um plano de projeto.
O plano de gerenciamento do projeto é atualizado principalmente pelos processos de planejamento,

e serve de entrada para praticamente todos eles, além de ser entrada para outros processos de Execução,
Monitoramento e controle e Encerramento.
A criação do plano de gerenciamento do projeto começa neste processo. Seus planos auxiliares são
desenvolvidos à medida que caminhamos pelos demais processos de planejamento (via elaboração progressiva).
Sua primeira versão só será finalizada quando atingirmos o último processo desse grupo de processos. Uma vez
finalizado, o plano de gerenciamento do projeto será aprovado pelo patrocinador e, em alguns casos pelas
principais partes interessadas. Após isso, toda e qualquer alteração só poderá ser efetuada a partir do processo
Realizar o controle integrado de mudanças conforme veremos nos capítulos referentes ao grupo de processos
de monitoramento e controle.
O processo
Este processo contém os seguintes componentes:
Entradas
Termo de abertura do projeto
Já vimos que o termo de abertura do projeto (TAP), ou project charter, é o documento formal que declara
o projeto como aberto e iniciado. Nesse documento estão descritos (em alto nível) os objetivos e os requisitos
necessários para satisfazer as expectativas das Partes interessadas.
O gerente do projeto deve usar o TAP para nortear o desenvolvimento do plano de gerenciamento do
projeto.
Saídas de outros processos

Como já vimos anteriormente o plano de gerenciamento do projeto é uma coleção de outros planos e
documentos. Não é a toa que este processo está na área de conhecimento Integração, pois o plano do projeto
integra todos os documentos de planejamento das demais áreas de conhecimento.
É por isso que as saídas de outros processos são entradas para este processo. Veja na figura a seguir uma
representação disso.
Fatores ambientais da empresa

Fatores ambientais são qualquer norma, guia de processos ou sistema organizacional que pode influir
no desenvolvimento do projeto podendo esse ser relativo à empresa requerente ou à empresa responsável
pelo projeto, e deve ser descrito no plano do projeto caso possa causar impacto ou influência significativa no
resultado do projeto.
Tais fatores são importantes, pois influenciam também na escolha dos processos, ferramentas e técnicas
que serão adotados no projeto. Entre eles citamos: O sistema de informações do gerenciamento do projeto,
estrutura organizacional, instalações e equipamentos etc.
Ativos de processos organizacionais

Os ativos de processos organizacionais são políticas, modelos ou informações históricas que podem
influenciar ou impactar no projeto. Favorecem o projeto, pois representam o conhecimento acumulado pela
organização. Entre eles citamos: modelos de planos de projeto, informações históricas, bases de conhecimento,
procedimentos de controle de mudanças etc.
Ferramentas e técnicas
Opinião especializada
Um projeto pode ter detalhes técnicos que não são da competência do gerente ou dos responsáveis
iniciais pelo seu desenvolvimento. Tais detalhes podem influenciar os custos e prazos do processo, além de
comprometer outros fatores. Por isso, sempre que possível, consulte um especialista para esclarecer os pontos
que possam gerar dúvidas.
A opinião especializada pode auxiliar a decidir quais processos, ferramentas e técnicas serão adotadas no
projeto; definir o nível de detalhamento de cada processo; como será o controle de mudanças; etc.
Coleta de dados
As técnicas de coleta de dados são utilizadas para obter dados de forma mais eficiente. As técnicas
recomendadas são: brainstorming, listas de verificação, grupos de discussão e entrevistas. Não se preocupe
neste momento com os detalhes dessas técnicas, pois iremos abordar uma a uma nos próximos capítulos. Mas
veja que esta não é uma lista exaustiva, ou seja, o próprio Guia PMBOK já indica que esta lista não se limita
a estes itens. É importante que você saiba quais são as ferramentas que podem se encaixar aqui, mas não há
necessidade de decorá-las..
Habilidades interpessoais e de equipe

Estas habilidades, chamadas de soft-skills auxiliam a obtenção do consenso e como sugestão o Guia PMBOK
sugere: gerenciamento de conflitos, facilitação e gerenciamento de reuniões. O gerenciamento de conflitos e
de reuniões veremos em detalhes em aulas futuras. Por isso, vamos abordar agora o que são essas habilidades
de facilitação.
As habilidades de facilitação são utilizadas para tornar as reuniões mais eficientes deixando claro o seu
objetivo, mantendo o foco para atender esse objetivo, estimulando participação e ainda garantindo que as
decisões tomadas serão corretamente documentadas e executadas. Durante a elaboração do termo de abertura
do projeto muitas reuniões serão realizadas para que haja um consenso sobre o seu conteúdo.
Observe que ao contrário do que muitas pessoas pensam, chegar a um consenso não significa conseguir
unanimidade. Consenso é um conceito mais aberto, que significa que os envolvidos podem até entender que
existem opções melhores, mas todas estão dispostas a aceitar a decisão da maioria.
Reuniões
As reuniões são usadas para se desenvolver todo o planejamento do projeto.
Uma reunião muito importante, a reunião de início do projeto (ou Kick-off) pode acontecer em dois
momentos distintos dependendo do tamanho do projeto e sua equipe de gerenciamento. Se a equipe for
pequena, a reunião de início do projeto é feita logo após o final da fase de iniciação. Já se tivermos um grande
e complexo projeto, com granedes equipes de gerenciamento e de execução, a reunião de kick-off do projeto é
normalmente realizada após o término do planejamento e logo no início da próxima fase, pois é nesse momento
que as equipes de execução estarão sendo incorporadas ao projeto.
Saídas
Plano de gerenciamento do projeto
O próprio plano de gerenciamento do projeto é a saída deste processo. Ele é uma coletânea de diversos
outros planos de gerenciamento (chamados de auxiliares ou subsidiários) como mostrado na tabela a seguir:
Planos auxiliares Descrição Área de

conhecimento
Plano de Descreve como o escopo 5 - escopo
gerenciamento do do projeto será definido,
escopo desenvolvido e verificado e
como a estrutura analítica do
projeto será criada e definida.
Fornece ainda orientação sobre
como o escopo do projeto será
gerenciado e controlado pela
equipe de gerenciamento de
projetos.
Plano de Tem como objetivo 5 - escopo
gerenciamento documentar como os
dos requisitos requisitos serão analisados,
documentados e gerenciados
do início ao fim do projeto.
Plano de Descreve como o cronograma 6 - cronograma
gerenciamento do do projeto será desenvolvido,
cronograma gerenciado e controlado pela
projetos.
Plano de Descreve como os custos 7 - custo
gerenciamento do projeto serão estimados,
dos custos gerenciados e controlados pela
projetos.
Plano de Descreve como as políticas de 8 - qualidade
gerenciamento da qualidade da organização serão
qualidade implementadas. Ele também
descreve como a equipe de
gerenciamento do projeto
planeja cumprir os requisitos
de qualidade estabelecidos
para o projeto.
Plano de Fornece orientação sobre como 9 - recursos
gerenciamento os recursos do projeto devem
dos recursos ser definidos, mobilizados,
gerenciados, controlados e, por
fim, liberados.
conhecimento
Plano de Descreve como as 10 -
gerenciamento comunicações serão realizadas comunicações
das comunicações durante o projeto, bem como
define as necessidades de
comunicação das partes
interessadas.
Plano de Tem como objetivo aumentar 11 - riscos
gerenciamento a probabilidade e o impacto
dos riscos dos eventos positivos, reduzir a
probabilidade e o impacto dos
eventos negativos no projeto
e orientar a equipe do projeto
sobre como os processos de
riscos serão executados.
Plano de Descreve como os processos 12 - aquisições
gerenciamento de aquisição serão gerenciados
das aquisições desde o desenvolvimento dos
documentos de aquisições até
o fechamento do contrato.
Plano de Identifica as estratégias de 13 - partes
gerenciamento gerenciamento necessárias interessadas
das partes para o engajamento das partes
interessadas interessadas de maneira eficaz.
Plano de É o documento que 4 – integração

gerenciamento fornece orientação para o
das mudanças gerenciamento do processo
de controle de mudanças e
documenta como funcionará
o comitê de controle de
mudanças (CCM).
Plano de É o documento que define 4 - integração
gerenciamento da os itens que podem sofrer
configuração alterações e os que requerem
controle formal de mudança.
Linhas de base A linha de base é uma 5 – escopo
“fotografia congelada” do 6 – cronograma
projeto em determinado
instante. Ou seja, quando 7 - custo
uma linha de base é criada, o
progresso do projeto naquele
momento fica guardado para
comparações futuras.
Podem ser: escopo,
cronograma e custo.
conhecimento
Linha de base Esta linha de base é usada 5 – escopo
da medição do como comparação para as 6 – cronograma
desempenho demais. Somente a partir de
comparações é que podemos 7 - custo
saber se o desempenho está
dentro do esperado.
Descritivo do ciclo É um documento que indica 4 – integração
de vida do projeto as fases pelas quais o projeto
deve passar.
Abordagem de É um documento que 4 – integração
desenvolvimento indica qual será o modelo
de desenvolvimento a ser
adotado: preditivo, iterativo,
ágil ou híbrido.
Veremos em detalhes cada um desses planos nos próximos capítulos. Mas tenha em mente, desde já, que
a partir deles e dos documentos auxiliares o plano de gerenciamento do projeto deve ser capaz de identificar
os seguintes itens:
• Quais os processos de gerenciamento de projetos serão usados e qual o nível de implementação de
cada um deles;
• Quais as ferramentas e técnicas serão usadas em cada um dos processos;
• Como os processos selecionados serão usados para gerenciar o projeto, incluindo como esses processos
irão interagir ao longo do ciclo de vida do projeto;
• Como o trabalho do projeto será completado;
• Como as mudanças serão controladas;
• Como o gerenciamento da configuração será realizada;
• Como as linhas de base serão utilizadas para melhor gerenciar o projeto;
• Quais serão as demandas de comunicações e quais as estratégias adotadas;
• Como as fases do projeto serão iniciadas e encerradas;
• Quando e como o desempenho do projeto será avaliado.
E à medida que o projeto progride e os processos são executados, os planos auxiliares e até mesmo o plano
do projeto sofrerãor mudanças. Essas mudanças serão controladas a partir do processo Realizar o controle
integrado de mudanças indicado no plano de gerenciamento de mudanças. Veremos em detalhes este processo
no nos capítulos referentes ao monitoramento e controle.
Planejando o escopo
Um dos aspectos mais importantes no gerenciamento de um projeto é o tempo dedicado ao seu
planejamento, e em particular à definição do que será entregue. É aqui que as atividades aparentemente
simples são menosprezadas.
A falha em definir exatamente o que será feito irá afetar o custo (e muitas vezes, o lucro) de um projeto e
resultar em um projeto com entregas recusadas pelo cliente.
A descrição clara do que será produzido é essencial para o sucesso do projeto. A equipe do projeto e
as Partes interessadas devem ter o mesmo entendimento acerca do que será produzido pelo projeto e que
processos serão usados.
O Guia PMBOK® fornece quatro processos que se executados corretamente ajudarão a definir o escopo do
projeto:
• Planejar o gerenciamento do escopo (5.1);
• Coletar os requisitos (5.2);
• Definir o escopo (5.3);
• Criar a EAP (5.4).
Observe que você deve adaptar os processos propostos pelo Guia PMBOK® às necessidades atuais do
seu projeto, uma vez que nem todos os documentos precisarão ser elaborados para que você o gerencie com
sucesso.
Escopo projeto x escopo produto

Muitas vezes o escopo do produto é confundido com o escopo do projeto, por isso é importante que você
saiba a diferença entre os dois termos:
• Escopo do produto: refere-se às características do produto ou serviço que se quer como resultado do
projeto. Exemplo: características que descrevem um novo modelo de automóvel.
• Escopo do projeto: é todo o trabalho a ser realizado dentro do projeto para fornecer um produto
ou serviço. Exemplo: todas as atividades que envolvem o desenvolvimento de um novo modelo de
automóvel.
Resumidamente, escopo do projeto é o meio para alcançar o objetivo que é definido no escopo do produto.
Um Escopo bem definido nos auxilia a estimar com maior precisão a duração, o custo e os recursos
envolvidos na execução do projeto, além de definir uma base para avaliação e controle do projeto.
Muitos erros aparecem no projeto tanto pela falta de conhecimento da relação entre o projeto e o produto
real, quanto pela má representação (e interpretação) do escopo projeto. Veja algumas atrocidades cometidas na
construção civil:
Fonte: http://mariana-projetista.blogspot.com.br/2013/05/veda-29-materializando-o-projeto.html
O gerenciamento e o controle do escopo do projeto difere do gerenciamento e controle do escopo do

produto como destacado na tabela a seguir:
Escopo Medição Critério de aceitação

Produto Contra os requisitos do produto. Está de acordo com a especificações?
Projeto Contra o plano do projeto (especificação O trabalho foi encerrado?
do escopo, EAP e dicionário da EAP).
Outro ponto que vale a pena ressaltar é a diferença entre os requisitos do produto e do projeto:
• Requisitos do projeto: geralmente são normas, leis, ou restrições que o projeto não pode infringir,
como por exemplo: uso de capacete em uma obra, leis ambientais, ISOs etc.
• Requisitos do produto: são as característica que o produto deve ter para que seja aceito pelo cliente,
como por exemplo: cores, largura, funcionalidades, etc.
Scope Creep e Gold Plating

Uma das responsabilidades do gerente de projetos é proteger seu escopo. Projetos que ficam mudando o
escopo indefinidamente durante sua execução têm sérias dificuldades em cumprir o cronograma, estouram o
orçamento, e muitas vezes levam o projeto ao fracasso.
O risco mais comum associado às mudanças de escopo é o que se chama de “scope creep”, que é o aumento
sem controle do escopo do projeto sem ajustes no tempo, recursos e custos. Assim, novas funcionalidades são
adicionadas sem que se meçam quais serão os impactos no projeto. Normalmente a solicitação de aumento
de escopo vem do cliente que a passa diretamente para algum membro da equipe de execução do projeto.
O gerente do projeto só descobre depois que o desempenho já está fora dos “trilhos”. Por isso, é importante
conscientizar TODA a equipe do projeto que essa é uma prática condenada.
Outro risco muito comum é o “gold plating”, que é entregar ao cliente mais do que o esperado. Mas,
você deve estar se perguntando: “Maravilhar o cliente não é o mais importante?” Não! Não é! Quanto mais
funcionalidades extras, melhor qualidade que a solicitada, desempenho maior que o esperado, maiores serão os
custos. E é quase certo que o cliente não arcará com os custos dessas melhorias não solicitadas. Normalmente
a solicitação dessas melhorias vem do gerente do projeto ou de sua equipe.
O gerente de projeto deve entregar ao cliente o que ele solicitou e somente isso. Adicionar extras ao
projeto produz uma perda de tempo e pode não representar benefícios para o projeto.
Fatores críticos de sucesso

• Em projetos o óbvio não é tão óbvio assim. Assim, o escopo do produto deverá prever todas as
funcionalidades esperadas e o escopo do projeto detalhar todo o trabalho a ser executado para que o
produto do projeto seja entregue de acordo com o especificado. Ou o cliente vai aceitar uma escada
que termine no teto?
• A preocupação maior de um gerente de projetos é garantir que o escopo estabelecido seja cumprido,
mesmo que sofra alterações, afinal de contas vivemos em mundo em que as mudanças acontecem de
forma cada vez mais rápida; e os projetos devem se adequar a essas mudanças..
• Para obter sucesso no gerenciamento do escopo é necessário ter um bom gerenciamento de mudanças.
Por mudanças entendemos como qualquer alteração ocorrida após a aprovação do escopo inicial. Ela
geralmente envolve alterações nos custos, prazos, qualidade ou em outros pontos do projeto.
• A maior preocupação que devemos ter ao tratarmos do escopo é compreender, definir e controlar o que
está e o que não está incluído no projeto.
Planejar o Gerenciamento do Escopo (5.1)
O planejamento do escopo abrange os processos necessários na definição e no controle do que está dentro
e do que está fora, ou seja, o que o projeto irar entregar e o que não irá entregar.
Um dos objetivos deste processo é gerar o plano de gerenciamento do escopo do projeto que estabelece as
políticas, procedimentos e documentação para planejar, desenvolver, gerenciar, executar e controlar o escopo
do projeto. O principal benefício deste processo é fornecer orientação de como o escopo será gerenciado
durante todo o projeto.
Outro objetivo importante deste processo é gerar o plano de gerenciamento dos requisitos que descreve
como os requisitos do produto/serviço serão analisados, documentados e gerenciados.
O processo
Este processo é composto pelos seguintes elementos:
Entradas
O termo de abertura do projeto é uma entrada muito importante, pois ele fornece a descrição em alto nível
do projeto e das características do produto.
A partir das informações contidas nesse documento o gerente do projeto será capaz de determinar quais
ferramentas e técnicas, bem como quais processos serão adotados no projeto.

O plano de gerenciamento do projeto é uma das entradas deste processo, já que ele contém os planos
auxiliares aprovados que podem influenciar na abordagem adotada no planejamento e gerenciamento desse
escopo.
Observe que logo no início do projeto o plano de gerenciamento não fornecerá muitas informações, pois
ele estará apenas no início de sua elaboração, sendo nesse momento um “rascunho” inicial. À medida que o
planejamento for evoluindo, o plano de gerenciamento do projeto conterá mais detalhes (de outros planos
auxiliares) e permitirá que o plano de gerenciamento do escopo seja revisado para refletir as alterações desses
planos.
Dois componentes importantes do plano de gerenciamento de projetos que devem ser consultados neste
processo são o descritivo do ciclo de vida do projeto que indica quais são as fases planejadas para o projeto e a
abordagem de desenvolvimento que indica qual o modelo de desenvolvimento, ou seja, modelo cascata, ágil,
adaptativo etc.

Veja que mais uma vez temos os fatores ambientais da empresa como entrada de um processo. Neste
caso, os fatores mais importantes são: conhecimentos e habilidades da equipe do projeto, relacionamento de
membros da equipe com as principais partes interessadas, cultura organizacional, condições de mercado entre
outros.

E aqui temos mais uma vez os ativos de processos organizacionais como entrada de um processo. Neste
caso, podemos considerar como importantes os seguintes ativos: modelos de planos de auxiliares, informações
históricas, lições aprendidas entre outros.
Ferramentas e Técnicas
Opinião Especializada
Um especialista que deve ser consultado é justamente aquele que deu origem ao termo de abertura do
projeto. Esse profissional poderá esclarecer quaisquer dúvidas sobre os objetivos do projeto, bem como sobre
a descrição do produto que será elaborado.
Além dele, outras partes interessadas também podem ser consultadas, tais como: patrocinador, gerentes
de outros projetos, membros da equipe que já participaram de projetos similares etc.
Análise de dados
Na análise de dados se procura identificar as opções e alternativas para o gerenciamento do escopo. Entre
todas as ferramentas de análise de dados, pode-ser usar a:
• Análise de alternativas: nada mais é que identificação das alternativas para o projeto, análise e seleção
da melhor opção. Em casos mais complexos uma matriz de decisão pode ser utilizada.
Reuniões
Bom, essa é uma ferramenta que não exige muitas explicações. O importante neste caso é que as reuniões
devam ser realizadas com os especialistas para estabelecer os itens a serem considerados no plano de
gerenciamento do escopo.
Saídas
Plano de gerenciamento do escopo
Como resultado deste processo teremos o plano de gerenciamento do escopo do projeto que fornece
orientações sobre como o escopo do projeto será definido, documentado, verificado, gerenciado e controlado
pela equipe de gerenciamento. Os itens recomendados que um plano de gerenciamento do escopo deve ter
são:
• Um processo para preparar uma especificação do escopo detalhado, com base no termo de abertura
do projeto;
• Um processo para criar a estrutura analítica do projeto (EAP) a partir da especificação do escopo
detalhado do projeto e que determine como a EAP será mantida e aprovada;
• Um processo que especifique como será realizada a aceitação formal das entregas;
• Um processo para controlar como serão processadas as solicitações de mudanças do escopo do projeto.
Este item será visto em detalhes nos capítulos referentes ao monitoramento e controle do escopo.
Plano de gerenciamento dos requisitos

Outra saída importante é o plano de gerenciamento dos requisitos. Este plano é também um componente do
plano de gerenciamento do projeto e descreve como os requisitos do projeto serão analisados, documentados
e gerenciados. Veremos em mais detalhes o que são requisitos no próximo capítulo.
Os itens recomendados que este plano deve conter são:
• Como serão as atividades para coletar e gerenciar os requisitos;
• Como as mudanças serão tratadas;
• Como será a estrutura de rastreabilidade dos requisitos;
• Como será o gerenciamento da configuração.

Coletar os requisitos (5.2)
A coleta dos requisitos é o processo de definição e documentação das funções e funcionalidades e do
produto/serviço a fim de atender às necessidades e expectativas das partes interessadas.
Este é um processo crítico, pois segundo o Standish Group, que elabora o Chaos Report, a principal causa de
falhas em projetos é que muitas vezes os requisitos de usuário estão incompletos, como mostra a figura a seguir.
Existem diversos tipos de requisitos que variam de acordo com o produto ou serviço a ser entregue. A seguir
apresentamos alguns desses tipos.
Requisitos
Requisitos funcionais
São requisitos que descrevem a funcionalidade do produto/serviço. Imprimir em preto e branco e em cores,
scanear documentos, tirar cópias e enviar fax são requisitos funcionais necessários para uma impressora
multifuncional.
Requisitos não-funcionais
São requisitos que não se referem diretamente à funcionalidade do produto/serviço, mas expressam
propriedades e/ou restrições sobre os serviços e funções por ele fornecidas. Podem ainda ser divididos em:
Requisitos de produto
São requisitos que especificam o comportamento do produto, tais como:
• Requisitos de facilidade de uso ou de usabilidade: referem-se ao esforço para utilizar ou aprender

a utilizar o produto. Exemplo: “O usuário da impressora deverá ser capaz de operá-la sem precisar
participar de um treinamento de 20hs”.
• Requisitos de confiabilidade: referem-se à frequência de ocorrência de falhas. Exemplo: “A impressora

deve imprimir 99,99% dos trabalhos recebidos sem atolar o papel.”
• Requisitos de eficiência: referem-se ao desempenho do produto/serviço e estão associados à eficiência,

uso de recursos e tempo de resposta do produto. Exemplo: “A impressora deve imprimir em qualidade
normal 40 páginas por minuto”.
Requisitos organizacionais
São requisitos derivados das políticas organizacionais do cliente e da empresa, como por exemplo, os
requisitos de padrões que se referem à definição de normas padronizadas a serem seguidas. Exemplo: “A
elaboração dos manuais de todos os produtos fabricados pela empresa devem seguir a mesma formatação de
página e cores”.
Requisitos Externos
São requisitos procedentes de fatores externos ao projeto e ao seu processo de desenvolvimento, como por
exemplo:
• Requisitos éticos - exemplo: código de ética do cliente, do PMI, da empresa etc.
• Requisitos legais - exemplo: leis, normas ABNT etc.
• Requisitos de integração - exemplo: quando duas ou mais empresas produzem partes do produto, é
essencial que os requisitos de integração sejam definidos, caso contrário corremos o risco de uma porta
produzida por A não encaixar no chassi do carro produzido por B.
Outro ponto importante referente aos requisitos é que eles devem fazer sentido para o projeto, ou seja,
devem possuir características que os tornem necessários. Para auxiliar a decidir se o requisito em avaliação é
necessário ou não, utilize a tabela a seguir.
Este requisito...
É necessário? Se o produto pode suprir as demandas sem este
requisito, significa que ele não é necessário e pode
ser descartado.
É inteligível? Se os leitores não compreendem o que o requisito
significa, ele deve ser reescrito.
É exequível? Se este requisito não pode ser implementado
dentro do prazo e orçamento, ele não é viável
e deve ser descartado ou analisado mais
atentamente.
É testável / Se a implementação deste requisito não puder ser
verificável / verificada por meio de um teste, deve ser definida
mensurável? outra forma de verificação.
É rastreável? Se a fonte deste requisito e sua localização não
forem rastreáveis, o requisito deve ser revisado.
É exclusivo? Não devem existir requisitos duplicados.
Está alocado? Se este requisito não estiver ancorado a um
objetivo do projeto, ele não é necessário e deve
ser descartado.
O sucesso do projeto é diretamente influenciado pela atenção na captura e gerenciamento dos

requisitos do projeto e do produto.
O processo
Este processo é composto pelos seguintes itens:
Entradas
O termo de abertura do projeto é uma entrada muito importante, pois ele fornece a descrição em alto nível
do projeto e das características do produto. Será a partir dessas descrições em alto nível que os requisitos serão
detalhados neste processo.

Entre os planos que podem ser consultados, temos:
• Plano de gerenciamento do escopo: o plano de gerenciamento do escopo do projeto fornece orientação

sobre como o escopo será definido, documentado, verificado, gerenciado e controlado pela equipe de
gerenciamento. Especificamente para este processo, esse plano determina como os requisitos serão
coletados.
• Plano de gerenciamento dos requisitos: este item é um componente do plano de gerenciamento do

projeto e descreve como os requisitos do projeto serão analisados, documentados e gerenciados.
• Plano de gerenciamento das partes interessadas: este plano será desenvolvido no processo de
Planejamento - Partes Interessadas. Por ora, tenha em mente que ele será usado para possibilitar o
entendimento dos requisitos de comunicação das partes interessadas e o nível de engajamento de cada
uma delas.
Documentos do projeto
O projeto gera inúmero documentos, e entre eles podem ser utilizados os seguintes para a coleta de
requisitos:
• Registro de premissas: neste registro está indicado o que o produto deve obrigatoriamente ter, bem
como as condições em que o projeto deve ocorrer.
• Registro de lições aprendidas: neste registro são documentadas as lições aprendidas de vários
projetos e tais informações são úteis para indicar as técnicas mais eficazes para a coleta de requisitos.
• Registro das partes interessadas: o registro das partes interessadas, criado durante a Iniciação do
projeto, contém a lista das partes interessadas juntamente com suas expectativas, influências, poderes
etc.
Documentos de negócios
O business case é fonte de informação sobre os objetivos que esse projeto deve alcançar, por isso pode
influenciar a coleta de requisitos.
O business case, em especial é um instrumento que permite prever os resultados de uma decisão empresarial.
É uma ferramenta de planejamento e suporte à decisão que projeta os prováveis resultados financeiros e outras
consequências empresariais de uma ação.
Acordos
Acordos são definidos pelo Guia PMBOK® como documentos que estabelecem as intenções iniciais de um
projeto e podem conter requisitos tanto do projeto como do produto.

outros.

caso, podemos considerar como importantes os seguintes ativos: modelos de planos auxiliares, informações
históricas, lições aprendidas entre outros.
O Guia PMBOK® cita diversas ferramentas e técnicas que podem ser utilizadas para auxiliar na captura de
requisitos. Vamos à lista delas juntamente com a indicação de suas vantagens e desvantagens de uso.
Um projeto pode ter detalhes técnicos que não são da competência do gerente ou dos responsáveis
iniciais pelo seu desenvolvimento. Tais detalhes podem influenciar os custos e prazos do processo, além de
comprometer outros fatores. Por isso, sempre que possível, consulte um especialista para esclarecer os pontos
que possam gerar dúvidas. E em especial neste processo, os especialistas podem ajudar na coleta correta dos
requisitos do produto.
Coleta de dados
Existem diversas ferramentas de coleta de dados, tal como veremos a seguir.
Brainstorming
Esta é uma ferramenta para geração de novas ideias, conceitos ou soluções relacionadas a um tema específico
num ambiente livre de críticas e de restrições à imaginação. Tem a finalidade de reunir uma série de ideias que
possam servir de orientação para a solução de um problema ou desenvolvimento de uma oportunidade.
A livre expressão de ideias é uma condição importante para potencializar a atitude criadora individual e
coletiva.
A palavra brainstorming pode ser traduzida como “tempestade cerebral” ou “tempestade de ideias”.
• Vantagens: permite que todos os participantes possam expor suas ideias livremente e contribuam para
a discussão. Permite que as principais Partes interessadas interajam.
• Desvantagens: se não houver um facilitador experiente, a reunião pode acabar sendo “dominada” pela
gerência. Ou seja, os funcionários ficam receosos de dar suas ideias e serem ridicularizados por seus
chefes.
• Requisitos: é necessária a participação de um grupo representativo de partes interessadas. Deve ser

liderado por um facilitador experiente.
Entrevistas
Consiste em entrevistar os participantes do projeto e especialistas na área em que o projeto irá ser
desenvolvido.
• Vantagens: endereçam requisitos em detalhes e geram comprometimento do entrevistados.
• Desvantagens: consomem muito tempo, pois as entrevistas normalmente são individuais. Podem
trazer à tona receios e preocupações não ligados ao projeto, o que requer do facilitador a filtragem
das informações. Formato não flexível, pois as entrevistas devem seguir um roteiro.
• Requisitos: o facilitador precisa ter habilidades de comunicação para conduzir as entrevistas de forma
satisfatória. Deve haver um ambiente de confiança e abertura. Tanto entrevistador e entrevistado
devem confiar um no outro.
Grupos de discussão
Um grupo de discussão, também chamado de grupo focal, é um grupo informal e de tamanho reduzido,
com o propósito de obter informações de caráter qualitativo em profundidade. É uma técnica rápida e de baixo
custo para avaliação e obtenção de dados e informações. Os participantes devem ser de uma mesma área.
• Vantagens: baixo custo, resultados rápidos, formato flexível permitindo ao moderador explorar perguntas
não previstas no roteiro.
• Desvantagens: o formato flexível depende muito do moderador; não garante anonimato fazendo com
que participantes não se sintam à vontade de falar o que realmente pensam; depende muito da escolha
dos participantes.
• Requisitos: o facilitador precisa ter habilidades de comunicação para conduzir o grupo de forma
satisfatória. Deve existir um ambiente de confiança e abertura entre todos os participantes. O grupo
pode variar entre 7 a 12 pessoas. Normalmente, os participantes devem possuir alguma característica
em comum, como por exemplo, trabalharem no mesmo departamento.
Questionários e pesquisas
Um questionário é um conjunto de perguntas feito para gerar os dados necessários para definir os requisitos
do projeto. É o instrumento típico de pesquisa. É importante ressaltar que em um processo de pesquisa podem
ocorrer dois tipos de erros: os erros amostrais e não-amostrais. O primeiro está ligado às falhas nos processos
de escolha da amostra e da determinação do seu tamanho. Já o segundo, possui inúmeras fontes de ocorrência,
entre elas, questionários mal elaborados, com questões tendenciosas ou dúbias e/ou o uso incorreto de escalas
de medição.
• Vantagens: facilidade de aplicação, processo e análise; facilidade e rapidez no ato de responder;

trabalham com diversas alternativas; recolhe informações de um grande número de pessoas; bom para
levantamento de dados estatísticos.
• Desvantagens: exige muito cuidado e tempo de preparação para garantir que todas as opções de
respostas sejam oferecidas; se alguma alternativa importante não foi previamente incluída, fortes
desvios podem ocorrer; o respondente pode ser influenciado pelas alternativas apresentadas.
• Requisitos: o questionário deverá ser elaborado por um profissional qualificado na técnica; a população
(ou amostra) deverá ser escolhida com imparcialidade.
Benchmarking
O benchmarking é um método utilizado pelas empresas para melhorar a sua gestão, mediante a realização
contínua e sistemática de levantamentos, comparações e análises de processos, produtos e serviços prestados
por outras empresas, normalmente reconhecidas como representantes das melhores práticas.
O benchmarking gera informações importantes para que as empresas conheçam diferentes maneiras de
lidar com situações e problemas semelhantes e, desta forma, contribui para que possam aperfeiçoar os seus
próprios processos de trabalho e determinar as suas “melhores” práticas.
• Vantagens: aproveita-se o conhecimento adquirido por outras empresas, ou seja, não se inicia o processo
do zero.
• Desvantagens: se mal aplicado pode se configurar em “espionagem industrial” o que é prática ilegal.
• Requisitos: as informações a serem recolhidas precisam ser públicas.

Análise de dados
Esta técnica é utilizada para coletar requisitos a partir da leitura e avaliação de toda a documentação
existente que possa ser relevante à elucidação de requisitos. Entre os diversos documentos possíveis o Guia
PMBOK® cita: planos de negócios, literatura de marketing, fluxos e documentação de processos atuais, modelos
de dados, regras de negócios, registros de problemas, leis, códigos, portarias etc.
• Vantagens: serve como complementação de informações obtidas por outros métodos.
• Desvantagens: pode ser um processo demorado dependendo da quantidade de informação a ser

pesquisada.
• Requisitos: documentos deverão estar disponíveis para avaliação pela equipe de gerenciamento do
projeto.
Tomada de decisão
O processo de tomada de decisão é um dos fatores mais críticos nos projetos. As técnicas para tomada de
decisão em grupo envolvem a avaliação das alternativas apresentadas para resolver uma determinada questão.
Elas podem ajudar na classificação e priorização das melhores alternativas apresentadas.
Existem vários métodos de tomada de decisão que um grupo pode utilizar. O Guia PMBOK® cita: ditadura,
maioria, pluralidade e unanimidade. Na tabela a seguir apresentamos resumidamente esses métodos e as suas
respectivas vantagens e desvantagens.
Método de Descrição Vantagem Desvantagem

decisão
Ditadura O grupo sugere Apropriado quando Não maximiza
ideias e realiza há claramente um as aptidões dos
discussões, mas a especialista na indivíduos do
decisão final cabe questão em causa. grupo. O grupo
apenas a uma Muito rápido. poderá não se
pessoa. empenhar em
implementar uma
decisão tomada
por uma pessoa.
Método de Descrição Vantagem Desvantagem
decisão
Maioria O grupo realiza Utiliza a participação A decisão da
uma votação democrática. maioria pode
acerca de uma Rápido. ofuscar as
determinada perspectivas
questão que possui das minorias,
apenas 2 opções encorajando a
de escolha. A criação de facções.
maioria ganha.
Como a votação é
feita para apenas
2 opções, a que
receber mais de
50% dos votos é a
escolhida.
Pluralidade O grupo realiza Democrático. Útil A decisão pode não
uma votação quando existem agradar a todos,
acerca de uma muitas ideias. pois como existem
determinada várias opções, a
questão que possui escolha não será
VÁRIAS opções de obrigatoriamente
escolha. A opção da maioria.
que receber a
maior quantidade
de votos ganha.
Unanimidade São realizadas Requer a realização Demorado.
diversas rodadas de várias rodadas
até que a decisão de votação, e por
seja tomada por isso dá a impressão
unanimidade. que a decisão final
representa a opinião
de cada um.
Análise de decisão envolvendo múltiplos critérios
Esta é uma técnica que utiliza uma matriz de decisão que permite classificar alternativas a partir da avaliação
de critérios e pesos.
• Vantagens: permite classificar alternativas a partir da avaliação de seus pontos fortes e fracos.
• Desvantagens: pode ser muito complicado chegar a um consenso no estabelecimento dos critérios de
avaliação, pois alguns critérios podem ser mais importantes para algumas partes interessadas do que
para outras. Não funciona muito bem quando existem muitas alternativas.
• Requisitos: critérios de avaliação devem estar bem definidos.

Roteiro para construção:
1. Escolha os critérios para avaliação das alternativas, colocando-os em ordem de importância. Dê pesos
a cada um deles. Por exemplo: de 1 a 5 (os mais relevantes recebem peso 5 e os de menor importância
peso 1);
2. Construa a matriz, colocando as alternativas e os critérios em eixos diferentes;
3. Compare cada alternativa com cada um dos critérios, dando-lhe uma nota à proporção que atenda bem
ou mal a cada critério;
4. Multiplique a nota de cada alternativa pelo peso de cada critério e obtenha a nota ponderada;
5. Some, para cada alternativa, todas as notas ponderadas obtidas;
6. Verifique que alternativa obteve o maior número de pontos: esta é a alternativa vencedora.
Alternativas
Critérios Pesos Realizar uma Organizar uma Promover
palestra missão uma feira
Investimento 5 5 x 30 5 x 20 5 x 10
150 100
Tempo 1 1 x 20 1 x 10 1 x 10
20 10 10
Quantidade de 3 3 x 30 3 x 20 3 x 30
envolvidos 90 60 90
Total 260 170 150
Classificação 1 2 3
Pesos -> 1 a 5
Atendimento aos objetivos -> 10, 20, 30
Representação de dados
Diagrama de afinidade
O diagrama de afinidade é utilizado para organizar em grupos um grande número de ideias, opiniões, ou
preocupações relativas a determinado tópico. O processo se destina a estimular a criatividade e a participação de
todos. Ele funciona melhor com grupos de tamanho limitado (é recomendado, no máximo, oito participantes),
onde as pessoas estão acostumadas a trabalhar juntas. Esta ferramenta é usada frequentemente para organizar
as ideias geradas por brainstorming.
• Vantagens: excelente ferramenta para despertar a criatividade dos participantes do grupo, pois explora
a capacidade intuitiva e o raciocínio lógico.
• Desvantagens: por se tratar de um método um pouco demorado o “diagrama de afinidades” não é

recomendado para a análise de problemas simples e que exijam resolução rápida, apenas para problemas
que apresentem um nível maior de complexidade.
• Requisitos: o facilitador deve ter as mesmas habilidades dos facilitadores de brainstormings. Papeis
coloridos, cartões ou post-its são bem vindos.
Fonte: http://gerisval.blogspot.com.br/2011/01/serie-ferramentas-de-gestao-diagrama-de_11.html
Mapa mental
O mapa mental é um diagrama usado para representar palavras, ideias, tarefas ou outros itens ligados a um
conceito central e dispostos radialmente em volta deste conceito. Ele representa conexões entre porções de
informação sobre um tema ou tarefa.
Os elementos são arranjados intuitivamente de acordo com a importância dos conceitos. Pela representação
das informações e suas conexões de uma maneira gráfica, radial e não linear, o mapa mental estimula a
imaginação e o fluxo natural de ideias livre da rigidez das anotações lineares (listagens).
Esta técnica auxilia o processo de organização do pensamento, ou seja, ajuda a hierarquizar o pensamento
e a compreender melhor as informações sobre determinado conteúdo.
• Vantagens: possibilita visualizar claramente os requisitos e estimula a criatividade dos participantes.
• Desvantagens: se não for bem organizado, o mapa mental pode virar uma verdadeira “confusão mental”
não ajudando em nada.
• Requisitos: software para elaboração do mapa ou papel e canetas coloridas. Ambiente aberto e amigável
para troca de informações.
Roteiro para construção
1. Escreva o tema central no centro de uma folha;
2. Desenhe diversas linhas a partir dele e escreva nos seus extremos palavras-chave, por exemplo,
“objetivos”, “benefícios”, “desenvolvimento”, “técnicas” e “princípios”. Não se preocupe inicialmente
com o tipo de ideias geradas ou com a sua utilidade;
3. Gere ideias a partir de cada uma das palavras-chave relacionadas com o tema central, sem fazer
qualquer tipo de avaliação sobre essas ideias;
4. Estabeleça as relações que quiser entre cada uma delas e faça os esquemas que achar úteis;
5. Analise as combinações geradas e avalie a coerência e exequibilidade.
Fonte: http://professorprojeto.blogspot.com.br/2012/12/como-criar-um-mapa-mental.html

Técnica do grupo nominal
É uma técnica mais estruturada e completa que o brainstorming usada principalmente na solução de
problemas com principal objetivo de desenvolver consenso entre equipe, sem que um integrante influencie o
voto dos demais.
• Desvantagens: se não houver um facilitador experiente, a reunião pode acabar sendo “dominada” pela
gerência. Ou seja, os funcionários ficam receosos de votar “contra” as ideias do chefe.
• Requisitos: é necessária a participação de um grupo representativo de partes interessadas. Deve ser

liderado por um facilitador experiente.
Cada participante escreve suas ideias em um papel;
1. Um facilitador recolhe o material escrito por cada participante e registra as ideias. Pode-se usar um flip
chart ou um quadro negro;
2. As ideias devem ser revistas e discutidas;
3. Deve-se, então, proceder à votação das ideias. Cada participante prioriza as ideias que serão ordenadas
conforme votação.
Observações/Conversas
A observação (em inglês “job shadowing”) é uma técnica que deve ser sistematicamente planejada, registrada
e ligada ao contexto de levantamento que está sendo realizado. Sem estes cuidados, pode resultar apenas em
um conjunto de curiosidades interessantes, mas que pouco agregam ao conhecimento do observador.
Em outras palavras, o observador acompanha como o trabalho é realizado. A partir dessas observações os
requisitos são elaborados.
• Vantagens: é um instrumento de pesquisa e coleta de dados que permite informar o que ocorre de
verdade, na situação real de fato.
• Desvantagens: a observação pode ser enganosa e ilusória; julgamentos e preconceitos podem deturpar
a experiência; as sugestões, opiniões podem enganar nossos sentidos; é um processo que pode ser
demorado.
• Requisitos: o observador deve ter experiência na técnica.
Facilitação
Conhecidas também pelo nome de workshops, as oficinas facilitadas são preparadas de forma que os
integrantes de diferentes áreas participem ativamente na definição de requisitos. Como o próprio nome sugere,
essas oficinas são coordenadas por um facilitador.
• Vantagens: agrega informações de diversas áreas.
• Desvantagens: se não for bem moderada a oficina pode virar uma reunião de amigos; não garante
anonimato fazendo com que participantes não se sintam à vontade de falar o que realmente pensam;
depende muito da escolha dos participantes.
• Requisitos: o facilitador precisa ter habilidades de comunicação para conduzir de forma satisfatória a
oficina. Deve existir um ambiente de confiança e abertura entre todos os participantes. Os participantes
devem ser de áreas distintas para que possam colaborar com visões de diferentes ângulos.
O Guia PMBOK® cita três técnicas famosas:
JAD
O JAD é uma técnica de levantamento interativo, criada por dois profissionais da IBM do Canadá na década
de 1970 onde, em uma ou mais sessões, são reunidos todos os interessados no assunto para tomar as decisões
sobre o mesmo. A técnica tem uma abordagem voltada para o trabalho em equipe e visa definir um modelo de
solução de problemas baseado em CONSENSO.
QFD
O desdobramento da função qualidade é um método específico de ouvir o que dizem os clientes, descobrir
exatamente o que eles querem e, em seguida, utilizar um sistema lógico (matrizes) para determinar a melhor
forma de satisfazer suas necessidades com os recursos existentes. Permite que todos trabalhem em conjunto
para dar aos clientes exatamente o que eles desejam.
História de usuário
Uma história de usuário pode ser caracterizada como uma curta e simples descrição da necessidade do
cliente. Ela normalmente é contada a partir da perspectiva de quem precisa da nova necessidade, sendo
geralmente uma parte interessada, tal como um usuário, um cliente do sistema ou um representante de
negócios do cliente. Uma história de usuário deve explicar bem para quem, o que e por que está sendo criada.
É comum escrever uma história de usuário em post-it’s, fichas ou notas. Elas podem ser coladas em paredes ou
mesas para facilitar o planejamento e discussão. Aliás, essas discussões são mais importantes do que qualquer
texto que esteja escrito nelas.
Diagrama de contexto
O diagrama de contexto descreve visualmente o escopo do produto e permite identificar os limites dos
processos, as áreas envolvidas com o processo e os relacionamentos com outros processos e elementos externos
à empresa (ex.: clientes, fornecedores).
Esse diagrama é muito utilizado no desenvolvimento de software e representa o sistema por um único
processo e suas interligações com as entidades externas, mostrando apenas as interfaces do sistema com o
ambiente em que ele está inserido. Não são apresentados detalhes do processamento interno. As características
representadas são: organizações/sistemas/pessoas que se comunicam com o sistema; dados que o sistema
absorve e deve processar; dados que o sistema gera para o ambiente; fronteira do sistema com o ambiente.
• Vantagens: é uma ferramenta visual que facilita o entendimento dos requisitos do produto/projeto. É
muito utilizada em projetos de software.
• Desvantagens: como possui notação própria pode ser de difícil elaboração por pessoas que não a
conheçam.
• Requisitos: profissional com conhecimentos da notação. Pode ser usada em combinação com a técnica
de brainstorming.

1. Identificar a função principal com um nome que represente claramente o objeto;
2. Identificar os agentes externos que possuem uma ligação com a função principal;
3. Identificar e associar, a cada agente externo, os eventos do negócio que causam a operação da função
principal;
4. Identificar para cada evento do negócio, um ou mais fluxos de dados de entrada que são enviados pelos
agentes externos.
5. Para cada fluxo de dados de entrada, analisar como a função principal responde ao evento, ou seja,
quais fluxos de dados de saída.
Desenhar o diagrama de contexto utilizando os componentes abaixo:
Fluxo de dados Fluxo de dados
Entidade Entidade
Função
Função principal
principal
externa 1 externa 2
Fluxo de dados Fluxo de dados
Exemplo de diagrama de contexto:
CLIENTES GRÁFICA
pedidos
Pedido de reimpressão
fatura
Livros recebidos
Sistema
Sistema de
de pedido
pedido de
de livros
livros
Relatórios de venda
Fatura emitida
CONTABILIDADE
DIREÇÃO
Situação do crédito
Protótipos
Protótipos são representações visuais do produto que está em processo de desenvolvimento. Podem ser
construídos utilizando uma lousa, um papel ou alguma ferramenta de desenho computadorizado.
Existem dois tipos de protótipos:
Protótipos descartáveis ou exploratórios: o protótipo é descartado após a fase inicial de identificação de

requisitos;
Protótipos evolutivos: a cada nova etapa os protótipos tornam-se mais complexos, incorporando novas
funcionalidades e a partir de um determinado momento passam a ser a base para o produto final.
• Vantagens: identificação antecipada de erros e possíveis modificações, reduzindo custo de

desenvolvimento; visualização de como ficará o produto final, proporcionando ao cliente a possibilidade
de mudar o que não está de acordo com o desejado logo no início do projeto.
• Desvantagens: pode causar, em alguns casos, a falsa impressão de que o produto já está pronto (e não
que é um protótipo); custos altos e tempo dedicado à elaboração do protótipo podem ser inviáveis em
pequenos projetos.
• Requisitos: ferramenta apropriada para elaboração do protótipo; equipe preparada para a sua
elaboração.
Inserir uma fase de prototipação no início do projeto assegura um bom resultado final. É um
investimento válido, pois diminui as chances de grandes erros serem identificados tardiamente, gerando um
custo alto para o projeto.
Saídas
Documentação dos requisitos
A documentação de requisitos descreve como os requisitos coletados atendem às necessidades do negócio.
A definição dos requisitos pode começar em um nível mais alto e progressivamente tornar-se mais detalhada.
Sugere-se que este documento deve incluir pelo menos os objetivos do negócio, requisitos funcionais e não-
funcionais, premissas, restrições e impactos em outras áreas.
O Guia PMBOK sugere vários tipos de requisitos, tais como, requisitos de negócios, requisitos das partes
interessadas, requisitos de solução entre outros, mas deve-se ter em mente que:
É muito importante que as principais partes interessadas aprovem a documentação de requisitos,

assinando-a.
Matriz de rastreabilidade dos requisitos

A matriz de rastreabilidade dos requisitos é uma tabela que liga os requisitos às suas origens e os rastreia
durante o ciclo de vida do projeto. A utilização desta tabela ajuda a garantir que cada requisito adiciona valor
através da sua ligação aos objetivos do negócio e aos objetivos do projeto. A matriz também pode fornecer uma
estrutura de gerenciamento das mudanças do escopo do produto.
Fonte: http://eduardo-prola.blogspot.com.br/2014/07/matriz-de-rastreabilidade.html
Definir o escopo (5.3)
Este é um processo crítico para o sucesso do projeto, pois deve gerar a especificação detalhada do escopo
do projeto. Se o escopo não for bem definido, o projeto estará inevitavelmente fadado ao fracasso, uma vez que
é o escopo que determina o que irá (e o que não irá) ser feito/produzido/entregue.
Vamos relembrar que o escopo do produto é diferente do escopo do projeto:
• Escopo do produto: refere-se às características do produto ou serviço que se quer como resultado do
projeto. Exemplo: características que descrevem um novo modelo de automóvel.
• Escopo do projeto: é todo o trabalho a ser realizado dentro do projeto para fornecer um produto
ou serviço. Exemplo: todas as atividades que envolvem o desenvolvimento de um novo modelo de
automóvel.
Um escopo definido de forma apressada vai causar problemas mais tarde. É por isso que este processo é a
oportunidade que as partes interessadas têm para definir suas expectativas em relação ao projeto.
Lembre-se que as alterações no escopo são mais simples no início do projeto, mas ficam cada vez mais
difíceis à medida que o projeto progride, por conta do trabalho, tempo e valores já investidos.
Um ponto muito importante e por vezes negligenciado é que, além de definir o escopo, o gerente do projeto
precisa definir o “não-escopo”, também chamado de Exclusões.
A falta de definição clara e formal, no início do projeto, do que não faz parte do escopo causa uma série
de problemas durante sua execução. Esses problemas podem ser os mais diversos, como: dúvidas do gerente
de projetos e sua equipe quanto ao trabalho a ser realizado, litígios que podem inviabilizar a sua execução etc.
O processo
Entradas
Já vimos anteriormente praticamente todas as entradas deste processo. Por isso, vamos citá-las rapidamente:

Entre os planos de gerenciamento do projeto destaca-se o Plano de gerenciamento do escopo que fornece
orientação sobre como o escopo do projeto será definido, documentado, verificado, gerenciado e controlado
pela equipe de gerenciamento de projetos. Outro item a ser considerado é a Linha de base do escopo que é
composta pela Especificação do escopo, a EAP e o dicionário da EAP e tais itens contém os detalhes das entregas
que precisam ser feitas.
Entre os diversos documentos que podem ser aqui consultados, temos:
• Registro das premissas: este documento indica as premissas e possíveis restrições que podem afetar
o projeto.
• Documentação dos requisitos: já que nem todos os requisitos identificados no processo Coletar
requisitos podem estar incluídos no projeto, o processo Definir o escopo seleciona os requisitos finais
a partir da documentação de requisitos.
• Registro dos riscos: este documento indica quais riscos podem afetar o escopo. Veja que logo no
início do projeto este documento pode ainda não existir, mas deverá ser elaborado à medida que o
projeto andar.

outros.

Aqui temos mais uma vez os ativos de processos organizacionais como entrada de um processo. Neste caso,
podemos considerar como importantes os seguintes ativos: modelos de especificação do escopo do projeto,
Informações históricas e lições aprendidas entre outros.
Mais uma vez a opinião especializada é citada. Neste caso a ideia é recorrer a indivíduos ou grupos que
disponham de treinamento, conhecimento especializado ou competências nas áreas analisadas.
Análise de dados
Entre as diversas formas de análise de dados, destaca-se a análise de alternativas que nada mais é que
identificação das alternativas para o projeto, análise e seleção da melhor opção. A geração de alternativas
é muito utilizada para mapear diferentes possibilidades de execução do projeto. A partir das alternativas
identificadas, escolhe-se a que mais se adeque às necessidades do projeto.
Tomada de decisão
Já vimos esta ferramenta no processo anterior. De forma resumida esta é uma técnica que utiliza uma
matriz de decisão que permite classificar alternativas a partir da avaliação de critérios e pesos.

Entre as habilidades indicadas está a facilitação que é usada em workshops de forma que os integrantes de
diferentes áreas participem ativamente na definição do escopo. Como o próprio nome sugere, essas oficinas são
coordenadas por um facilitador.
Análise de produto
Esta ferramenta/técnica tem como principal objetivo analisar um produto e traduzir as descrições de alto
nível em entregas e requisitos tangíveis. Ela pode ser feita por um especialista ou até mesmo pelos próprios
usuários do produto.
O Guia PMBOK® cita várias técnicas, tais como: estrutura analítica do produto, análise de sistemas, análise
de requisitos, engenharia de sistemas, engenharia de valor e análise de valor. A seguir apresentamos um breve
resumo de cada uma delas.
• Estrutura analítica do produto: esta técnica decompõe o produto em funções menores para que possam
ser estudadas individualmente. Exemplo: Um computador pode ser subdividido em componentes físicos
tais como processador, memória, placa de rede etc. Uma estrutura analítica do produto pode ilustrar a
hierarquia de cada um desses componentes.
• Análise de sistemas: é a atividade que tem como finalidade a realização de estudos de processos a fim
de encontrar o melhor caminho racional para que a informação possa ser processada. Exemplo: uma
grande confecção para abastecer as lojas de roupa desde o pedido até a entrega precisa realizar diversas
atividades. A análise de sistemas irá estudar como cada uma dessas atividades se inter-relaciona e como
o processo pode ser aprimorado.
• Análise de requisitos: é um processo que envolve o estudo das necessidades do usuário para se encontrar
uma definição correta ou completa do sistema ou requisito de software. Exemplo: na construção de um
edifício que irá fornecer espaço para escritórios, os requisitos solicitados pelo cliente diferem de outro
que solicita a construção de um edifício de apartamentos.
• Engenharia de sistemas: é uma abordagem interdisciplinar que torna possível a concretização de

“Sistemas” de elevada complexidade. O seu foco encontra-se em definir, de maneira precoce no ciclo de
desenvolvimento de um sistema, as necessidades do usuário, bem como as funcionalidades requeridas,
realizando a documentação sistemática dos requisitos, e abordando a síntese de projeto e a etapa de
validação de forma a considerar o problema completo. É uma evolução da análise de sistemas, já que
este foca apenas o inter-relacionamento entre as atividades.
• Engenharia de valor: é o emprego sistemático de técnicas comprovadas para a avaliação das funções
de um produto ou tarefa, com o objetivo de encontrar novos caminhos que preencham as funções
necessárias de maneira econômica, preservadas todas as condições de segurança. Desta forma, podemos
afirmar que a Engenharia de Valor é uma técnica utilizada para atingir um ótimo valor do produto com
o menor custo possível. Isto significa produzir um produto com a mesma qualidade e características,
porém a um custo mais baixo.
• Análise de valor: a análise do valor constitui uma abordagem original para reduzir custos de produção
de bens e serviços e aumentar o valor para o usuário. Consiste basicamente em identificar as funções
de determinado produto, avaliá-las e finalmente propor uma forma alternativa de desempenhá-las de
maneira mais conveniente do que a conhecida.
Não se preocupe em memorizar o que cada uma dessas técnicas faz (decomposição do produto,
análise de sistemas, análise de requisitos, engenharia de sistemas, engenharia de valor e análise de valor).
Memorize apenas o nome delas e também que a análise de produto é uma ferramenta/técnica do processo
Definir o escopo.
Saídas
Especificação do escopo do projeto
Esta é a principal saída deste processo. A especificação do escopo do projeto é comumente chamada de
Declaração do escopo do projeto e tem como finalidade documentar os objetivos, entregas e requisitos do
projeto, de modo a usá-los como referência para decisões futuras.
Este documento é uma espécie de acordo entre o projeto e o cliente, especificando com precisão quais
serão os resultados das atividades. Ele também informa a todas às partes interessadas qual será o resultado
obtido quando o trabalho for concluído.
Sugere-se que este documento contenha no mínimo:
• Descrição do escopo do produto: elabora progressivamente as características do produto, serviço ou

resultado descritos no termo de abertura do projeto e na documentação dos requisitos.
• Critérios de aceitação dos produtos: define o processo e critérios de aceitação de produtos, serviços ou
resultados concluídos.
• Entregas do projeto: as entregas incluem tanto as saídas que compõem o produto ou serviço do projeto,
como os resultados auxiliares (relatórios e documentação de gerenciamento do projeto). As entregas
podem ser descritas resumidamente ou em grande detalhe.
• Exclusões do projeto: identifica de modo geral o que é excluído do projeto. Declarar explicitamente o
que está fora do escopo do projeto ajuda no gerenciamento das expectativas das partes interessadas.
A especificação do escopo é a base para um plano de projeto bem sucedido. Tais especificações são utilizadas
para identificar as principais entregas e exclusões de um projeto, definindo as expectativas que moldam o
orçamento do projeto, a linha de base do cronograma e as necessidades de recursos. Isso ajuda a empresa
contratada a identificar as mudanças que ocorrem no trabalho depois que o contrato é feito e ajuda o cliente a
entender o trabalho que está sendo realizado.
Muitas vezes imagina-se que o termo de abertura do projeto e a especificação do escopo do projeto têm o
mesmo conteúdo. Embora parcialmente correta essa afirmação, o que diferencia um documento do outro é o
grau de detalhamento. Assim, o termo de abertura possui informações de alto nível enquanto que a especificação
do escopo contém informações detalhadas.
A especificação de escopo deverá ser aceita formalmente pelo cliente e então ser divulgada e
distribuída para todas as partes interessadas.
Atualizações dos documentos do projeto
Este processo pode gerar atualizações dos documentos, pois como o projeto está evoluindo, outros
documentos já elaborados poderão passar por atualizações. Por exemplo, pode ser que durante a elaboração da
especificação do escopo do projeto alguns requisitos precisem ser alterados por conta de solicitações vindas das
principais partes interessadas. Dessa forma, o registro das partes interessadas, a documentação dos requisitos
e a matriz de rastreabilidade dos requisitos deverão refletir essa alteração.
Criar a EAP (5.4)
A estrutura analítica do projeto (EAP), ou em inglês work breakdown structure (WBS), é muito parecida com
uma árvore genealógica e inclui todo o escopo do projeto, ou seja, todo o trabalho necessário (e somente ele)
para terminar o projeto e atender aos requisitos das Partes interessadas.
A partir da EAP é possível realizarmos estimativas de custo e tempo, identificar riscos e apresentar uma
visão geral do projeto. Por isso, a EAP é considerada o “coração” do projeto e sem ela nenhum projeto deveria
ir em frente.
Segundo o Guia PMBOK®, a EAP é uma decomposição hierárquica orientada à entrega do trabalho a
ser executado. Cada nível descendente da EAP representa uma definição gradualmente mais detalhada do
trabalho do projeto.
Alguns tópicos importantes

Entregas (deliverables)
Uma entrega é qualquer produto, resultado ou serviço único e verificável que é produzido na conclusão de
um processo, uma fase ou um projeto.
Para ser verificável, ele deve atender a padrões predeterminados para sua conclusão, como especificações
de design de um produto (por exemplo, um novo carro) ou uma lista de verificação das etapas concluídas como
parte de um serviço (por exemplo, a manutenção dos equipamentos de uma fábrica).
Uma entrega pode ser originada a partir de múltiplas entregas menores, por exemplo, na construção de um
edifício podemos ter diversas entregas: alicerces, colunas, paredes mestras, elevadores, escadas, acabamento,
garagens etc.
Uma EAP orientada a entregas fornece muitos benefícios ao projeto tais como:
1. Facilita a comunicação entre membros do projeto, patrocinadores e partes interessadas;
2. Auxilia no entendimento do escopo do projeto;
3. Ajuda a equipe a focar no que é mais importante;
4. Facilita a geração de estimativas de tempo, custo, recursos, riscos etc;
5. Identifica falhas de construção do escopo;
6. Permite definir melhor as responsabilidades;
7. Ajuda no controle de mudanças do projeto;
8. Pode ser reutilizada em outros projetos.
Forma de apresentação da EAP

Embora a forma mais usual de representar uma EAP seja a de uma espécie de organograma, como mostrado
na figura a seguir, nada impede ela seja elaborada em forma de lista hierarquizada. Independentemente da
forma escolhida, a EAP deve permitir ao time do projeto estabelecer custos, cronograma, recursos e alocações
de forma mais acurada.
Outra forma de construir a EAP é a partir de uma lista hierarquizada, como mostrada a seguir:
0 Projeto Web 2.0
1 Avaliação de ferramentas
1.1 Aplicações Web
1.1.1 Avaliação aplicações Web
1.1.2 Escolha aplicações Web
1.2 Tecnologias
1.2.1 Avaliação tecnologias
1.2.2 Escolha tecnologias
Pacote de trabalho
O pacote de trabalho é uma entrega ou componente do trabalho do projeto no nível mais baixo de cada
ramo da estrutura analítica do projeto. O pacote de trabalho inclui as atividades do cronograma necessárias
para terminar a entrega do pacote de trabalho ou o componente do trabalho do projeto. É nesse nível que os
custos, recursos e prazos são avaliados e alocados.
Os pacotes de trabalho contêm as atividades do cronograma, e por isso, tais atividades não são representadas
na EAP.
Código de contas e plano de contas

• Código de contas: é um sistema usado para atribuir uma numeração única a cada elemento da EAP. Essa
numeração auxilia o relato do desempenho do projeto.
• Plano de contas do projeto: é baseado no plano de contas (contábil) da organização. Ao se utilizar

um plano de contas para o projeto, os custos do projeto podem ser categorizados por sua natureza
(trabalho, custos de fabricação, viagens etc).
Pacote de planejamento
Segundo o Guia PMBOK®, um pacote de planejamento é um componente da EAP abaixo da conta de
controle e acima do pacote de trabalho, com conteúdo de trabalho conhecido, mas sem atividades detalhadas
do cronograma.
Conta de controle
Segundo o Guia PMBOK®, uma conta de controle é um ponto de controle do gerenciamento onde o escopo,
custo e cronograma são integrados e comparados ao valor agregado para uma medição de desempenho. Essas
contas são localizadas em pontos de gerenciamento selecionados na EAP. Cada conta de controle pode incluir
um ou mais pacotes de trabalho, bem como um ou mais pacotes de planejamento, mas cada um deles deve
estar associado a somente uma conta de controle. Portando, uma conta de controle é um componente da EAP
usada para a contabilidade de custos do projeto.
Código de
conta
Estrutura analítica do produto

A estrutura analítica do produto contém todos os itens necessários para que o produto seja “montado” e
entregue. A EAP, ao contrário, além dos itens necessários para que o produto seja entregue, contém também
os demais itens referentes a entrega do projeto. Por exemplo, na EAP são incluídos itens de gerenciamento do
projeto e itens de aquisição de matérias-primas, que não pertencem à estrutura analítica do produto.
Integração com outras áreas de gerenciamento do projeto

A EAP pode, e deve, ser usada em diversos outros processos como mostrado na tabela a seguir:
Processo Descrição
Definir as atividades (6.2) O que deve ser feito para
desenvolver cada pacote de
trabalho?
Estimar os custos (7.2) Quanto vai custar cada pacote de
trabalho?
Determinar o orçamento (7.3) Quanto vai custar o projeto?
Planejar o gerenciamento da Quais são os requisitos da
qualidade (8.1) qualidade?
Estimar os recursos das Quem fará o trabalho?
atividades (9.2)
Identificar os riscos (11.2) Quais os riscos envolvidos para cada
pacote de trabalho?
Planejar as aquisições (12.1) O que será comprado?
O que será terceirizado?
O Processo
Entradas
Já vimos anteriormente praticamente todas as entradas deste processo. Por isso, vamos citá-las rapidamente.

Do plano de gerenciamento do projeto usaremos o plano de gerenciamento do escopo do projeto que
fornece orientação sobre como o escopo será definido, documentado, verificado, gerenciado e controlado pela
equipe de gerenciamento de projetos.
• Especificação do escopo do projeto: na especificação do escopo do projeto estão documentadas as
entregas que devem ser feitas para satisfazer as necessidades do cliente.
• Documentação dos requisitos: a documentação dos requisitos ajuda a entender com mais detalhes o
que precisa ser produzido como resultado final do projeto.

Entre os fatores ambientais que podem afetar este processo, podemos citar padrões do setor (ligados à
natureza do projeto). Um exemplo seriam as normas que orientam a fabricação de brinquedos. Mas qualquer
norma, padrão ou legislação que afete o desenvolvimento do produto deve ser considerada aqui.

Entre os ativos de processos organizacionais que podem auxiliar neste processo, citamos: os modelos
e procedimentos já existentes na organização (caso existam!), as EAPs, e as lições aprendidas de projetos já
encerrados.
O uso de EAP´s de projetos anteriores não fere em nada o princípio de que os projetos são únicos!
Você não precisa começar do zero toda vez que iniciar um projeto. “Recicle” sempre que possível o
conhecimento já adquirido.
Mais uma vez a opinião especializada é citada. Neste caso a ideia é recorrer a indivíduos ou grupos que
disponham de treinamento, conhecimento especializado ou competências nas áreas analisadas. Nem pense em
desenvolver a EAP sem consultar os especialistas, a não ser que você mesmo seja um especialista no produto
que será entregue pelo projeto.
Decomposição
A decomposição é uma técnica para subdividir entregas em unidades menores e mais facilmente gerenciáveis.
A ideia é subdividir as entregas até o ponto em que se torne mais simples realizar o planejamento, execução,
monitoramento e controle dessas entregas.
A EAP, à medida que é decomposta, vai ganhando níveis descendentes. E embora o gerente do projeto
possa determinar a quantidade de níveis que terá a EAP (e consequentemente o nível de detalhamento), é certo
afirmar que o primeiro nível será sempre o nível do projeto completo.
O nível mais baixo de uma EAP é o pacote de trabalho. Os pacotes de trabalho contém as atividades do
cronograma, e por isso, tais atividades não são representadas na EAP.
A EAP não demonstra as sequências de trabalho de seus itens, isto é, não mostra a sequência em que
os itens devem ser executados (quem faz isso é o diagrama de rede que veremos em capítulos posteriores).
A EAP deve conter 100% do trabalho do projeto, ou seja, todas as entregas (internas e externas)
precisam estar representadas na EAP. Entregas não relacionadas na EAP não fazem parte do projeto!
Observações importantes!
Veja que para grandes projetos a EAP pode ficar monstruosa caso o gerente do projeto detalhe todas as
entregas em um mesmo gráfico. Por conta disso, o Guia PMBOK® sugere algumas formas de decompô-la:
• Principais entregas: esta é a forma usual em projetos de pequeno e médio porte. No primeiro nível da
decomposição (ou seja, no SEGUNDO nível da EAP) são colocadas as principais entregas do projeto. A
partir daí, cada entrega é decomposta até o nível do Pacote de trabalho;
• Subprojetos: grandes projetos podem ser subdivididos em subprojetos, por isso no primeiro nível da
decomposição (ou seja, no SEGUNDO nível da EAP) são colocados os subprojetos. Neste caso, cada
gerente de subprojeto irá elaborar sua própria EAP;
• Fases: grandes projetos também podem ser subdivididos em fases, e sendo assim, o primeiro nível da
decomposição (ou seja, o SEGUNDO nível da EAP) representará cada uma dessas fases.
A decomposição até o pacote de trabalho pode não ser viável para uma entrega que será realizada em
um futuro distante, por isso podemos usar o planejamento em ondas sucessivas que é normalmente utilizado
em projetos de longa duração (normalmente acima de um ano), onde as incertezas são grandes demais para
podermos planejar em detalhes alguns itens da EAP.
Assim, planejamos de forma detalhada o que se conhece e de forma mais superficial o que não se conhece.
E a medida que o projeto avança e o conhecimento a seu respeito aumenta, passamos a refinar os elementos
da EAP ainda não detalhados.
1. Coloque no primeiro nível o nome do projeto;
2. Coloque no segundo nível as principais entregas do projeto ou as fases que estabelecem o ciclo de vida
do projeto;
3. Acrescente as subentregas necessárias para que seja alcançado o sucesso do projeto, em quantos níveis
forem necessários;
4. Para cada entrega colocada na EAP, avalie se ela é gerenciável, isto é, se poderá ser detalhada pelas
outras áreas de conhecimento (custo, tempo, qualidade, riscos, recursos etc);
5. Se ainda não for gerenciável subdivida em duas ou mais subentregas;
6. Revise e refine a EAP até completar o planejamento do projeto.
Dicas importantes!!!
• Identifique cada uma das entregas da EAP com um código para poder rastreá-las posteriormente;
• Utilize substantivos para nomear cada uma das entregas;
• Um elemento da EAP não pode ter somente um filho, pois o filho será exatamente igual ao pai;
• O objetivo da EAP é documentar entregas (= “coisas”: produtos e subprodutos) e não atividades, por
isso NUNCA coloque atividades na sua EAP;
• O maior nível de detalhamento da EAP são os pacotes de trabalho, e eles estão nos níveis mais baixos
da EAP;
• A EAP deve ser completa, organizada e pequena o suficiente para tornar possível a medição do progresso,
e não detalhada demais para se tornar, ela mesma, um obstáculo à realização do projeto;
• Uma dica é a regra 8-80 que sugere que um pacote de trabalho ocupe entre 8 e 80 horas de duração
para projetos de pequeno e médio porte. Já para projetos maiores, a dica é utilizar 300 horas;
• A EAP precisa ser revisada com as partes interessadas.
Saídas
Linha de base do escopo
A principal saída deste processo é a linha de base do escopo que é um componente importantíssimo do
gerenciamento do projeto e é composta por:
• Especificação do escopo do projeto: apresenta a descrição do escopo do projeto, as entregas do projeto

e critérios de aceitação do usuário em relação ao produto;
• EAP: define cada entrega e a decomposição das entregas em pacotes de trabalho;
• Pacote de trabalho: como já vimos, este é o nível mais baixo da EAP.

• Pacote de planejamento: esta abaixo da contra de controle e acima do pacote de trabalho.
• Dicionário da EAP: apresenta uma descrição detalhada do trabalho e documentação técnica para cada
elemento da EAP.
Dos itens indicados apenas não vimos ainda o dicionário da EAP, que veremos na sequência.
O dicionário da EAP fornece descrições mais detalhadas dos componentes da EAP, ou seja, nele são
detalhados os pacotes de trabalho. Entre as informações que podem constar do dicionário da EAP sugerimos:
• Identificador – normalmente é o mesmo código do elemento da EAP;

• Nome do componente ou do pacote de trabalho;
• Descrição do trabalho a ser realizado;
• Restrições e premissas;
• Responsável pela atividade;
• Custos estimados;
• Critérios de aceitação;
• Referência técnicas.
A tabela a seguir mostra um exemplo de dicionário de EAP onde foram detalhados alguns pacotes de
trabalho.
EAP ID Pacote de Descrição Critério de Responsável
Trabalho Aceitação
1.1.1 Avaliação Verificar ferramentas Relatório com prós e Montgomery
aplicações disponíveis no mercado: contras detalhados, Scott
Web bem como
Blogs, Wikis, Tags,
valores para sua
Networking, Mash-ups
implementação
1.2.1 Avaliação Verificar tecnologias Relatório com prós e Geordi Laforge
tecnologias existentes no mercado: contras detalhados,
bem como
Web Services, AJAX, RSS etc
valores para sua
implementação
2.1.3 Compra dos Executar atividades para Equipamentos Quark
servidores compra dos servidores: comprados conforme
especificação.
- Especificar requisitos
de hardware; Cotar
equipamentos; Criar Ordem
de Compra e Efetuar
Compra
A linha de base do escopo será a referência para o monitoramento e controle do projeto, ou seja, será
usada para avaliar se o projeto está andando conforme o planejado.
Atualização dos documentos do projeto

Este processo pode gerar atualizações dos documentos do projeto, pois como o projeto está sempre
evoluindo, outros documentos já elaborados poderão passar por atualizações. Por exemplo, pode ser que
durante a elaboração da EAP algumas entregas precisem ser alteradas. Dessa forma, a especificação do escopo
do projeto e a documentação dos requisitos deverão refletir essa alteração.
Planejando o Cronograma
O gerenciamento do cronograma em projetos é uma das práticas mais importantes e complexas para um
gerente de projetos em função do elevado número de variáveis que podem resultar em impactos negativos nos
prazos do projeto. Embora o uso de cronogramas seja algo corriqueiro em uma organização, a sua elaboração
nem sempre é tão trivial. Muitas falhas ocorrem durante o dimensionamento dos prazos de execução das
atividades.
Os atrasos gerados por falhas são muito danosos, pois, além de quase sempre comprometerem o custo,
retardam a entrega dos seus produtos e, consequentemente, a disponibilidade de iniciar a sua utilização. É por
conta disso que o Guia PMBOK® traz seis processos de planejamento que se executados corretamente ajudarão
o projeto a ser entregue na data acordada:
• Planejar o gerenciamento do cronograma (6.1);
• Definir as atividades (6.2);
• Sequenciar as atividades (6.3);
• Estimar as durações das atividades (6.4);
• Desenvolver o cronograma (6.5).
Observe que você deve adaptar os processos propostos pelo Guia PMBOK® às necessidades atuais do
seu projeto, uma vez que nem todos os documentos precisarão ser elaborados para que você gerencie seu
projeto com sucesso.

É de extrema importância que os seguintes pontos sejam levados em conta para o sucesso do projeto:
• Examinar e consolidar bem o escopo antes de estimar os prazos do projeto.
• Não tentar enganar a si mesmo e nem aos outros, elaborando planejamentos inviáveis que não poderão
ser cumpridos.
• Não aceitar o impulso de estimar os prazos do projeto com base no prazo desejado.
• Verificar informações históricas de outros projetos similares para ter como base ao estimar os prazos de
um novo projeto.
• Os recursos considerados no projeto devem possuir disponibilidade real.
• A elaboração do cronograma deve envolver preferencialmente toda a equipe e representar um

consenso geral; depois de concluído, deve ser bem divulgado, para se tornar do conhecimento de todos
os envolvidos e contar com o seu comprometimento.
• Procurar envolver ao máximo também os clientes, não só no planejamento, como também na execução
do projeto.
• Obter o máximo de informações referentes às condições para a execução do projeto (cultura de trabalho
do cliente, suas normas de segurança, de projeto, de obra e outras praticadas; acordos sindicais vigentes
no local da execução do projeto; calendário religioso/festivo e outros costumes, regionalidades ou leis
locais que possam afetar o desenvolvimento do projeto).
• Analisar e considerar no planejamento os riscos do projeto.
• Monitorar a execução do projeto e adequar o cronograma sempre que for preciso.
• Promover ações efetivas, envolver e incentivar a equipe para recuperar o cronograma, quando forem
identificados atrasos.
Planejar o gerenciamento do cronograma (6.1)
O objetivo deste processo é gerar o plano de gerenciamento do cronograma do projeto que estabelece
as políticas, procedimentos e documentação para planejar, desenvolver, gerenciar, executar e controlar o
cronograma do projeto.
O principal benefício deste processo é fornecer orientação de como o cronograma será gerenciado durante
todo o projeto. Ele também estabelece regras sobre como o cronograma será alterado e/ou atualizado.
Elaboração iterativa de cronograma com lista de pendências (backlog)

Esta é a forma usual de desenvolvimento de cronogramas quando são usados os métodos ágeis. É uma
espécie de planejamento em ondas sucessivas, onde cada onda é uma iteração. Os requisitos de usuário são
escritos em forma de histórias de usuário e estes são priorizados e detalhados pouco antes de sua efetiva
construção. O backlog nada mais é do que uma lista de histórias de usuário que serão desenvolvidas.
Cronograma sob demanda

Este tipo de cronograma é normalmente usado quando se aplica o sistema Kanban. Esse sistema tem por
característica o desenvolvimento por demada, ou seja não depende da elaboração prévia de um cronograma
tampouco de uma iteração. Ele é comumente usado em atividades de manutenção de software, onde as
demandas são urgentes e precisam ser realizadas assim que um recurso esteja disponível.
O processo
Entradas
Observe que as entradas deste processo são exatamente as mesmas entradas do processo Planejar o
gerenciamento do escopo do projeto, sendo que aqui o foco será no planejamento do cronograma. Vamos
então fazer uma breve revisão.

O termo de abertura do projeto é uma entrada muito importante, pois ele contém a lista dos principais
marcos do projeto. Esses marcos serão acrescentados ao cronograma para que possam ser acompanhados e
gerenciados.

O plano de gerenciamento do projeto contém os planos auxiliares aprovados que podem influenciar na
abordagem adotada no planejamento e gerenciamento do cronograma. Ele também contém a linha de base do
escopo que é uma importante fonte de informações para o desenvolvimento do cronograma. (Você lembra que
a linha de base do escopo é composta principalmente pela especificação do escopo do projeto, EAP e dicionário
da EAP?).
O cronograma do projeto será derivado diretamente da EAP, que como já sabemos, contém as entregas e
os pacotes de trabalho.
Informações sobre custos, riscos e comunicações também podem influenciar a elaboração do cronograma.
Por exemplo, durante o processo de planejamento dos riscos a equipe de gerenciamento decide que serão
reservadas 2 horas semanais para acompanhamento dos riscos. Essas horas deverão estar refletidas no
cronograma.
Observe que logo no início do projeto o plano de gerenciamento do projeto não conterá todas essas
informações sobre custos, riscos e comunicações, pois ele estará apenas começando a ser elaborado, sendo
nesse momento um “rascunho” inicial. À medida que o planejamento for evoluindo, o plano de gerenciamento
do projeto conterá mais detalhes (de outros planos auxiliares) e permitirá que o plano de gerenciamento do
cronograma seja revisado a fim de refletir essas alterações.
Outro item importante é a abordagem de desenvolvimento que será utilizada, pois ela indica que tipo
cronograma e que ferramentas serão utilizadas. Assim, se for uma abordagem ágil, é possivel que o cronograma
seja acompanhado com um quadro Kanban juntamente com alguma ferramenta de software específica para
esse tipo de abordagem.

Veja que mais uma vez temos os fatores ambientais da empresa como entrada de um processo. E, como
demonstra o Guia PMBOK®, os fatores mais utilizados por este processo são: a estrutura organizacional, a
cultura organizacional, a disponibilidade dos recursos, as habilidades dos recursos, o software de planejamento
do cronograma e os bancos de dados comerciais.

Como já vimos, os ativos de processos organizacionais se referem à toda informação acumulada pela
empresa, e neste caso serão considerados os seguintes: ferramentas de monitoramento e controle, informações
históricas, políticas e procedimentos ligados ao controle do cronograma, modelos, procedimentos de controle
de mudanças e procedimentos de controles de riscos.
Como já vimos em diversos outros processos, os especialistas devem ser consultados sempre. Eles são uma
importante fonte de informação, pois podem auxiliar na indicação das melhores ferramentas e métodos, com
base em suas experiências em projetos anteriores. Neste caso eles podem auxiliar com o desenvolvimento
do cronograma fornecendo informações sobre qual metodologia usar, por exemplo, ciclo de vida preditivo ou
adapativo, qual software de elaboração de cronograma e etc.
Análise de dados
As técnicas de análise de dados aqui usadas se referem à análise de alternativas. E como tal, avaliam as
diferentes possibilidades que podem ser utilizadas, tais como: metodologias a serem adotadas, softwares a
serem usados, nível de detalhamento necessário, duração das ondas de planejamento entre outras.
Reuniões
A equipe de gerenciamento do projeto pode convocar reuniões com o patrocinador, partes interessadas e
especialistas para desenvolver o plano de gerenciamento do cronograma.
Saídas
Plano de gerenciamento do cronograma
Como resultado deste processo teremos o plano de gerenciamento do cronograma do projeto que
fornece orientação sobre como o cronograma do projeto será definido, documentado, verificado, gerenciado e
controlado pela equipe de gerenciamento. Os componentes desse plano devem incluir:
• Desenvolvimento do modelo do cronograma do projeto: deve-se definir qual é o método de elaboração

do cronograma. Usualmente temos o método do caminho crítico e o método da corrente crítica. Iremos
ver esses métodos nos capítulos seguintes.
• Duração do lançamento e iteração: quando se usa um ciclo de vida adaptativo, deve-se elaborar
o cronograma com as datas de entrega de cada iteração. E neste caso, essas datas são fixas, já que
iterações tem duração fixa pré-determinada.
• Nível de exatidão: este elemento descreve a forma de arredondamento que será utilizada no cálculo da
duração das atividades. Por exemplo, se o cálculo da duração da atividade retornar 4 dias e meio para
uma atividade muito complexa, você pode considerar que essa atividade terá a duração de uma semana
(5 dias úteis).
• Unidade de medida: aqui se define se o cronograma será modelado em horas, dias, semanas etc.
• Manutenção do modelo do cronograma do projeto: aqui se indica qual será o processo a ser adotado
toda vez que uma alteração tiver que ser feita.
• Limites de controle: aqui são estabelecidos limites de variação dentro dos quais nenhuma atitude será
tomada. Por exemplo, pode-se estabelecer que uma variação de 10% nos prazos de entregas é aceitável.
Caso haja uma variação de 15%, aí sim algo deve ser feito.
• Regras para medição do desempenho: para que se possa verificar o cumprimento do cronograma do
projeto, devem ser estabelecidas as regras para medir o desempenho. Um dos métodos mais utilizados
é o gerenciamento do valor agregado (GVA), mas qualquer outro método pode ser utilizado, desde
que se consiga medir de forma consistente como está o andamento do projeto. (Veremos o GVA nos
capítulos referentes ao Monitoramento - Custos).
• Formatos de relatórios: o plano de gerenciamento do cronograma estabelece os modelos de relatórios

que serão apresentados para as principais partes interessadas, bem como a periodicidade de sua
emissão.
Definir as atividades (6.2)
São as atividades que geram os resultados do projeto. É por isso que neste processo são identificadas as
ações específicas a serem realizadas para produzir as entregas.
Já vimos que na EAP o nível mais baixo (e por consequência, o mais detalhado) é o pacote de trabalho. Pois
bem, é neste processo que os pacotes de trabalho são decompostos em componentes ainda menores chamados
de atividades. Essas atividades representam o trabalho necessário para completar o pacote de trabalho.
O processo
Entradas
Entre os diversos componentes do plano de gerenciamento do projeto, estão:
• Plano de gerenciamento do cronograma: É óbvio que esta seria uma das entradas do processo, não
é mesmo? Neste caso iremos extrair desse plano as informações referentes ao nível de detalhamento
necessário de decomposição das atividades, para que depois seja fácil o seu gerenciamento.
• Linha de base do escopo: Já vimos que a linha de base do escopo é composta pela especificação do
escopo do projeto, EAP e dicionário da EAP. Além disso, a EAP é a principal fonte de informação para
a construção do cronograma. E complementarmente, as entregas, as restrições e as premissas são
extraídas da especificação do escopo do projeto e do dicionário da EAP.

Veja que mais uma vez temos os fatores ambientais da empresa como entrada de um processo. Segundo o
Guia PMBOK® são eles: estrutura organizacional, cultura organizacional, software corporativo de planejamento
do cronograma, bancos de dados comerciais.

Neste caso os ativos a serem considerados: base de conhecimento que contenham listas de atividades de
outros projetos similares, processos padronizados, modelos de listas, metodologia de elaboração do cronograma.
É muito importante que especialistas sejam envolvidos na definição das atividades. Os membros da equipe
do projeto também são boa fonte de informação, pois afinal são eles que executarão o trabalho.
Decomposição
A decomposição é uma técnica para subdividir entregas em unidades menores e mais facilmente gerenciáveis.
A ideia é subdividir as entregas até o ponto em que se torne mais simples realizar o planejamento, execução,
monitoramento e controle.
No planejamento do escopo vimos que esta técnica é utilizada para dividir o escopo do projeto até o nível
do pacote de trabalho durante a construção da EAP.
Agora, neste processo, os pacotes de trabalho serão decompostos em atividades que representam
efetivamente a execução do trabalho do projeto, uma vez que o cronograma é composto por atividades.
Planejamento em ondas sucessivas

Através do planejamento em ondas sucessivas as atividades mais próximas ao tempo atual são definidas
de forma mais detalhada enquanto as atividades que serão realizadas no futuro são definidas de forma menos
específica. É importante salientar que, apesar das atividades a serem executadas futuramente serem menos
detalhadas, elas não podem ser deixadas de lado, nem muito menos ter seu valor diminuído em razão desse
desconhecimento.
Reuniões
especialistas para verificar a melhor forma de definir as atividades do projeto.
Saídas
Lista de atividades
A lista de atividades deve ser muito abrangente e deve conter TODAS as atividades necessárias para o
término do projeto. Além, obviamente, do nome da atividade, essa lista deve conter informações tais como:
descrição do escopo do trabalho de cada atividade de forma detalhada (para que os membros da equipe do
projeto consigam entender o que deverá ser executado) e código da atividade (que é um identificador único
para ela).
Atributos das atividades
No início do projeto o documento atributos das atividades contém basicamente as mesmas informações
presentes na lista das atividades (nome, código e descrição), mas à medida que o planejamento e a execução do
projeto avançam o número de atributos tende a crescer, sendo incorporados a essa lista outros itens tais como
o nome do responsável pela atividade, as atividades predecessoras e sucessoras, datas, restrições, premissas
ou qualquer outro atributo que seja relevante ao desenvolvimento da atividade e do projeto. Esses atributos
devem ser devidamente documentados para que possam ser consultados quando for necessário.
A lista de atividades pode conter também as informações dos atributos dessas atividades, mas não há
impedimento de que sejam utilizados dois documentos separadamente: uma lista de atividades e um documento
de atributos dessas atividades.
Lista de marcos
A lista de marcos identifica pontos importantes no projeto, mas que não envolvem trabalho, tempo, custo
ou recursos associados. São datas de referência que indicam que o projeto alcançou um ponto importante.
Marcos são utilizados para identificar o início ou a conclusão de alguma entrega importante. Veremos com mais
detalhes nos capítulos seguintes como os marcos são representados nos cronogramas.
Se a entrega indicada pelo Marco não for aprovada, o projeto não deve prosseguir. Marcos são muito
importantes para o controle do andamento do projeto.
Os marcos não são padronizados pelo Guia PMBOK® , uma vez que o ciclo de vida de um projeto também
não o é. Assim podem existir marcos de diversos tipos, como por exemplo:
• Internos ou externos: indicam uma entrega importante que será realizada por algum fornecedor externo
ou interno. Os marcos externos geram mais riscos para o projeto do que os internos, já que temos pouco
controle sobre eles.
• Marcos executivos: são utilizados para reportar o status do projeto para os gerentes, diretores e sócios;
• Marcos financeiros: mostram os momentos de desembolso financeiro. São muito importantes para
indicar as datas de pagamento de fornecedores.
• Marcos-chave: mostram pontos importantes do projeto, tais como os mostrados na figura a seguir.
Mas veja que não há necessidade de classificá-los por tipos, faça isso caso o projeto seja muito grande. Em
projetos menores, é possível gerenciá-los sem precisar classificá-los.
Solicitações de mudança
Depois que se estabelece a linha de base do projeto e ele começa a ser desenvolvido, podemos descobrir
que atividades anteriormente planejadas não serão necessárias, ou ainda, atividades não planejadas precisarão
ser adicionadas. Por isso, é necessária que sejam abertas Solicitações de mudança para refletir essas alterações.
Atualizações no plano de gerenciamento do projeto

Os esforços de gerenciamento do cronograma criam mudanças no plano de gerenciamento do projeto, pois
pacotes de trabalho podem ser removidos, adicionados ou re-alocados. Os principais componentes que podem
sofrer alterações são a linha de base do cronograma, justamente pelas alterações dos pacotes de trabalho
que podem gerar mudanças em entregas e a linha de base de custos que veremos quando abordarmos o
planejamento dos custos.
Sequenciar as atividades (6.3)
Uma vez identificadas, as atividades precisam ser sequenciadas, isto é, colocadas em uma ordem lógica de
execução para que possamos descobrir as dependências entre si.
Por exemplo, vamos supor que você precisa construir um muro. A pintura do muro só poderá ser feita depois
que o muro tiver sido construído, correto? Pois bem, muitas vezes encontramos em projetos sequenciamentos
totalmente “fora de órbita”, ou seja, projetos em que a pintura do muro seria feita antes mesmo do muro ter
sido construído!
Por isso que o processo sequenciar as atividades exige muita atenção, já que qualquer erro neste ponto
pode comprometer o projeto em fases posteriores. Decisões equivocadas em relação ao tipo de dependência
entre as atividades podem provocar o fracasso total do projeto.
Apesar de recomendado, o uso de um programa de computador para geração do sequenciamento não

é obrigatório, mas quanto maior a quantidade de atividades envolvidas, maior será a complexidade deste
processo.
O processo
Entradas
Do plano de gerenciamento do projeto, os seguintes itens em particular serão utilizados neste processo:
• Plano de gerenciamento do cronograma: iremos extrair desse plano as informações referentes ao

método e a ferramenta que será utilizada para o sequenciamento das atividades.
• Linha de base do escopo: já vimos que a linha de base do escopo é composta pela especificação do
Entre os documentos do projeto, os seguintes serão utilizados neste processo:
• Atributos das atividades: os atributos das atividades podem conter as sequências necessárias de eventos
ou relacionamentos lógicos das atividades. Essas informações influenciam, e muito, o sequenciamento
das atividades.
• Lista de atividades: obviamente, se vamos sequenciar as atividades, precisaremos da lista completa de

atividades do projeto.
• Registro de premissas: este documento, elaborado durante a Iniciação do projeto, contém informações
que podem influenciar como as atividades serão sequenciadas. Inclusive, gerando riscos ao projeto por
conta de antecipações e esperas previstas.
• Lista de marcos: esta lista pode conter datas agendadas de determinados marcos que podem influenciar
a maneira como as atividades serão sequenciadas.

Dentro dos fatores ambientais que serão considerados neste processo temos: padrões governamentais e/
ou de setores econômicos, SIGP (sistema de gerenciamento de projetos), ferramenta de cronograma e sistemas
de autorização de trabalho.

Como já vimos os ativos se referem a toda informação acumulada pela empresa, e neste caso serão
considerados: base de conhecimento que contenha metodologias de agendamento, processos padronizados e
modelos de redes de cronograma, entre outros.
Método do diagrama de precedência
A ferramenta de diagrama mais utilizada atualmente é o método do diagrama de precedência (MDP) ou,
como é conhecido também, atividade no nó (ANN). Quadrados ou retângulos representam as atividades (ou
nós), e as flechas/setas indicam as relações lógicas entre as atividades.
Quadrados / Retângulos representam as atividades Setas indicam as dependências
A B C D
INÍCIO E F FIM
G H I
Veja que o diagrama de rede é uma representação gráfica do sequenciamento das atividades. Observe
também que todas as atividades (e marcos) devem ser conectadas por pelo menos uma atividade antecessora e
uma sucessora, com exceção das atividades de início e fim.
O MDP define quatro tipos de relacionamentos lógicos entre as atividades:
• (TI) - Término para início: este relacionamento significa que a atividade A precisa ser completada
antes que a atividade B possa começar. Este é o relacionamento mais comumente usado. Exemplo: Só
podemos pintar um muro depois que ele estiver construído.
Término para início

S T Q Q S
Predecessora
(A)
Sucessora
(B)
• (TT) - Término para término: a atividade A precisa ser completada para que a atividade B possa ser
completada. Idealmente as atividades deveriam acabar ao mesmo tempo, mas nem sempre é o que
acontece. Exemplo: Se tivermos duas atividades, “Adicionar fiação” e “Inspecionar sistema elétrico”,
não será possível concluir “Inspecionar sistema elétrico” antes do término de “Adicionar fiação”.
Término para término
S T Q Q S
Predecessora
(A)
Sucessora
(B)
• (II) - Início para início: A atividade A precisa começar para que a atividade B inicie. Exemplo: Se temos
que construir e pintar um muro bem grande, podemos iniciar a pintura de uma parte mesmo antes que
terminemos de construí-lo.
Início para início

S T Q Q S
Predecessora
(A)
Sucessora
(B)
• (IT) - Início para término: Este relacionamento é o mais raro e requer que a atividade A inicie para que
a atividade B possa ser finalizada. Exemplo: Um servidor de dados antigo só pode ser desligado após o
início do funcionamento do novo.
Algumas dicas importantes:
• O relacionamento Início para término é raramente utilizado.
• Duas atividades podem ter mais de um relacionamento entre si; no entanto somente um deles deve ser
escolhido, o que gere o menor impacto negativo em prazo, custo e recursos.
Início para término
S T Q Q S
Predecessora
(A)
Sucessora
(B)
Método do diagrama de setas (MDS)

Não é certo que este tipo de diagrama esteja presente no seu Exame de certificação por conta das limitações
que ele tem e também por conta de que praticamente todos os softwares de controle de cronograma utilizam
o modelo MDP. Mas, por via das dúvidas é bom que você saiba um pouco sobre ele.
O método do diagrama de setas (MDS) é um método de construção de um diagrama de rede do cronograma

do projeto que usa setas para representar atividades e as conecta nos nós para mostrar suas dependências. Esta
técnica é também chamada de atividade na seta (ANS) e é menos adotada do que o MDP, pois usa somente
dependências do tipo Término para início e pode exigir o uso de atividades “fantasmas” (ou “dummy”), que
são mostradas como linhas pontilhadas, de forma a definir corretamente todos os relacionamentos lógicos.
Como as atividades fantasmas não são atividades reais do cronograma (não possuem conteúdo de trabalho), é
atribuída a elas uma duração nula para fins de análise de rede do cronograma.
Círculos (nós) representam dependências Setas indicam as atividades
B C
1 2 3
D
A
E F
INÍCIO 4 5 FIM
G I
6 7
H
Este diagrama possui várias particularidades que vamos abordar a seguir tomando como exemplo o
diagrama da figura anterior:
• Um nó recebendo uma seta ou mais setas indica que a atividade acabou. Por exemplo, o nó 1 indica
que a atividade A foi finalizada.
• Veja que a atividade F só pode começar quando as atividades A e E forem concluídas. E para complicar
ainda mais a situação, não conseguimos ligar a atividade A diretamente na F, porque a atividade B
depende exclusivamente de A.
• Então, para representarmos as dependências da atividade F, precisamos de um nó “agregador” de
atividades que é o nó 4.
• Além do nó agregador, precisamos acrescentar a seta pontilhada ligando o nó 1 ao nó 4. Essa seta
pontilhada representa uma atividade “fantasma” sem duração que precisa ser colocada no gráfico para
que as precedências se liguem logicamente.
• Veja que se você ligar o nó 1 ao 4 com uma seta normal, estará acrescentando uma nova atividade ao
diagrama gerando uma inconsistência na rede do cronograma.
Este diagrama pode parecer complicado, (e às vezes é), mas se estiver com pouco tempo de estudo
guarde que o MDS possui atividades fantasmas, que as atividades são representadas pelas setas e as
precedências pelos nós, e que as atividades fantasma (“dummy”) tem duração nula.
Técnica de avaliação e análise gráfica (GERT)

Está é outra incerteza no seu Exame PMP, mas como este método de desenho de diagrama de rede já esteve
presente nos exames das versões passadas do Guia PMBOK®, vale a pena comentarmos algumas coisas sobre
ele.
O GERT (Graphical Evaluation and Review Technique) é um método de desenho de diagrama em rede que
permite um caminho de retorno entre atividades (loop), coisa que o MDP e o MDS não permitem. Além disso,
este diagrama também permite a indicação de caminhos condicionais, ou seja, dependendo do resultado de
uma atividade, o caminho pode seguir por um ramo ou por outro. Veja a figura aseguir que tem exemplos
dessas duas particularidades do GERT:
Reprovado
B Loop Aprovado?
Aprovado
C D
Loop
Cateter =
A 0,05mm?
Sim B
Não
C D
Condicional
Integração e determinação de dependência

A dependência entre atividades é o relacionamento entre o início ou término de uma atividade e o início ou
término de outra atividade. Com cada dependência definimos que atividades estão guiando outras atividades
do projeto.
Predecessora Dependência entre

atividades
Sucessora
Existem quatro tipos de dependência:
• Dependências obrigatórias: não podem ser mudadas já que dependem da natureza do trabalho. Também
podem ser obrigatórias por conta de exigências legais ou contratuais. São chamadas de hard logic ou
hard dependencies. Exemplo: Não se pode colocar o azulejo em uma parede sem antes construí-la.
As dependências obrigatórias NÃO podem ser consideradas como restrições do projeto!

• Dependências arbitradas: são baseadas nas melhores práticas de mercado ou algum aspecto diferencial
do projeto onde uma sequência alternativa é preferida à sequência original. São chamadas também de
lógica preferida, lógica preferencial ou soft logic. Exemplo: Devemos aplicar primeiro o gesso do teto
antes de pintar a parede, pois normalmente a aplicação do gesso “destrói” a pintura. Observe que nada
o impediria de pintar primeiro a parede, mas com certeza você seria obrigado a pintá-la novamente
depois da aplicação do gesso.
As dependências arbitradas precisam ser totalmente documentadas, pois podem gerar folgas e limitar
as opções de agendamento.
• Dependências externas: dependem de atividades fora do domínio e controle do projeto. Exemplo:

contratação de empresa para construção da piscina.
Muitas atividades e projetos atrasam em função do desconhecimento ou até descaso por parte da
equipe e do gerente do projeto quanto à dependência externa. Por isso, atenção às atividades ligadas à
fornecedores e ao Governo (licenças ambientais, leis etc).
• Dependências internas: envolvem relações de precedência entre as atividades do projeto e que estão
sob o controle da equipe do projeto.
Antecipações e esperas
É fundamental também que sejam consideradas as antecipações (leads) e os atrasos (lags) já que podem
influir na relação lógica entre atividades ou mesmo em sua duração.
• Antecipações: aplicamos antecipações quando a atividade sucessora puder começar antes que a atual
termine. Exemplo: posso começar a pintar uma parede antes que a aplicação do gesso termine.
• Esperas: ocorre um retardo para início da atividade sucessora. Exemplo: ao pintar a parede preciso de
um tempo para que a tinta seque. Neste caso, eu acrescento um tempo de espera entre as demãos.
Geralmente, estas antecipações e esperas são características do tipo de atividade e se forem aplicadas não
devem envolver aumento de riscos.
O uso de tempo de antecipação ou de espera pode ser necessário entre as atividades para dar suporte
a um cronograma de projeto realista e executável.
Sistema de informações de gerenciamento de projetos

Esse sistema consiste em um conjunto de ferramentas e técnicas que, basicamente, organizam, integram
e exibem os resultados do gerenciamento de projetos. Aqui neste processo, este sistema agrega o software de
elaboração do cronograma que pode ajudar a elaborar o sequenciamento das atividades, os relacionamentos
lógicos, as antecipações e esperas e os diversos tipos de dependência.
Saídas
Diagramas de rede do cronograma do projeto
Ao final deste processo teremos o nosso diagrama de rede do cronograma, que mostra as atividades e seus
inter-relacionamentos, tipo de dependência de cada relacionamento e as antecipações e esperas definidas.
A B
Início p/ Início
C D E
Início F G H Término
Início p/ Início + 10
I J
J L Término p/ Término
Da mesma forma que a EAP, o diagrama de rede do cronograma é uma representação visual do trabalho
a ser executado. Esse diagrama pode conter todos os detalhes das atividades ou, quando o projeto for muito
complexo, apenas atividades agrupadas. Veja que neste caso não é viável criar um diagrama de rede detalhado.
Cria-se então, um diagrama sumarizado que então pode ser expandido em partes.
Atualizações nos documentos do projeto

Como este processo pode evidenciar alguma atividade que foi esquecida, as mudanças devem ser refletidas
em outros documentos do projeto, tais como: lista de atividades, atributos das atividades, lista de marcos e
registro das premissas.
Estimar as durações da atividade (6.4)
Estimar a duração das atividades, sem dúvida nenhuma, é um processo complexo, pois precisamos obter
avaliações quantitativas do número provável de períodos de trabalho necessários para a conclusão de cada uma
das atividades. Pela própria característica dos projetos, muitas vezes não temos parâmetros para realizar essa
estimativa.
As durações variam por diversos motivos entre eles o nível de conhecimento do profissional,
interrupções durante o expediente, eventos inesperados, erros e mal entendidos.
Quem deve fazer a estimativa é quem faz o trabalho, por isso, a equipe do projeto deve sempre ser
consultada.
É aqui que a elaboração progressiva toma forma. As estimativas tipicamente começam com um nível
de confiança baixo, e à medida que mais detalhes vão sendo conhecidos, as estimativas tornam-se mais
acuradas.
Duração x Esforço x Tempo Decorrido

Antes de prosseguirmos é importante entender os conceitos de duração, esforço e tempo decorrido.
• Esforço: ou trabalho, ou ainda empenho é o tempo necessário para que cada recurso cumpra seu papel
na atividade. É normalmente medido em horas ou homens/hora.
• Duração: é o número total de períodos de trabalho necessários para cumprir uma atividade. É
normalmente medida em dias ou semanas.
Para pintar um muro o mestre de obras estimou que seriam necessárias 32 horas de trabalho. Para essa
atividade iremos alocar 2 recursos (pintores) que têm a jornada de trabalho de 8 horas por dia. A partir desses
dados temos que a duração da atividade será de:
Duração = (32 / 2) / 8
Duração = 2 dias
Se tivéssemos apenas um pintor, a duração mudaria para:
Duração= (32 / 1) / 8
Duração = 4 dias
A duração de uma atividade NÃO leva em conta o calendário, ou seja, não considera feriados ou
períodos de descanso (sábados e domingos).
• Tempo decorrido: é a diferença entre a data de início e de fim de uma atividade. Este, sim, leva em
conta o calendário, ou seja, são considerados os feriados e os períodos de descanso.
Vamos verificar a diferença entre duração e tempo decorrido, considerando uma atividade de 32 horas de
duração com períodos de trabalho de 8 horas por dia.
Fatores a serem considerados ao estimar a duração das atividades

Lei dos retornos (ou rendimentos) decrescentes e número de recursos alocados
De acordo com a Lei dos rendimentos decrescentes (lei muito conhecida na área de estudos da Economia),
à medida que aumenta o uso de um determinado insumo (mantendo-se fixos os demais insumos), acaba-se
chegando a um ponto em que a produção adicional descresce.
Alguns gestores ainda pensam que todos os problemas relacionados a seus projetos podem ser solucionados
se contratarem mais pessoas. Chegam ao ponto de esperarem que, ao dobrar o número de integrantes de um
time, sua performance dobre também. No entanto, isso não é verdade.
O aumento na produtividade de um processo não é diretamente proporcional ao aumento no número de

pessoas do time em questão. Isso acontece pois existe um limite no número de maneiras de paralelizar um
trabalho (algumas vezes, é impossível dividir ainda mais uma tarefa). Além disso, cada membro adicional do
time pode prejudicar a organização do mesmo.
Quando existem funcionários em demasia, alguns se tornarão ineficientes e o produto marginal do insumo
"trabalho" apresentará uma queda. Em outras palavras, quanto mais recursos você coloca em uma atividade,
menor a produtividade individual dos recursos.
Por exemplo, "Incluir estagiários ou profissionais pouco qualificados" (insumos) para produzir algo mantendo
os outros insumos constantes, implicará em uma redução da produtividade dos profissionais envolvidos e não
implicará necessariamente em um aumento de produção.
Em algumas situações, isso pode até implicar em maior atraso, já que o profissional mais qualificado deverá
usar seu tempo para explicar para os profissionais menos qualificados o que precisa e o que deve ser feito.
Motivação da equipe
Dois fatores bem conhecidos em se tratando de equipes são:
• Síndrome do estudante: também é conhecida como procrastinação. Este é um mecanismo de defesa

natural. Significa adiar o trabalho até o último momento possível, não porque somos preguiçosos, pelo
contrário, estamos trabalhando duro. Todos, ocasionalmente, caímos presos da Síndrome do Estudante.
É curioso observar que esta “síndrome” ganhou esse nome pela forma como os estudantes lidam com
o dever de casa. Imagine nos idos do seu colegial (ou ensino médio, dependendo de sua idade) quando
seu professor que lhe dizia que você teria uma prova final em 19 semanas. Ele lhe dá todo o material, o
livro, os objetivos que serão testados e a data. Quando você começava a estudar? Na véspera da prova.
Por quê? Você tinha tempo. Como outras tarefas mais importantes e urgentes surgiam, você postergava
o início dos estudos até o último momento possível.
• Lei de Parkinson: esta lei afirma que “O trabalho se expande de modo a preencher o tempo disponível
para sua realização.” Cyril Northcote Parkinson, em 1955, afirmou que se você tiver uma tarefa que
demoraria 30 minutos para fazer, mas o seu prazo é de um dia, você provavelmente a terminará em
um dia. Se tiver uma reunião, que poderia ser feita em 10 minutos e você aloca 1 hora para ela, 1 hora
será gasta. E por quê? Por que se você terminar antes, com certeza terá mais coisas para fazer, e assim
despenderá mais energia.
O processo
Entradas
• Plano de gerenciamento do cronograma: iremos extrair desse plano as informações referentes ao nível
de exatidão e as unidades de medida para a execução da estimativa de duração das atividades.
• Atributos das atividades: os atributos das atividades podem conter informações importantes para
estimar a duração. Por exemplo, a melhor época para pintar um edifício é a época em que não chove
(no Sudeste é no inverno, no Nordeste é no verão). Essa restrição pode afetar a estimativa de duração
da atividade.
• Lista de atividades: da lista de atividades extraímos informações das atividades que precisarão de
estimativas de duração.
• Registro das premissas: premissas e restrições apontadas podem influenciar na seleção e na

disponibilidade de recursos, afetando diretamente a estimativa de duração das atividades.
• Registro das lições aprendidas: este registro pode ajudar na definição da duração das atividades a partir
da experiência em projetos anteriores.
• Lista de marcos: a lista de marcos pode conter datas fixas de entregas, e sendo assim, pode afetar as
estimativas de duração.
• Alocações da equipe do projeto: ainda não vimos este tópico, pois ele é resultado da área gerenciamento
dos recursos. De forma resumida, a equipe do projeto estará pronta quando as pessoas apropriadas
tiverem sido alocadas.
• Estrutura analítica dos recursos: este tópico será visto na área de gerenciamento de recursos, mas de
forma resumida ela é uma estrutura que mostra os recursos identificados por categoria e tipo, inclusive
com a hierarquia entre eles.
• Calendários dos recursos: ainda não vimos este tópico, pois ele é resultado da área gerenciamento dos
recursos. De forma resumida, este é um calendário que contém a lista de disponibilidades dos recursos
(tanto materiais como humanos) ao longo do período. Ou seja, contém informações de quando e por
quanto tempo um recurso estará disponível para o projeto.
• Requisitos de recursos: os requisitos de recursos estimados têm efeito direto na estimativa de duração
da atividade. Por exemplo, supondo que temos uma atividade complexa a ser executada por dois
analistas sêniores e a disponibilidade de recursos é de apenas um analista júnior e um analista sênior
saberemos que a duração da atividade será afetada, pois ela levará mais tempo para ser completada
por esses recursos.
• Registro dos riscos: ainda não vimos o que é o registro dos riscos, pois este item será detalhado na área
de conhecimento Gerenciamento dos riscos. De forma resumida temos que os eventos de risco podem
influenciar na seleção e na disponibilidade de recursos, afetando diretamente a estimativa de duração
das atividades.

Dentro dos fatores ambientais que serão considerados neste processo temos: métricas de desempenho dos
recursos, bancos de dados com estimativas de duração de atividades, entre outros.

Como já vimos, os ativos se referem a toda informação acumulada pela empresa, e neste caso serão
considerados: informações históricas sobre duração das atividades, calendários de outros projetos, metodologia
de elaboração de cronograma e lições aprendidas.
Uma das ferramentas recomendadas para estimar a duração de uma atividade é a opinião especializada, ou
seja, os especialistas da área e os responsáveis pelas atividades são as principais fontes de consulta.
Quando guiada por informações históricas, a opinião especializada pode fornecer informações sobre
estimativas de duração ou durações máximas recomendadas para as atividades.
É importante considerar que quanto menor a experiência dos profissionais envolvidos nas estimativas,
maior será o risco.
Estimativa análoga
Também conhecida como estimativa top-down, esta estimativa utiliza dados de projetos anteriores (análogos)
para estimar a duração de uma atividade. É muito utilizada pela sua facilidade de aplicação principalmente
quando não se têm informações detalhadas e consequentemente não é a mais exata. Estimamos os valores
atuais a partir de valores de atividades similares realizadas em projetos anteriores.
A estimativa análoga utiliza informações históricas e é muitas vezes mais confiável que as estimativas
realizadas pelos membros do time do projeto.
Estimativa paramétrica
Esta estimativa utiliza um algoritmo (ou fórmula matemática) juntamente com dados históricos para o
cálculo da duração da atividade.
Por exemplo, sei que um recurso pode produzir 500 peças por dia em média. De quantos dias precisaria
para produzir 10.000 peças com quatro recursos deste mesmo tipo? A resposta seria: 5 dias.
Esta técnica pode produzir estimativas relativamente precisas quando as fórmulas e os dados forem de
qualidade. E pode ser utilizada em parte do projeto e também usada em combinação com outras técnicas.
Estimativa única
Com certeza esta é uma das estimativas mais usuais em projetos, embora não seja a mais adequada. É
chamada de estimativa única porque quem faz a estimativa fornece apenas um valor para ela.
Estimar apenas um valor pode gerar os seguintes problemas:
• O avaliador inflaciona a estimativa para se proteger de eventuais riscos. Por exemplo, se uma atividade
pode ser realizada em dois dias, é certo que o estimador a avaliará como três, para garantir qualquer
problema no caminho.
• Já que todas as estimativas são inflacionadas, dificilmente o patrocinador acreditará que o projeto
durará x meses, e tentará reduzir o prazo pela metade.
• É impossível avaliar com certeza quanto tempo uma atividade durará, já que muitas coisas podem
acontecer nesse ínterim. Se o avaliador indicar que a atividade durará exatamente o tempo previsto, ele
estará inserindo riscos de atraso no projeto.
É por conta desses problemas, que geralmente a melhor opção é utilizar a estimativa de três pontos, como
veremos a seguir.
Estimativa de três pontos

Esta ferramenta/técnica é baseada em três estimativas distintas para cada uma das atividades que compõem
o cronograma. Este tipo de estimativa considera o grau de incerteza e risco a que uma determinada atividade
pode estar exposta. Especialistas ou os recursos que executarão as atividades indicam valores para as seguintes
estimativas:
• Otimista (O): baseia-se no melhor cenário;
• Mais provável (MP): baseia-se na duração que tem mais chance de ocorrer (a que normalmente ocorre,
considerando-se interrupções e desempenhos normais);
• Pessimista (P): baseia-se no pior cenário.
Distribuição beta ou PERT “tradicional”
O modelo mais conhecido deste tipo de estimativa é o modelo PERT (Program Evaluation Review Technique)
que utiliza a média ponderada abaixo (também chamada de Distribuição Beta):
Observe que nesta fórmula aplica-se um peso maior para a estimativa mais provável, mas não deixa de
considerar as estimativas pessimista e otimista, assim estamos considerando as eventuais incertezas que
poderão ocorrer.
Esta técnica (PERT) pode ser usada tanto para estimar duração de atividades como os custos delas.
Para calcular o intervalo de variação esperado, a técnica utiliza o conceito de desvio padrão (ou também
chamado de sigma), que mede a dispersão estatística. Em outras palavras, com o valor de sigma é possível
calcular a margem de erro da estimativa.
Na estatística não se usa o “desvio padrão” puro para o cálculo da dispersão (ou “margem de erro”). Isso
acontece, além de outros motivos, porque em alguns casos o valor do desvio padrão resulta em números
negativos impedindo que o cálculo seja feito de maneira correta.
Assim, a exemplo dos estatísticos, você usará na prova para o cálculo do desvio padrão a raiz quadrada da
variância, conforme mostramos nas fórmulas a seguir:
Apenas a título de exemplo, a figura a seguir mostra um exemplo de como é graficamente uma distribuição
Beta.
Probabilidade
relativa de
ocorrência
Otimista Mais provável Média PERT Pessimista
Vamos efetuar uma comparação entre o cálculo usando a estimativa de um único ponto (que á a Mais
Provável) e a de três pontos a partir do seguinte cenário: “No trânsito caótico de São Paulo, você costuma levar
2 horas para chegar em casa. Mas em dias de chuva leva 5 horas, e em dias sem trânsito (bem incomum!) leva
apenas 30 min (0,5 hora). Qual é a duração da atividade ´chegar em casa´ ?”
• Pela estimativa de um único ponto, ou seja, a estimativa mais provável levaremos 2 horas. Observe que
aqui não consideramos eventuais riscos (como alagamentos ou trânsito bom).
• Já pelo modelo PERT utilizamos a fórmula:
Média PERT = (5 + 4 x 2 +0,5) / 6 = 2,25 horas (2 horas e 15 minutos)

Variância = ((5-0,5)/6)2
Variância = (0,75)2= 0,5625 horas
Desvio padrão = 0,75 horas
Estimativa 1 = 2,25 - 0,75 = 1,50 horas
Estimativa 2 = 2,25 + 0,75 = 3 horas
A estimativa PERT aponta que em média você chegaria em casa em 2 horas e 15 minutos (2,25 horas) com
uma margem de erro de 45 minutos (0,75 horas), ou seja, entre 1 hora e 30 minutos (1,50 horas) e 3 horas.
Dessa forma consideramos também as possibilidades das coisas darem certo ou errado, e assim conseguimos
obter uma estimativa mais precisa.
Não utilize o acrônimo PERT/CPM para se referir SOMENTE à estimativa de 3 pontos.
Distribuição triangular
Esta é outra forma de calcular a estimativa de três pontos. Neste caso, a fórmula é a média simples das 3
estimativas:
Estimativa bottom-up
Esta ferramenta consiste em estimar o tempo de cada pacote de trabalho de uma EAP de baixo para cima,
chegando ao tempo estimado total do projeto. Um item deve possuir a somatória de tempo de seus subitens e
assim por diante conforme mostrado na figura a seguir.
Observe que a estimativa bottom-up é feita de baixo para cima. No exemplo da figura a seguir, primeiro
somamos os valores das estimativas das atividades dos Pacotes de trabalho A e B, gerando o resultado C.
Prosseguimos somando de baixo para cima até obtermos H que é a soma de tudo que está abaixo dele.
A estimativa bottom-up NÃO é uma alternativa adequada para fazer uma estimativa de tempo nas fases
iniciais do projeto, uma vez que nessa fase ainda não temos detalhes suficientes das atividades envolvidas no
projeto. Em seu lugar, recomenda-se o uso da estimativa análoga. E a medida que o projeto evolui passa a ser
uma estimativa bem precisa.
Análise de dados
Análise de alternativas
Esta técnica é utilizada para comparar diferentes níveis de capacidade ou habilidades, técnicas de compressão
de cronograma, ferramentas, decisões de fazer, alugar ou comprar etc.
Análise das reservas
Esta técnica tem por objetivo determinar as reservas de contingência e gerencial caso possíveis riscos
conhecidos venham a se concretizar.
As reservas de contingência são as durações estimadas alocadas para riscos identificados que são aceitos
e para os quais foram desenvolvidas respostas contingentes ou mitigadoras. Essas respostas são associadas
à “incógnitas conhecidas” que podem ser estimadas para justificar retrabalhos. Já a reserva gerencial é um
montante alocado para imprevistos que caso ocorram, possam ser usadas. Esse tipo de reserva está associada
à "incógnitas desconhecidas" e não devem fazer parte da linha de base do cronograma.
O valor das reservas pode ser calculado a partir de um percentual da duração da atividade (exemplo: 5%), de
uma quantidade de dias (+ 2 dias) ou a partir de simulações como a de Monte Carlo (veremos esta ferramenta
quando estudarmos a área de conhecimento gerenciamento de riscos).
À medida que informações mais precisas se tornem disponíveis, a reserva para contingência pode ser usada,
reduzida ou eliminada. É por isso que é muito importante que as reservas de contingência sejam identificadas
claramente no cronograma. Já a reserva gerencial só pode ser usada a partir da aprovação do patrocinador.
Tomada de decisão
O processo de tomada de decisão é um dos fatores mais críticos nos projetos. As técnicas para tomada de
decisão em grupo envolvem a avaliação das alternativas apresentadas para resolver uma determinada questão.
Elas podem ajudar na classificação e priorização das melhores alternativas apresentadas.
Entre as ferramentas que podem ser utilizadas, o Guia PMBOK sugere a Fist of Five, ou punho de cinco.
Esta ferramenta é um mecanismo simples e rápido para chegar a um consenso em grupo e para conduzir uma
discussão. Após a discussão inicial sobre uma determinada proposta ou decisão pendente, usando os dedos, os
membros da equipe são convidados a votar em uma escala de 1 a 5.
O valor de uso desta técnica não está apenas na construção do consenso, mas também na condução de
discussões, pois cada membro do time é convidado a explicar a razão de seu ranking. Eles também têm a
oportunidade de expressar quaisquer problemas ou preocupações. Assim que o time discutir o assunto, uma
decisão coletiva será tomada.
Roteiro para utilização:
Um membro do time expõem um assunto que precisa ser decidido, e pede que os demais partipantes
votem. Assim, o número de dedos usados na votação indica o nível de acordo e desejo de discussão:
1. Um dedo: eu não concordo com a conclusão do grupo e tenho dúvidas.
2. Dois dedos: eu não concordo com a conclusão do grupo e gostaria de discutir alguns problemas menores.
3. Três dedos: eu não tenho certeza e gostaria de apoiar a conclusão de consenso do grupo.
4. Quatro dedos: eu concordo com a conclusão do grupo e gostaria de discutir alguns problemas menores.
5. Cinco dedos: eu concordo plenamente com a conclusão do grupo.
Reuniões
As reuniões são utilizadas para que a equipe de gerenciamento do projeto se reúna para estimar a duração
das atividades. É também aqui neste ponto que o Guia PMBOK® cita pela primeira e única vez o termo
Scrum e uma das poucas vezes que o termo Sprint é também citado.
De forma resumida, no Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de
Sprints. A Sprint representa um período de tempo dentro do qual um conjunto de atividades deve ser
executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido
em iterações, que são chamadas de Sprints no caso do Scrum.
As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida
como Backlog do Produto. No início de cada Sprint, faz-se uma Reunião de Planejamento da Sprint, ou
seja, uma reunião de planejamento na qual o Dono do Produto (chamado também de proprietário do
produto) prioriza os itens do Backlog do Produto e a equipe seleciona as atividades que ela será capaz de
implementar durante a Sprint que se inicia. As tarefas alocadas em uma Sprint são transferidas então do
Backlog do Produtp para o Backlog da Sprint.
Saídas
Estimativa de duração
As estimativas de duração devem ser avaliações quantitativas do número mais provável de períodos de
trabalho (duração) que serão necessários para completar uma atividade. Estas estimativas não devem incluir
nenhuma espera, e podem conter indicações de faixas de resultados possíveis (reservas), tais como:
• 15 dias + - 2 dias, indicando que a atividade levará no mínimo 13 e no máximo 17 dias;
• 10% de probabilidade de exceder 15 dias, ou 90% de probabilidade de que a atividade levará 15 dias ou
menos.
Base das estimativas

A base das estimativas fornece a documentação de suporte aos valores estimados das durações. Imagine
que seu projeto tenha a duração de dois anos, e que o patrocinador queira saber, depois de decorridos 18
meses do projeto, de onde você tirou que uma determinada atividade deveria ser executada em 15 dias.
É por isso que a base das estimativas deve fornecer um entendimento claro e completo a respeito de como
a estimativa de duração das atividades foi derivada. Os detalhes de suporte para essas podem incluir:
• Documentação das bases para a estimativa (por exemplo, como foi desenvolvida);
• Documentação de todas as premissas adotadas;
• Documentação de quaisquer restrições conhecidas;
• Indicação da faixa das estimativas possíveis (por exemplo, ±10% para indicar que a duração estimada do
item é esperado nesse intervalor de valores);
• Indicação do nível de confiança da estimativa final;
• Documentação de riscos que podem afetar essas estimativas.

Obviamente, alguns documentos do projeto serão afetados pelas estimativas de duração das atividades,
e devem ser atualizados. Podem ser: os atributos das atividades, registro de premissas e registro das lições
aprendidas.
Desenvolver o Cronograma (6.5)
É neste processo que será elaborado o cronograma das atividades, definindo suas respectivas datas de
inicio, de término.
O preparo do cronograma proporciona a base para muitas das funções importantes que fazem parte do
processo de gerenciamento de projetos.
Da mesma forma que em outros processos é muito importante levar em consideração as restrições e as
premissas ao se elaborar o cronograma. As principais restrições neste caso são as datas impostas e as datas de
eventos-chave ou marcos.
Datas impostas são mais comuns do que se imagina, caso contrário, é bem possível que nenhum projeto
saísse na data desejada. As restrições de data mais usuais são as do tipo: “não começar antes de” (por exemplo,
não pinte a parede antes de terminar de colocar o gesso) e “não finalizar depois de” (por exemplo, não termine
a pintura do quarto depois da parte externa) e que estão presentes em praticamente todos os softwares de
desenvolvimento de cronogramas.
Já os eventos-chave ou marcos se referem às entregas parciais do projeto em datas específicas. Por exemplo,
no caso da montagem de um veículo é necessário que as suas partes já tenham sido entregues. Assim, a entrega
das partes são controladas a partir de marcos no projeto.
Além disso, tanto o patrocinador quanto as principais partes interessadas podem exigir que algumas entregas
sejam realizadas obrigatoriamente em datas determinadas. Assim, se o gerente do projeto garantir que uma
data será cumprida (mesmo que o faça verbalmente) estará assumindo efetivamente esse compromisso.
Gerenciar projetos NÃO é apenas elaborar e gerenciar o cronograma! É claro que o cronograma é um
item muito importante do gerenciamento, no entanto não é o único!
Desenvolver um cronograma com centenas de atividades sem um software de gerenciamento de projetos

adequado pode ser uma tarefa inglória, portanto não deixe de considerar este recurso.
O processo
Entradas
Para elaborarmos o cronograma usaremos praticamente todos os documentos e informações gerados nos
processos anteriores. Quanto mais detalhes recolhidos desses documentos, mais preciso ficará o cronograma.

• Plano de gerenciamento do cronograma: iremos extrair desse plano as informações referentes ao nível
de exatidão e as unidades de medida para a execução da estimativa de duração das atividades.
estimar a duração. Por exemplo, a melhor época para pintar um edifício é a época em que não chove
(no Sudeste é no inverno, no Nordeste é no verão). Essa restrição pode afetar a estimativa de duração
da atividade e consequentemente afetar a criação do cronograma.
• Lista de atividades: para montarmos o cronograma precisamos saber quais atividades irão compô-lo.
• Registro das premissas: premissas e restrições apontadas podem influenciar na seleção e na
disponibilidade de recursos, afetando diretamente a criação do cronograma.
• Base das estimativas: este documento fornece informações de como as estimativas foram feitas.
• Estimativas de duração: para se montar o cronograma, precisamos das estimativas de duração de cada
atividade.
• Registro das lições aprendidas: este registro pode ajudar na elaboração do cronograma a partir da
experiência em projetos anteriores.
• Lista de marcos: a lista de marcos pode conter datas fixas de entregas, e sendo assim, essas datas
precisam ser indicadas no cronograma.
• Diagramas de rede do cronograma do projeto: o diagrama de rede contém o relacionamento lógico entre
atividades, indicando predecessoras e sucessoras, e isso é usado para calcular datas do cronograma.
• Alocações da equipe do projeto: ainda não vimos este tópico, pois ele é resultado da área gerenciamento
dos recursos. De forma resumida, a equipe do projeto estará pronta quando as pessoas apropriadas
tiverem sido alocadas.
• Requisitos de recursos: os requisitos de recursos estimados têm efeito direto nas atividades do
cronograma. Por exemplo, supondo que temos uma atividade complexa a ser executada por dois
analistas sêniores e a disponibilidade de recursos é de apenas um analista júnior e um analista sênior, a
duração da atividade será afetada, pois ela levará mais tempo para ser completada por esses recursos.
E sendo assim, o cronograma também será afetado.
influenciar nas reservas de tempo do cronograma.
Acordos
Acordos são definidos pelo Guia PMBOK® como documentos que estabelecem as intenções iniciais de um
projeto e podem conter requisitos tanto do projeto como do produto.

Dentro dos fatores ambientais que serão considerados neste processo temos: padrões organizacionais e
canais de comunicação (que veremos na área de conhecimento Gerenciamento da comunicação).

Como já vimos, os ativos se referem a toda informação acumulada pela empresa, e neste caso serão
considerados: metodologia de elaboração de cronograma, calendários de outros projetos, modelos de outros
projetos já encerrados entre outros.
Análise de rede do cronograma
A análise de rede do cronograma gera o cronograma do projeto. Ela envolve determinar as seguintes datas:
• Data de início mais cedo: é o momento mais cedo possível no qual as partes incompletas de uma
atividade do cronograma podem ser iniciadas. Esta data pode mudar conforme o projeto se desenvolve;
• Data de término mais cedo: é o momento mais cedo possível no qual as partes incompletas de uma
atividade do cronograma podem ser terminadas sem que o projeto atrase. Esta data pode mudar
conforme o projeto se desenvolve;
• Data de inicio mais tarde: é o momento mais tarde possível no qual uma atividade do cronograma pode
ser iniciada com base na lógica de rede do cronograma sem violação de uma restrição do cronograma
ou atraso na data de término do projeto. As datas de início mais tarde são determinadas durante o
cálculo do caminho de volta da rede do cronograma do projeto;
• Data de término mais tarde: é o momento mais tarde possível no qual uma atividade do cronograma
pode ser terminada com base na lógica de rede do cronograma sem violação de uma restrição do
cronograma ou atraso na data de término do projeto. As datas de término mais tarde são determinadas
durante o cálculo do caminho de volta da rede do cronograma do projeto.
A análise de rede do cronograma é realizada a partir da utilização de uma ou mais das seguintes técnicas:
método do caminho crítico, método da corrente crítica, nivelamento de recursos, estabilização de recursos,
análise e-se, simulação, antecipações e esperas, compressão do cronograma. Veremos cada uma delas a seguir.
Método do caminho crítico (Critical Path Method - CPM)

O caminho crítico é a sequência de atividades de um diagrama de rede que não permite atrasos. Ou seja, se
uma atividade desse caminho atrasar, o projeto também atrasará.
Esta é uma técnica utilizada para identificar o caminho crítico de um projeto, através da determinação de
datas de início e término mais cedo e de início e término mais tarde de cada atividade existente, sem considerar
quaisquer limitações de recursos.
Os diferentes caminhos possíveis no diagrama de rede do projeto permitem que uma atividade possua uma
certa variedade de datas possíveis de início e término (datas mais cedo e mais tarde de início e término).
Através destas datas, é possível determinar a folga livre e a folga total de uma atividade:
• Folga livre: informa quanto tempo uma atividade pode atrasar sem que haja impacto no início da
atividade sucessora;
• Folga total: informa quanto tempo uma atividade pode atrasar sem que haja impacto no término do
projeto;
• Folga total do projeto: é a soma de todas as folgas livres.
Ao identificarmos o caminho que contém as atividades com folga total igual a zero ou ainda o caminho
que contém a maior duração na soma das durações das atividades, estaremos determinando assim, o caminho
crítico do projeto. Assim, o caminho crítico é o conjunto de atividades que não possuem folga, ou seja, as
atividades contidas no caminho crítico não podem atrasar, pois causariam um atraso no prazo final do projeto.
Embora possa parecer estranho, existe a possibilidade de uma folga ser negativa. Isso indica que há tempo
que precisará ser recuperado, pois estão faltando dias para que o cronograma seja cumprido. Isso costuma
acontecer quando a data final do projeto é fixa e as atividades do caminho crítico atrasam.
As atividades que ficam no caminho crítico são denominadas atividades críticas e são aquelas que necessitam
ser melhor gerenciadas sob o risco de comprometerem o prazo do projeto.
As atividades que não estão no caminho crítico possuem uma folga (= folga livre) e mesmo atrasando
geralmente não comprometem o cronograma do projeto. Veja que se a folga for toda consumida, é possível que
um caminho que não era crítico passe a sê-lo.
Acompanhar o caminho crítico do cronograma do projeto, durante a sua execução, é fundamental para o
controle do prazo do projeto, e garante que ações preventivas e corretivas possam ser tomadas a tempo. Esse
acompanhamento normalmente se dá pela verificação da evolução das folgas das atividades.
Este método não leva em consideração as limitações de recursos do projeto, ou seja, este método
sempre considerará que todos os recursos necessários estarão à disposição do projeto.
• As técnicas denominadas PERT e CPM foram independentemente desenvolvidas para a gestão e

controle de projetos por volta de 1950.
• A grande semelhança entre elas fez com que o termo PERT/CPM seja utilizado corriqueiramente como
apenas uma técnica, o que não representa a verdade!
• Os termos PERT e CPM são acrônimos de Program Evaluation and Review Technique (PERT) e Critical
Path Method (CPM).
• PERT é o cálculo a partir da média ponderada de 3 durações possíveis de uma atividade (otimista, mais
provável e pessimista).
• CPM é um método de apuração do caminho crítico dada uma sequência de atividades, isto é, quais
atividades de uma sequência não podem sofrer alteração de duração sem que isso reflita na duração
total de um projeto. Para isso, este método calcula as datas de início e término mais cedo e as datas de
início e término mais tarde, como veremos no exemplo a seguir.
Exemplo:
Para mostrarmos o funcionamento desta técnica utilizaremos o diagrama de rede da figura a seguir. A
duração das atividades está indicada entre parênteses. Considere ainda que o projeto inicia em 01/12.
Atividade B Atividade D
(10 dias) (2 dias)
Atividade A Atividade F
(4 dias) (4 dias)
Atividade C Atividade E
(2 dias) (6 dias)
Passo 0: Para cada uma das atividades do diagrama de rede, preencheremos um quadro igual o a seguir:
Inicio mais (2) Término mais

Duração
cedo cedo
(1)
Nome da Tarefa
Inicio mais Término mais

Folga
tarde tarde
1. Preencha o nome das atividades (itens em preto);
2. Preencha as durações das atividades (itens em verde). As durações a serem preenchidas poderão
ser calculadas a partir das técnicas de estimativas de três pontos, paramétricas, análogas etc. Neste
exemplo, já foram dadas as durações das atividades;
Passo 1 - Caminho de ida: Calcularemos agora as datas indicadas em vermelho na figura a seguir, que
representam o caminho das atividades com início e fim “mais cedo”;
3. Coloque a data de início do projeto na Atividade A (01/12);
4. Some a duração da Atividade A (4 dias) à data 01/12 e obtenha o término mais cedo da Atividade A ->
04/12;
5. Passe para a Atividade B. A data de início mais cedo dessa atividade é o dia seguinte da data de término
da Atividade A -> 05/12;
6. Some a duração da atividade B (10 dias) à data 05/12 e obtenha o término mais cedo da Atividade B ->
14/12;
7. Faça o mesmo para as Atividades C, D e E;
8. Atenção! Para o cálculo da data de Início mais cedo da Atividade F observe que a data de término
mais cedo da Atividade D (16/12) é maior que a da Atividade E (12/12). Neste caso devemos SEMPRE
considerar a Maior data. Por isso, a data de Início mais cedo da Atividade F é o dia seguinte ao da maior
data -> 17/12;
9. Some a duração da Atividade F (4 dias) à sua data de Inicio mais cedo e obtenha o término mais cedo
do projeto -> 20/12;
Passo 2 - Caminho de volta: Calcularemos agora as datas indicadas em azul na figura a seguir, sendo que o
caminho será feito de trás para frente, representando o caminho das atividades com inicio e fim “mais tarde”.
10. Comece pela última data em vermelho da Atividade F (20/12). Copie essa data para a última data em
azul da Atividade F -> Término mais tarde;
11. Subtraia a duração da Atividade F (4 dias) e encontre a data início mais tarde da Atividade F -> 17/12;
12. Passe para a Atividade D. A data de término mais tarde dessa atividade será o dia anterior da data de
Início mais tarde da Atividade F -> 16/12;
13. Subtraia a duração da Atividade D (2 dias) e encontre a data início mais tarde da Atividade D -> 15/12;
14. Faça o mesmo para as demais atividades! Não esqueça que a subtração deverá ser feita com a duração
das atividades -> itens em verde;
15. Atenção! Para o cálculo da data de término mais tarde da atividade A observe que a data de inicio
mais tarde da Atividade B (05/12) é menor que a da Atividade C (09/12). Neste caso devemos SEMPRE
considerar a menor data. Por isso, a data de término mais tarde da Atividade A é o dia anterior da menor
data -> 04/12;
16. Subtraia a duração da Atividade A (4 dias) do término mais tarde e obtenha o Início mais tarde do
projeto -> 01/12;
Passo 3: Faremos agora o cálculo das folgas, que são os itens indicados em roxo na figura a seguir.
17. Subtrairemos as datas início mais cedo e início mais tarde (ou término mais cedo e término mais tarde)
de todas as atividades e as colocaremos nos itens marcados em roxo, que representam as folgas livres:
Exemplo:
Atividade F -> (20/12 – 20/12 = 0) ou (17/12 – 17/12) = 0
Atividade E -> (11/12 – 07/12 = 4) ou (16/12 – 12/12) = 4
Passo 1 -> Cálculo “mais cedo”
(5) Caminho Crítico

05/12 10(2) 14/12
(6)
15/12
(7)
2(2) 16/12
(7)
Ca
mi
r í tico Atividade B
(1)
Atividade D
(1) nh
oC
oC ríti
m inh co
Ca 05/12
(14)
0(17) 14/12
(14)
15/12
(13)
0(17) 16/12
(12)
(3)
01/12 4(2) 04/12
(4)
(8)
17/12 4(2) 20/12
(9)
(1)
Atividade A (1)
Atividade F
(16)
01/12 0(17) 04/12
(15)
(11)
17/12 0(17) 20/12
(10)
(7) (2) (7) (7)

05/12 2 06/12 07/12 6(2) 12/12
(7)
(1) (1)
Atividade C Atividade E
(14) (17) (14) (14)

09/12 4 10/12 11/12 4(17) 16/12
(14)
Passo 2 -> Cálculo “mais tarde”
O caminho crítico é indicado pelas atividades que tem folga igual a 0. Valores de folga diferentes de
zero indicam que a atividade pode atrasar até consumir toda a folga sem que atrase o final do projeto. No
entanto se várias atividades consumirem suas folgas, podem acabar criando um novo caminho crítico.
Todo cronograma terá, no mínimo, um caminho crítico, que pode ser definido como o conjunto de
atividades que têm folga zero. Quando estruturado em um diagrama de rede o caminho crítico tem por
característica ser o caminho mais longo da rede, em termos de soma das durações das atividades que o
compõem. Qualquer atraso em uma atividade do caminho crítico irá causar atraso na data de término do
projeto!
Método da corrente crítica
A corrente crítica (critical chain) é uma técnica de análise de rede do cronograma que o modifica para que
se leve em conta a limitação de recursos. Ou seja, este método considera que nem sempre o recurso necessário
estará disponível!
A corrente crítica é uma nova abordagem para gerenciamento de projetos, voltado para a administração de
prazos e atividades, baseado na teoria das restrições (Theory of Constraints - TOC).
A rede do cronograma é formada obedecendo às restrições de tempo e recursos, sendo a corrente crítica a
sequência na qual não pode ocorrer nenhum atraso em nenhuma atividade.
Este método usualmente aloca as atividades de alto risco logo no início do projeto, para que problemas
possam ser identificados e endereçados imediatamente. Além disso, permite que várias atividades alocadas
para um mesmo recurso possam ser combinadas e indicadas no cronograma como sendo apenas uma atividade.
Um ponto importante a observar é que neste método nenhuma atividade poderá ter “proteções” individuais
de duração para eventuais atrasos.
Veja que, via de regra, o método PERT retorna uma estimativa acurada, mas, mesmo assim, em alguns casos
o gerente do projeto acrescenta “proteções” individuais para cada uma das atividades do cronograma só para
garantir que elas serão finalizadas no tempo indicado. Por exemplo, suponha que o cálculo PERT da construção
de um muro retorne 6 dias. O gerente do projeto pode acrescentar mais dois dias ao prazo de entrega só para
garantir um eventual atraso. Imagine agora, essas proteções sendo expandidas por todo o cronograma.
Já o método da corrente crítica não utiliza “proteções” individuais. No lugar delas são utilizados os buffers,
que são “proteções” de agrupamentos de atividades. Mas atenção, pois aqui não devem ser somadas as
proteções individuais de cada atividade para se gerar um buffer!
Existem três tipos de buffers:

• Buffer de projeto: incluído no final da corrente crítica para proteger a data alvo de término contra o
seu desvio ao longo da corrente crítica;
• Buffer adicional ou de alimentação: é inserido em um ponto de uma sequência de tarefas dependentes
fora da corrente crítica para protegê-la contra o seu desvio ao longo das cadeias de alimentação;
• Buffer de recursos: inserido antes de uma atividade da corrente crítica, onde é exigido um recurso
crítico.
Existem algumas formas de se calcular o tamanho do buffer, porém a maneira mais simples é considerar
que ele terá a metade do total das margens de segurança (proteções) removidas do caminho que ele protege.
Roteiro de construção:
1. Construa o diagrama de rede usando estimativas de duração de atividades sem as margens de

segurança (sem as proteções individuais);
2. Defina as dependências;
3. Defina as restrições;
4. Calcule o caminho crítico;
5. Entre com a disponibilidade dos recursos no cronograma;
6. Recalcule o cronograma para obter a corrente crítica.
Este método considera dois fenômenos muito comuns quando se estimam as durações de atividades a
síndrome do estudante e a Lei de Parkinson que já vimos em um capítulo anterior.
O método do caminho crítico gerencia a folga total nos caminhos do cronograma, já a corrente crítica
gerencia as duração dos buffers.
A corrente crítica é construída a partir do caminho crítico.
Os buffers, além de protegerem o cronograma contra incertezas, ainda tem o objetivo de proteger o
cronograma contra a síndrome do estudante e a lei de Parkinson.
Otimização de recursos
Estas técnicas visam ajustar o cronograma de forma que ele seja mais eficiente em termos de alocação
de recursos. O Guia PMBOK® cita três técnicas: estabilização de recursos, alocação reversa de recursos e
nivelamento de recursos.
Estabilização de recursos
Esta técnica que também é conhecida como Resource Smoothing ajusta as atividades de um cronograma de
maneira que os requisitos de recursos do projeto não excedam limites preestabelecidos. Esta técnica não muda
o caminho crítico já estabelecido e tampouco a data de conclusão do projeto. Para isso as atividades só podem
ser atrasadas dentro de sua folga livre ou folga total o que muitas vezes não gera resultados satisfatórios, pois a
técnica não é capaz de otimizar todos os recursos.
Alocação reversa de recursos
Este tipo de alocação é muito útil nos seguintes casos:
1. Se o seu projeto tem uma data final estabelecida (sem que os recursos sejam um problema), então o
ideal é construir o cronograma de trás para frente. Isso significa que você irá iniciar o cronograma a partir
do último dia da última atividade e irá trabalhá-lo até alcançar o presente. Assim, serão estabelecidas as
datas em que serão precisos os recursos;
2. Quando um recurso altamente especializado é necessário em uma determinada data o ideal é alocá-lo
de forma reversa, ou seja, de trás para frente a partir da data final da atividade.
Nivelamento de recursos
Vimos que o método do caminho crítico não considera a disponibilidade dos recursos. E para que o
cronograma seja finalizado é preciso que além da determinação da rede do cronograma (com os caminhos
críticos) sejam alocados os recursos às atividades desse cronograma.
Veja que, como os recursos são inseridos após a determinação da rede de atividades, pode acontecer que um
recurso seja alocado simultaneamente em mais de uma atividade ao mesmo tempo, gerando a “superalocação”
desse recurso. Veja na figura a seguir um exemplo disso.
O normal é que um recurso seja alocado em 100% (ou menos) de suas horas em uma determinada data.
Por exemplo, se o recurso trabalha 8 horas e foi alocado em 100% em um determinado dia significa que ele
trabalhará as 8 horas desse dia executando essa atividade. Valores que extrapolem esse número são considerados
“superalocação” e podem implicar em horas extra de trabalho.
Como o nivelamento dos recursos tenta corrigir essas superalocações, ele normalmente atrasa o final do
projeto e muitas vezes mexe no caminho crítico, por isso é importante verificar se poderão ser alocados mais
recursos, se serão pagas horas extra ou se poderemos atrasar o final do projeto.
A maior parte dos softwares de gerenciamento de projetos identifica esta superalocação e efetua o
nivelamento. Mesmo assim, o gerente de projetos deve realizar a análise de rede para verificar se tudo foi feito
corretamente e se há necessidade de mais algum ajuste.
Exemplo:
No exemplo da figura a seguir o recurso chamado Scott foi alocado em 2 tarefas que podem ser executadas
simultaneamente. Considerando que ele trabalhe 8 horas por dia, ele não conseguirá executá-las ao mesmo
tempo, a não ser que trabalhe 16 horas por dia. É por conta de superalocações desse tipo que executamos o
nivelamento de recursos, ou seja, Scott primeiro executará a Atividade A e depois a Atividade B.
01/12 05/12 10/12 15/12
Atividade A = Instalar servidores (duração 5 dias) Scott

Aqui Scott terá que trabalhar 16 horas
por dia entre os dias 01/12 e 05/12
Atividade B = Instalar cabeamento (duração 13 dias) Scott

Nivelamento
Atividade A = Instalar servidores (duração 5 dias) Scott

Aqui Scott trabalhará 8 horas por dia, no entanto a
data de entrega será postergada.
Atividade B = Instalar cabeamento (duração 13 dias) Scott
Veja que esse nivelamento atrasou o cronograma e se tivéssemos uma dessas atividades no caminho crítico
o projeto também atrasaria.
Se as atividades forem sequenciais (dependentes entre si) e o recurso alocado for o mesmo, não precisaremos
executar o nivelamento.
O nivelamento de recursos pode alterar o caminho crítico bem como a data final do projeto.
A estabilização de recursos modifica as atividades dentro de suas folgas sem alterar o caminho crítico
nem a data final do projeto.
A alocação reversa de recursos é usada principalmente quando um recurso especifico é necessário em
uma determinada data.
Análise de dados
Análise de cenário e-se
Esta é uma análise da pergunta “e se a situação representada pelo cenário ‘X’ ocorrer?”, ou seja, simulações
de diferentes cenários são realizadas, tais como atrasar a entrega de um componente principal, prolongar
as durações ou introduzir fatores externos (uma greve ou uma mudança no processo de licenciamento, por
exemplo).
O resultado desta análise pode ser utilizado para avaliar a viabilidade do cronograma do projeto sob
condições adversas, e para preparar planos de contingência e de resposta para superar ou mitigar o impacto de
situações inesperadas.
Simulação
A simulação envolve o cálculo de múltiplas durações de projeto com diferentes conjuntos de hipóteses. A
técnica mais comum é a análise de Monte Carlo, na qual uma distribuição das possíveis durações de atividades
é definida para cada atividade e usada para calcular uma distribuição de possíveis resultados para o projeto.
Antecipações e esperas
Já vimos esta ferramenta/técnica anteriormente. Vamos revisá-la?
As antecipações e as esperas são refinamentos aplicados durante a análise da rede para produzir um
cronograma viável.
• Antecipações: aplicamos antecipações quando a atividade sucessora puder começar antes que a atual
termine. Exemplo: posso começar a pintar uma parede antes que a aplicação do gesso termine.
• Esperas: ocorre um retardo para início da atividade sucessora. Exemplo: ao pintar a parede preciso de
um tempo para que a tinta seque. Neste caso, eu acrescento um tempo de espera entre as demãos.
Geralmente, estas antecipações e esperas são características do tipo de atividade e se forem aplicadas não
devem envolver aumento de riscos.
Compressões do cronograma
As técnicas de compressão do cronograma devem ser utilizadas quando queremos obter prazos menores
para conclusão do projeto. As mais comuns são:
• Compressão: são alocados mais recursos para as atividades do projeto. Isso, quase sempre, aumenta os
custos do seu projeto. Exemplo: colocar dois pintores ao invés de um para terminar a pintura reduz pela
metade o prazo de entrega, mas em contrapartida dobra o custo da pintura.
• Paralelismo: duas ou mais atividades que estavam originalmente previstas para serem executadas
sequencialmente são executadas simultaneamente. O paralelismo aumenta os riscos do projeto e
também pode gerar retrabalho. Exemplo: Pintar a parede juntamente com a aplicação do gesso pode
ser feito, porém o risco de termos que pintar a parede novamente é muito alto.
Algumas dicas:
• Não use o paralelismo se o diagrama de rede não puder ser alterado, ou se o risco do projeto for
elevado.
• Não usar compressão se não for possível aumentar os custos.
• A compressão é utilizada como meio de antecipar o final do projeto, por isso, normalmente é usada
no caminho crítico (que é o caminho mais longo da rede). Comprimir atividades não críticas não tem
impacto na duração do projeto.
Opções Impacta
Compressão Aumenta os custos
Reduzir escopo Satisfação do cliente
Reduzir a qualidade Satisfação do cliente
Paralelismo Aumenta o risco
Mover recursos de atividades não Aumenta os custos e os riscos
críticas para atividades críticas
Sistema de informações de gerenciamento de projetos (SIGP)

São as ferramentas automatizadas para o desenvolvimento do cronograma que auxiliam e facilitam a criação
dos diagramas de rede, alocações de recursos, otimizações etc.
Planejamento ágil de grandes entregas

Este tópico que tem um título bem sui generis, na verdade trata do Roadmap do produto (chamado pelo
Guia PMBOK de Roteiro do produto), um tema bem usual quando se trata das metodologias ágeis.
O roteiro do produto deve apresentar uma visão panorâmica de todos os lançamentos do produto ao longo
da linha do tempo, contendo características importantes e principais funcionalidades ou conteúdos das versões
futuras. A distribuição das funcionalidades na linha do tempo normalmente se dá por importância, prioridade
e/ou obrigatoriedade.
Saídas
Linha de base do cronograma
A linha de base do cronograma é uma versão específica do cronograma já aceito e aprovado, que será
utilizada na comparação do planejado com o que foi executado no projeto. Esta comparação nos permitirá
perceber como se encontra o projeto em relação ao cronograma original.
Normalmente esta linha de base é marcada com a primeira versão do cronograma aprovado, não sofrendo
mais nenhuma alteração ao longo do projeto, a não ser por meio do gerenciamento integrado de mudanças
(que veremos em capítulos posteriores).
Como o gerenciamento de projetos apresenta processos iterativos, só poderemos fechar a linha de base
do cronograma “definitivamente” ao final da fase de planejamento, depois de executados todos os outros
processos. Observe que “fechar definitivamente” não significa que o cronograma não poderá ser alterado
durante a execução do projeto.
A linha de base do cronograma é um dos componentes do Plano de gerenciamento do projeto.
Cronograma do projeto
Logicamente, a principal saída deste processo é o Cronograma do projeto. Existem alguns elementos
mínimos que todo cronograma deve possuir:
• Conexão de atividades com datas;

• Duração das atividades;
• Marcos;
• Recursos planejados;
• Datas de início e fim de cada atividade.
Um cronograma pode ser apresentado de diversas formas como veremos a seguir.
Gráficos de barras
São mais conhecidos como gráficos de Gantt.
Este diagrama foi desenvolvido em 1917 pelo engenheiro mecânico Henry Gantt. Nele podem ser visualizadas
as atividades de cada membro de uma equipe, o tempo necessário para cumpri-las, o sequenciamento das
atividades, os marcos etc.
Além disso, podem ser apresentados na forma detalhada ou na resumida, como mostrado nas figuras a
seguir.
Gantt detalhado
No gráfico da figura a seguir as barras coloridas representam o início e fim de cada atividade. As atividades
em vermelho são as que estão no caminho crítico. Já as atividades em azul, são as atividades que possuem
folgas e por isso não fazem parte do caminho Crítico.
Os losangos indicam os marcos do projeto. As barras pretas mostram itens da EAP. Por exemplo, o item 2
– Hardware é um subproduto da EAP. Este item foi decomposto em dois pacotes de trabalho: 2.1 e 2.2. E cada
pacote de trabalho foi decomposto em suas atividades (2.1.1, 2.1.2 etc).
Atividade sem folga –

Caminho crítico
Atividade com folga
Subproduto EAP
Pacote de
trabalho
Atividades Marco
Gantt resumo
Este gráfico mostra as atividades-resumo, que normalmente são os produtos indicados na EAP.
Gráfico de marcos
Esses gráficos são muito semelhantes com os gráficos de barras, no entanto mostram apenas os marcos
sinalizados no cronograma.
Diagrama de rede do cronograma do projeto
Já vimos neste capítulo os diagramas de rede do projeto. Os diagramas de rede do cronograma do projeto
são bem parecidos e acrescentam ao diagrama de rede as datas das atividades, a indicação dos caminhos críticos.
Dados do cronograma
São dados complementares ao cronograma que podem estar em seu próprio corpo, ou em documentos
auxiliares, podendo ter:
• Marcos;
• Atividades e atributos das atividades;
• Recursos e seus requisitos;
• Premissas e restrições que foram aplicadas;
• Cronogramas alternativos, como melhor ou pior caso, nivelado ou não nivelado por recursos, com ou
sem datas impostas;
• Alocação das reservas de contingências.

Veja na figura a seguir um exemplo de documento auxiliar do cronograma.
Calendário do projeto
Para alguns projetos faz-se necessário ter um calendário especial, com datas disponíveis para trabalho e
outras não. Este calendário diferenciado deverá ser seguido ao longo do projeto para evitar planejamentos
incorretos.
Atualização do plano de gerenciamento do projeto
Após o desenvolvimento do cronograma, é possível que mudanças sejam necessárias nos seguintes itens do
plano de gerenciamento do projeto:
• Linha de base do cronograma;
• Plano de gerenciamento do cronograma.

Ao se concluir o cronograma do projeto, alguns documentos podem necessitar de alteração, tais como,
atributos das atividades, registro das premissas, estimativas de duração, requisitos dos recursos e registro dos
riscos.
Planejando os Custos
Todo projeto tem um orçamento e parte do seu gerenciamento eficaz está relacionado a concluí-lo dentro
da meta estabelecida. Administrar custos em projetos requer uma abordagem disciplinada referente às
estimativas e ao controle dos custos. É por conta disso que o Guia PMBOK® sugere três processos para auxiliar
no planejamento do gerenciamento dos custos do projeto:
• Planejar o gerenciamento dos custos (7.1);
• Estimar os custos do projeto (7.2);
• Determinar o orçamento (7.3).
Em alguns projetos, principalmente aqueles de menor escopo, os processos desta Área de conhecimento
estão estreitamente conectados sendo vistos como um único processo que poderá ser executado por uma
pessoa. É importante ressaltar que muitas vezes os gerentes de projeto não são responsáveis pela parte
relacionada a custos, ficando um gerente funcional responsável por isso.
Observe que você deve adaptar os processos propostos pelo Guia PMBOK® às necessidades atuais do seu
projeto, uma vez que nem todos os documentos precisarão ser elaborados para que você gerencie seu projeto
com sucesso.
Gasto x Despesa x Custo

Esta área de conhecimento envolve diversos termos que muitas vezes são confundidos, por isso é muito
importante que você os conheça.
Gasto
É todo sacrifício financeiro para obtenção de um produto ou serviço qualquer. Esse sacrifício é representado
pela entrega ou promessa de entrega de ativos (normalmente dinheiro). É um conceito extremamente amplo e
que se aplica a todos os bens e serviços recebidos. Exemplos: gastos com a compra de matérias-primas, gastos
com mão de obra, gastos com honorários da diretoria, gastos na compra de máquinas e equipamentos etc.
Custo
É todo gasto utilizado na produção de outros bens e serviços. Observe que o custo é também um gasto, no
entanto o sacrifício financeiro é utilizado na fabricação de um produto ou execução de um serviço. Exemplos:
energia elétrica utilizada na fabricação de uma peça de computador.
Despesa
É todo gasto não correlacionado com a produção de bens e serviços. Exemplo: a energia elétrica da área
administrativa de uma fábrica que produz peças de computador é um gasto que se torna imediatamente uma
despesa.
Desembolso
Pagamento resultante da aquisição de um bem ou serviço.
Perda
Bem ou serviço consumido de forma anormal e involuntária. Não se confunde com a despesa (muito
menos com o custo), pois não é um sacrifício feito com intenção de obtenção de receita. Exemplos: perdas com
incêndios, gasto com mão de obra durante um período de greve, material deteriorado por um defeito anormal.
Custos diretos
São os custos que podem ser diretamente apropriados aos produtos, bastando haver uma medida de
consumo. Exemplos: custo da mão de obra dos recursos humanos que produzem peças de computador, custo
das matérias-primas usadas na fabricação das peças.
Custos indiretos
São os custos que beneficiam toda a produção e não são identificados individualmente para cada produto.
Ou são aqueles que para apropriação é necessário o uso de rateio ou estimativas. Exemplos: depreciação das
máquinas, aluguel do galpão, energia elétrica da área administrativa, etc.
Custos variáveis
São aqueles que são relacionados (variam) diretamente com o volume de produção ou volume de atividade
da empresa. Quanto maior a produção (volume de atividade) maior o custo variável total; quanto menor o
nível de produção menor o custo variável total. Exemplo: quanto mais eu produzir peças mais vou gastar com
matéria-prima e energia elétrica.
Custos fixos
São aqueles que independem do volume de produção. Trata-se dos custos de estrutura da empresa, e
que não guardam qualquer relação com o volume de atividade. Exemplo: o valor do aluguel não vai aumentar
mesmo caso a produção de peças aumentar.
Custos afundados
São os custos que não podem ser evitados, mesmo que o projeto seja cancelado. Esses custos são relevantes
para avaliar o desempenho do projeto, mas não devem ser relevantes para decidir se o projeto deve seguir em
frente ou ser cancelado. Exemplo: gastos com salários não são relevantes para decidir se o projeto deve seguir
em frente, mas devem ser pagos mesmo que o ele seja cancelado.
Custos recorrentes
São os custos que ocorrem com base repetitiva. Exemplos: salários, aluguéis.
Custos não-recorrentes
São aqueles que ocorrem apenas uma vez no projeto. Exemplo: compra de um equipamento.
Custo do ciclo de vida do produto
O planejamento do escopo a partir do custo de ciclo de vida permite incluir decisões importantes relativas
ao desenvolvimento, operação e descontinuidade do produto. Assim, ponderam-se os custos do ciclo de vida
do produto e não somente do projeto. Exemplo: pode-se decidir elaborar uma documentação simples para um
software, pois isso pode baratear o custo do projeto, no entanto, uma vez instalado o software no cliente isso
poderá gerar altos custos de suporte. (Veja que os custos de suporte são relativos às operações rotineiras e não
custos de projeto!).
Observe que as classificações indicadas não são mutuamente exclusivas. Por exemplo, o gasto com
aluguel pode ser ao mesmo tempo: custo indireto, custo fixo e custo recorrente.

É de extrema importância que os seguintes pontos sejam levados em conta para o sucesso do projeto:
• Examinar e consolidar bem o escopo antes de estimar os custos do projeto.
• Não tentar enganar a si mesmo e nem a outros, fazendo planejamentos inviáveis que sabe que não
podem ser realizados.
• Não aceitar o impulso de estimar os custos do projeto de forma superficial.
• Verificar informações históricas de outros projetos anteriores e similares, para ter como base ao estimar
os custos de um novo projeto.
• A elaboração do orçamento deve envolver preferencialmente toda a equipe e representar um consenso

geral; depois de concluído, o mesmo deve ser bem divulgado, para se tornar do conhecimento de todos
os envolvidos e contar com o comprometimento dos mesmos.
• Procurar envolver ao máximo também os clientes, não só no planejamento, como também na execução
do projeto.
• Obter o máximo de informações inerentes às condições para a execução do projeto, tais como cultura
de trabalho do cliente, normas de segurança, de projeto, de obra e outras praticadas; acordos sindicais
vigentes no local da execução do projeto; calendário religioso/festivo e outros costumes, regionalidades
ou leis locais que possam afetar o desenvolvimento do projeto.
• Analisar e considerar no planejamento os riscos do projeto.
• Monitorar a execução do projeto e adequar o orçamento sempre que for preciso.

Planejar o gerenciamento dos custos (7.1)
O objetivo deste processo é gerar o plano de gerenciamento dos custos que estabelece as políticas,
procedimentos e documentação para planejar, desenvolver, gerenciar, executar e controlar o orçamento do
projeto. O principal benefício deste processo é fornecer orientação de como o orçamento será gerenciado
durante todo o projeto.
O processo
Entradas
Observe que as entradas deste processo são exatamente as mesmas entradas do processo Planejar o
gerenciamento do cronograma do projeto, que por sua vez são exatamente as mesmas do processo Planejar
o gerenciamento do escopo do projeto. É claro que algumas das informações constantes dessas entradas irão
variar entre um processo e outro, por isso vamos passar por elas novamente.

O termo de abertura do projeto é uma entrada muito importante, pois ele contém o orçamento resumo
aprovado para o projeto. Contém também os requisitos de aprovação do projeto que podem influenciar no
gerenciamento dos custos do projeto.

O plano de gerenciamento do projeto é outra entrada deste processo, já que ele contém os planos auxiliares
aprovados que podem influenciar na abordagem adotada no planejamento e gerenciamento dos custos. Dentre
as informações constantes nesse plano temos:
• Plano de gerenciamento do cronograma: este plano contém informações que são muito úteis para
a realização das estimativas de custo, pois elas mostram como o cronograma pode afetar o custo do
projeto.
• Plano de gerenciamento dos riscos: riscos afetam cronograma e custo, por isso a sua importância de
ser aqui avaliado.
É muito importante que estas informações estejam atualizadas, pois podem ter sofrido alterações nos
processos anteriores.

Veja que mais uma vez temos os fatores ambientais da empresa como entrada de um processo. E como
demonstra o Guia PMBOK® existem diversos fatores que podem influenciar este processo, tais como: estrutura
organizacional, cultura organizacional, as condições de mercado (por exemplo, vender ventilador de teto no Polo
Norte pode não ser um bom negócio), taxas de câmbio (quando são usados recursos importados), informações
comerciais publicadas (= catálogos de preços), sistema de informações de gerenciamento de projeto (pois
fornecem possíveis alternativas de gerenciamento dos custos).

E aqui temos mais uma vez os ativos de processos organizacionais como entrada de um processo. Os ativos
referem-se à toda informação acumulada pela empresa, e neste caso são considerados: procedimentos de
controles financeiros (por exemplo, relatórios de despesas, relatórios contábeis etc), informações históricas,
lições aprendidas, bancos de dados financeiros e políticas (formais e informais) de estimativas de custos e de
elaboração de orçamentos.
Como já vimos em outros processos, os especialistas devem ser consultados sempre. Eles são uma importante
fonte de informação, pois podem auxiliar na indicação das melhores ferramentas e métodos, com base em
suas experiências em projetos anteriores. Quando guiada por informações históricas, a opinião especializada
pode fornecer informações sobre estimativas de custos recomendadas para as atividades a partir de projetos
anteriores similares.
Considere que quanto menor a experiência dos profissionais envolvidos nas estimativas, maior será o risco
para o projeto.
Essa análise é usada para prever possíveis resultados simulando cenários e valores das variáveis do projeto.
Por exemplo, estas técnicas podem ser usadas para decidir se o projeto será autofinanciado ou financiado
com capital de terceiros. Outro tipo decisão muito comum é a relacionada a equipamentos: comprar, alugar,
arrendar etc.
Reuniões
especialistas, para desenvolver o plano de gerenciamento dos custos.
Saídas
Como resultado deste processo teremos o plano de gerenciamento dos custos que fornece orientação sobre
como os custos do projeto serão definidos, documentados, verificados, gerenciados e controlados pela equipe
de gerenciamento de projetos. Os componentes de um plano de gerenciamento dos custos do projeto devem
incluir os seguintes elementos:
• Unidades de medida: aqui se definem as unidades que serão usadas nas medições, por exemplo:
• Homem/hora para medida de tempo;
• Litros, quilos, quilômetros etc para medidas de quantidades;
• Reais ou dólares para indicar valores monetários.
• Nível de precisão: define como serão arredondados os valores dos custos das atividades. Por exemplo,
R$259,00 poderá ser arredondado para R$300,00. O nível de precisão depende diretamente do tamanho
e da complexidade do projeto. Por exemplo, em projetos de milhões de reais, será aceitável arredondar
R$900,00 para R$1000,00.
• Nível de exatidão: indica a faixa de erro aceitável das estimativas, podendo incluir uma quantidade
para contingências. Por exemplo, pode-se aceitar uma variação de +- 10% nas estimativas de custo do
projeto.
• Vínculos com procedimentos organizacionais: a primeira vista este termo pode parecer confuso, mas
nada mais é que indicação de que a EAP será utilizada como ponto de partida para a elaboração das
estimativas de custo. O componente da EAP usado para contabilizar os custos é a Conta de controle.
Vimos este elemento em capítulos anteriores, mas vamos revisá-lo agora:
• Segundo o Guia PMBOK®, uma conta de controle é um ponto de controle do gerenciamento onde
o escopo, custo e cronograma são integrados e comparados ao valor agregado para uma medição
de desempenho. Essas contas são localizadas em pontos de gerenciamento selecionados na EAP.
Cada conta de controle pode incluir um ou mais pacotes de trabalho, mas cada um deles deve estar
associado a somente uma conta de controle. Portando, uma conta de controle é um componente da
EAP usado para a contabilidade de custos do projeto.
• Limites de controle: aqui são estabelecidos limites de variação dentro dos quais nenhuma atitude será
tomada. Por exemplo, pode-se estabelecer que uma variação de 10% nos custos são aceitáveis. Caso
haja uma variação de 15%, aí sim algo deve ser feito.
• Regras para medição do desempenho: para que se possa verificar se o projeto está cumprindo
o orçamento, devem ser estabelecidas as regras para medir o desempenho. Um dos métodos mais
utilizados é o gerenciamento do valor agregado (GVA), mas qualquer outro método poderá ser utilizado,
desde que se consiga medir de forma consistente como está o andamento do projeto. (Veremos o GVA
em capítulo referente ao Monitoramento e Controle dos Custos).
• Formatos de relatórios: aqui são estabelecidos os modelos de relatórios que serão apresentados para
as principais partes interessadas.
• Detalhes adicionais: podem ser acrescentadas ao plano informações adicionais, tais como: decisões
de escolha de tipos de financiamento, procedimentos para acompanhar flutuações de câmbio e
procedimentos para registros dos custos.
Estimar os custos (7.2)
Agora que já decompomos as atividades do projeto e que já temos as estimativas, relativamente precisas de
sua duração, a pergunta é: “Quanto vai custar?”. O objetivo deste processo é estimar os custos para cada pacote
de trabalho, ou seja, atribuir valores monetários para os recursos utilizados em cada atividade do projeto.
Observe que este processo estima custos tanto humanos como materiais para cada atividade através de
escolhas da melhor alternativa, avaliação de riscos e trade-offs (acordos, compromissos).
Por exemplo, uma empresa pode optar em desenvolver internamente um software ou comprá-lo de um
fornecedor. E como optar por uma dessas alternativas? Tudo vai depender do escopo do produto. Caso o
software necessário seja algo trivial e a empresa já tenha know-how em desenvolvimento de software, talvez
a melhor alternativa seja desenvolvê-lo internamente. No entanto, caso o software seja complexo (como o
software de controle automatizado de linhas de metrô) talvez o ideal seja realmente terceirizar esta parte do
projeto.
Um ponto importante a ser abordado é que a exatidão de uma estimativa irá aumentar conforme o projeto
se desenvolve através do seu ciclo de vida. Por exemplo, um projeto na fase de Iniciação pode ter estimativas
grosseiras na faixa de -25% a + 75% de variação nos custos. Em etapas posteriores, conforme as informações vão
sendo recolhidas, pode-se ter uma variação de -10 a +25%. Obtendo-se finalmente às estimativas definitivas de
-5% a +10%.
O processo
Entradas
• Plano de gerenciamento dos custos: iremos extrair desse plano as informações referentes ao nível de
exatidão e as unidades de medida para a execução das estimativas de custo das atividades.
• Plano de gerenciamento da qualidade: os padrões definidos de qualidade podem afetar o custo do

projeto, por isso é importante considerá-lo aqui.
• Linha de base do escopo: da linha de base podemos por exemplo, ter como premissa a indicação de que
as estimativas de custo só considerarão os custos diretos. Já os indiretos (luz, energia elétrica, aluguel
etc) não serão considerados como custo do projeto. Outro exemplo se refere ao item mais comum
relacionado aos custos: a restrição orçamentária.
Importante também verificar se as entregas previstas possuem obrigações contratuais, que se quebradas
gerem custos adicionais (por exemplo, atrasos nas entregas podem causar pagamento de multas). Outro item
importante são as normas legais/governamentais que também podem afetar os custos, como por exemplo, as
licenças para construção (alvarás).
• Registro das lições aprendidas: este registro pode ajudar na elaboração das estimativas dos custos a
partir da experiência em projetos anteriores.
• Cronograma do projeto: o cronograma possui detalhes do tipo, data de duração, quantidade etc de
cada atividade do projeto. A partir dessa informação são calculadas as estimativas de custos.
• Requisitos de recursos: os requisitos de recursos têm efeito direto nos custos do projeto. Por
exemplo, supondo que temos uma atividade complexa a ser executada por dois analistas sêniores e a
disponibilidade de recursos é de apenas um analista júnior e um analista sênior, o custo da atividade
será afetado, por conta dos salários diferentes de cada um dos recursos.
influenciar nas reservas de custo.

Os fatores que mais podem influenciar nas estimativas dos custos são:
• Condições de mercado: as condições de oferta e procura podem influenciar nos custos dos materiais e
equipamentos necessários para o projeto.
• Informações comerciais publicadas: é comum existirem bancos de dados com valores de taxas de
recursos, bem como listas de preço padrão de equipamentos e materiais.
• Taxas de câmbio: quando consideramos projetos multinacionais.

Os ativos que mais podem influenciar na estimativa de custos do projeto são as políticas e modelos de
estimativa de custos, informações históricas e as lições aprendidas.
Muitas das ferramentas que serão apresentadas a seguir já foram vistas nos capítulos referentes ao
planejamento do tempo, mas aqui o foco será dado em relação ao custo.
A opinião de especialistas, principalmente daqueles que irão realizar as atividades, é muito importante para
a determinação das estimativas de custo, pois são eles que têm um maior domínio do trabalho a ser realizado.
Estimativa análoga
Também chamada de top-down, utiliza dados de projetos anteriores (análogos) para estimar escopo,
custo, orçamento e duração de atividades. No caso dos custos, esta estimativa utiliza custos reais de projetos já
encerrados como base de estimativa para os custos do projeto.
Esta estimativa é muito útil quando se tem pouca informação detalhada do projeto e precisamos entregar
logo as estimativas iniciais de custo, ou seja, na fase inicial de planejamento do projeto ainda temos poucas
informações detalhadas, e é neste momento que esta técnica deve ser aplicada.
Mas veja que ela não é uma técnica muito exata, justamente porque estimamos os valores atuais a partir de
valores de atividades similares realizadas em projetos anteriores.
Mesmo assim, se o seu projeto não é muito complexo ou é de fato similar (as atividades são realmente
semelhantes) e a equipe do projeto possui habilidade para realizar as estimativas, a estimativa análoga torna-se
mais confiável.
Esta estimativa utiliza um algoritmo (ou fórmula matemática) juntamente com dados históricos para
o cálculo dos custos das atividades. Embora o Guia PMBOK® não cite explicitamente, existem dois tipos de
estimativas paramétricas:
• Análise de regressão: esta é uma abordagem estatística que prevê valores futuros a partir de valores
históricos.
• Curva de aprendizado: esta abordagem é bem simples, e indica que o custo por unidade decresce a
medida que mais unidades de trabalho são completadas, já que os trabalhadores vão aprimorando
seu aprendizado ao longo do tempo. Isto só é verdade nos casos de trabalhos repetitivos, tais como,
construção de casas, pinturas de muros, montagem de computadores etc.
qualidade. Pode ser utilizada apenas em uma parte do projeto e também pode ser usada em combinação com
outras técnicas.
Estimativa de três pontos

Já vimos em detalhes este tipo de estimativa em capítulos anteriores. Resumidamente temos que esta
ferramenta/técnica é baseada em três estimativas distintas: a otimista, a pessimista e a mais provável. Assim,
ela considera o grau de incerteza e risco a que uma determinada atividade pode estar exposta.
As estimativas de três pontos mais comuns em gerenciamento de projetos são:
• Distribuição beta (ou PERT);

• Distribuição triangular.
Estimativa bottom-up
Esta ferramenta consiste em estimar o custo de cada pacote de trabalho de uma EAP de baixo para cima,
chegando ao custo estimado total do projeto. Um item deve possuir a somatória de custo de seus subitens e
assim por diante conforme mostrado na figura a seguir.
Observe que a estimativa bottom-up é feita de baixo para cima. No exemplo da figura a seguir, primeiro
somamos os valores das estimativas das atividades dos Pacotes de trabalho A e B, gerando o resultado C.
Prosseguimos somando de baixo para cima até obtermos H que é a soma de tudo que está abaixo dele.
A estimativa bottom-up NÃO é uma alternativa adequada para fazer uma estimativa de custos nas fases
iniciais do projeto, uma vez que nessa fase ainda não temos detalhes suficientes das atividades envolvidas no
projeto. Em seu lugar, recomenda-se o uso da estimativa análoga.
Algumas características a destacar são:

• Estimativa muito precisa;
• Demorada e custosa, pois usa a EAP para agregar os custos.
Um ponto muito importante a ser destacado é que esta ferramenta só será utilizada para agregar
valores até o nível do pacote de trabalho neste processo. Os demais níveis da EAP serão agregados no
processo seguinte: Determinar o orçamento.
Casa dos meus sonhos
Up
H
1. Gerenciamento 3. Acabamento
2. Construção
do Projeto interno
F E G
2.1 Fundação
2.2 Primeiro Andar

C
2.2.1 Suite 1
Ordem a seguir: atividades
1o
C = A + B Comece por aqui
B
Bottom
2.2.2 Suite 2
2o E = D
+ C
atividades
3o H = F + E + G
Análise de dados
Análise das reservas
Já vimos esta técnica anteriormente. Em resumo, temos que o seu objetivo é utilizar buffers (reservas de
contingência) caso possíveis riscos conhecidos venham a se manifestar. A reserva de contingência faz parte da
linha de base de custos.
Várias alternativas podem surgir quando, por exemplo, o custo de um recurso excede o valor previsto. Assim
esta técnica pode avaliar se valeria a pena construir um item ou comprá-lo ou ainda alugá-lo etc.
Custo da qualidade
Veremos com detalhes o que são custos da qualidade quando abordarmos os processos da área de
conhecimento gerenciamento da qualidade. Neste ponto, apenas indicamos que esse custo está ligado aos
produtos com defeitos, incluídos todos os custos na produção, detecção, reparo e correção das causas desses
defeitos.
Software de gerenciamento de projetos

Aplicativos de software, planilhas, ferramentas estatísticas etc, podem ser usadas para ajudar nas estimativas
dos custos. Atualmente é impensável realizar estimativas sem o auxílio de alguma dessas ferramentas.
Análise de proposta de fornecedor

Como o próprio nome sugere, esta técnica tem como foco avaliar as propostas dos fornecedores para
estabelecer as estimativas de custo. Quando um projeto precisa ser executado por um fornecedor, usualmente
se estabelece um processo competitivo para que se possa escolher o melhor (baseado em diversos critérios:
preço, técnica etc). Veremos em detalhes como é esse processo quando abordarmos a área de gerenciamento
de aquisições.
Tomada de decisão
O Guia PMBOK® cita que a técnica a ser usada aqui é a votação, mas não se limita a ela. O que importa é
que todos os envolvidos cheguem a um consenso com relação à estimativa dos custos.
Saídas
Estimativas de custos
Obviamente, a principal saída deste processo é a estimativa de custo das atividades. Essas estimativas
usualmente estarão em valores monetários e se referem a todos os recursos necessários (pessoas, equipamentos,
materiais, serviços, taxas de câmbio e inflação, juros, financiamentos, aluguéis etc) para completar as atividades
do projeto.

A base das estimativas fornece a documentação de suporte aos valores estimados dos custos. Imagine que
seu projeto tenha a duração de dois anos, e que o patrocinador queira saber, depois de decorridos 18 meses do
projeto, de onde você tirou o valor estimado de uma das atividades.
a estimativa de custos foi derivada. Os detalhes de suporte para estimativas de custos de atividades podem
incluir:
• Documentação das bases para a estimativa (por exemplo, como foi desenvolvida);
• Documentação de todas as premissas adotadas;
• Documentação de quaisquer restrições conhecidas;
• Indicação da faixa das estimativas possíveis (por exemplo, $10.000 (±10%) para indicar que o custo do
item é esperado nesse intervalor de valores);
• Indicação do nível de confiança da estimativa final.

É claro que alguns documentos do projeto serão afetados pelas estimativas de custo das atividades, e devem
ser atualizados. Entre eles podemos citar: a especificação do escopo do projeto, os documentos de aquisição
do projeto e o registro de riscos.
Determinar o orçamento (7.3)
O orçamento pode ser definido como a determinação dos gastos necessários para a realização de TODAS as
atividades de um projeto, de acordo com o plano de gerenciamento previamente estabelecido. Para obtermos
o orçamento devemos somar os custos estimados de todas as atividades individuais (ou pacotes de trabalho) e
totalizá-los.
Este processo cria a linha de base de custos que será utilizada como medida de desempenho do projeto a
partir da técnica do gerenciamento do valor agregado (GVA) que será vista em detalhes nos capítulos referentes
ao monitoramento e controle dos custos.
Além dos custos estimados, este processo considera dois tipos de reservas:
• Reserva de contingência para incógnitas conhecidas (known unknowns), itens que identificamos no
gerenciamento de riscos. Exemplo: eventuais atrasos na entrega de algumas atividades por conta do
período de chuvas em São Paulo.
• Reserva de gerenciamento para incógnitas desconhecidas (unknown unknowns), itens que não
conseguimos identificar no gerenciamento de riscos. Exemplo: neste caso reservamos um percentual
do valor do projeto para eventuais “catástrofes” não previstas. Além disso, a aprovação da alta direção
é necessária para fazer uso da reserva de gerenciamento.
A reserva de contingência é calculada e faz parte da linha de base do custo. Já a reserva de

gerenciamento é estimada (por exemplo, 5% do custo do projeto) e faz parte do orçamento do projeto, mas
não da linha de base.
O processo
Entradas
Este processo repete várias entradas já vistas em detalhes anteriormente. Por isso, faremos uma breve
revisão delas.

• Plano de gerenciamento dos custos: este plano estabelece como os custos serão estimados, gerenciados
e controlados.
• Plano de gerenciamento dos recursos: este plano mostra informações sobre custos de pessoal e
materiais, bem como outros gastos tais como viagens, gastos adicionais etc.
• Linha de base do escopo: a linha de base pode conter indicação de limitações formais de gastos por
período. Por exemplo, o cliente do projeto pode exigir que o projeto não gaste mais do que uma
determinada quantia mensal, mesmo que exista orçamento disponível.
• Base das estimativas: este documento, também saída do processo anterior, contém os detalhes de
suporte das estimativas de custo.
• Estimativas de custos das atividades: esta é a saída do processo anterior (Estimar os custos) que fornece
os custos de cada pacote de trabalho.
• Cronograma do projeto: o tipo e a quantidade dos recursos, além da quantidade de tempo que será
alocada para esses recursos são fatores muito importantes na determinação do custo do projeto. Por
isso, do cronograma iremos extrair as seguintes informações:
ДД Datas de início e fim de cada atividade;
ДД Marcos;
ДД Pacotes de trabalho;
ДД Contas de controle.
• Registro dos riscos: ainda não vimos o que é o registro dos riscos, pois este será detalhado na área de
conhecimento gerenciamento dos riscos. De forma resumida temos que o registro de riscos deve ser
revisto para considerar os custos das respostas aos riscos, principalmente aqueles que gerem impactos
negativos ao projeto. Obviamente, riscos que tragam benefícios monetários ao projeto também devem
ser considerados.
Acordos
Este item será visto com mais detalhes quando abordarmos a área de conhecimento Gerenciamento
das aquisições. Mas, de forma resumida, temos que as informações de contrato de compra de materiais,
equipamentos, etc devem ser considerados na formação do orçamento do projeto.

Entre os fatores ambientais que podem afetar a estimativa de custos está a taxa do câmbio.

Os ativos que mais podem influenciar na determinação do orçamento do projeto são as políticas e
procedimentos relacionados a orçamentos, ferramentas de controle de orçamento e métodos de elaboração
de relatórios.
Especialistas podem ajudar (e muito) na elaboração do orçamento do projeto. Podem ser: consultores,
partes interessadas, outros departamentos etc.
Agregação de custos
A agregação de custos nada mais é que a soma dos valores dos níveis inferiores da EAP (pacotes de trabalho)
até os níveis superiores.
Importante ressaltar que as contas de controle são pontos onde o escopo, custo e cronograma são integrados
e comparados ao valor agregado para medição de desempenho. Essas contas são localizadas em pontos de
gerenciamento selecionados na EAP. Cada uma pode incluir um ou mais pacotes de trabalho, mas cada pacote
de trabalho tem que estar associado a somente uma conta de controle. Portanto, uma conta de controle é um
componente usado para a contabilidade de custos do projeto.
Na figura a seguir mostramos um exemplo do processo de Determinar o orçamento a partir de dados de
um projeto fictício.
Orçamento total
R$ 1785,00
do projeto
Reserva de
gerenciamento + R$ 85,00 5% Linha de
base de custos
Linha de base de
R$ 1700,00
custos
Reserva de
contigência + R$ 200,00
Custo do projeto R$ 1500,00
Contas de C1
Controle R$ 1000,00 C2
R$ 500,00
Pacotes de P1 P2 P3
trabalho R$ 100,00 R$ 500,00 R$ 400,00
A1 A2 A3 A4
Atividades
R$ 25,00 R$ 25,00 R$ 25,00 R$ 25,00
Veja que:
1. Inicialmente temos os custos das atividades (A1, A2, A3 e A4) que são somadas no pacote de trabalho
(P1);
2. A seguir os pacotes de trabalho (P1, P2 e P3) são somados para compor a conta de controle (C1);
3. As contas de controle (C1 e C2) são então somadas para compor o custo do projeto;
4. Observe que além do Custo do projeto os dois tipos de reserva (contingência e gerencial) devem ser
considerados. Ao somarmos o custo do projeto à reserva de contingência obteremos a linha de base de
custo. E esta ao ser somada à reserva de gerenciamento gera o orçamento total do projeto;
5. Veja que conta de controle C2 vem de outro ramo da EAP do projeto, que não foi representada nessa
figura.
Análise de dados
Uma das técnicas de análise de dados é a análise das reservas, que tem por objetivo estabelecer as reservas
gerenciais do projeto. Essas reservas são custos que não podem ser estimados já que se referem aos eventos de
riscos que não podem ser previstos, ou seja, incógnitas desconhecidas (unknown unknowns). São criadas para
suportar o impacto de riscos não previstos, tais como eventos climáticos, mudanças organizacionais, mudanças
não previstas no escopo etc.
Revisão de informações históricas

Elaborar um orçamento do “zero” não é muito prático, ainda mais se já existirem dados históricos. Mas
veja que o item aqui indica revisão de informações históricas e não dados históricos. Isso se deve ao fato de
que devemos utilizar as “fórmulas” ou “formas” de cálculo históricas e não os valores históricos. Por exemplo,
uma empresa de construção civil, que lança anualmente edifícios de moradia popular, deve utilizar os mesmos
modelos matemáticos para calcular o orçamento de suas obras.
Reconciliação dos limites de recursos financeiros

Esta técnica envolve ajustes nos cronogramas do trabalho para nivelar ou regular variações indesejáveis
nos gastos. É realizada colocando restrições de datas para alguns pacotes de trabalho. Por exemplo, um projeto
gastou mais do que o previsto neste semestre por conta de uma enchente que inutilizou parte do canteiro
de obras. Por conta disso, as obras de paisagismo, previstas inicialmente para começar neste semestre, serão
adiadas para o fim do semestre seguinte.
Financiamento
Esta técnica está relacionada à obtenção de recursos financeiros para o projeto. É muito comum que a
empresa executora do projeto não tenha todos os recursos financeiros necessários, e sendo assim recorre à
instituições financeiras para captar tais recursos.
Saídas
Linha de base dos custos
A principal saída deste processo é a linha de base dos custos do projeto que será utilizada nos processos de
monitoramento e controle. O objetivo maior da linha de base de custo é oferecer parâmetros de comparação
entre o custo real (atual) e o custo planejado (orçado).
A linha de base de custos indica mês a mês os recursos que estão sendo consumidos e quanto será necessário
(financiamento) para prosseguir.
Ela é representada graficamente por uma curva em S como a mostrada na figura a seguir:
A linha de base de custo tem esse formato porque os custos são mais baixos no início do projeto e tendem
a aumentar durante a sua execução.
A linha de base de custo considera a reserva de contingência na sua composição. Já o orçamento do

projeto, além de considerar a linha de base inclui também a reserva de gerenciamento.
Requisitos de recursos financeiros do projeto

O financiamento do projeto é liberado por partes, ou seja, normalmente ele não recebe todos os recursos
necessários no início. Dessa forma, os requisitos de recursos financeiros do projeto são gerados a partir da linha
de base dos custos.
Importante ressaltar que as reservas de gerenciamento também fazem parte dos requisitos de recursos
financeiros do projeto, uma vez que é aqui que são injetados os recursos monetários.

E como em todos os processos que já vimos, poderão ser necessárias atualizações nos documentos do
projeto, tais como: registro dos riscos, estimativas de custo e cronograma do projeto.
Planejando a Qualidade
O gerenciamento da qualidade deve ser direcionado tanto para a gerência do projeto quanto para o seu
produto. O termo genérico “produto” é ocasionalmente empregado na literatura da qualidade para referenciar
tanto a bens quanto a serviços. O fracasso em se atingir os requisitos de qualidade, pode trazer consequências
negativas sérias para uma ou até mesmo para todas as partes envolvidas do projeto.
Assim, o planejamento da qualidade é o processo de identificação dos requisitos e/ou padrões da qualidade
do projeto e suas entregas, além da documentação de como ele demonstrará a conformidade com os requisitos
de qualidade.
O gerenciamento da qualidade do projeto se aplica a todos os projetos, independentemente da natureza

das suas entregas. O Guia PMBOK® sugere o seguinte processo relativo ao planejamento da qualidade:
• Planejar o gerenciamento da qualidade (8.1).

A equipe de gerência do projeto deve também estar atenta ao fato de que a gerência moderna da qualidade
complementa a gerência do projeto. Por exemplo, ambas devem reconhecer a importância da/dos:
• Satisfação do cliente: entender, gerenciar e influenciar necessidades de forma que as expectativas do

cliente sejam satisfeitas. Isto exige a combinação de conformidade com requerimentos (o projeto deve
produzir o que foi dito que ele produziria) e conveniência para o uso (o produto ou serviço produzido
deve satisfazer as necessidades reais).
• Prevenção ao invés de inspeção: o custo da prevenção de erros é sempre muito menor que o custo para
corrigi-los.
• Responsabilidade da gerência: o sucesso exige a participação de todos os membros da equipe, mas

permanece a responsabilidade da gerência em fornecer os recursos necessários para se ter êxito.
• Processos dentro de fases: o ciclo repetitivo de planejar, fazer, checar e agir (PDCA) descrito por Deming
deve ser utilizado por todo o ciclo de vida do projeto.
Conceitos básicos sobre Qualidade
Do latim, “qualitate”, a qualidade está muitas vezes ligada a aspectos subjetivos que refletem as necessidades
internas de cada um. Muitas pessoas avaliam a “qualidade” pela aparência; outras pelas características do
material com que é feito o produto e outras, ainda, avaliam a qualidade de algo pelo seu preço.
A preocupação com a qualidade existe desde os tempos em que reis faraós governavam o mundo. O
primeiro relato documentado remonta aos tempos de Hamurabi e seu código. Numa das seções desse código
lê-se que “Se uma casa mal construída causa a morte de um filho do dono da casa, então o filho do construtor
será condenado à morte”.
É inegável que o movimento da qualidade tem contribuído de forma marcante até os dias atuais na obtenção
das vantagens competitivas das empresas. Feigenbaum, um dos “gurus” da qualidade dividiu esse movimento
em cinco fases:
• Controle da qualidade pelo operador (1900): não era ainda um movimento em prol da qualidade, mas
apenas uma forma de trabalho em que o trabalhador era responsável pela fabricação do produto por
inteiro e também pela qualidade de seu serviço.
• Controle da qualidade pelo supervisor (1918): nesta fase, evolução da anterior, um supervisor assumia
a responsabilidade da qualidade referente ao trabalho de sua equipe.
• Controle da qualidade por inspeção (1937): esta fase surgiu com a finalidade de verificar se os materiais,
peças, componentes, ferramentas e outros estavam de acordo com os padrões estabelecidos. Cada
peça saída da produção deveria ser verificada (inspecionada).
• Controle estatístico da qualidade (1960): na produção industrial dificilmente uma peça é exatamente
igual à outra. Sempre existirão pequenas variações. Esta fase foca não em distinguir se houve ou não
uma variação, mas em identificar quais variações estão dentro de um nível aceitável. Foi nesta fase
que surgiram as sete ferramentas básicas da qualidade: fluxograma, folha de verificação, diagrama de
Pareto, diagrama de causa e efeito, histograma, diagrama de dispersão e carta de controle.
• Controle da qualidade total (1980): a partir desta fase a qualidade passa a ser vista como um processo
global dentro da empresa. Inicia-se o efetivo gerenciamento em que além de prevenir e atacar os
problemas começa-se a quantificar os custos da qualidade e ela passa a fazer parte da Visão Estratégica
Global da empresa, com o objetivo de manter a sua competitividade em termos mundiais para atender
as grandes transformações que ocorrem no mercado.
Os gurus da qualidade
São as pessoas que desempenham um grande papel para o desenvolvimento da tecnologia e que tornam
possíveis os avanços da humanidade. Dentre tantos homens e mulheres, citamos os que mais se destacaram e
que foram imprescindíveis para o desenvolvimento do gerenciamento da qualidade no mundo.
Feigenbaum
Armand Feigenbaum (1922-2014) é considerado o “pai” da qualidade. Ele afirmava que este é um trabalho
de todos na organização, uma vez que não é possível fabricar produtos de alta qualidade se o departamento de
manufatura trabalha isolado.
Segundo ele, diferentes departamentos devem intervir nas parcelas do processo que resultam no produto,
e esta colaboração varia desde o projeto do produto ao controle pós-venda, para que assim não ocorram erros
que prejudiquem a cadeia produtiva, causando problemas ao consumidor.
Em 1968 escreveu o livro “Gerenciamento da Qualidade Total” (Total Quality Management – TQM). Nele
define o TQM como: “um sistema eficaz para integrar esforços de desenvolvimento, manutenção e melhoria
da qualidade dos vários grupos de uma organização, permitindo levar a produção e o serviço aos níveis mais
econômicos da operação e que atendam plenamente à satisfação do consumidor”.
Embora tenha sido publicado nos Estados Unidos, foram os japoneses que primeiro colocaram o conceito
em prática, em escala ampla e, consequentemente, popularizaram a abordagem e a sigla TQM.
Deming
Edward Deming (1900-1994) introduziu a filosofia da qualidade total na indústria japonesa do pós-guerra
juntamente com seu colega Joseph Juran. Foi quase um deus para os gestores japoneses, que em 1951, criaram
um prêmio de qualidade em sua homenagem (o Deming Prize). É o criador do ciclo PDCA.
A filosofia básica de Deming é que a qualidade e a produtividade aumentam à medida que a “variabilidade
do processo” (imprevisibilidade do processo) diminui.
Juran
Joseph M. Juran (1904-2008) acompanhou Edward Deming na revolução da qualidade no Japão do pós-
guerra. Juran é um dos mais importantes inspiradores do conceito de qualidade total, disseminado através de
suas obras, a “Trilogia de Juran” é aceita mundialmente como a referência básica para a gestão e o controle de
qualidade. Segundo ele a gestão da qualidade se divide em três pontos fundamentais:
Planejamento -> Controle -> Melhoria da Qualidade
1. Planejamento da qualidade: é o processo de preparação para obtenção dos objetivos da qualidade. É

um conjunto de atividades que visam desenvolver os produtos e processos necessários para atender às
necessidades dos clientes. Engloba as seguintes atividades:
• Identificar os consumidores.
• Determinar as suas necessidades.
• Criar características de produto que satisfaçam essas necessidades.
• Criar os processos capazes de satisfazer essas características.
• Transferir a liderança desses processos para o nível operacional.
2. Controle da qualidade: é o processo que assegura o cumprimento dos objetivos da qualidade durante
as operações. Consiste em:
• Avaliar o nível de desempenho atual.
• Comparar com os objetivos fixados.
• Tomar medidas para reduzir a diferença entre o desempenho atual e o previsto.
3. Melhoria da qualidade: é o processo que visa elevar a qualidade a novos níveis de desempenho. Envolve
as seguintes atividades:
• Reconhecer as necessidades de melhoria.
• Transformar as oportunidades de melhoria numa tarefa de todos.
• Criar um conselho de qualidade.
• Promover a formação em qualidade.
• Avaliar a progressão dos projetos.
• Premiar as equipes vencedoras.
• Fazer a publicidade dos resultados.
• Rever os sistemas de recompensa para aumentar o nível de melhorias.
• Incluir os objetivos de melhoria nos planos de negócio da empresa.
Os três processos da trilogia de Juran estão inter-relacionados como mostrado na figura a seguir:
Fonte: http://walkerbastos.blogspot.com.br/2012/03/o-sistema-de-gestao-da-qualidade-no.html
Ishikawa
Kaoru Ishikawa (1915-1989) aprendeu os princípios do controle estatístico da qualidade com Deming e
Juran e traduziu, integrou e expandiu seus conceitos para o sistema japonês.
Ishikawa quis mudar a maneira das pessoas pensarem a respeito dos processos de qualidade. Para ele, a
qualidade é uma revolução da própria filosofia administrativa, exigindo uma mudança de mentalidade de todos
os integrantes da organização, principalmente da alta direção.
Ishikawa criou em 1982 o diagrama de causa e efeito ou espinha de peixe, também conhecido como
diagrama de Ishikawa. Seu diagrama forneceu uma poderosa ferramenta que pode ser facilmente usada
por não especialistas para analisar e resolver problemas.
Crosby
Philip Bayard “Phil” Crosby (1926-2001) foi um empresário e escritor que contribuiu para a teoria de gestão
e práticas da qualidade. Ele sugeriu que muitas organizações não sabem quanto gastam em qualidade, seja para
consertar o que fazem de errado ou para fazer o certo.
Crosby procurou destacar os custos e benefícios da implementação de programas de qualidade através

de seu livro “Qualidade é grátis” (Quality is free), no qual apresentou um programa de zero defeito, em que
acreditava poder reduzir o custo total da qualidade.
Isso é resumido em suas máximas:

• Fazer certo da primeira vez.
• Qualidade é conformidade às exigências.
• Previsão, não inspeção.
• O padrão de desempenho deve ser “zero defeito”.
• Mensure o “preço da não-conformidade”.
• Não existe essa figura chamada problema de qualidade.
O método de Crosby para a melhoria da qualidade incluía um programa de 14 passos. Sua crença era de
que uma organização que estabeleceu um programa de qualidade teria um retorno econômico que iria pagar o
custo do programa de qualidade, em outras palavras “a qualidade é grátis”.
Mas afinal, o que é QUALIDADE ?

Qualidade é hoje uma palavra muito difundida nas empresas. Veja na tabela a seguir o que os gurus da
Qualidade se “arriscaram” a definir.
Guru Definição de Qualidade
Ishikawa “Qualidade é desenvolver, projetar, produzir e comercializar
um produto de qualidade que é mais econômico, mais útil e
sempre satisfatório para o consumidor.”
Juran “Qualidade é ausência de deficiências”, ou seja, quanto
menos defeitos, melhor a qualidade.
“Qualidade é adequação ao uso”.
Feigenbaum “Qualidade é a correção dos problemas e de suas causas ao
longo de toda a série de fatores relacionados com marketing,
projetos, engenharia, produção e manutenção, que exercem
influência sobre a satisfação do usuário”.
Crosby “Qualidade é a conformidade do produto às suas
especificações.” As necessidades devem ser especificadas,
e a qualidade é possível quando essas especificações são
obedecidas sem ocorrência de defeito.
Guru Definição de Qualidade
Deming “Qualidade é tudo aquilo que melhora o produto do ponto de
vista do cliente”. Deming associa qualidade à impressão do
cliente, portanto não é estática.
ISO
A ISO (Internacional Organization for Standardization) é uma entidade totalmente focada em criar padrões e
aprovar normas internacionais em todos os campos técnicos, como normas técnicas, normas de procedimentos
e processos etc. Foi criada em 1947 e sua sede é em Genebra, Suíça. No Brasil, a ISO é representada pela ABNT
(Associação Brasileira de Normas Técnicas).
A ISO promove a normatização de empresas e produtos, para manter a qualidade permanente. As normas
mais conhecidas, ISO 9000 e 9001 representam um conjunto de ações preventivas, para garantir e padronizar
um serviço ou um produto. Conforme estabelecido nas normas dessa família ISO 9000, “o objetivo da melhoria
contínua de um sistema de gestão da qualidade é aumentar a probabilidade de melhorar a satisfação dos
clientes e de outras partes interessadas”. As ações para a melhoria incluem o seguinte:
• Análise e avaliação da situação existente para identificar áreas para melhoria;
• Estabelecimento dos objetivos para melhoria;
• Pesquisa de possíveis soluções para atingir os objetivos;
• Avaliação e seleção dessas soluções;
• Implementação da solução escolhida;
• Medição, verificação, análise e avaliação dos resultados da implementação para determinar se os
objetivos foram atendidos;
• Formalização das alterações.
Custo da qualidade
Pode parecer contraditório, mas custo da qualidade são os custos da não qualidade em sua empresa!
O custo da qualidade está ligado aos produtos com defeitos, incluídos todos os custos de prevenção,
detecção, reparo e correção das causas desses defeitos. Já os custos envolvidos com a produção de um produto
com qualidade NÃO integram os custos da qualidade.
O custo da qualidade é uma das ferramentas/técnicas utilizadas no gerenciamento da qualidade como

veremos ainda neste capítulo.
Esses custos podem ser divididos nas seguintes categorias:
• Custos de Prevenção: são os custos de todas as atividades destinadas especificamente a prevenir a

qualidade pobre. É um custo preventivo.
• Custos de avaliação: são os custos associados com a medição, avaliação ou auditoria de produtos ou
serviços de modo a garantir conformidade com padrões de qualidade e requisitos de desempenho.
• Custos de falha: são os custos associados com a falha em atingir os requisitos. Inclui os custos de falha
internos e externos (detectadas pelo cliente). É um custo reativo.
Qualidade x grau
Qualidade e grau são conceitos diferentes e muitas vezes confundidos. Vamos às definições:
O gerente e sua equipe de gerenciamento são responsáveis pelo gerenciamento dos compromissos
associados à entrega dos níveis requeridos de qualidade e grau.
Pode não ser um problema se um produto de software com poucas funcionalidades (baixo grau de
qualidade) for de alta qualidade (sem defeitos óbvios e manual legível), já que o produto seria apropriado
para o objetivo geral de uso.
Mas pode ser um problema se um software com muitas funcionalidades (alto grau de qualidade) for
de baixa qualidade (com muitos defeitos e documentação de usuário mal organizada). Em essência, as suas
múltiplas funções seriam ineficazes e/ou ineficientes devido à sua baixa qualidade.
Exatidão x precisão
Exatidão e precisão são aspectos diferentes, mas fundamentais, que precisam ser levados em consideração
quando desejamos avaliar a qualidade do resultado de uma medição e/ou processo.
A precisão é definida através do desvio padrão de uma série de medidas de uma mesma amostra ou um
mesmo ponto. Quanto maior o desvio padrão, menor é a precisão. A precisão está relacionada com as incertezas
aleatórias da medição e tem relação com a qualidade do instrumento.
A exatidão está relacionada às incertezas sistemáticas da medição. A exatidão pode ser avaliada através da
calibração do instrumento.
Veja na figura a seguir um exemplo da diferença entre precisão e exatidão.
Fonte: http://calibraend.blogspot.com.br/2013/02/voce-conhece-diferenca-entre-precisao-e.html
A equipe de gerenciamento deve determinar níveis adequados de exatidão e precisão para uso no plano
de gerenciamento da qualidade.
Gerenciamento da qualidade total

O gerenciamento da qualidade total, ou como é mais conhecido, TQM (Total Quality Management) é
uma técnica multidisciplinar de administração, que utiliza programas, ferramentas e métodos nos processos
produtivos de uma empresa. O gerenciamento da qualidade total visa obter o domínio sobre a satisfação de
todas as pessoas que têm alguma participação no processo produtivo e aquisitivo.
O TQM é guiado por princípios como os mostrados a seguir:

Princípio Descrição
Satisfação do Quando se fala em qualidade total os clientes são vistos
cliente como a parte mais importante de uma empresa e ela
deve criar ações de atendimento ao cliente, parceria
e superação de expectativas. Uma organização deve
direcionar suas metas através da satisfação de seus
clientes.
Gerência As empresas devem se habituar a repassar informações
participativa aos seus funcionários, pois esse processo de mobilização
gera mais responsabilidade na empresa. A liderança
deve ouvir, motivar, delegar, informar, compartilhar e
transformar seus funcionários em equipes de trabalho.
Reduzir o medo de opinar e estimulá-los para que
digam o que pensam. A participação leva a outras
ações ocasionando melhor convívio com os clientes,
fornecedores, acionistas e comunidade.
Aprimoramento Os seres humanos são uma parte essencial de um
dos recursos processo produtivo e motivá-los ajuda a aumentar
humanos o potencial e a iniciativa. Deve-se fazer com que
eles conheçam a missão e as metas da empresa. Em
contrapartida a empresa deve investir em capacitação e
treinamento.
Constância de As mudanças e alterações dentro de uma empresa
propósitos devem ser regularmente reforçadas e repetidas dentro da
organização. As ideias devem ser coerentes e executadas
de forma clara. Novos processos são implantados
gradualmente até que a alteração se torne irreversível.
Aperfeiçoamento A empresa deve antecipar as necessidades de seus
contínuo clientes se comprometendo a melhorar, inovar, utilizar
novas tecnologias, inserir metas e usar indicadores
de desempenho. O aperfeiçoamento deve ser uma
constância na empresa superando a expectativa e
garantindo satisfação dos clientes.
Gerenciamento O gerenciamento dos processos possibilita a redução
de processos de impedimentos entre as diversas áreas da empresa
provendo uma maior integração.
Princípio Descrição
Delegação O controle de uma empresa se torna mais eficiente
quando a responsabilidade é descentralizada e dividida
e as decisões possuem autonomia. As tarefas devem
ser delegadas para funcionários capacitados e deve-
se garantir a comunicação rápida de forma a reduzir
barreiras e a demora na resolução de problemas.
Disseminar As informações devem fluir na empresa com os
informações funcionários tendo ciência da missão, dos propósitos e
os planos da instituição. Deve-se estabelecer um sistema
interno de informações. Os clientes também devem
saber a missão e os objetivos da empresa, garantido a
transparência dos diversos grupos do ciclo empresarial:
fornecedores, clientes e funcionários.
Garantia da Planejar e formalizar são essenciais para garantir a
Qualidade qualidade de um sistema. Os processos devem ser tornar
rotineiros e sistemáticos, as ações devem ser planejadas
e a qualidade do serviço prestado deve ser garantida. É
importante ter tudo documentado para facilitar o acesso
e permitir que ele seja encontrado.
Não aceitar erros A política em uma empresa deve ser a de “Zero Defeito”
e ser adotada por todos os seus segmentos. Ações
corretivas devem ser introduzidas em casos recorrentes,
pois prevenir um erro sai mais barato do que consertá-lo
posteriormente.
Prevenção ao A qualidade deve ser planejada, projetada e criada, e
invés de inspeção não inspecionada no gerenciamento do projeto ou nas
entregas do projeto. O custo de prevenção dos erros é
geralmente muito menor do que o custo de corrigir tais
erros quando eles são encontrados pela inspeção ou
durante o uso do produto.
Melhoria contínua
A melhoria contínua da qualidade é a abordagem sistemática, coordenada e baseada em prioridades
relacionadas à melhoria das normas de desempenho da qualidade e à redução dos custos em todas as funções
de uma organização. É fundamentalmente olhar para frente, procurando atingir níveis de desempenho mais
altos, através da identificação e solução de problemas da qualidade.
A melhoria contínua se aplica a partir do uso de metodologias sistemáticas que utilizadas por equipes
multifuncionais e interdisciplinares permitem uma análise rigorosa dos problemas crônicos que afetam os
resultados. Neste capítulo abordaremos algumas das mais importantes vertentes que tornam o processo de
melhoria contínua efetivo:
• PDCA
• Kaizen
• 5S
• 6 Sigma
• QFD
• Benchmarking
• Análise de valor
PDCA
Também conhecido como ciclo de Deming, o PDCA é um método gerencial utilizado principalmente para
a melhoria contínua. Este método deverá ser aplicado de forma cíclica e ininterrupta, consolidando-se assim a
padronização de práticas.
Suas fases são:
1ª fase – Plan O primeiro passo para a aplicação do

(Planejamento) PDCA é o estabelecimento de um plano
que deverá ter como base as diretrizes
e políticas da empresa. São três passos
importantes a serem considerados:
o estabelecimento dos objetivos; o
estabelecimento do caminho para que
o objetivo seja atingido e, a definição
do método que deve ser utilizado
para consegui-lo. A boa elaboração do
plano evita falhas e perdas de tempo
desnecessárias nas próximas fases do
ciclo.
2ª fase – Do O segundo passo do PDCA é a execução
(Execução) do plano que consiste no treinamento
dos envolvidos no método a ser
empregado, a execução propriamente
dita e a coleta de dados para posterior
análise. É importante que o plano seja
rigorosamente seguido.
3ª fase – Check O terceiro passo do PDCA é a análise ou
(Verificação) verificação dos resultados alcançados
e dados coletados. Ela pode ocorrer
concomitantemente com a realização
do plano quando se verifica se o
trabalho está sendo feito da forma
devida, ou após a execução quando são
feitas análises estatísticas dos dados e
verificação dos itens de controle. Nesta
fase podem ser detectados erros ou
falhas.
4ª fase – Act (Agir A última fase do PDCA é a realização das
corretivamente) ações corretivas, ou seja, a correção das
falhas encontradas no passo anterior.
Depois de realizada a investigação
das causas das falhas ou desvios no
processo, deve-se repetir, ou aplicar o
ciclo PDCA novamente.
O PDCA deve ser executado continuamente, ou seja, girar o ciclo PDCA significa obter previsibilidade nos
processos e aumento da competitividade organizacional.
Kaizen
Kaizen significa literalmente “mudança para melhor” e mais do que isso, significa contínuo melhoramento
na vida pessoal, na vida social e na vida profissional. Kaizen é uma forma de buscar muitas, porém pequenas
melhorias, sem muito investimento, atingindo padrões cada vez mais elevados.
Esta prática de gestão surgiu em 1986 no livro Kaizen – A Chave do Sucesso da Competitividade Japonesa
(Kaizen-The Key to Japan’s Competitive Success) de Masaaki Imai. O autor colocou uma série de inovações de
gestão japonesas, até ali olhadas separadamente, debaixo do que ele chama de “guarda chuva” conceitual.
Kaizen é o conceito predominante da boa administração. Ele é o elo que une a filosofia, os sistemas e
as ferramentas para solução de problemas desenvolvidos no Japão nos últimos 40 anos. Seu princípio é o
melhoramento e a tentativa de sempre fazer melhor.
Os dez mandamentos do Kaizen:
1. O desperdício é o inimigo público nº1; para eliminá-lo é preciso sujar as mãos;
2. Melhorias graduais devem ser feitas continuadamente;
3. Todo o pessoal deve estar envolvido, da alta direção até o chão de fábrica;
4. Implantada numa estratégia de baixo custo, acredita num aumento de produtividade sem investimentos
significativos;
5. Aplica-se em qualquer cultura; não serve só para os japoneses;
6. Apoia-se numa “gestão visual”, numa total transparência de procedimentos, processos, valores; torna
os problemas e os desperdícios visíveis aos olhos de todos;
7. Focaliza a atenção no local onde se cria realmente valor (chão de fábrica - ‘gemba’ em japonês);
8. Orienta-se para os processos;
9. Dá prioridade às pessoas, ao “humanware”; acredita que o esforço principal de melhoria deve vir de
uma nova mentalidade e estilo de trabalho das pessoas (orientação pessoal para a qualidade, trabalho
em equipe, cultivo da sabedoria, elevação do moral, autodisciplina, círculos de qualidade e prática de
sugestões individuais ou de grupo);
10. O lema essencial da aprendizagem organizacional é aprender fazendo.
Portanto, Kaizen é a busca incessante, insistente e sem fim de pequenas melhorias que são mais comumente
conhecidas como melhorias contínuas.
5S
O programa 5S é um programa de melhoria comportamental, cuja principal característica é a simplicidade.
Seus conceitos são bastante profundos e podem ser aplicados tanto na vida profissional como na vida pessoal.
Pessoas que praticam este conceito tornam-se gerentes de si mesmas proporcionando uma melhora para a
organização e para o mercado de trabalho.
A denominação “5S” é devido às cinco palavras que orientam o programa e que são iniciadas pela letra “S”,
quando pronunciadas em japonês: Seiri, Seiton, Seiso, Seiketsu e Shitsuke.
Seiri - Senso de utilização e descarte
O primeiro passo para se colocar ordem no ambiente é separar o útil do inútil. O que realmente é utilizado
nas tarefas diárias e aquilo que raramente ou nunca usamos. Essa arrumação começa a dar sentido a filosofia
de uma nova cultura. O que não é necessário pode e deve ser descartado, transferido para outro departamento,
doado, ou simplesmente jogado fora. Ao iniciar este trabalho as pessoas percebem que a maioria dos objetos
ou papeis guardados realmente são sem importância e que estavam simplesmente tumultuando o local de
trabalho ou ocupando espaço que poderia servir para organizar outros materiais mais utilizados.
Seiton - Senso de arrumação e ordenação
Após organizar e separar o útil do inútil é necessário arrumar e ordenar todo o material. Nesta etapa
é importante classificar todos os materiais conforme sua necessidade de uso, aqueles usados com maior
frequência devem ficar sempre mais acessíveis do que os utilizados raramente. É importante que todos os
materiais e objetos sejam identificados, rotulados e etiquetados para que qualquer pessoa que os necessite
possa encontrá-los com facilidade e rapidez.
Seiso - Senso de limpeza
Nada mais importante para a realização de um trabalho do que a limpeza. Um ambiente limpo proporciona
segurança, conforto e torna o ambiente mais agradável tanto para as pessoas que ali trabalham como para as
que circulam pela área. Esta etapa consiste na conscientização dos funcionários a não sujarem o ambiente
e segundo se sujar, limpar. Se cada um contribuir com a limpeza do local de trabalho muitos desperdícios de
tempo e dinheiro serão evitados. “Usou, limpou e guardou”.
Seiketsu - Senso de saúde e higiene (asseio)
Todos devem cuidar da sua aparência e higiene pessoal, pois transmitem a imagem da empresa. Devem-se
eliminar hábitos de comer, beber ou fumar no local de trabalho.
Shitsuke - Senso de autodisciplina
Fase da aceitação e comprometimento das equipes de trabalho. Apesar de ser um programa implantado
para beneficio conjunto, que tanto a empresa como os funcionários terão melhorias, redução de tempo na
execução das tarefas, rapidez, facilidade e maior organização, ainda poderão existir algumas resistências. Por
isso é importante realizar um trabalho forte de conscientização dos benefícios trazidos pelos 5S.
6Sigma
O 6sigma traduz os esforços de melhoria das organizações na meta especifica de reduzir defeitos. Objetiva
atingir em determinados processos o máximo de 3,4 defeitos por milhão de oportunidades (-> podem ser
peças fabricadas, serviços realizados ou qualquer outro produto a ser entregue por um processo). Orienta-se
unicamente pelo entendimento preciso das necessidades dos consumidores; pelo uso disciplinado de fatos;
dados e análise estatística; e pela atenção ao gerenciamento, à melhoria e à reinvenção dos processos de
negócio.
O 6sigma surgiu na Motorola em 1985 quando um engenheiro, Bill Smith, começou a influenciar a organização
para que se estudasse a variação dos processos como uma forma de melhorá-los. Em 1995 o CEO da General
Electric, Jack Welch, inteirou-se do sucesso desta nova estratégia e devido ao seu esforço transformou a GE em
uma “organização 6sigma”, com resultados de grande impacto em todas as suas divisões. Desde então, centenas
de companhias por todo o mundo tem adotado o 6sigma.
O que é o sigma?
O sigma (σ) é uma letra grega que os estatísticos usam para representar o desvio-padrão de uma amostra.
Ou seja, quanto maior a variação dos dados, maior é o desvio-padrão. Um exemplo típico é quando compramos
camisas e elas, apesar da etiqueta indicar o contrário, não são exatamente do mesmo tamanho!
Em uma distribuição normal, o desvio padrão mede a dispersão de valores individuais em torno de um
valor médio. A figura a seguir mostra dois processos que variam em torno de um valor médio. Observe que
quanto maior a variação no processo, mais achatada é a curva.
Fonte: http://www.agroinfoti.com.br/portal/component/content/article/28-current-users/78-normastecnicas
O nível sigma de desempenho também é expresso como “defeitos por milhões de oportunidades” (DPMO).
O DPMO indica quantos erros apareceriam caso uma atividade fosse repetida um milhão de vezes.
A tabela a seguir mostra como nível sigma e o DPMO podem ser relacionados:
Sigma Taxa de acerto Taxa de erro Defeitos por milhão
(aproximadamente)
1 30,9% 69,1% 690.00
2 62,9% 30,9% 308.00
3 93,3% 6,7% 66.800
4 99,4% 0,62% 6.210
5 99,98% 0,023% 320
6 99,9997% 0,00034% 3,4
Assim, em um processo 6Sigma, seriam encontradas 3,4 peças com defeitos a cada 1 milhão de peças
fabricadas, ou seja, o processo tem 99,9997% de probabilidade de produzir peças boas! Por isso quanto mais
elevado for o nível Sigma, melhor será o processo, e menor é a probabilidade de um erro / defeito ocorrer. A
tabela a seguir mostra um comparativo de desempenho entre os processos 4 e 6Sigma.
Medidas 4 Sigma 6 Sigma

Cirurgias erradas em um hospital (em 3,2 por semana 3,4 em 5 meses
500 por semana)
Erros de aterrissagem (em 320 2 por dia 4 por ano
pousos por dia)
Falta de energia elétrica 7 horas por mês 1 hora a cada 20 anos
Outro ponto a considerar são os valores dos desvios-padrão de cada Sigma, conforme mostrado na figura a
seguir. Veja que os percentuais indicam a área coberta pelo Sigma correspondente, ou seja, se seu processo for
3 Sigma, há a probabilidade de 99,7% de um item produzido estar dentro dos limites de conformidade.
É muito importante que os valores de desvio-padrão dos Sigmas sejam memorizados para o exame de
certificação!
O DMAIC
O DMAIC é um ciclo de desenvolvimento de projetos de melhoria originalmente utilizado na estratégia
6Sigma. Ele não é efetivo somente na redução de defeitos, sendo abrangente também para projetos de aumento
de produtividade, redução de custo, melhoria em processos administrativos, entre outras oportunidades.
Cada letra representa sequencialmente uma etapa do processo de evolução de um determinado projeto:
Define (Definir), Measure (Medir), Analyse (Analisar), Improve (Melhorar), Control (Controlar). Por representar
um ciclo organizado e ordenado de trabalho, o DMAIC é constantemente comparado ao ciclo PDCA, também
conhecido como ciclo de Deming (Plan, Do, Check, Act).
Definir
(Define)
Controlar Medir
(Control) (Measure)
Melhorar Analisar
(Improve) (Analyse)
• Definir: um projeto 6 Sigma começa com um problema bem definido. Muitas pessoas são usadas para
definir os problemas em alta escala. Por exemplo, o dono de uma empresa pode dizer que as contas
não pagas de cliente são o problema, mas essa definição não funcionaria no 6 Sigma. Deve-se avaliar o
problema em termos quantitativos. No exemplo citado o problema deve ser definido como: “30% das
faturas não-pagas estão atrasadas há mais de 45 dias”.
• Medir: definir o problema é apenas o começo. A seguir devemos determinar as características que
influenciam o comportamento do processo. Isso é conseguido com medições e coleta de dados.
• Analisar: coletar dados também não é o bastante. É preciso analisá-los usando ferramentas de
matemática e estatística. A análise revela se um problema é real ou se é apenas um evento aleatório. Se
o evento for aleatório, então não existe solução dento da área de trabalho do 6 Sigma.
• Melhorar: uma vez determinado se o problema é real e não um evento aleatório, as equipes do 6
Sigma procuram identificar as possíveis soluções. As soluções devem ser testadas para se saber como
interagem com outras variáveis de entrada. Por fim, a equipe escolhe as melhores soluções para a
implementação.
• Controlar: pode parecer que a aplicação de uma solução finaliza o processo do 6 Sigma, mas não. Para
ter certeza de que uma solução pode ser sustentada em longo prazo, é preciso um planejamento de
controle, que envolve coletar dados de controle de qualidade e verificar medidas regularmente. Isso
assegura que os processos continuem a rodar com eficiência.
Os pontos-chave do 6 Sigma e do DMAIC são:
1. Medir o problema: é sempre necessário ter uma noção clara dos defeitos produzidos em termos de
quantidades e de custos associados;
2. Focar no cliente: as necessidades e requisitos do cliente são fundamentais e devem ser sempre levados
em consideração;
3. Verificar a causa raiz: é essencial chegar à razão fundamental ou raiz, evitando ficar apenas nos sintomas;
4. Romper com os maus hábitos: uma mudança real requer soluções criativas;
5. Gerir os riscos: a comprovação e o aperfeiçoamento das soluções é fundamental para a melhoria;
6. Medir os resultados: o seguimento de qualquer solução é verificar o seu impacto real;
7. Manter a mudança: a chave final é conseguir que a mudança perdure.
Funções e Responsabilidades
Para levar a cabo as atividades do 6sigma são necessários recursos humanos devidamente qualificados,
capazes não apenas de aplicar corretamente a metodologia, mas também de levar a filosofia a todos os níveis
da organização, criando uma visão compartilhada.
As funções e respectivas responsabilidades ligadas à atividade 6sigma são:
• Champion: é o gerente sênior que supervisiona um projeto de melhoria. Ele deve definir as pessoas
que irão disseminar os conhecimentos sobre o 6sigma por toda a empresa e liderar os executivos-chave
da organização. Deve compreender as teorias, os princípios e as práticas do 6sigma, pois cabe a ele
organizar e guiar o começo, o desdobramento e a sua implementação em toda a organização.
• Master black belts: representam o nível mais alto de domínio técnico e organizacional. Estes profissionais
necessitam ter o conhecimento dos black belts e entender a teoria nas quais os métodos estatísticos se
baseiam. Deve ser um expert em qualidade dedicado integralmente ao 6sigma. Ele é o mentor de um
grupo de black belts e atua diretamente na formulação da estratégia de implementação, no treinamento
dos participantes, na seleção, direcionamento e revisão de projetos.
• Black belts: são profissionais treinados para utilizar ferramentas e técnicas para prevenção e resolução
de problemas. Cabem, a eles, certas atividades gerenciais, mesmo desempenhando um papel mais
operacional e fazendo com que a melhoria aconteça. Eles devem liderar vários projetos ao mesmo tempo,
liderar times de trabalho, orientar os green belts, identificar as oportunidades de melhoria e auxiliar no
treinamento dos demais envolvidos com a implementação dos projetos sob sua responsabilidade.
• Green belts: são os profissionais parcialmente envolvidos com as atividades relacionadas com o 6sigma.
Em geral, são pessoas de nível operacional ou de média gerência que recebem treinamento simplificado
sobre as ferramentas e técnicas para prevenção e resolução de problemas. Suas tarefas principais podem
ser resumidas em auxiliar os black belts na coleta de dados, desenvolvimento de experimentos e liderar
pequenos projetos de melhoria em suas áreas de atuação.
QFD – Quality function deployment

O QFD (ou casa da qualidade) é uma técnica que pode ser empregada durante todo o processo de
desenvolvimento de um produto e que tem por objetivo auxiliar o time de desenvolvimento a incorporar no
projeto as reais necessidades dos clientes.
A força do QFD está em tornar explícitas as relações entre necessidades dos clientes, características do
produto e parâmetros do processo produtivo, permitindo a harmonização e priorização das várias decisões
tomadas durante o processo de desenvolvimento do produto, bem como em potencializar o trabalho de equipe.
Outro aspecto importante a considerar é que, por ser uma metodologia que se baseia no trabalho coletivo, os
membros da equipe desenvolvem uma compreensão comum sobre as decisões, suas razões e suas implicações,
e se tornam comprometidos com iniciativas de implementar as decisões que são tomadas coletivamente.
Na prática, o QFD corresponde a várias matrizes onde são feitos o planejamento do produto e que costumam
ser chamadas genericamente de “casa da qualidade”. A partir dos requisitos dos consumidores, que podem
ser captados através de pesquisas, reclamações etc, a equipe de projeto os traduz em requisitos de projeto
que podem ser mensuráveis e, portanto, transformados em características efetivas do produto (conceitos). Por
meio de um conjunto de matrizes parte-se dos requisitos expostos pelos clientes e realiza-se um processo de
“desdobramento” transformando-os em especificações técnicas do produto. As matrizes servem de apoio para
o grupo orientando o trabalho, registrando as discussões, permitindo a avaliação e priorização de requisitos e
características e, ao final, será uma importante fonte de informações para a execução de todo o projeto.
Benefícios da aplicação do QFD:
• Foco no consumidor;
• Considera a concorrência;
• Registro das informações;
• Interpretações convergentes das especificações;
• Redução do tempo de lançamento e reparos após o lançamento;
• Seu formato visual ajuda a dar foco para a discussão do time de projeto, organizando a discussão;
• Aumenta o comprometimento dos membros da equipe com as decisões tomadas;
• Os membros da equipe desenvolvem uma compreensão comum sobre as decisões, suas razões e
implicações.
Veja na figura a seguir como são montadas e relacionadas as matrizes do QFD.

Análise de valor
A análise de valor é um sistema para solucionar problemas através do uso de um conjunto especifico de
técnicas, um corpo de conhecimentos e um grupo de pessoas especializadas. É um enfoque criativo e organizado
que tem como propósito a identificação e remoção de custos desnecessários.
Sua metodologia se aplica muito bem ao novo conceito da qualidade, buscando superar as expectativas
do consumidor a um preço que este deseja pagar. Em outras palavras esta técnica tenta descobrir quanto um
consumidor está disposto a pagar por um determinado produto.
A metodologia da análise de valor identifica a função de um produto ou serviço, estabelece um valor para
aquela função e objetiva prover tal função ao menor custo total, sem degradação.
Valor econômico
Sob o enfoque econômico, o valor pode ser dividido em:
• Valor de custo: representa a soma de custos de mão de obra, matéria prima, despesas gerais e outros
esforços para a fabricação do produto;
• Valor de uso: representado pela utilidade de um bem ou serviço para o uso esperado;
• Valor de estima: representado pelos aspectos que visam dotar um produto de beleza, aparência, status
etc.;
• Valor de troca: é a quantidade de dinheiro que equivale à troca do produto no mercado.
O valor econômico é uma imagem mental, feita por comparação no momento da compra. No caso, o produto
é influenciado pelos valores do consumidor.
A análise de valor identifica o valor mínimo a ser gasto para adquirir ou produzir um produto com uso,
estima e a qualidade requerida.
O valor econômico pode ser representado pela seguinte relação:
As funções de uso e estima

Os valores de uso, estima e troca são obtidos por meio de funções desempenhadas pelo produto, sendo
uma função definida como toda e qualquer atividade que um produto desempenha. Estas funções podem ser
básicas, as quais justificam a existência de um produto no mercado, sendo a tradução de uma necessidade
expressa pelos consumidores.
A função de uso está diretamente relacionada com o valor de uso do produto e envolve atividades que
exprimem o desempenho técnico de utilização. Já a função de estima está diretamente relacionada com o valor
de estima do produto, envolvendo atividades que auxiliam as vendas do produto, dotando-o de beleza, status,
moda etc.
Principais ferramentas da qualidade

Diagrama de Causa e Efeito
É também conhecido como diagrama de Ishikawa ou espinha de peixe. É uma representação gráfica que
permite a organização identificar as possíveis causas de um determinado problema ou efeito.
• Vantagens: A representação visual do projeto promove o pensamento estruturado, ou seja, é uma

forma de organizar ideias. Para pensar de forma estruturada é preciso saber fazer a decomposição de
conceitos ou ideias em partes menores. Uma EAP, um organograma ou um diagrama de Ishikawa são
ótimas ferramentas que podem nos auxiliar a pensar dessa forma.
• Desvantagens: O diagrama pode facilmente se tornar complexo.
• Requisitos: A seleção dos itens que compõem o diagrama deve ser criteriosa para não torná-lo ilegível.
Veja um exemplo desse diagrama na figura a seguir.

Possíveis
causas
RH Custos
Recursos alocados Efeito
incorretamente
Orçamento insuficiente
Estimativa de custo
equivocada
Treinamento deficiente Aumento no valor
do dólar
Projeto atrasado
“Scope creep”
Estimativa de tempo
equivocada
Atraso
Requisitos incorretos
fornecedores
Escopo Tempo
Categorias
Os componentes do diagrama são:

• Efeito: contém o problema que se quer descobrir a possível causa. Usualmente desenhado do lado
direito da folha.
• Eixo central: uma flecha horizontal, apontando para o efeito. Usualmente desenhada no meio da folha.
• Categoria: representa os principais grupos de fatores relacionados com o efeito. A categoria é desenhada
em um retângulo com uma flecha saindo dele e convergindo para o eixo central.
• Causa: causa potencial, dentro de uma categoria que pode contribuir com o efeito. As flechas são
desenhadas em linhas horizontais, apontando para o ramo de categoria.
Fluxograma
O fluxograma é um tipo de diagrama que pode ser entendido como uma representação esquemática de um
processo, muitas vezes feito através de figuras geométricas que ilustram de forma descomplicada a transição de
informações entre os elementos que o compõem. É uma das sete ferramentas da qualidade e é muito utilizado
em fábricas e indústrias para a organização de produtos e processos.
A figura a seguir mostra os elementos básicos para construção de um fluxograma.

Decisão Conec
Início / Fim tor
Processo Subprocesso
Entrada manual
Documento Dados /
Preparação
Informação
Quando pretendemos descrever um processo através de fluxogramas, as formas mais comuns de disposição
são: de forma linear (fluxograma linear) ou de forma matricial (fluxograma funcional ou matricial).
O fluxograma linear é um diagrama que exibe a sequência de trabalho passo a passo que compõe o processo.
Ele ajuda a identificar retrabalhos, redundâncias ou etapas desnecessárias.
Já o fluxograma funcional (ou fluxograma de raias) tem como objetivo mostrar o fluxo de processo atual
e quais as pessoas ou grupo de pessoas envolvidas em cada etapa. Neste caso, linhas verticais ou horizontais
são utilizadas para definir as fronteiras entre as responsabilidades. Ele demonstra onde as pessoas ou grupo de
pessoas se encaixam em cada sequência do processo e como elas se relacionam com outro grupo. Veja na figura
a seguir a diferença entre esses dois tipos.
Fluxograma Funcional Fluxograma Linear
Início Início
Coloca insumo na Coloca insumo na

máquina máquina
Operação
Inicia operação e Inicia operação e

produção produção
Produto dentro N Produto dentro N

Descarta produto Descarta produto
da especificação da especificação
S S
Expedição
Embala produto Embala produto

Transportadora
Envia para cliente Envia para cliente
Fim Fim
• Vantagens: O fluxograma permite visão global do processo por onde passa o produto e, ao mesmo
tempo, ressalta operações críticas ou situações, em que haja cruzamento de vários fluxos. O próprio
ato de elaborar o fluxograma melhora o conhecimento do processo e desenvolve o trabalho em equipe
necessário para aprimorá-lo.
• Desvantagens: Falta de padronização. A maioria das empresas não é padronizada. Quando se encontra
alguma padronização, ela é montada de forma inadequada e as pessoas da empresa não a conhecem.
Uma pessoa sozinha é incapaz de completar o fluxograma, a não ser que tenha ajuda de outros.
• Requisitos: Entrevistar operadores do processo, desenhá-lo e mostrá-lo aos entrevistados para validação.
Folhas de verificação
As folhas (ou listas) de verificação nada mais são que formulários planejados onde se registram os dados
dos itens a serem verificados, permitindo uma rápida interpretação da situação, ajudando a diminuir erros e
confusões.
As folhas de verificação podem ser usadas para distribuição do processo de produção, verificação de itens
defeituosos, localização de defeitos, causas de defeitos etc. A figura a seguir mostra um exemplo de uma folha
de verificação para coleta de dados de defeitos em peças.
• Vantagens: A ferramenta é muito simples e de fácil elaboração.
• Desvantagens: Os dados coletados para este tipo de folha de verificação não podem ser interrompidos.
O processo de coleta pode ser lento e demandar muitos recursos dependendo do tamanho da amostra.
• Requisitos: Descrição detalhada da área que está sendo analisada. Identificar claramente o objetivo
da coleta de dados quais são os defeitos mais importantes. Decidir como coletar os dados. Estipular a
quantidade de dados que serão coletados. Estabelecer um período regular de coleta.
PEÇA: XXXXXX
Lotes Avaliados
Tipo de Defeito Lote 1 Lote 2 Lote 3 Lote 4 Lote 5 Lote 6
Manchada 4 2 1
Quebrada 2 5 5
Riscada 1 7
Diagrama de Pareto
O diagrama de Pareto é uma ferramenta que apresenta um gráfico de barras dispostas em ordem decrescente
de valores e que permite determinar, por exemplo, as prioridades dos problemas a serem resolvidos, através
das frequências de suas ocorrências. Esse diagrama segue o Princípio de Pareto, que afirma que para muitos
fenômenos, 80% das consequências advêm de 20% das causas.
• Vantagens: A análise de Pareto permite a visualização dos diversos elementos de um problema, ajudando
a classificá-los e priorizá-los. Permite a rápida visualização dos 80% mais representativos, por isso facilita
o direcionamento de esforços;
• Desvantagens: Existe uma tendência em se deixar os “20% triviais” em segundo plano. Isso gera a
possibilidade de Qualidade 80% e não 100%; não é uma ferramenta de fácil aplicação, pois pode ser
muito complicado identificar as categorias que fazem parte do diagrama, bem como a coleta de dados
pode ser complicada.
• Requisitos: Problema a ser avaliado deve ser bem identificado. Mais de uma causa deve ser identificada.
A coleta de dados pode utilizar a Folha de Verificação. As frequências de ocorrência devem ser calculadas
e desenhadas.
1. Selecionar um problema que deve ser analisado.
2. Estabelecer um período de tempo para coletar dados (dias, semanas etc.).
3. Reunir os dados dentro de cada categoria .
4. Traçar dois eixos verticais e um horizontal. No eixo vertical da direita, desenhar uma escala de 0% a
100%, e no eixo vertical da esquerda uma escala de 0 até o valor total. No eixo horizontal fazer uma
escala de acordo com o número de itens classificados por categoria.
5. Listar as categorias em ordem decrescente de frequência da esquerda para a direita. Os itens de menos
importância podem ser colocados dentro de uma categoria “outros” que é colocada na última barra à
direita do eixo.
6. Calcular a frequência acumulada para cada categoria.
Histograma
O histograma é uma ferramenta da estatística, também conhecido como Distribuição de Frequências ou
Diagrama das Frequências. Tem como base a medição de dados, tais como, dimensões de peças, variações de
temperatura, entre outros.
Assim, o histograma se utiliza de dados na forma de variáveis e revela quanto de variação existe em qualquer
processo. O histograma típico tem forma de uma curva superposta a um gráfico de barras. Esta curva é chamada
“normal”, sempre que as medidas concentram-se em torno da medida central. Amostras aleatórias de dados
sob controle estatístico seguem este modelo, também chamado de curva do sino.
• Vantagens: É uma ótima ferramenta para verificar a quantidade de produtos não-conforme e determinar
a dispersão de valores ao redor de um valor central.
• Desvantagens: Não é tão simples de ser montado, pois exige conhecimentos básicos de estatística. Exige
também uma coleta de dados superior a 30 medições.
• Requisitos: Realizar coleta de dados (pelo menos mais de 30). Calcular amplitude, classe, frequência de
cada classe, média e desvio padrão.
Histograma de X
Densidade
Gráfico de Controle
O gráfico de controle, ou carta de controle, é um gráfico utilizado para examinar se o processo está ou não
sobre controle. Sintetiza um amplo conjunto de dados, usando métodos estatísticos para observar as mudanças
dentro do processo, baseado em dados de amostragem.
Algumas definições importantes:

• Limites de controle (superior e inferior): estes limites indicam as tolerâncias máxima e mínima
aceitáveis de variação de um processo para que este seja considerado sob controle. São determinados
de acordo com a política de qualidade adotada pela organização (3 sigmas, 6 sigmas etc). A ocorrência
de variação fora destes limites indica em geral que causas especiais estão afetando o processo e, dessa
forma, ele deve estar fora de controle.
• Limite central: é geralmente exibida nos diagramas de controle como uma linha sólida horizontal
equidistante dos limites de controle, indicando a tendência central de variação dos resultados em
relação à tolerância estabelecida para o processo.
• Causas especiais: são fontes aleatórias de variabilidade no processo. Geralmente são identificáveis
com facilidade, e podem ser rastreadas até a sua origem. As principais origens podem ser atribuídas a
fatores relacionados a tempo, máquina, método, material, energia, medição, pessoas e ambiente.
• Causas aleatórias: são fontes naturais de variabilidade no processo, sendo consideradas normais e
inerentes a ele. Podem ocorrer em grande número e diversificação, sendo geralmente difíceis de serem
identificados. As principais origens são equipamento inadequado ou obsoleto, métodos inadequados
ou errados, ambiente de trabalho impróprio (iluminação, temperatura) etc.
• Regra dos sete: determina que, caso existam sete pontos de amostragem agrupados sequencialmente
de um mesmo lado (superior ou inferior ao limite central), mesmo que nenhum deles esteja fora dos
limites de controle, o processo pode estar fora de controle.
• Fora de controle: o conceito de processo fora ou sob controle está relacionado à sua estabilidade.
Quando o processo só está sujeito à causas aleatórias, temos um processo estável, ou seja, a sua saída
não variará além de parâmetros pré-definidos. Se houver causas especiais, o processo é considerado
instável ou fora de controle, tendo em vista não ser possível determinar quando a próxima causa
especial poderá se manifestar e, portanto, não podemos prever a amplitude da sua variabilidade.
Os limites de controle de um processo são os balizadores que informam se ele está sobre controle ou não.
Eles são escolhidos de forma que, se o processo está sobre controle estatístico, quase todos os pontos coletados
terão seus valores entre o limite de controle superior (LCS) e o limite de controle inferior (LCI). Enquanto os
pontos apresentarem esse comportamento, o processo será considerado sob controle, dispensando qualquer
ação corretiva. Se os pontos começarem a sair desses limites, será uma evidência de que o processo está saindo
de controle, sendo necessário um estudo das causas dessa variação e, provavelmente, ações corretivas terão
de ser tomadas.
• Vantagens: É uma ferramenta muito utilizada em linhas de produção, pois permite acompanhar a
variabilidade presente em processos produtivos. Mostra tendência ao longo do tempo.
• Desvantagens: Exige conhecimentos estatísticos, tais como cálculos de médias, desvio padrão, variância
etc. Tem que ser constantemente atualizado conforme o período escolhido (diário, semanal, mensal),
caso contrário perde o sentido.
• Requisitos: Primeiramente, faz-se um experimento para determinação dos parâmetros de controle,

medindo-se a propriedade que se quer controlar em uma amostra com pelo menos 7 pontos. Determina-
se a partir de então os valores de média e desvio padrão. Em seguida, os valores são colocados no
gráfico e uma linha cheia, que representa a linha média é desenhada por toda a extensão do gráfico.
Embora sejam usados mais frequentemente para rastrear as atividades repetitivas necessárias para produzir
lotes manufaturados, os gráficos de controle também podem ser usados para monitorar variações de custos,
prazos, volume e frequência de mudanças no escopo ou outros resultados de gerenciamento e assim ajudar a
determinar se os processos de gerenciamento do projeto estão sobre controle.
Quando um processo está sob controle ele não deve ser ajustado. Não há problemas em alterar o
processo para trazer melhorias, mas ele não deve ser ajustado.
Processos fora de controle
Abaixo mostramos alguns exemplos de processos fora de controle, bem como os critérios que indicam
porque estão assim:
• Causa especial: 1 ponto mais do que 3 desvios padrão a partir da linha central, ou seja, um ponto fora
do limite superior de controle (LSC) ou limite inferior de controle (LIC).
Fonte: http://www.portalaction.com.br
• Regra dos 7: 7 pontos consecutivos no mesmo lado da linha central.
• Regra dos 7: 14 pontos consecutivos, alternando acima e abaixo da linha central;
• Causa especial: 2 de 3 pontos consecutivos maior que 2 desvios padrão a partir da linha central (mesmo
lado);
Diagrama de Dispersão
Os diagramas de dispersão são representações de duas ou mais variáveis que são organizadas em um
gráfico, uma em função da outra. Este tipo de diagrama é muito utilizado para correlacionar dados de variáveis
dependentes com independentes.
A variável dependente é aquela que o investigador pretende avaliar, e depende da variável independente.
Já a variável independente é aquela que integra um conjunto de fatores/condições experimentais, que são
manipuladas e modificadas pelo investigador. No curso de uma experiência, o investigador apenas faz variar
uma variável independente, para poder verificar de que modo essa variável afeta a variável dependente.
• Vantagens: É uma ferramenta que permite inferir uma relação causal entre variáveis, ajudando na
determinação da causa raiz de problemas. Se a correlação puder ser estabelecida, uma linha de regressão
pode ser calculada e usada para estimar como uma mudança na variável independente influenciará o
valor da variável dependente. Ideal quando há interesse em visualizar a intensidade do relacionamento
entre duas variáveis.
• Desvantagens: É um método estatístico complexo. Não há garantia de causa-efeito. As comparações

(correlações) devem ser feitas por pares. Pode ser difícil identificar qual é a variável dependente e qual
é a variável independente.
• Requisitos: Identificar as variáveis dependente e independente. Realizar medições e plotar no gráfico.
A figura a seguir mostra três gráficos com correlações diferentes entre si. No gráfico à esquerda temos
uma fraca correlação entre duas variáveis (uma dependente e outra independente), ou seja, quando a variável
independente muda, a variável dependente é pouco afetada, o que nos leva a crer que possivelmente essa
variável é também independente (pois não é afetada).
Já o gráfico à direita mostra uma correlação perfeita, ou seja, quando a variável independente muda, a
variável dependente também muda na mesma intensidade, levando-se a concluir que a variável é realmente
dependente (pois é totalmente afetada).
Projeto de experimentos
O projeto de experimentos (em inglês Design of Experiments, DOE) é uma técnica utilizada para se planejar
experimentos, ou seja, para definir quais dados, em que quantidade e em que condições devem ser coletados
durante um determinado experimento, buscando, basicamente, satisfazer dois grandes objetivos: a maior
precisão estatística possível na resposta e o menor custo.
A sua aplicação no desenvolvimento de novos produtos é muito importante, onde uma maior qualidade dos
resultados dos testes pode levar a um projeto com desempenho superior seja em termos de suas características
funcionais seja em robustez. Os projetos de experimentos também podem ser usados tanto no desenvolvimento
de processos quanto na solução de problemas desses processos.
Etapas para o desenvolvimento de um projeto de experimentos
1. Caracterização do problema;
2. Escolha dos fatores de influência (variáveis de controle / entradas) e níveis (faixas de valores das
variáveis de controle);
3. Seleção das variáveis de resposta;
4. Determinação de um modelo de planejamento de experimento;
5. Condução do experimento;
6. Análise dos dados;
7. Conclusões e recomendações.
Planejar o gerenciamento da qualidade (8.1)
O planejamento da qualidade envolve identificar quais padrões de qualidade são relevantes para o projeto
e determinar como satisfazê-los. Ele é um dos processos-chave facilitadores durante o planejamento do projeto
e deve ser executado regular e paralelamente a outros processos do planejamento do projeto. Por exemplo,
mudanças no produto do projeto, necessárias para atender os padrões de qualidade identificados, podem exigir
ajustes no prazo ou no custo ou, ainda, a qualidade desejada do produto pode exigir uma análise detalhada do
risco de um problema identificado.
O principal benefício desse processo é o fornecimento de orientação e instruções sobre como a

qualidade será gerenciada e validada ao longo de todo o projeto.
O processo
Este processo contém os seguintes componentes:
Entradas
O termo de abertura do projeto contém a definição em alto do nível do produto do projeto, bem como dos
requisitos de aprovação e critérios de sucesso.

Dentre as informações constantes nesse plano temos:
• Plano de gerenciamento dos requisitos: Deste plano são extraídas informações referentes às métricas
de qualidade que serão utilizadas no projeto.
• Plano de gerenciamento dos riscos: Riscos devem ser considerados em todos os processos e fases do
projeto, dessa forma, esse plano deve ser consultado aqui também.
• Plano de engajamento das partes interessadas: Este plano fornece informações sobre as expectativas
das partes interessadas, e essas expectativas podem conter informações sobre os níveis de qualidade a
serem aplicados ao projeto.
• Linha de base do escopo: A especificação do escopo além de conter o que precisa ser entregue,
também contém os critérios de aceitação dos produtos produzidos. E veja que o cumprimento de todos
os critérios de aceitação implica que as necessidades das partes interessadas foram atendidas.
• Registro de premissas: este documento contém todas as premissas do projeto, e essas premissas podem
envolver padrões e fatores de qualidade que precisam ser alcançados.
• Documentação dos requisitos: a documentação dos requisitos contém as funcionalidades desejadas

pelas principais partes interessadas. Os componentes dessa documentação incluem, mas não estão
limitados aos requisitos do projeto (incluindo os do produto) e de qualidade. Os requisitos são usados
pela equipe do projeto para planejar como o controle da qualidade será implementada no projeto.
• Matriz de rastreabilidade de requisitos: essa matriz vincula os requisitos com as entregas, além de
fornecer uma visão geral dos testes requeridos de cada requisito.
• Registro dos riscos: o registro dos riscos contém informações sobre as ameaças e oportunidades que
podem afetar os requisitos de qualidade.
• Registro das partes interessadas: o registro das partes interessadas ajuda a identificar as partes
interessadas que têm um interesse específico, ou que podem gerar um impacto na qualidade do projeto.

Entre os fatores ambientais que podem afetar este processo, podemos citar: regulamentações
governamentais, normas e padrões de qualidade e percepções culturais que influenciam as expectativas de
qualidade, estrutura organizacional etc.

Entre os ativos que podem influenciar este processo, temos: políticas organizacionais com relação à padrões
de qualidade, bancos de dados históricos e lições aprendidas.
Especialistas podem ajudar (e muito) em atividades relacionadas à qualidade, tais como: Garantia e controle
da qualidade, medições, melhorias da qualidade etc.
Coleta de dados
Benchmarking
O benchmarking é um método utilizado pelas empresas para melhorar a sua gestão, mediante a realização
contínua e sistemática de levantamentos, comparações e análises de processos, produtos e serviços prestados
por outras empresas, normalmente reconhecidas como representantes das melhores práticas.
O benchmarking gera informações importantes para que as empresas conheçam diferentes maneiras de
lidar com situações e problemas semelhantes e, desta forma, contribui para que possam aperfeiçoar os seus
próprios processos de trabalho e determinar as suas “melhores” práticas.
Brainstorming
Conforme já vimos, esta é uma técnica usada em reuniões onde uma ideia pode ajudar a gerar outras ideias
sobre o mesmo tema. Nenhuma das ideias propostas deve ser descartada ou julgada como errada/absurda.
Entrevistas
Consiste em entrevistar os participantes do projeto e especialistas na área em que o projeto irá ser
desenvolvido.
Análise de dados
Análise de custo benefício
Análise Custo Benefício (ACB) estuda a relação entre os custos e os benefícios da aplicação de padrões de
qualidade, expressos em termos monetários. A ACB encontra, identifica e soma todos os aspectos positivos –
benefícios. Depois identifica, quantifica e subtrai todos os negativos - os custos.
Embora os benefícios do cumprimento dos requisitos de qualidade sejam menos retrabalho, maior
produtividade, aumento da lucratividade entre outros, deve-se considerar que se o custo da implementação
desses requisitos for muito maior que o benefício é bem provável que o padrão de qualidade exigido não seja
implementado.
Além disso, muitas vezes o aumento da qualidade se deve à adição de funcionalidades extras ou gold plating
não solicitado pelo cliente o que é uma prática condenada no gerenciamento de projetos.
Custo da qualidade
Já vimos anteriormente que o custo da qualidade está ligado aos produtos com defeitos, incluídos todos os
custos de prevenção, detecção, reparo e correção das causas dos defeitos.
Esses custos são divididos nas seguintes categorias:
• Custos de Prevenção: são os custos de todas as atividades destinadas especificamente a prevenir a

qualidade pobre. É um custo preventivo.
• Custos de avaliação: são os custos associados com a medição, avaliação ou auditoria de produtos ou
serviços de modo a garantir conformidade com padrões de qualidade e requisitos de desempenho.
• Custos de falha: são os custos associados com a falha em atingir os requisitos. Inclui os custos de falha
internos e externos (detectadas pelo cliente). É um custo reativo.
Tomada de decisão
O Guia PMBOK® sugere a técnica análise de decisão envolvedo múltiplos critérios que utiliza uma matriz de
decisão que permite classificar alternativas a partir da avaliação de critérios e pesos. Dessa forma, esta técnica
auxilia na priorização de métricas de qualidade.
Fluxograma
O fluxograma é um tipo de diagrama que pode ser entendido como uma representação esquemática de um
processo, muitas vezes feito através de figuras geométricas que ilustram de forma descomplicada a transição de
informações entre os elementos que o compõem. É uma das sete ferramentas da qualidade e é muito utilizado
Modelo lógico de dados
Um modelo lógico de dados é uma representação lógica das informações da área de negócios, ou seja, não
é um banco de dados. Este é o conceito chave da modelagem de dados lógica. Ele deve ser independente da
tecnologia implementada devido a constante mudança dos produtos tecnológicos.
Quando surge uma nova tecnologia o responsável pelo modelo de dados lógico não necessita questionar os
profissionais da área de negócios de novo, pois as regras de negócios continuam sendo as mesmas, ele precisa
apenas revisar o modelo lógico, entender os requisitos de negócios e oferecer sugestões para a implementação
de mudanças perante a nova tecnologia ou sugerir “Como” a nova tecnologia poderia mudar a maneira dos
requisitos de negócios serem feitos. Desta forma, desenvolver e fazer manutenção utilizando modelo de dados
lógico permite prover um serviço diferenciado para a área de negócios com maior rapidez e menor custo.
O modelo de dados lógico é o retrato de todas as informações necessárias para a realização dos negócios.
Ele é representado de diversas maneiras diferentes, utilizando metodologias e ferramentas diferentes para
implementações diferenciadas.
O modelo entidade-relacionamento (MER) é uma técnica de modelagem amplamente utilizada pelos

administradores de dados. O diagrama entidade-relacionamento é um desenho estruturado utilizado como uma
ferramenta de comunicação entre os profissionais de negócios e os desenvolvedores de sistemas de aplicação.
Ele representa a diagramação dos dados necessários para as regras de negócios. Os componentes do MER são
representados pelas entidades, os relacionamentos e os atributos. Cada entidade representa um conjunto de
pessoas, coisas ou conceitos sobre os quais o negócio precisa de informações. Cada relacionamento representa
a associação entre duas entidades. Cada atributo é a característica ou parte da informação de uma entidade. Um
nome e uma definição textual descreve cada um desses componentes. Estes nomes e definições provêem da
documentação das regras de negócio e informações as quais são armazenadas e mantidas num repositório de
dados garantindo assim a padronização conceitual dos dados. O MER utiliza a simbologia do IDEF1x (Integration
Definition for Information Modeling) e IE (Information Engineering).
Diagramas Matriciais
Em nossas atividades rotineira, de Gestão ou de Execução, frequentemente temos que estabelecer vínculos
entre diferentes informações, o que, em princípio, soa fácil. E realmente é, porém as dificuldades começam
quando cada atributo se correlaciona não com um, mas com diversos outros atributos, e quando trabalhamos
com diferentes grupos de atributos ou informações.
E para nos auxiliar a construir, qualificar e visualizar estas inter-relações entre informações, é que foi criado
o conceito do Diagrama Matricial. Este diagrama pode ser construído em diversos formatos.
Diagrama Matricial em L
Este é o tipo mais elementar de Diagrama Matricial. Usualmente construído na forma de um L invertido,
correlacionando linhas e colunas, como se vê no exemplo abaixo, relativo à oferta de algum tipo de serviço pela
Internet.
Fonte: https://blogtek.com.br/diagrama-matricial-uma-das-sete-ferramentas-de-gerenciamento/
Diagrama Matricial em T
Este Diagrama Matricial é útil para correlacionar três grupos de informação (A, B e C), onde A se relaciona
com B e C, porém B e C não se inter-relacionam. Vejamos um exemplo, onde correlacionamos os empregados
de um setor aos treinamentos que fizeram, e os resultados obtidos em termos de desempenho:
Neste exemplo (hipotético), o gestor pode inferir que o curso de Relacionamento Interpessoal teve efeito
geralmente positivo nas vendas, enquanto que o curso de Gestão da Qualidade aparentemente não impactou
significativamente os resultados de vendas.
Diagrama Matricial em Y
Este Diagrama Matricial é útil para correlacionar três grupos de informação (A, B e C), os quais se inter-
relacionam. Este gráfico é pouco utilizado, mais pela dificuldade de construí-lo em uma planilha Excel.
Vemos a seguir um exemplo que inter-relaciona as métricas internas, os insumos do processo e os requisitos
do cliente.
O Diagrama Matricial em Y poderia ser também construído como C (C de Cubo), onde se correlacionam
os três grupos de atributo segundo as arestas de um cubo, mas isto não resolve o problema da dificuldade
construtiva.
Diagrama Matricial em X ou em Cruz
Este Diagrama Matricial consiste em quatro matrizes em L, conjugadas de forma a se perceber as inter-
relações entre quatro grupos de variáveis, como se vê a seguir.
No diagrama acima, pode-se perceber quais produtos cada localidade mais produz, quais produtos cada
cliente compra em maior quantidade, quais transportadoras mais utilizadas pelos clientes para receber suas
mercadorias, e quais transportadoras mais utilizadas por cada fábrica para receber matéria-prima.
Mapeamento mental
Já vimos em detalhes esta ferramenta. De forma resumida ela utiliza diagramas e figuras para organizar
informações visualmente.
Planejamento de testes e inspeções

Os produtos gerados pelo projeto devem passar por testes e inspeções e tais atividades devem ser planejadas
para que possam cumprir as metas de desempenho e confiabilidade do produto.
Reuniões
Durante o planejamento do projeto inúmeras reuniões serão realizadas, já que um bom plano de projeto
é aquele elaborado de forma colaborativa pelos integrantes da equipe de gerenciamento. É importante
estabelecer uma agenda prévia, e ao final da reunião uma lista de pendências e uma lista de ações (to-do list) a
serem executadas a partir do acordado.
Saídas
Plano de gerenciamento da qualidade
O plano de gerenciamento da qualidade é um componente do plano de gerenciamento do projeto. Nele são
descritas as políticas de qualidade de uma organização e como elas serão implementadas. Esse plano também
descreve como a equipe de gerenciamento do projeto planeja cumprir os requisitos de qualidade estabelecidos
para o projeto.
Métricas da qualidade
Uma métrica da qualidade descreve um atributo de projeto ou produto e como o processo de controle da
qualidade o medirá. A medição é um valor real. A tolerância define as variações aceitáveis na métrica.
Por exemplo, se o objetivo é ficar dentro do orçamento aprovado em ± 10%, a métrica de qualidade é usada
para medir o custo de cada entrega e determinar a variação percentual do orçamento aprovado para tal entrega.
As métricas da qualidade são usadas nos processos de garantia e de controle da qualidade. Alguns exemplos
de métricas incluem desempenho dentro do prazo, controle dos custos, frequência de defeitos, taxa de falhas,
disponibilidade, confiabilidade e cobertura de testes.

Os planos que podem sofrer atualizações, após passarem pelo controle integrado de mudanças são o
plano de gerenciamento dos riscos, pois a abordagem de qualidade escolhida pode acrescentar ou eliminar
riscos do projeto e a linha de base do escopo, já que novas atividades relacionadas à qualidade podem ter sido
acrescentadas.

Este processo pode gerar atualizações dos documentos do projeto, pois como o projeto está sempre
evoluindo, outros documentos já elaborados poderão passar por atualizações. Os documentos que podem
passar por atualizações são: registro das lições aprendidas, matriz de rastreabilidade de requisitos, registro dos
riscos e registro das partes interessadas.
Planejando os Recursos
Projetos dependem de pessoas motivadas e comprometidas para garantir o seu sucesso. Seu desempenho
também depende diretamente da disponibilidade de pessoas com conhecimento e habilidades necessárias para
o desenvolvimento de suas atividades. Além disso, o projeto deve ter definições claras das responsabilidades
de cada um.
E é claro que um projeto não depende só de pessoas, outros recursos também são necessários para que
projeto consiga entregar o que se propõem a fazer.
O gerenciamento dos recursos tem como objetivo principal possibilitar a utilização mais efetiva das pessoas
e recursos materiais envolvidos no projeto.
O gerenciamento dos recursos é afetado por outras áreas de conhecimento uma vez que:
• À medida que o escopo e a estrutura analítica do projeto (EAP) são detalhados, pode-se descobrir que
serão necessários mais recursos do que os já previstos.
• Membros novos adicionados com o projeto já em andamento podem gerar novos riscos.
• Como normalmente o cronograma é elaborado antes de se identificar todos os recursos necessários,

existe a possibilidade dele precisar ser alterado por conta de recursos indisponíveis.
• Requisitos podem exigir novos materiais não anteriormente previstos.
Dentro do grupo de processos de Planejamento o Guia PMBOK® recomenda o seguinte processo para a criação
do plano de gerenciamento dos recursos humanos:
• Planejar o gerenciamento dos recursos (9.1)
• Estimar os recursos (9.2)
com sucesso.
Papéis e responsabilidades em um projeto

Quando se aborda o tema papéis e responsabilidades devemos ter em mente que ele é composto por
quatro elementos muito importantes:
• Papel: é a função exercida por uma pessoa no projeto. Exemplos: analistas de sistemas, designer
instrucionais etc.
• Autoridade: é o direito de aplicar recursos no projeto, tomar decisões, assinar aprovações, aceitar
entregas e influenciar outras pessoas. A autoridade pode variar muito de acordo com a estrutura
organizacional da empresa. Em empresas projetizadas, o gerente tem muita autoridade, já em estruturas
funcionais, não.
• Responsabilidade: são as obrigações e o trabalho que se espera de um membro da equipe para concluir
as atividades do projeto. É importante haver um balanceamento entre autoridade e responsabilidade,
pois é comum um recurso ser responsável por uma atividade, mas não ter autoridade para concluí-la,
pois depende de outras pessoas para isso.
• Competência: é a habilidade e a capacidade necessárias para concluir as atividades designadas. Aqui
também a responsabilidade e a competência precisam ser balanceadas, pois se um recurso não tem a
competência necessária para concluir uma atividade, ele não deve ser responsável por ela.
Conceitos essenciais para um bom gerenciamento de equipe

Existe um conjunto de fatores críticos ou indicadores-chave de sucesso para uma gestão eficaz e bem
sucedida dos recursos humanos em um projeto :
• Liderança democrática e participativa: em um projeto em que o seu gerente tem uma atitude
democrática, a tomada de decisões e a definição de objetivos são partilhados e conhecidos por todos
os membros da equipe. Este tipo de liderança permite criar um ambiente mais cooperativo, inclusivo
e mais centrado nas pessoas. A comunicação, o consenso e o trabalho em equipe são considerados
fatores-chave na gestão do sucesso de um projeto.
• Gestão descentralizada: em vez de estilos de gestão rígidos “de cima para baixo”, as organizações
e os gestores de projeto são encorajados a adotar políticas que asseguram o comprometimento do
trabalhador, o entusiasmo coletivo, o compartilhamento de valores e da missão da organização, a
orientação para os objetivos do projeto, a partilha de responsabilidades e o enfoque nas pessoas.
• Reconhecimento e estima: Herzberg e Maslow já falavam há mais de 50 anos da importância dos
fatores motivacionais na empresa, das necessidades de estima e de realização pessoal. A lealdade e o
empenho dos colaboradores de uma empresa dependem muito mais dos fatores motivacionais (como
a estima, o reconhecimento e a valorização pessoal e profissional) do que dos incentivos salariais.
• Engajamento: o engajamento reflete o envolvimento e a intensidade do compromisso que os
trabalhadores assumem para com a gestão e para com a organização. O engajamento dos colaboradores
de uma empresa está diretamente relacionado com o nível de desempenho e os resultados apresentados,
e é por isso que deve ser um fator trabalhado e estimulado pelo gerente do projeto.
• Inteligência emocional: o gerente do projeto deve investir em inteligência emocional, pois com o
crescimento das equipe auto-gerenciáveis, o gerente do projeto deve estar preparado para mudar a
sua forma de atuação, sendo mais um líder servidor do que um comandante de time.
• Equipe auto-organizáveis: muitas vezes também chamadas de auto-gerenciáveis, são as típicas equipes
de projetos ágeis e que não necessitam de uma pessoa comandando todas as atividades a serem
realizadas. Neste tipo de equipe o gerente do projeto se torna um líder servidor e delega as funções de
controle do time para o próprio time.
• Equipes virtuais: esta configuração tem se tornado cada vez mais comum. Equipes são distribuídas pelo
mundo e o seu gerenciamento requer novas habilidades do gerente do projeto. O uso de tecnologias de
comunicação passa a ser ponto crucial para que o andamento do projeto corra sem grandes dificuldades.
Calendário dos recursos

Recursos não são infinitos tampouco estão disponíveis 24 horas por dia durante todo o projeto. Por isso
é muito importante que seja definido o calendário de uso de cada recurso, para que se tenha uma previsão
de quando cada um estará disponível. O Guia PMBOK® sugere a utilização do histograma de recursos, uma
ferramenta disponível em vários softwares de gerenciamento de projeto. O histograma pode mostrar a
quantidade de horas alocadas por recurso, por função, por equipe ou até mesmo por departamento. Esse
gráfico também pode mostrar se um recurso está “super-alocado”, ou seja, se ele tem mais horas de trabalho
do que realmente dispõem ou até mesmo se foi alocado em duas ou mais tarefas simultâneas. Para evitar esse
conflito de cronograma utiliza-se a ferramenta nivelamento de recursos, que é uma técnica de otimização de
recursos já vista nos capítulos referentes ao planejamento do cronograma.
No exemplo da figura a seguir mostramos um histograma de recursos indicando a quantidade de horas
alocadas para cada membro da equipe do projeto. Observe a existência de uma linha vermelha. Essa linha
representa a quantidade de horas excedentes dos recursos.
Planejar o gerenciamento dos recursos (9.1)
Este processo é responsável por determinar e identificar uma abordagem para garantir que recursos
suficientes estejam disponíveis para a boa conclusão do projeto. Esses recursos podem ser: membros da equipe,
suprimentos, materiais, equipamentos, serviços e instalações.
Os recursos do projeto podem ser internos e externos, e estes últimos chegam ao projeto por meio do
processo de aquisição. Uma ponto importante a ser destacado é que quase nunca temos todos os recursos
necessários disponíveis, ou seja, dentro de uma empresa, sempre existe uma competição por recursos e isso
pode afetar de forma significativa os custos, cronogramas, riscos, qualidade etc.
O processo
Entradas
O termo de abertura do projeto contém os marcos do projeto, partes interessadas e recursos previamente
aprovados que podem afetar o desenvolvimento deste processo.

Deste plano iremos extrair informações tais como:
• Plano de gerenciamento da qualidade: este plano fornece informações sobre o nível de recursos que
serão necessários para se alcançar a qualidade esperada.
• Linha de base do escopo: A linha de base indica as entregas que serão feitas, e a partir daí pode se
avaliar os recursos necessários para o cumprimento dessas entregas.
• Cronograma do projeto: o cronograma indica quando determinados recursos serão necessários.
• Documentação dos requisitos: Esta é uma lista dos tipos e quantidades de recursos necessários para
a execução de cada atividade prevista em um pacote de trabalho. Esta informação é importante neste
ponto, pois é durante o planejamento dos recursos que começamos a delinear a equipe necessária para
a execução do projeto.
• Registro dos riscos: determinadas ameaças e/ou oportunidades podem afetar a alocação tanto de
recursos materiais como humanos.
• Registro das partes interessadas: algumas partes interessadas podem exigir que determinados recursos
participem do projeto, mesmo não tendo habilidades para tal e o contrário também, exigir que recursos
sejam afastados do projeto.

Existem inúmeros fatores ambientais que podem afetar o projeto. No caso especifico de recursos humanos,
esses fatores são muito importantes na determinação dos papeis e responsabilidades, relações de subordinação
e habilidades técnicas necessárias para a conclusão do trabalho. Entre os vários fatores citamos: cultura
organizacional e estrutura, distribuição geográfica, competências e disponibilidades e condições de mercado.

O Guia PMBOK® cita alguns exemplos de ativos de processos organizacionais. Tenha em mente que todo
tipo de documentação ou base de conhecimento da empresa ligado ao gerenciamento de pessoas faz parte
desse grupo. Assim, podemos citar os manuais de procedimentos e processos de RH, as listas de descrições de
cargos, os modelos de organogramas, a base de conhecimento com lições aprendidas em projetos anteriores
entre outros.
Como já vimos em diversos outros processos, os especialistas devem ser consultados sempre. Especificamente
para este processo a opinião especializada pode ajudar em determinar os melhores recursos e na falta destes, os
seus possíveis substitutos. Quais riscos podem acontecer caso os recursos necessários não estejam disponíveis.
Os papéis necessários para o projeto e quais as habilidades necessárias para a execução das atividades.
Existem diversas formas de se representar os papeis, as responsabilidades e a hierarquia dentro de uma
equipe. O Guia PMBOK® cita três categorias: gráficos de hierarquia, gráficos matriciais e formatos orientados
a texto.
Gráficos de hierarquia
A forma mais usual de um gráfico de hierarquia é o organograma, encontrado em praticamente todas as

empresas do mundo. No entanto, como o Guia PMBOK® cita mais alguns tipos de gráficos de hierarquia é
importante que você os conheça também.
Organograma
Este tipo de gráfico mostra as relações de hierarquias dentro da empresa/projeto, isto é, mostra a cadeia de
comando (quem é chefe de quem). Veja nas figuras a seguir um exemplo.
Estrutura analítica de recursos do projeto
Este tipo de gráfico decompõe o trabalho do projeto de acordo com os tipos de recursos necessários. Observe
que aqui não há necessariamente uma relação de hierarquia, pois os recursos podem ser subordinados a um
gerente funcional e estarem participando como recursos do projeto. Cada nível descendente representa uma
descrição cada vez mais detalhada do recurso até que seja suficientemente detalhado para o uso em conjunto
com a estrutura analítica do projeto (EAP), permitindo assim o planejamento, monitoramento e controle do
projeto. Vale lembrar que recursos podem ser humanos ou materiais. Veja nas figuras a seguir um exemplo.
Estrutura Analítica Organizacional
Já este tipo de gráfico mostra a relação entre o trabalho e as unidades organizacionais. O trabalho é
decomposto por departamentos ou funções e não por indivíduos.
Projeto XXX
Desenvolvimento Banco de
Hardware
Portal dados
Web
Designer Programador
Programador Administrador
Diretor presidente
Diretor Financeiro Diretor Técnico
Gerente de
sistemas
Coordenador Coordenador
de sistemas Web Team
Analista de Arquiteto de Web

sistemas soluções Designer
Programador Programador
Programador
Gráficos matriciais
Uma matriz de responsabilidades é um gráfico matricial que mostra os recursos do projeto alocados para
cada um dos pacotes de trabalho. Assim, gráficos matriciais nada mais são que tabelas que indicam quem é
responsável pelo quê. Ou seja, a tabela deve mostrar todas as atividades/pacotes de trabalho associados a uma
pessoa e todas as pessoas associadas a uma atividade/pacote de trabalho. Essa é uma forma bem simples de
garantir que apenas uma pessoa seja responsável por uma atividade especifica, evitando a típica confusão: “Ué?
Achei que você fosse o responsável por isso”.
O modelo mais usual é a chamada matriz RACI:

Web Designer
Especialista TI
Programador
Patrocinador
Membro GP
Coord. Web
Comprador
Atividade
Consultor
Gerente
Projeto
1.1.1 Avaliar aplicações Web A R C C I

1.2.1 Avaliar Tecnologias I A R C C I
2.1.1 Especificar requisitos de I A R I
hardware
2.1.2 Cotar Servidores A R C/I
2.1.3 Comprar servidores A A R C/I
2.2.1 Instalar servidores A R
2.2.2 Testar equipamentos A R
Onde:
• R: Responsável – é a pessoa que irá executar a atividade. Deve existir apenas um responsável por
atividade;
• A: Aprovador – é a pessoa ou grupo de pessoas que devem aprovar o resultado de uma atividade;
• C: Consultado – é a pessoa ou grupo de pessoas que pode ser consultada e participar da decisão ou
atividade;
• I: Informado – é a pessoa ou grupo de pessoas que deve receber a informação de que uma atividade foi
executada.
Observe que apenas deve existir um responsável por atividade, para evitar conflitos de execução.
Formatos orientados a texto
Quando são necessárias descrições detalhadas das atividades dos membros do projeto podem ser adotados
documentos do tipo descrições de cargos como mostrado a seguir:
Descrição de Cargo - Programador
Missão do Cargo
Elaborar e testar programas de computador, estabelecendo os processos operacionais

necessários para o tratamento dos dados, baseando-se nas definições fornecidas na fase de análise
de sistemas e valendo-se de métodos e técnicas adequadas aos equipamentos e aplicações a que
se destinam.
Responsabilidades
Realizar a codificação dos programas de computador, estudando os objetivos propostos,

analisando as características dos dados de entrada e o processamento necessário a obtenção dos
dados de saída desejados.
Executar a compilação de linguagens de programação, visando conferir e acertar sintaxe do

programa.
Realizar testes em condições operacionais simuladas, visando verificar se o programa executa

corretamente dentro do especificado e com a performance adequada.
Modificar programas, alterando o processamento, a codificação e demais elementos, visando

corrigir falhas e/ou atender alterações de sistemas e necessidades novas.
Aperfeiçoar conhecimentos técnicos, através de pesquisas, estudo de manuais e participação

em cursos, visando a otimização da utilização dos recursos disponíveis na empresa.
Realizar simulações e criar ambientes de produção a fim de aferir os resultados dos programas.
Criar documentações complementares, como “helps”, instruções de operação ou de acertos de

consistência.
Teoria organizacional
A indicação desta ferramenta no Guia PMBOK® pode parecer “nebulosa” para os incautos. No fundo ela se
refere ao estudo de como as organizações funcionam e como elas afetam e são afetadas pelo ambiente no qual
operam. São consideradas três importantes variáveis nesse estudo:
• Estrutura organizacional é o sistema formal de tarefas e relacionamentos de autoridade que controla

como as pessoas coordenam suas ações e usam os recursos para atingir os objetivos organizacionais;
controla também a coordenação e as formas de motivação. Para qualquer organização, uma estrutura
apropriada é aquela que facilita respostas eficazes aos problemas de coordenação e motivação, evolui
à medida que a organização cresce e se diferencia, e pode ser gerenciada e modificada através do
processo de desenho organizacional.
• Cultura organizacional é o conjunto de valores compartilhados e normas que controla a interação entre
os membros da organização e destes com fornecedores, clientes e outras pessoas externas. Formata o
comportamento das pessoas e é formada pelas pessoas internas, pela ética da organização, pelo seu
tipo de estrutura e pelos direitos dos empregados. Também evolui e pode ser gerenciada através do
desenho organizacional.
• Desenho organizacional é o processo pelo qual os gerentes selecionam e gerenciam vários aspectos e
dimensões da estrutura e cultura de forma que a organização possa controlar as atividades necessárias
para atingir seus objetivos. Para a sua sobrevivência, deve equilibrar as pressões internas e as externas
do ambiente.
A teoria organizacional contribui para a análise de situações complexas nas organizações, descobre ou
inventa meios eficazes e criativos para lidar com elas, além de abrir a mente para aspectos da vida, dentro e
fora das organizações. Veja na tabela a seguir uma lista das principais teorias das organizações.
Teoria tem ênfase Nome da teoria Principais enfoques

em
Tarefas Administração Racionalização do trabalho no
científica nível operacional
Estrutura Teoria Clássica Organização formal
organizacional Teoria Princípios gerais da administração
Neoclássica Funções do administrador
Teoria da Organização formal burocrática
burocracia Racionalidade organizacional
Teoria Múltipla abordagem
estruturalista Organização formal e informal
Análise intra-organizacional e
inter-organizacional
Pessoas Teoria das Organização informal
relações Motivação, liderança,
humanas comunicações e dinâmica de
grupo
Teoria do Estilos de administração
comportamento Teoria das decisões
organizacional
Integração dos objetivos
organizacionais e individuais
Teoria tem ênfase Nome da teoria Principais enfoques
em
Teoria do Mudança organizacional
desenvolvimento planejada
organizacional Abordagem de sistema aberto
Ambiente Teoria Análise intra-organizacional e
estruturalista análise ambiental
Teoria da Análise ambiental
contingência Abordagem de sistema aberto
Competitividade Novas Caos e complexidade
abordagens da Aprendizagem organizacional
administração
Capital intelectual
Observe que as questões do exame PMP não abordam especificamente cada uma dessas teorias. Por
isso, leve para a prova que a teoria das organizações (TO) contribui para a análise de situações complexas
nas organizações, descobre ou inventa meios eficazes e criativos para lidar com elas, além de abrir a mente
para aspectos da vida, dentro e fora das organizações.
Reuniões
especialistas para desenvolver, juntamente com outras ferramentas, o plano de gerenciamento dos recursos.
Saídas
A saída deste processo obviamente é o plano de gerenciamento de recursos. O objetivo desse plano é
nortear, delimitar e gerenciar de forma integrada todos os aspectos ligados aos recursos do projeto, tais como:
definir, alocar, mobilizar, gerenciar e liberar os recursos do projeto. O Guia PMBOK® cita os componentes que
devem estar nesse plano:
• Identificação dos recursos: são os métodos que serão utilizados para identificar os possíveis recursos
do projeto.
• Papéis e responsabilidades: embora seja o gerente do projeto o principal responsável por seu sucesso,
deve-se observar que, sob o ponto de vista de cada atividade individual, a responsabilidade é da pessoa
que a executa. Sendo assim, todos os envolvidos em um projeto devem saber qual é o seu papel e a sua
responsabilidade nesse esforço. E cabe ao gerente de projetos exibir de maneira clara e objetiva esses
papéis e responsabilidades. Além disso, deve-se também descrever quais são as competências exigidas
para a conclusão das atividades, bem como o nível de autoridade de cada um. Estas informações podem
ser armazenadas em um documento chamado lista da equipe do projeto (project team directory).
• Organograma: é importante destacar que o Guia PMBOK® aceita que o organograma pode ser formal
ou informal (!). Além disso, o organograma deve ser construído de acordo com as necessidades do
projeto. O nível de detalhamento muda de acordo com a quantidade de pessoas envolvidas.
• Gerenciamento dos recursos da equipe do projeto: Este item se refere a documentar como e quando
os recursos humanos entram e saem do projeto, sendo que esse plano pode ser formal ou informal,
minucioso ou genérico. Entre os itens que compõem este plano podemos destacar:
ДД Mobilização do pessoal: ao planejar a equipe que comporá o projeto, é necessário estabelecer se
os recursos serão internos ou externos, onde serão alocados (centralizado, distribuído ou virtual), qual
o custo de cada profissional com experiência etc.
ДД Plano de liberação do pessoal: um dos grandes fatores de risco de um projeto é a desmotivação e
falta de comprometimento da equipe à medida que o projeto vai chegando ao seu fim. Como em muitos
casos os recursos alocados são temporários, a moral e a ansiedade com relação ao futuro começam a
afetar as etapas finais do projeto. Por isso, é muito importante que um plano de liberação do pessoal
seja elaborado com vistas a indicar que a medida que um recurso não é mais necessário ele poderá
ser alocado em outro projeto ou devolvido ao seu departamento de origem. Também é importante
observar que se um recurso não é mais necessário ele não deve continuar gerando custo ao projeto.
• Treinamento: deve ser elaborado um plano de treinamento a ser oferecido aos membros da equipe
que ainda não possuam as competências necessárias à execução de suas tarefas. Treinamentos são
muito úteis quando estamos utilizando novas ferramentas e/ou novas tecnologias, pois nivelarão o
conhecimento de toda a equipe.
• Plano de reconhecimento: veremos com mais detalhes em capítulos posteriores, mas vale adiantar que
o gerente pode e deve recompensar o bom trabalho realizado pelos membros do projeto.
• Conformidade e segurança: a conformidade com regulamentações governamentais e sindicais deve ser

indicada no plano de gerenciamento do pessoal. Deve-se também especificar os requisitos de segurança
de pessoal, principalmente em projetos de construção civil.
Estimar os recursos das atividades (9.2)
Todos os projetos, sem exceção, precisam de recursos. E recurso é tudo que serve para a execução das
atividades ou que é consumido por elas. Os recursos que executam as atividades são chamados de recursos de
trabalho (pessoas e equipamentos) e sua produtividade determina a duração das atividades. Já os recursos que
são consumidos pelas atividades, como os materiais, não determinam ou influenciam diretamente o andamento
das atividades, no entanto são consumidos por elas e quando faltam, as atividades relacionadas não podem ser
concluídas.
Neste processo realizaremos a determinação dos recursos, bem como as quantidades que serão usadas e
quando cada um estará disponível. Normalmente estimar recursos envolve ações tais como:
• Revisar a disponibilidade do pool de recursos (calendário de recursos);
• Revisar a EAP;
• Identificar recursos potencialmente disponíveis;
• Revisar as informações históricas sobre o uso de recursos no passado ou em projetos semelhantes;
• Revisar as políticas da organização sobre o uso de recursos;
• Solicitar a opinião de especialistas sobre quais recursos são necessários e estão disponíveis;
• Analisar formas alternativas de concluir o trabalho;
• Decisões de fazer ou comprar.
O processo
Entradas
Muitas das entradas deste processo já foram vistas. Vamos revisá-las?

• Plano de gerenciamento dos recursos: este plano indica como os recursos para o projeto serão
identificados, bem como define os métodos para quantificar os recursos necessários.
• Linha de base do escopo: a partir das informações do escopo do produto e do projeto, estimativas de
recursos podem ser elaboradas.
estimativa dos recursos. Por exemplo, uma determinada atividade que é altamente complexa só poderá
ser executada por um profissional especializado nesse assunto.
• Lista de atividades: da lista de atividades extraímos informações das tarefas que precisarão de recursos.
• Registro de premissas: este registro pode conter informações sobre fatores de produtividade,
disponibilidade, estimativas de custos etc que podem afetar a alocação de recursos.
• Estimativas de custo das atividades: estas estimativas indicam quanto cada recurso custará. E com essa
informação podemos avaliar se determinado recurso poderá ser selecionado para o projeto ou se ele é
caro demais, inviabilizando assim sua convocação.
• Calendário dos recursos: este calendário contém informações de quando e por quanto tempo um
recurso estará disponível para o projeto.
• Registro dos riscos: ainda não vimos o que é o registro dos riscos, pois este será detalhado na área de
conhecimento Gerenciamento dos riscos. De forma resumida temos que os eventos de risco podem
influenciar a seleção e a disponibilidade de recursos. Por exemplo, supondo que temos um projeto em
algum grande banco do governo, é quase certo que haverá uma greve por ano por volta de outubro/
novembro. Dessa forma, se o seu projeto utilizará recursos dessa entidade, é preciso estar preparado
para esse risco.

Dentro dos fatores ambientais que serão considerados neste processo temos: localização, disponibilidade
e competências dos recursos.

Como já vimos os ativos se referem a toda informação acumulada pela empresa, e neste caso serão
considerados: as políticas e procedimentos de mobilização do pessoal, políticas e procedimentos de compras,
informações históricas de recursos utilizados em atividades semelhantes.
Especialista podem ajudar a determinar os recursos necessários para cada atividade do projeto.
Estimativa “bottom-up”
Esta técnica é usada todas as vezes que uma atividade não puder ter sua duração/recursos estimados
devido ao seu tamanho ou complexidade. Neste caso é recomendável decompor a atividade em mais detalhes
até conseguir estimar os recursos que irão executá-la.
Estimativa análoga
Também conhecida como estimativa top-down, esta estimativa utiliza dados de projetos anteriores (análogos)
para estimar os recursos de uma atividade. É muito utilizada pela sua facilidade de aplicação principalmente
quando não se têm informações detalhadas e consequentemente não é a mais exata. Estimamos os valores
atuais a partir de valores similares realizados em projetos anteriores.
A estimativa análoga utiliza informações históricas e é muitas vezes mais confiável que as estimativas
realizadas pelos membros do time do projeto.
Esta estimativa utiliza um algoritmo (ou fórmula matemática) juntamente com dados históricos para o
cálculo dos recursos necessários para uma atividade.
Por exemplo, sei que um recurso pode produzir 500 peças por dia em média. De quantos recursos eu
precisaria para produzir 10.000 peças em 5 dias? A resposta seria: 4 recursos.
qualidade. E pode ser utilizada em parte do projeto e também usada em combinação com outras técnicas.
Análise de dados
Muitas atividades do cronograma podem ter mais de uma alternativa para a sua realização, permitindo
o uso diferente de capacidades ou habilidades, diferentes tipos de máquinas ou ferramentas para execução.
Assim a ténica de análise de alternativas é usada para avaliar as opções identificadas, e selecionar as opções ou
abordagens a serem usadas para a melhor utilização dos recursos.
Por exemplo, a análise de alternativas pode incluir decisões entre:
• Realizar o trabalho manual ou automatizá-lo;
• Comprar um software ou desenvolvê-lo internamente;
• Alocar um recurso sênior ou dois júniores.
Software de gerenciamento de projetos

Vários softwares, inclusive gratuitos, podem auxiliar no gerenciamento de recursos, disponibilidades,
calendários etc.
Reuniões
São nas reuniões que as estimativas podem ser elaboradas. O gerente do projeto pode solicitar a presença
dos gerentes funcionais dos recursos escolhidos para auxiliar no desenvolvimento das estimativas.
Saídas
Requisitos de recursos
Uma das saídas deste processo é o documento de requisitos de recursos que identifica os tipos e as
quantidades de recursos necessários para que cada atividade seja concluída. A quantidade de detalhes e o nível
de especificidade das descrições podem variar de acordo com a sua área de aplicação.
Na figura a seguir temos um exemplo desta saída. Observe que o item 14 – “Servidor” tem como tipo de
recurso “Material” e que para ser completado precisará de quatro unidades.

A base das estimativas fornece a documentação de suporte aos recursos estimados. Imagine que seu projeto
tenha a duração de dois anos, e que o patrocinador queira saber, depois de decorridos 18 meses do projeto,
porque aquela quantidade de material foi solicitada para a construção de um determinado trecho da estrada.
a estimativa foi derivada.
Estrutura analítica dos recursos

Outra saída é a estrutura analítica dos recursos (EAR), que é uma estrutura hierárquica que agrupa os
recursos por categoria e tipo como mostrado na figura a seguir.
Recursos do projeto
1 Pessoas 2 Materiais 3 Equipamentos
3.1 Trator
1.1 Gerente Projeto 2.1 Construção
3.2 Escavadeira
2.2 Engenharia
1.2 Engenheiro
2.2.1 Itens 3.3 Caminhão

1.2.1 Eng Civil
elétricos
1.2.2 Eng Elétrico 2.2.2 Itens

Mecânicos
1.2.2 Eng Mecânico

A execução deste processo pode gerar alterações em alguns documentos do projeto, tais como: lista de
atividades, atributos das atividades e calendário dos recursos.
Planejando as Comunicações
Projetos são realizados por pessoas, que se valem da comunicação para compreender como devem realizar
tarefas e atingir resultados. Assim, a comunicação é um aspecto muito importante no gerenciamento do projeto,
sendo considerada um fator crítico de sucesso.
Uma boa comunicação começa pela capacidade de ouvir, de compreender o que o outro deseja comunicar,
de saber interpretar o que ele deseja. É também saber silenciar no momento certo e estar disponível para
escutar o interlocutor dando-lhe a devida atenção.
É preciso que o projeto mantenha uma boa comunicação tanto interna como externamente isso pode incluir:
• A forma pela qual as comunicações do projeto serão realizadas (processos e procedimentos);
• Cronogramas de atividades de comunicação;
• Papeis e responsabilidades ligados à comunicação;
• Análise de partes interessadas.
A gestão das comunicações é frequentemente ignorada pelos gerentes de projeto, porque acham que isso
já está implícito na execução de suas tarefas diárias. No entanto, a boa comunicação não se limita a conversas
ou à emissão de relatórios de desempenho. O gerente do projeto deve verificar as necessidades de informação
de cada parte envolvida e mantê-las a par do que é mais importante para cada um.
Dentro do grupo de processos de Planejamento o Guia PMBOK® recomenda o seguinte processo para a
criação do plano de gerenciamento das comunicações:
• Planejar o gerenciamento das comunicações (10.1).
com sucesso.
Dimensões
O Guia PMBOK® cita que existem diversas potenciais dimensões que devem ser consideradas quando se
trata de comunicação. Entre elas, citamos as que mais têm chance de estarem presentes em seu exame.
Paralingual e não verbal

A comunicação paralingual é aquela que utiliza sons ou qualidade de voz que acompanha a fala e revela a
situação em que o falante se encontra, ou seja, aspectos como velocidade e entonação.
Já a comunicação não-verbal, conhecida também como linguagem corporal, é aquela que se dá sem o
uso de palavras. Este tipo de comunicação é o mais primitivo, eficiente e revelador que a comunicação verbal.
Mensagens não-verbais são usadas para substituir, reforçar e, às vezes contradizer uma mensagem.
Existe um estudo (de Albert Meharabian) que destaca que os aspectos não-verbais da comunicação
interpessoal tem maior influência no impacto total da mensagem do que os fatores verbais, conforme mostramos
a seguir:
Impacto da mensagem = 7% palavras + 38% paralingual + 55% não verbal
Oral e escrita
Apesar dos grandes avanços tecnológicos, a comunicação oral e escrita ainda é a mais utilizada para
transmitir informações, principalmente nas relações interpessoais. Em uma empresa, por exemplo, avisos são
transmitidos com linguagem escrita (por e-mail) e em relações familiares o diálogo permanece eficaz.
Embora a comunicação visual seja hoje o recurso mais usado na propaganda, esta ainda se utiliza de recursos
verbais em alguns meios de comunicação, como, principalmente, no rádio e na televisão, e, eventualmente, na
internet.
Observe que manter comunicações orais e presenciais é extremamente importante para criar e manter
o espírito de equipe. A presença física e os milhares de sinais não-verbais que são transmitidos ampliam a
confiança dos envolvidos no processo.
Formal e Informal
A comunicação formal é a endereçada através dos canais de comunicação existentes no organograma da
empresa, pois é derivada da alta administração. A mensagem percorre os canais formalmente estabelecidos
pela empresa na sua estrutura organizacional. É basicamente a comunicação veiculada pela estrutura formal
da empresa, sendo quase toda feita por escrito e devidamente documentada através de correspondências ou
formulários.
Já a comunicação informal, é aquela desenvolvida espontaneamente através da estrutura informal e

fora dos canais de comunicação estabelecidos pelo organograma, sendo todo tipo de relação social entre os
colaboradores. É a forma dos funcionários obterem mais informações, através da conhecida “rádio peão”.
A seguir mostramos uma tabela com algumas dicas de quando usar cada tipo:
Método de comunicação Quando usar
Escrita – Formal Problemas complexos, planos de projeto,
documentos do projeto
Verbal – Formal Apresentações
Escrita – Informal Memorandos, e-mails, notas
Verbal – Informal Reuniões, conversas
Sentido/Direção da comunicação
• Comunicação descendente: (ou de cima para baixo) é em geral vista como seguindo a via de comando
formal da organização do alto até o nível mais baixo. Tende a refletir a relação de autoridade expressa
no organograma. Exemplo: designação de funções e ordens.
• Comunicação ascendente: (ou para cima) representa o feedback de dados ou informações dos níveis mais
baixos para os níveis da alta administração. Exemplo: relatório de desempenho indicando resultados,
progresso ou problemas.
• Comunicação lateral ou horizontal: essa forma de comunicação é essencialmente utilizada para

coordenação de atividades e resulta do conceito de especialização organizacional. Inclui a comunicação
entre colegas do mesmo grupo e comunicação entre departamentos do mesmo nível.
Fatores Críticos de sucesso
As principais características de uma boa comunicação do ponto de vista do comunicador são:
• Objetividade;
• Conhecimento do interlocutor (público alvo);
• Compreensão do interlocutor (saber ouvir);
• Linguagem adequada;
• Clareza e simplicidade;
• Preferência pela voz ativa;
• Correção;
• Concisão;
• Fidelidade ao pensamento original;
• Tradução do pensamento nas palavras certas;
• Eliminação da filtragem (garantia de que o pensamento original chegou com precisão ao interlocutor e
foi por ele captado).
Além disso, é importante que o gerente esteja atento a:
• Estabelecer e manter canais de comunicação formais e informais entre as partes interessadas, incluído
a gerência, outros gerentes de projeto, os gerentes funcionais, os clientes, os fornecedores e a equipe
do projeto.
• Facilitar e incrementar a comunicação do projeto.
• Saber o quê, como e quando comunicar.
• Gerenciar as expectativas de comunicação das partes interessadas.
• Resolver conflitos.
Planejar o gerenciamento das comunicações (10.1)
O planejamento do gerenciamento das comunicações determina as necessidades de informações e
comunicações das partes interessadas no projeto. Isto inclui determinar o que precisa ser comunicado, para
quem, quando, com que frequência e por qual método.
O Guia PMBOK® indica que o planejamento do gerenciamento das comunicações deve ser feito bem no
inicio do projeto. E há uma boa justificativa para isso. Para que a comunicação seja efetiva, recursos devem ser
alocados nessas atividades. Boa comunicação no projeto não se resume a emissão de relatórios de desempenho.
Pode haver a necessidade da criação de um site para compartilhamento de informações, alocação de espaço
em servidores para armazenamento de documentos, reuniões mensais para apresentação do desempenho do
projeto etc.
Alguns pontos a serem considerados:
• Comunicação eficiente não significa informação em demasia.
• Informação eficiente é aquela enviada na quantidade e momento certos.
• Todos os envolvidos no projeto devem entender como as comunicações os afetam.
O processo
Entradas
O termo de abertura contém informações sobre as principais partes interessadas e ainda pode conter
informações sobre seus papéis e responsabilidades.

Entre os planos auxiliares do plano do projeto, podemos obter informações do:
• Plano de gerenciamento dos recursos: este plano contém entre outras informações o organograma do
projeto.
• Plano de gerenciamento das comunicações: este plano contém as informações relativas aos requisitos
de comunicação necessários para o bom andamento do projeto.
• Plano de engajamento das partes interessadas: este plano contém as estratégias de comunicação que
podem ser usadas para o engajamento das partes interessadas.
• Documentação dos requisitos: esta documentação pode conter informações referentes às comunicações
com as partes interessadas.
• Registro das partes interessadas: O registro das partes interessadas, criado durante a Iniciação do
projeto, contém a lista das partes interessadas juntamente com suas expectativas, influências, poderes
etc. É muito importante que as principais partes interessadas sejam consideradas no planejamento das
comunicações.
Fatores Ambientais
Quando se trata da comunicação, praticamente TODOS os fatores ambientais afetam este processo. Veja
que os fatores ambientais estão relacionados com o ambiente em que o projeto está sendo desenvolvido. Dessa
forma, é correto imaginar que tudo que se relacione a esse ambiente afete as comunicações do projeto. Por
exemplo, estrutura organizacional, cultura organizacional, sistemas de informação etc.

Quando se trata da comunicação, praticamente TODOS os ativos de processos organizacionais afetam este
processo. Mas devemos destacar dois elementos: lições aprendidas e informações históricas. Como já dissemos
inúmeras vezes, devemos sempre observar o que deu certo e o que deu errado em projetos anteriores, para que
possamos acertar mais e errar menos no projeto atual.
Obviamente, mais uma vez podemos nos utilizar da opinião especializada para o desenvolvimento do plano
de gerenciamento das comunicações. E aqui os especialistas podem ajudar na escolha das ferramentas de
comunicação, como melhor efetivar a comunicação com as partes interessadas entre outras atividades.
Análise dos requisitos das comunicações
Os requisitos de comunicação são a soma de todos os requisitos de informação das partes interessadas no
projeto. Para obter esses requisitos é necessário combinar o tipo e o formato de todas as informações e avaliar
o seu valor, ou seja, o quanto ela irá contribuir para o sucesso do projeto.
Com tanta informação disponível atualmente, certifique-se que a SUA informação não vá para a Lixeira. Por
isso, por exemplo, não perca tempo tentando deixar a par nos mínimos detalhes o patrocinador do projeto. Ele
com certeza o agradecerá por isso!
Existem diversas fontes de informação que podem ser utilizadas para auxiliar na definição das necessidades
de comunicação das partes interessadas, como por exemplo:
• Organogramas da empresa e dos departamentos;
• Lista de partes interessadas;
• Lista dos recursos envolvidos e sua localização;
• Necessidades internas de comunicação (departamentos específicos, diretorias etc);
• Necessidades externas de comunicação (imprensa, fornecedores etc).
Veja na figura a seguir um exemplo de relacionamento entre partes interessadas e seus requisitos de
informação.
Alta gerência,
Cliente,
Patrocinador
Informal
A
Interessados Gerentes
Externos Funcionais
Gerente do
D B
projeto
Outros gerentes
Agências de projeto
Reguladoras,
Governo
Formal
C
Equipe do projeto
Canais de comunicação
Cada elemento do projeto cria com outro um canal de comunicação para troca de informações. Os canais
crescerão potencialmente a taxas indicadas pela fórmula:
Onde: n = número de partes interessadas
Embora nem todos os integrantes da equipe tenham que se comunicar com os demais, o número indicado
pela fórmula nos mostra os potenciais canais presentes em um projeto. Decore essa fórmula para a prova!
Por exemplo, imagine um projeto com 5 pessoas envolvidas. Teremos 10 canais potenciais de comunicação,
o que no fundo não é muito complicado de gerenciar. Imagine agora um projeto que envolva 100 pessoas, serão
“apenas” 4950 potenciais canais de comunicação. Como é que o gerente do projeto gerencia isso? Bom, ele não
gerencia, pois é impossível uma só pessoa conseguir lidar com tantas variáveis.
Por isso, é muito importante que os requisitos de comunicação sejam levantados para que se possa limitar
a quantidade de canais.
Fonte: http://dicaspm.com/melhore-comunicacao-seu-projeto-ja/
Tecnologia de comunicações
Vivenciamos a cada dia inovações tecnológicas que nos aproximaram (e ao mesmo tempo nos afastaram)
das pessoas. Existem diversas formas de transmitir as informações para as partes interessadas. Os fatores que
podem influenciar na escolha da melhor forma são:
• Urgência da necessidade: se a informação precisa estar disponível em tempo real, considere o uso
de Web sites atualizados dessa forma. Envio de mensagens via e-mail disparados assim que uma
determinada condição se concretize também podem ser uma boa solução.
• Disponibilidade da tecnologia: a tecnologia deve facilitar a transmissão da comunicação e não complicá-

la. Veja o caso de obrigar as partes interessadas a instalar plug-ins em seus smartphones só para poderem
ter acesso àquela “super apresentação” em flash que você criou.
• Facilidade de uso: a informação além de acessível deve ser fácil de ser encontrada e entendida. Relatórios
com diversas páginas confundem e cansam. Ninguém está disposto a ler mais que duas páginas de um
relatório. E-mails com mais de uma página vão direto para a Lixeira. Seja breve e conciso.
• Ambiente do projeto: você deve considerar se a comunicação será realizada presencialmente ou

virtualmente. Em grandes projetos, uma boa solução é a realização de Web conferências.
• Sensibilidade e confidencialidade das informações: imagine publicar a planilha de salários dos membros
do projeto na intranet da empresa...por isso é muito importante definir que tipo de informação deve ser
publicada livremente e que tipo deve ser enviada para uma lista restrita de destinatários.
Modelos de comunicações
Há muitos modelos de comunicação, dependendo do contexto em que a comunicação se processa. No
modelo de comunicação interpessoal, chamado também de modelo básico de comunicação, destacam-se os
seguintes elementos:
• Emissor: que emite, codifica a mensagem;
• Receptor: que recebe, decodifica a mensagem;
• Meio ou mídia: canal pelo qual circula a mensagem;
• Mensagem: conteúdo transmitido pelo emissor.

Fonte: http://opilotoprofissional.blogspot.com.br/2010/07/comunicacao-e-seguranca-de-voo-primeira.html
A sequência de passos para executar a comunicação de uma informação é a seguinte:

• Codificação da mensagem: refere-se a escolha de uma forma, verbal ou não, de comunicação que seja
capaz de transferir um significado, como, por exemplo, palavras faladas ou escritas, gestos ou atos.
• Transmissão da mensagem: envio da comunicação da fonte para o receptor que reflete a escolha do
comunicador em relação ao meio ou canal de distribuição. A comunicação oral pode ser transmitida
por muitos canais como por telefone ou vídeo e a comunicação escrita pode ser transmitida por
memorandos, relatórios, jornais, entre outros.
• Decodificação da mensagem: atribuir um significado à mensagem, o que é feito pelo receptor.
• Envio de feedback à fonte: depois que uma mensagem foi recebida e decodificada, o receptor pode
proporcionar feedback, transmitindo uma mensagem de retorno, que estimula o comunicador original.
Mesmo utilizando-se dos melhores meios/formas/modelos a comunicação não é isenta de ruídos. Esses
ruídos normalmente são causados por:
• Ambiente adverso: local em que há muito barulho poderá distrair a atenção do receptor, que por sua
vez compreenderá apenas parte da mensagem emitida pelo emissor;
• Momento em que a mensagem está sendo transmitida: caso o receptor não esteja concentrado para
obter as informações necessárias, a mensagem não será completamente entendida;
• Linguagem inadequada: uso de termos técnicos ou palavras em idioma desconhecido pelo receptor;
• Exposição descuidada: falar de temas que não são do interesse dos receptores, desviando assim a
atenção, não centrando nos assuntos que são de fato importantes.
• Outros: distância, diferenças culturais, tecnologias não familiares etc.

Por tudo que vimos, podemos concluir que a comunicação efetiva somente ocorre quando o receptor
decodifica a mensagem conforme o emissor planejou. Uma quebra no processo de comunicação pode ocorrer
se a mensagem não foi codificada ou decodificada de forma adequada seja por falta de conhecimento do
código pelos participantes do ato comunicativo, seja pela existência de ruído no canal de comunicação ou ainda
pela influência de fatores cognitivos ou sociais envolvidos no processo.
E fique atento com isto: é do emissor a responsabilidade da comunicação estar clara e completa e de
que o receptor a tenha entendido corretamente. É claro que o receptor também tem a responsabilidade de
enviar seu feedback indicando o que entendeu da informação.
Métodos de comunicação
Os métodos de comunicação estão relacionados às formas de interatividade entre emissores e receptores.
• Comunicação ativa: o emissor envia unilateralmente a mensagem para destinatários específicos, mas
não há confirmação de que a informação foi entendida. Exemplos: e-mails, relatórios etc.
• Comunicação passiva: a informação é disponibilizada em um repositório e os destinatários acessam a

qualquer tempo. Aqui, o destinatário não recebe a informação; ele tem que procurá-la no repositório.
Exemplo: sites, bancos de dados de lições aprendidas etc.
• Comunicação interativa: é a forma mais eficiente de trocar informações, pois são duas ou mais pessoas
interagindo entre si. Exemplos: reuniões, telefones, mensagens instantâneas, web conferências etc.

Quando se trata da comunicação, as habilidades interpessoais e de equipe entram em destaque. Um dos
fatores que mais prejudicam o projeto é a inabilidade de comunicar pontos importantes às principais partes
interessadas. Dentre as diversas habilidades, podemos citar:
• Avaliação de estilos de comunicação: esta avaliação verifica as melhores formas e formatos para que as
informações do projeto cheguem às pessoas certas e no tempo certo.
• Consciência política: este item não se refere ao gerente do projeto votar em um ou em outro partido
político. Na verdade, se refere à percepção das estruturas de poder formais e informais que podem
ocorrer dentro do projeto e da empresa executora. Por mais que o gerente do projeto não queira se
envolver, é extremamente necessário que ele entenda tais estruturas e de quem ele pode esperar apoio
e de quem ele pode esperar justamente o contrário.
• Consciência cultural: da mesma forma que o item anterior, o gerente do projeto precisa entender
a cultura da organização para adaptar as estratégias de comunicação ao seu contexto. Por exemplo,
empresas mais tradicionais podem exigir que todas as comunicações sejam feitas por escrito, em outras,
pode ser que apenas um comunicado verbal em uma reunião de acompanhamento já seja o suficiente.
Reuniões
As reuniões são utilizadas para discutir como o planejamento do gerenciamento das comunicações será
realizado.
Saídas
Plano de gerenciamento das comunicações
Todo projeto precisa de um bom plano de comunicação, mas nem todos os projetos contam com os
mesmos tipos, métodos, canais etc. É no plano de gerenciamento das comunicações que são documentadas as
necessidades de informação das partes interessadas, e em que momento serão disponibilizadas.
As informações comunicadas usualmente abrangem o desempenho do projeto, solicitações de mudança,

riscos, atualizações de cronograma etc etc etc.
O Guia PMBOK® traz uma lista bem completa das informações que devem estar presentes no seu plano de
gerenciamento das comunicações. Entre eles citamos:
• Requisitos de comunicação das partes interessadas;
• Relatório/Informação (formato, conteúdo, nível de detalhe, modelo);
• Propósito;
• Responsável;
• Destinatários;
• Meios de comunicação ou tecnologia;
• Frequência;
• Início e término;
• Critério para escalação;
• Método para atualização do plano;
• Glossário do projeto;
• Modelos e diretrizes para reuniões, e-mail etc.

Como em todos os processos de planejamento, pode ser que existam alterações a serem realizadas no
plano de gerenciamento de projetos. Entre os diversos planos, um que com certeza poderá ser afetado é o
plano de engajamento das partes interessadas, porque a comunicação afeta diretamente as partes interessadas
e vice-versa, as partes interessadas afetam diretamente como as comunicações serão efetivadas.

Como em todos os processos de planejamento, pode ser que existam alterações a serem realizadas em seus
documentos. Entre eles citamos:
• Cronograma do projeto: por exemplo, o cronograma pode sofrer alterações por conta de reuniões que
serão agendadas.
• Registro das partes interessadas: este registro poderá ser alterado por conta de novas informações
“descobertas” durante o planejamento das comunicações.
Planejando os Riscos
O risco é inerente a qualquer atividade na vida pessoal ou profissional e pode envolver perdas, bem como
oportunidades. Quando corremos um risco, apostamos em um resultado que será consequência de uma decisão
que tomamos, embora não saibamos ao certo qual será esse resultado. A essência da administração do risco
está em maximizar as áreas onde temos certo controle sobre o resultado, enquanto minimizamos as áreas onde
não temos absolutamente nenhum controle sobre o resultado e onde o vínculo entre efeito e causa está oculto
de nós.
Muitas vezes pela falta de conhecimento, o gerenciamento de riscos acaba muitas vezes sendo confundido
com resolução de problemas ou intervenção em crises (o famoso “apagar incêndios”).
O Guia PMBOK® recomenda 5 processos de planejamento para identificação e análise de riscos:

• Planejar o gerenciamento dos riscos (11.1);
• Identificar os riscos (11.2);
• Realizar a análise qualitativa dos riscos (11.3);
• Realizar a análise quantitativa dos riscos (11.4);
• Planejar as respostas aos riscos (11.5).
Observe que você deve adaptar os processos propostos pelo Guia PMBoK® às necessidades atuais do
seu projeto, uma vez que nem todos os documentos precisarão ser elaborados para que você gerencie seu
projeto com sucesso.
Risco, incerteza e impacto

A palavra “risco” deriva do italiano risicare (por sua vez derivado do latim risicu, riscu), que significa “ousar”
e nos mostra que o risco é uma opção, e não um destino, ou seja, trata das ações pelas quais ousamos optar.
Quando você investe em ações, cirurgiões realizam operações, engenheiros projetam pontes e empresários
abrem seus negócios, o risco é um parceiro inevitável. Contudo o risco não precisa ser hoje tão temido:
administrá-lo tornou-se sinônimo de desafio e oportunidade.
O risco é constituído pela falta de conhecimento dos eventos futuros, pois nunca dispomos de 100% das
informações necessárias para a tomada de decisões, o que caracteriza a incerteza. Se tivermos absoluta certeza,
isso não pode ser classificado como risco. É coisa conhecida. Por exemplo, se você se joga do 20º andar de um
prédio é certo que não sobreviverá à queda, pois você não sabe voar. Neste caso, não se fala em risco (ou
evento de risco), se fala em evento certo!
A incerteza significa probabilidade desconhecida, isto é, algo é incerto quando temos parte da informação.
Nossa informação está correta e um fato deixa de ocorrer ou nossa informação é incorreta e um fato ocorre. A
total incerteza geralmente nos deixa pouco à vontade; a maioria de nós prefere riscos (conhecidos) à ela.
O impacto é o efeito no projeto se um evento de risco ocorrer. Normalmente é uma grandeza mensurável.
Costuma-se entender “risco” como “algo que pode não dar certo”, mas sua conceituação atual envolve a
quantificação e qualificação tanto das “perdas” quanto dos “ganhos” envolvidos em determinado evento.
Exemplo: quando a empresa onde você trabalha é comprada pelo concorrente a manutenção do seu
emprego pode ser totalmente incerta, pois você sabe que trabalha bem, no entanto não sabe se esse será um
critério para que o mantenham no quadro de funcionários, ou seja, você não tem informação alguma que lhe
dê o mínimo de segurança.
A figura a seguir nos mostra onde o gerenciamento de riscos atua.
Sem informação Informação parcial Informação

(Unkowns unkowns) (Knows unkowns) completa (Knowns)
Total Incerteza Incerteza Total

Incerteza Geral Específica Certeza
Espectro do gerenciamento de riscos do projeto
Psicologia do risco
É importante ter em mente que, embora os riscos sejam eventos reais, isto é, que existem efetivamente no
universo que nos cerca, a análise deles se baseia muito mais na nossa percepção de sua existência do que na sua
própria existência. Isso ocorre, principalmente, porque nossa compreensão é limitada e imperfeita.
Duas pessoas avaliam o mesmo evento de risco de forma diferente. Por exemplo, para uns saltar de
paraquedas pode ser uma boa forma de se divertir. Para outros, só de pensar em atravessar a porta do avião
com uma “mochila” nas costas é uma insanidade.
Normalmente existem dois componentes que influenciam nossa percepção do risco:

No exemplo do paraquedas o fator medo pode ser o temor do impacto potencial do paraquedas (e do
reserva) não abrirem. Já o fator controle é que nesse caso se os dois paraquedas não abrirem não existe controle
algum sobre o evento.
Um fato pode ter qualquer probabilidade entre 0 e 100%, de acordo com a opinião da pessoa cujo grau de
crença a probabilidade representa. Tal probabilidade representa o grau de convicção de um indivíduo de que
certo fato acontecerá e sempre depende das informações disponíveis ao avaliador que a específica.
Teoria da decisão
A teoria da decisão é a teoria de decidir o que fazer quando é incerto o que acontecerá. Tomar uma decisão
é o primeiro passo essencial em qualquer esforço de administração do risco. Muitas vezes tomamos decisões
com base na experiência passada, ou seja experiências que nós ou outros conduzimos no decorrer de nossas
vidas.
As decisões são tomadas em três diferentes condições:
• Decisão com base em certeza: é quando o tomador de decisão sabe exatamente as consequências de
cada alternativa;
• Decisão sob risco: quando o tomador da decisão conhece as consequências e a probabilidade de cada
alternativa;
• Incerteza: ocorre quando o tomador de decisão não conhece todas as consequências de cada alternativa,
ou não conhece a probabilidade de pelo menos uma das alternativas.
Em gerência de projetos, prevalece a tomada de decisões em condições de risco.
Teoria da utilidade
O mundo está cheio de coisas desejáveis, mas a quantia que as pessoas estão dispostas a pagar por elas
difere de uma para outra. A teoria da utilidade nos mostra como variam essas preferências: cada benefício ou
utilidade é percebido de modo diferente por pessoas diferentes, ou seja, o mesmo resultado pode ser mais útil
para uma pessoa do que para outra.
A teoria da utilidade avalia quanto risco as pessoas correrão na esperança de obter algum ganho desejado,
mas incerto. Ajuda, pois a modelar as preferências de um tomador de decisão, com base na sua propensão ou
atitude em relação ao risco. Está intimamente ligado à tolerância ao risco.
Tolerância ao risco
A vida real é um jogo de estratégia. Mas, raramente podemos esperar sairmos sempre “vencedores”.
Escolher a alternativa de aparente maior retorno tende a ser a decisão mais arriscada, pois poderá provocar a
defesa mais acirrada dos que perderão com essa alternativa. Geralmente aceitamos alternativas moderadas de
meio termo: nem se ganha muito nem se perde muito.
Tome como exemplo o Jogo do Milhão (ou qualquer outro que envolva o risco de ganhar ou perder uma
“bolada”). Quantos competidores se arriscariam a ir adiante depois que já conseguiram uma boa quantia em
dinheiro, sabendo que se errarem a resposta irão perder tudo o que já foi ganho? A troca do “certo” pelo
“incerto” é uma questão de tolerância.
O nível de tolerância ao risco é diferente para cada indivíduo e para cada organização. Não se trata apenas
de uma questão de atitude ou de cultura, mas também das capacidades, muitas vezes chamada também de
resiliência, ou seja, a capacidade que cada um tem de suportar um determinado nível de risco sem “entrar
em pânico” . Em um mesmo projeto, diferentes partes interessadas podem ter diferentes tolerâncias, limites,
critérios e níveis de resiliência para lidar com riscos.
As três classificações mais usuais de tolerância a riscos em função de sua utilidade são as mostradas na
figura a seguir. O eixo “y” representa a utilidade, que como já explicado representa a quantidade de satisfação
que um indivíduo recebe a partir de uma escolha. O eixo “x” representa a quantidade monetária que se pode
perder se determinada escolha for feita. Observe que para uma mesma quantidade monetária, a utilidade
precisa ser muito maior no gráfico à esquerda (avesso) do que no gráfico à direita (favorável).
U Avesso ao U Neutro ao U Favorável

Risco Risco ao Risco
50 $ 50 $ 50 $
Apetite ao risco
O apetite ao risco (risk appetite) é a atitude de uma organização com relação a ele e que determina os níveis
que ela é capaz de aceitar. Dentro de um cenário de mudanças, o apetite ao risco torna-se essencial, pois é um
direcionador, juntamente com outros fatores, para a tomada de decisão.
O apetite ao risco está intimamente ligado à tolerância ao risco e embora a diferença entre os dois termos
seja bem sutil, podemos resumi-las em:
O conjunto destes dois componentes define o perfil de riscos da organização, no que diz respeito à exposição
ao risco que a mesma aceita incorrer.
O risco é uma percepção subjetiva, consequentemente o estabelecimento de um nível de tolerância/

apetite ao risco para a organização é uma questão complicada e muitas vezes controversa. É aqui que
se fundamenta o principal objetivo da visão do apetite e tolerância a riscos: calibrar a sensibilidade e a
subjetividade inerentes a todos os indivíduos que compõem a organização. Dessa forma se estabelece
uma “régua” para a análise dos riscos, permitindo a priorização de decisões de acordo com os objetivos de
negócio da empresa.
As empresas que se expõem muito aos riscos tendem a gerenciá-los como forma de reconhecer as
oportunidades de ganho.
Limites de riscos
É a medida do nível de incerteza ou nível de impacto em que uma parte interessada pode ter em um
interesse específico. A organização aceitará o risco abaixo daquele limite. A organização não tolerará o risco
acima daquele limite de risco.
Classificação de riscos
A seguir apresentamos algumas classificações importantes:
• Risco de negócio: risco de fazer negócios que podem acarretar ganho ou perda.
• Risco puro: risco que apresenta apenas chance de perda. Também chamado de “insurable risk” (risco
“segurável”).
• Known-unknowns (riscos conhecidos): riscos que podem ser identificados e analisados. Coisas que
você sabe que não sabe. São percebidos a partir de experiências anteriores ou pela análise do ambiente
onde o projeto ocorre.
• Unknown-unknowns (riscos desconhecidos): riscos impossíveis de ser identificados. Coisas que você
não sabe que não sabe. Nem a experiência anterior nem o ambiente onde o projeto ocorre indicam que
eles possam ocorrer.
Risco em projetos
Segundo o Guia PMBOK®, risco é um evento ou condição incerta que se ocorrer, tem um efeito positivo ou
negativo em pelo menos um dos objetivos do projeto. Os riscos em projetos tem origem na incerteza existente
em todos eles.
Podemos observar que, em geral, as definições de riscos dadas por diversos autores incluem dois
componentes primários: a incerteza e o efeito nos objetivos do projeto. A dimensão incerteza pode ser descrita
usando-se o termo “probabilidade” e a dimensão efeito como sendo o “impacto”. Por isso, define-se que o risco
é o resultado da seguinte função:
Risco = f(probabilidade, impacto)

Como exemplo, podemos nos perguntar qual é a probabilidade de um tornado de grandes proporções
devastar o campo de obras de um projeto de construção civil que você está gerenciando. Bom, a probabilidade
de encontrarmos um fenômeno desses em terras brasileiras é bem baixo, na ordem de 0,1% ou menos. Mas
se por azar esse 0,1% vier a se concretizar, ou seja, se o tornado realmente se formar e destruir o seu campo
de obras o impacto será devastador. O exemplo pode parecer absurdo quando levamos em conta o clima
brasileiro, mas se o seu campo de obras estiver localizado no corredor dos tornados nos Estado Unidos haverá
realmente a necessidade de se considerar esse risco.
O gerenciamento de riscos e seus componentes

O gerenciamento de riscos é uma forma organizada de identificar, avaliar, responder e controlar os riscos do
projeto, de modo sistemático e durante toda a vida do projeto, no melhor interesse de seus objetivos. Não deve
ser considerada apenas uma atividade do gerente do projeto. Toda a equipe deve estar atenta aos possíveis
riscos que possam comprometer os seus resultados.
Para um efetivo gerenciamento de risco é necessário que tenhamos sempre à mão:
• Acesso à informação confiável e atualizada de informações sobre riscos;
• Processo de decisão apoiado em um modelo de análise e avaliação de riscos;
• Processo implantado para controlar os riscos.
O processo de gerenciamento de riscos de projetos é um dos mais complexos de ser colocado em prática,
pois consome tempo da equipe para identificação, análise e elaboração do plano de respostas aos riscos.
Além disso, o planejamento deve ser colocado em prática, ou seja, executado, pois apenas gerar dezenas de
documentos e não utilizá-los não será útil ao projeto.
O gerenciamento de riscos em um projeto NÃO é uma atividade opcional. É essencial ao sucesso do projeto
e para isso deve acompanhá-lo em todas as suas fases.
Fatores Críticos de Sucesso

Existem diversos Fatores críticos de sucesso no gerenciamento de riscos de um projeto que são essenciais
para o seu sucesso:
• Reconhecimento do valor do gerenciamento de riscos: o gerenciamento de riscos deve ser reconhecido
como uma disciplina que agrega valor e traz retornos positivos ao investimento da organização. Todos
os envolvidos devem reconhecer que o gerenciamento de riscos é benéfico ao projeto e não apenas um
“mal necessário”.
• Comprometimento da equipe: todos os membros participantes bem como os Patrocinadores devem

aceitar suas responsabilidades em atividades que envolvam o gerenciamento de riscos. O gerenciamento
de riscos é responsabilidade de todos e não apenas do gerente do projeto.
• Comunicação aberta e honesta: já que o gerenciamento de riscos é responsabilidade de todos, a

comunicação deve ser o mais aberta e honesta possível. Não deve existir a cultura da “punição” por algo
dar errado. Quando isso acontece, as pessoas tendem a esconder os problemas com medo de serem
punidas. E quando o problema finalmente vem à tona, muitas vezes já é tarde demais.
• Comprometimento da organização: a organização só se compromete com o gerenciamento de riscos

se as metas estabelecidas estão alinhadas com as metas da empresa. Como o gerenciamento de riscos
muitas vezes envolve o apoio da alta direção, ele deve ser amplamente justificado. Se a alta direção não
puder enxergar o benefício, ou seja, se só enxerga que é um desperdício de tempo e dinheiro, não haverá
comprometimento.
• Integração com o gerenciamento do projeto: o gerenciamento de riscos não existe no “vácuo”, ou seja,
isolado dos demais processos de gerenciamento do projeto. Para um bom gerenciamento de riscos
sempre o integre com as demais áreas de conhecimento de gerenciamento.
• Esforço na medida certa: como o gerenciamento de riscos envolve tempo e dinheiro seja consistente ao
estabelecer o nível de gerenciamento que se vai executar. Por exemplo, gerenciar riscos de um projeto
de implantação de software para uma farmácia é bem diferente de gerenciar riscos de um projeto de
software para controlar um avião.
Planejar o gerenciamento dos riscos (11.1)
Um gerenciamento de riscos efetivo requer a criação de um plano de gerenciamento de riscos. Nesse plano
descrevemos como os processos de gerenciamento de riscos serão levados adiante e como eles se relacionam
com os demais processos de gerenciamento do projeto.
O objetivo principal deste processo, portanto, será produzir o plano de gerenciamento de riscos que contém
o “como fazer“ a gestão de riscos do projeto.
Dois pontos importantes devem ser observados:
• Identificar barreiras: em empresas onde a cultura do “apagar incêndios” prospera, o gerenciamento de

riscos não é reconhecido como um processo válido. Neste caso, comece gerenciando poucos riscos. Não
deixe de registrar os problemas que foram evitados pelo gerenciamento e apresente-os no relatório de
desempenho do projeto. Mudanças culturais em organizações são demoradas. E para que realmente
ocorram você precisa demonstrar que valem a pena.
• Envolver partes interessadas: o gerente precisa envolver as partes interessadas nas atividades de
planejamento do gerenciamento de riscos. Em empresas com uma relativa maturidade no gerenciamento
de riscos, as partes interessadas podem participar de todo o processo de desenvolvimento do plano
de gerenciamento de riscos, sendo uma fonte preciosa de informações e de apoio. Já em empresas
com baixa maturidade no gerenciamento de riscos, a participação das partes interessadas poderá ficar
restrita a conversas informais sobre os receios que eles têm com relação ao sucesso do projeto. Mesmo
assim não deixe de procurar por informações que possam ser úteis.
O processo
Entradas
Você se lembra dos principais elementos componentes do Termo de abertura? Pois bem, eles são uma
entrada muito importante para o gerenciamento de riscos, e incluem: riscos de alto nível, requisitos de alto
nível entre outros.

Praticamente todas as áreas de conhecimento (escopo, custo, qualidade, recuros, partes interessadas etc)
podem gerar riscos, por isso é muito importante que se considere o plano de gerenciamento como uma das
entradas deste processo.

Note que mais uma vez temos os Fatores ambientais da empresa como entrada de um processo. Neste caso,
os fatores mais importantes são: atitudes, limites e tolerância aos riscos.

caso, podemos considerar como importantes os seguintes ativos: categorias de riscos, definições de conceitos
e termos, modelos padrão (templates), papéis e responsabilidades, lições aprendidas.
Os especialistas que podem ser consultados são: diretores, gerentes de projetos que já trabalharam com o
mesmo tipo de projeto, especialistas no assunto, grupos e consultores, associações técnicas etc.
Análise de dados
Como já vimos nos capítulos referentes ao planejamento do tempo e custos, as técnicas e análise de dados
são usadas em gerenciamento de projeto para prever possíveis resultados, simulando cenários e valores das
variáveis do projeto.
O gerenciamento de riscos é uma combinação de fatores que se inter-relacionam e que por conta disso
devem ser analisados em conjunto. Observe, por exemplo, que cada parte interessada tem uma atitude em
relação ao risco (apetite e tolerância), e que a organização também tem uma atitude em relação a esse mesmo
risco, mas muitas vezes essas atitudes são opostas.
Reuniões
O principal objetivo das reuniões - que deverá ter a participação dos membros do time, partes interessadas,
gerentes funcionais e outros que possam estar envolvidos no processo de gerenciamento de riscos - é ter a
contribuição de todos os participantes na elaboração do plano de gerenciamento de riscos.
Saídas
A saída deste processo é o plano de gerenciamento de riscos que deve conter as instruções de como serão
gerenciados os riscos, ou seja, como eles serão identificados, mensurados e controlados.
O plano de gerenciamento de riscos NÃO deve conter a lista de riscos identificados, tampouco as
possíveis respostas a eles. Tais informações são armazenadas em outros documentos que veremos em
capítulos posteriores.
O plano deve conter:
• Metodologia: define a abordagem e ferramentas que podem ser usadas para realizar o gerenciamento
dos riscos no projeto. Lembre-se de adaptar essa abordagem às necessidades do projeto, pois projetos de
baixa prioridade exigem menos esforço de gerenciamento de riscos do que projetos de alta prioridade.
• Papéis e responsabilidades: quem fará o quê? As pessoas que não são membros da equipe podem
também ter papéis e responsabilidades relacionadas ao gerenciamento dos riscos.
• Financiamento: é necessário calcular os custos com o gerenciamento dos riscos, mesmo sabendo que esse
gerenciamento economiza tempo e dinheiro do projeto, evitando e reduzindo ameaças e aproveitando
oportunidades. Lembre-se que o acompanhamento de um risco envolve tempo (e consequentemente
dinheiro) do recurso responsável por ele.
• Prazos: trata-se do período em que será realizado o gerenciamento de riscos do projeto. Os riscos
devem ser acompanhados e relatados diariamente, semanalmente ou mensalmente? Note que aqui
será estabelecido um cronograma de acompanhamento e que ele deverá ser integrado ao cronograma
do projeto.
• Categorias de riscos: são listas com as fontes de riscos comuns enfrentados pela empresa ou por
projetos semelhantes. As categorias são elaboradas de acordo com a natureza do projeto e podem ser
organizadas como uma lista simples ou de forma estruturada, como uma estrutura analítica de riscos
(EAR ou RBS - Risk Breakdown Structure) como a mostrada na figura a seguir.
Atrasos no cronograma
Tempo Força Maior
Mudanças
Greves
Recursos
Deficiências Técnicas
Humanos
Falta de recursos
Erros de estimativa
Custos Multas
Internos ao projeto Mudanças
Problemas hardware
Escopo Design Não viável
Mudanças
Projeto Web 2.0
Performance
Qualidade Garantia
Itens Subcontratados
Falta de clareza
Aquisições Disputas
Falhas nas entregas
Legislação
Externos ao
Outros Governo
projeto
Taxas cambiais
Outra sugestão para criar uma lista de categorias é:

ДД Riscos técnicos: requisitos do produto, mudanças de tecnologia;
ДД Riscos externos: fornecedores, governo, leis, clima;
ДД Riscos internos: financiamento, prazos, regras, mudanças organizacionais;
ДД Riscos do gerenciamento do projeto: estimativas de prazo, estimativas de custo, comunicação.
ДД Riscos imprevisíveis: cerca de 10% dos riscos são imprevisíveis.
É importante ter em mente que a lista de categoria dos riscos deve ser feita de acordo com as necessidades
do projeto.
• Definição de probabilidade dos riscos: a avaliação da probabilidade dos riscos investiga a probabilidade
de ocorrência de cada risco específico. Essa probabilidade pode ser obtida através da avaliação de dados
históricos, ou pode ser simulada e estimada.
Probabilidade Critério Possibilidade
Muito alto > 85% Ocorrência quase certa
Alto 51 – 85% Mais certo ocorrer do que não
ocorrer
Médio 26 – 50% Pode ocorrer, mas não é certo que
ocorra
Baixo 11 – 25% É possível que não ocorra
Muito Baixo < 10% É quase certo que não ocorrerá
Outro exemplo de escala de probabilidade é o apresentado na tabela a seguir:

Escala de probabilidade
Avaliação qualitativa Desprezível Baixo Moderado Alto Muito Alto
Probabilidade 5% 10% 20% 40% 80%
• Definição de impacto: a avaliação do impacto investiga o efeito potencial sobre um objetivo do projeto
(tempo, custo, escopo, qualidade etc) considerando tanto os efeitos negativos das ameaças quanto os
efeitos positivos das oportunidades. O impacto deve ser classificado considerando a ocorrência de um
evento com perdas inesperadas, e deve ser classificado de acordo com a sua gravidade.
Impacto Custo Tempo
Muito alto > 750K > 25 dias
Alto 500K – 750K 20 dias – 25 dias
Médio 250K – 500K 10 dias – 20 dias
Baixo 50K – 250K 5 dias – 10 dias
Muito Baixo < 50K < 5 dias
Outro exemplo de classificação de impacto é o apresentado na tabela a seguir:

Objetivo do Desprezível Baixo 0.1 Moderado Alto Muito Alto
Projeto 0.05 0.2 0.4 0.8
Custo Aumento Até 15% de Entre 15% Entre 30% Acima de
insignificante aumento e 30% de e 40% de 40% de
do custo do aumento aumento aumento
projeto
Cronograma Atraso Até 15% de Entre 15% Entre 30% Acima de
insignificante atraso e 30% de e 40% de 40% de
atraso atraso atraso
Escopo Redução do Áreas menos Áreas Redução Produto

escopo não importantes importantes do escopo final é
perceptível do escopo do escopo inaceitável inútil
são afetadas são afetadas
Qualidade Degradação Apenas Redução de Redução de Produto
de qualidade implicações qualidade qualidade final não é
não mais críticas requer inaceitável utilizável
perceptível são afetadas aprovação pelo cliente
do cliente
• Matriz de probabilidade e impacto: tipicamente as organizações avaliam a prioridade dos riscos em um
objetivo a partir da combinação da probabilidade de ocorrência e do impacto nos objetivos do projeto
usando definições como as mostradas nas quatro tabelas anteriores. Os riscos são então classificados a
partir de uma matriz de probabilidade impacto (PxI) como a representada na tabela a seguir.
A organização deve determinar as combinações de probabilidade e impacto que resultam em uma

classificação de risco alto, risco moderado e risco baixo. Podem ser usados termos descritivos ou valores
numéricos, dependendo da preferência organizacional. Em geral, essas regras de classificação de risco são
especificadas pela organização antes do projeto e são incluídas nos Ativos de processos organizacionais.
Classificação de Probabilidade e Impacto

PROB Impacto (Ameaças) Impacto (Oportunidades) PROB
Mt Alto B M M A A A A M M B Mt Alto
Alto B B M A A A A M B B Alto
Médio B B M A A A A M B B Médio
Baixo B B B M A A M B B B Baixo
Mt Baixo B B B B M M B B B B Mt Baixo
Mt Baixo Médio Alto Mt Mt Baixo Médio Alto Mt
Baixo Alto Baixo Alto
Impacto (Ameaças) Impacto (Oportunidades)
B = Baixo, M = Médio, A = Alto
Observe que utilizamos uma combinação de cores para especificar os níveis de Probabilidade x Impacto
nos dando a gravidade:
• Impacto de nível Alto -> cinza escuro;
• Impacto de nível Médio -> cinza claro;
• Impacto de nível Baixo ->branco.
• Apetite a riscos das partes interessadas: As tolerâncias à riscos das partes interessadas devem ser
registradas. Essas tolerâncias não devem ser implícitas, mas sim detalhadas durante o ciclo de vida do
projeto.
• Formatos de relatórios: O plano de gerenciamento de riscos deve conter modelos de como os relatórios
deverão ser gerados e formatados.
• Acompanhamento: O plano de gerenciamento de riscos deve indicar como as atividades de risco serão
registradas e acompanhadas.
Identificar os riscos (11.2)
Um risco não pode ser gerenciado se não foi identificado. Isso parece óbvio, mas muitas vezes deixamos os
riscos que a princípio nos parecem simples passar despercebidos.
Por isso, depois que o Planejamento tiver sido concluído, o próximo passo é identificarmos os riscos que
podem afetar os objetivos do projeto. Devemos sempre ter em mente que é impossível identificar todos os
riscos de uma só vez, já que à medida que o tempo passa e o projeto evolui novos riscos podem aparecer e
riscos anteriormente identificados deixam de existir.
Os riscos identificados devem ser listados e servirão de entrada para os demais processos desta área de
conhecimento.
É muito importante lembrar, que todos os processos do gerenciamento de riscos devem ser repetidos ao
longo do ciclo de vida de projeto já que novos riscos podem surgir.
O processo
Entradas
São inúmeras as entradas deste processo, mas não é para menos, uma vez que praticamente todas as áreas
de conhecimento podem gerar riscos para o projeto.
Praticamente todas as áreas de conhecimento são afetadas pelos riscos, então todos os planos auxiliares do
plano de gerenciamento do projeto devem ser aqui considerados.
Por exemplo, caso haja necessidade da presença de um recurso altamente especializado em determinada
data, deve-se considerar que se esse recurso não estiver disponível isso poderá acrescentar riscos ao projeto.
Veja que a informação do recurso especializado vem do plano de gerenciamento de recursos e do plano de
gerenciamento do cronograma.
Assim, os planos são: plano de gerenciamento dos requisitos, plano de gerenciamento do cronograma,
plano de gerenciamento dos custos, plano de gerenciamento da qualidade, plano de gerenciamento dos
recursos, o próprio plano de gerenciamento dos riscos, e as linhas de base do escopo, cronograma e custo.
Documentos do Projeto
Praticamente todos os documentos do projeto precisam ser avaliados criticamente para se verificar se há
algum possível risco indicado. Entre os documentos temos:
• Estimativas de custos das atividades: tais estimativas fornecem uma avaliação do custo provável para
concluir as atividades programadas e muitas vezes indicam também um intervalo que mostra o grau
de risco. Quanto maior o intervalo, maior o risco. Por exemplo, há uma chance de 80% do projeto ser
concluído dentro do custo programado. Ou há uma variação prevista de 10% positiva e negativamente
nos custos orçados. Tais variações devem ser consideradas como possíveis riscos ao projeto.
• Estimativas de duração: estas estimativas funcionam da mesma forma que as estimativas de custo das
atividades. Elas fornecem a previsão de tempo para a execução das atividades e por consequência a
duração total do projeto, podendo incluir intervalos de risco. Quanto maior o intervalo, maior o risco.
Por exemplo, há uma chance de 10% do projeto não ser concluído no prazo previsto.
• Registros das partes interessadas: esse documento é importante, pois garante que os principais
interessados no projeto sejam entrevistados e participem da identificação dos riscos.
Acordos e documentação de aquisição

Ainda não vimos essa área de conhecimento, mas mesmo assim não é difícil perceber que caso o projeto
necessite de aquisições externas (compra de equipamentos, terceirização de mão de obra etc) riscos serão
acrescentados ao projeto.
Por exemplo, imagine a construção de um pequeno edifício de três andares. Se o fornecedor do misturador
de cimento atrasar a entrega, toda a construção atrasará.

caso, os fatores mais importantes são: informações publicadas, bancos de dados, estudos acadêmicos, listas de
verificação, benchmarking entre outras.

caso, podemos considerar como importantes os seguintes ativos: arquivos de outros projetos, controles
organizacionais e de processos, modelos de declaração de riscos e lições aprendidas.
Os riscos podem ser identificados diretamente por especialistas com experiência relevante em projetos
ou áreas de negócios semelhantes. Esses especialistas devem ser identificados pelo gerente e convidados
a considerar todos os aspectos do projeto, além de sugerir os riscos possíveis com base na sua experiência
anterior e nas áreas de especialização.
Coleta de dados
O Guia PMBOK® cita várias técnicas que podem ser utilizadas para coletar informações:
Brainstorming
É uma técnica utilizada em reuniões onde uma ideia pode ajudar a gerar outras ideias sobre o mesmo tema.
Nenhuma das ideias propostas deve ser descartada ou julgada como errada/absurda. O objetivo é gerar uma
lista completa dos riscos do projeto.
• Desvantagens: caso não haja um facilitador experiente, a reunião pode acabar sendo “dominada” pela
gerência. Ou seja, os funcionários ficam receosos de dar suas ideias e serem ridicularizados por seus
chefes.
• Requisitos: é necessária a participação de um grupo representativo de Partes interessadas. Deve ser

liderado por um facilitador experiente e uma Estrutura Analítica de Riscos deve ser usada.
Listas de verificação
Essas listas são geradas durante o planejamento do gerenciamento dos riscos, com base em informações
históricas, lições aprendidas e entrevistas com especialistas. O nível mais baixo da EAR (RBS) pode ser usado
como uma lista de verificação de riscos
• Vantagens: captura experiências anteriores e gera uma lista detalhada de riscos.
• Desvantagens: a lista pode ficar tão longa que será impossível gerenciá-la. Riscos não indicados na lista
podem ser ignorados. Muitas vezes só são incluídas as ameaças e as oportunidades são esquecidas.
• Requisitos: revisão regular da lista e o uso da EAR são essenciais.
Entrevistas
Consiste em entrevistar os participantes e especialistas na área em que o projeto irá ser desenvolvido.
• Vantagens: endereça riscos em detalhes e gera comprometimento de todos os entrevistados.
• Desvantagens: consome muito tempo, pois as entrevistas normalmente são individuais. Pode trazer
à tona receios e preocupações não ligados ao projeto, o que requer do facilitador a filtragem das
informações.
• Requisitos: o facilitador precisa ter habilidades de comunicação para conduzi-la de forma satisfatória.
Deve existir um ambiente de confiança e abertura. Tanto entrevistador e entrevistado devem confiar
um no outro.
Análise de dados
Análise da causa raiz
Também conhecida como RCA (Root Cause Analysis) é uma maneira de identificar as causas de um
problema, afinal os problemas são melhor resolvidos ao tentar corrigir ou eliminar as suas causas. Ao analisar
um problema, é importante levá-lo até o maior nível de detalhamento possível para descobrir a sua causa
primária. Existem diversas técnicas para a análise da causa raiz, no entanto a técnica dos “cinco por quês” é uma
das mais simples de ser aplicada.
Exemplo:
Você é encontrado dormindo em plena 2ª feira às 11 horas da manhã. Aí, sua esposa (ou mãe) iniciam o
“interrogatório” para chegar à causa raiz de tal “irresponsabilidade”:
Por que você não foi trabalhar? – Porque o carro está sem gasolina
Por que o carro está sem gasolina? – Porque eu não o abasteci ontem
Por que você não o abasteceu hoje cedo? – Porque estou sem dinheiro
Por que você está sem dinheiro? – Porque gastei tudo ontem à noite com cerveja
Porque você gastou tudo ontem à noite com cerveja??? – Porque estava deprimido por ter sido demitido
Observe que com essa série de perguntas conseguimos chegar à causa raiz do problema, embora ela tenha
sido “camuflada” nas primeiras respostas. Na prática não será necessário passar pelos 5 por quês, o importante
é chegarmos à causa raiz.
• Vantagens: permite identificar riscos adicionais e dependentes uns dos outros. Permite a identificação de
riscos inter-relacionados em decorrência das causas raiz em comum. É a base para o desenvolvimento de
respostas aos riscos identificados. Serve para reduzir a complexidade da informação ou para investigar
causas “camufladas”.
• Desvantagens: muitas vezes os riscos são individuais, ou seja, o próprio risco é sua causa raiz, o que
pode gerar confusão ao usarmos essa série de questionamentos.
• Requisitos: a gerência da organização precisa se comprometer a tratar a causa raiz e não somente adotar
medidas paliativas. Deve-se ter a habilidade para perceber que o risco é causado por algo não passível
de ser identificado imediatamente.
Análise das premissas e restrições
Todos os projetos são concebidos baseados em uma série de hipóteses (premissas) que devem ser satisfeitas
e restrições que o limitam. Analisar quais premissas foram utilizadas no projeto e quais as suas restrições nos
ajudam a encontrar possíveis riscos.
• Vantagens: é uma abordagem estruturada e simples, pois utiliza informações já listadas no termo de
abertura do projeto e na especificação de escopo. Por exemplo, se temos uma restrição de orçamento,
um risco a ser documentado é que o custo não deve ultrapassar o valor listado.
• Desvantagens: nem todas as premissas e/ou restrições são listadas. Muitas vezes só as descobrimos a
medida que o projeto evolui.
• Requisitos: para se usar esta técnica, precisamos que o termo de abertura e a especificação do escopo
indiquem as premissas e restrições do projeto.
Roteiro para construção:
1. Faça uma lista das premissas e restrições do projeto (você pode encontrá-los no termo de abertura do
projeto e na especificação de escopo).
2. Teste cada premissa e restrição fazendo as seguintes perguntas:
3. Esta premissa/restrição pode ser falsa?

• Se for falsa, um ou mais objetivos do projeto serão afetados?
• Se a resposta às duas questões foi “Sim”, um risco acaba de ser encontrado.
Por exemplo, considere que temos em um projeto a premissa que teremos atendimento 24x7 do suporte
de um determinado equipamento. Vamos agora executar os 3 passos:
1. A premissa “atendimento 24x7” pode ser falsa? -> Sim, pois verificamos com o fornecedor que o suporte
só atende em horário comercial.
2. Sendo falsa a premissa, haverá algum impacto no objetivo “data de entrega do projeto em 05/março”?
-> Sim, pois como iremos trabalhar em 3 turnos, caso tenhamos algum problema com o equipamento no
período noturno o desenvolvimento do projeto irá parar e por consequência o projeto poderá atrasar.
3. Encontramos um risco, pois as duas respostas foram “Sim”. Como o cronograma foi provavelmente
calculado considerando-se que o suporte estaria disponível 24x7 e descobrimos que isso não é verdade,
acabamos de identificar um possível risco de atraso na entrega do projeto.
Análise de Forças, Oportunidades, Fraquezas e Ameaças
Esta técnica é comumente usada para a tomada de decisão. E pode ser adaptada para a identificação dos
riscos da seguinte forma:
• Strenghts (Forças): vantagens internas da empresa que está conduzindo o projeto.
• Weaknesses (Fraquezas): desvantagens internas da empresa que está conduzindo o projeto.
• Opportunities (Oportunidades): aspectos positivos que podem influenciar o projeto.
• Threats (Ameaças): aspectos negativos que podem influenciar o projeto.
Ajuda Atrapalha
S W
Organização
que conduz o (Forças – Strengths) (Fraquezas – Weaknesses)
projeto
Padronização do trabalho Necessidade de treinamento
Redução de riscos do projeto Dificuldade de implantação nos 1os
Ganhos em produtividade projetos
O T
Fatores que
afetam o (Oportunidades – Opportunities) (Ameaças – Threats)
projeto
Acesso às melhores práticas Custos de implantação
Uso de modelos e ferramentas Não aceitação
• Vantagens: garante foco igual tanto para às ameaças quanto para as oportunidades.
• Desvantagens: tende a gerar riscos de alto-nível muitas vezes não ligados ao projeto.
• Requisitos: é necessária a presença de um bom facilitador para organizar as ideias e conduzir a reuniões.
Uso consistente da ferramenta (não confundir forças com oportunidades e fraquezas com ameaças).
Revisões de documentação
Já que muitas entradas deste processo são documentos, nada mais lógico do que considerar que todos
esses documentos serão revistos e analisados.
Outras ferramentas
Estas ferramentas não são citadas no Guia PMBOK®, mas são usadas para para a identificação de riscos:
Diagrama de causa e efeito
É também conhecido como diagrama de Ishikawa, ou ainda, espinha de peixe. É uma adaptação feita para
área de gestão de riscos, com o objetivo de identificar os fatores facilitadores, ou seja, as causas dos possíveis
riscos.
• Vantagens: a representação visual do projeto promove o pensamento estruturado.
• Desvantagens: o diagrama pode facilmente se tornar complexo.
• Requisitos: a seleção dos itens que compõem o diagrama deve ser criteriosa para não “entulhar” demais
o diagrama.
Os componentes do diagrama são:
• Efeito: Contém o problema que se quer descobrir a possível causa. Usualmente desenhado do lado
direito da folha.
• Eixo central: Uma flecha horizontal, apontando para o efeito. Usualmente desenhada no meio da folha.
• Categoria: representa os principais grupos de fatores relacionados com o efeito. A categoria é desenhada
em um retângulo com uma flecha saindo dele e convergindo para o eixo central.
• Causa: Causa potencial, dentro de uma categoria que pode contribuir com o efeito. As flechas são
desenhadas em linhas horizontais, apontando para o ramo de categoria.
Possíveis
causas
RH Custos
Recursos alocados Efeito
incorretamente
Orçamento insuficiente
Estimativa de custo
equivocada
Treinamento deficiente Aumento no valor
do dólar
Projeto atrasado
“Scope creep”
Estimativa de tempo
equivocada
Atraso
Requisitos incorretos
fornecedores
Escopo Tempo
Categorias
Fluxograma
O fluxograma é um tipo de diagrama, e pode ser entendido como uma representação esquemática de um
processo, muitas vezes construído através de figuras geométricas que ilustram de forma fácil a transição de
informações entre os elementos que o compõem. É uma das Sete Ferramentas da Qualidade e é muito utilizada
Vimos em detalhes esta ferramentano no capítulo referente ao planejamento da qualidade, por isso o que
é importante frisar é que a avaliação visual do fluxo do processo permite a identificação de possíveis riscos em
cada uma de suas etapas.
Diagramas de influência
Este diagrama é uma forma simples de representar situações de decisão. Os diferentes elementos são
exibidos por meio de figuras geométricas diferentes, ligadas por meio de flechas, cuja direção especifica a forma
com que se dá o relacionamento entre os diferentes elementos.
Retângulos representam decisões, elipses representam incertezas e losangos representam os resultados ou

consequências. Um retângulo de pontas arredondadas é utilizado para representar um cálculo matemático ou
um valor constante. Essas quatro formas geralmente são chamadas de “nós” e são conectadas por flechas. Na
figura a seguir mostramos um exemplo do diagrama. Observe que as cores do diagrama são apenas para melhor
visualização dos itens que o compõem.
Preço
Market Share Recebimentos
Volume
produção
Capacidade
de produção
CAPEX Rentabilidade
Desenvolver novo Tamanho do
produto? mercado
Inflação
OPEX
Eficiência
produção
• Vantagens: mostra riscos-chave. Permite gerar “insights” que com outras técnicas não são possíveis.
• Desvantagens: requer pensamento disciplinado. Nem sempre é simples de determinar a estrutura

apropriada.
• Requisitos: áreas-chave precisam ser bem identificadas.

Entre as habilidades interpessoais e de equipe que podem ser usadas, o Guia PMBOK sugere a facilitação,
conhecida também pelo nome de workshops e oficinas facilitadas. Elas são preparadas de forma que os
integrantes de diferentes áreas participem ativamente na identificação dos riscos. Como o próprio nome sugere,
essas oficinas são coordenadas por um facilitador.
Listas de alertas
Essas listas são coletâneas de itens pré-determinados que ajudam na identificação de categorias de riscos
que podem ser considerados no projeto. Dessa forma, a equipe tem um ponto de partida para começar a
identificação dos riscos.
Modelo PESTEL
Esse modelo, um acrônimo de Political, Economic, Social-Cultural, Technological, Environmental and Legal,
é uma matriz que indica fatores externos à organização que podem afetá-la de forma positiva ou negativa. Os
membros do time de gerenciamento verificam cada um dos fatores e passam a identificar os riscos ligados a
cada um deles.
Modelo VUCA
Esse termo surgiu na década de 90, e é derivado de um vocabulário militar. Com o passar do tempo, ele foi
sendo aplicado em outras situações, tais como na liderança estratégica e nas organizações.
Entender cada um dos elementos da VUCA ajuda a ampliar a visão e percepção estratégica do ambiente em
que se encontra, além de auxiliar na gestão de riscos. Então vamos ao entendimento da VUCA.
• V, de Volatilidade: basicamente mostra que tudo muda o tempo todo, em uma velocidade que não
controlamos, e com um impacto que desconhecemos. No ambiente corporativo, é preciso se preparar
para as mudanças e, nesse sentido, quanto mais informações você tiver, mais munido você estará.
• U, de Uncertainty (incerteza para o português): significa não saber o vem depois, é a surpresa e a
imprevisibilidade das coisas – é preciso saber liderar com o inesperado. Nesse contexto, as diferentes
opiniões e pontos de vista influenciam no momento da análise e na tomada de decisão.
• C, de Complexidade: afirma que nada é tão simples quanto parece, então é preciso explorar cada vez
mais. Tudo está cada vez mais relacionado, e é difícil saber o que estimula determinados resultados. A
interdependência torna o mundo mais complexo.
• A, de Ambiguidade: mostra que há diversas e possíveis interpretações para a mesma coisa, que a
realidade pode ser deturpada, e que os significados têm mais de um sentido. Assim, as decisões tomadas
podem conter riscos e implicações.
Reuniões
São nas reuniões que os riscos serão inicialmente identificados. Workshops facilitados em combinação com
a técnica de brainstorming são os ideais para a identificação dos riscos.
Saídas
Registro dos riscos
O registro dos riscos é o documento no qual a maioria das informações dos riscos é guardada. Este documento
começa a ser elaborado no processo de identificação dos riscos e é atualizado pelos outros processos de riscos
durante o desenrolar do projeto. O registro de riscos neste processo costuma ter as seguintes informações:
• Número identificador: identificador do risco;
• Ameaça ou oportunidade: Identificação de se é ameaça ou oportunidade;
• Evento de risco: é a descrição do risco;
• Categoria: classificação dos riscos (escopo, custo, qualidade etc);
• Causa raiz: quais as possíveis causas raiz: esta informação será importante quando elaborarmos as
respostas aos riscos;
• Dono do risco: é a pessoa responsável por acompanhar o risco;
• Lista de possíveis respostas: muitas vezes durante a execução da identificação dos riscos, algumas
possíveis respostas já são identificadas e então, já devem compor a lista.
Relatório de riscos
Este relatório é criado neste processo e segue sendo completado e aprimorado ao longo de todos os
processos de gerenciamento de riscos. É um relatório resumo dos riscos gerais do projeto. Assim, ele deverá
indicar as fontes de risco geral do projeto e um resumo sobre os riscos individuais identificados.
Atualizações de documentos do projeto

Como em todos os processos de planejamento, pode ser que existam alterações a serem realizadas em seus
documentos. Entre eles estão os registros das premissas, registro das questões e registro das lições aprendidas.
Realizar a análise qualitativa dos riscos (11.3)
Avaliar riscos usando a análise qualitativa estima a probabilidade de cada risco individual ocorrer e o seu
impacto nos objetivos do projeto. Observe que esta análise se concentra em cada risco individual e não nos
resultados da combinação entre eles.
Por exemplo, podemos ter o risco de atrasar o cronograma em virtude de greves no transporte público,
problemas climáticos (inundações), falta de treinamento dos recursos, realocação dos recursos em outro
projetos etc. A análise qualitativa irá indicar em ordem crescente (ou decrescente) quais desses riscos são mais
críticos para o projeto. No entanto não teremos o valor estimado do impacto da combinação de todos esses
riscos juntos. Será na análise quantitativa que poderemos ter esse resultado.
O principal benefício deste processo é que ele permite ao gerente do projeto reduzir o nível de incerteza
bem como focar em riscos de alta prioridade, já que dependendo da complexidade do projeto, é impossível
gerenciar todos os riscos.
A análise qualitativa de riscos é normalmente uma maneira rápida e econômica de estabelecer

prioridades para o planejamento de respostas a riscos, e estabelece a base para a análise quantitativa de
riscos, se esta for necessária.
De forma a ficar claro como a análise qualitativa é executada, mostramos um fluxo com os passos a serem
executados na figura a seguir:
Coletar e analisar Categorizar as Documentar

Priorizar riscos
dados causas dos riscos resultados
• Coletar e analisar dados: a avaliação dos riscos individuais depende da informação coletada a respeito
deles. É muito importante que a informação coletada esteja livre de preconceitos e receios não racionais.
• Priorizar riscos: os riscos deverão ser avaliados de acordo com a sua probabilidade de ocorrência e seu
impacto nos objetivos do projeto. Quanto mais prováveis e quanto maior o impacto, mais graves.
• Categorizar as causas dos riscos: os riscos podem ser categorizados por causas (fontes) de risco (a partir
da EAR), pela área do projeto afetada (a partir da EAP) ou por outra categoria útil para determinar as
áreas do projeto mais expostas aos efeitos da incerteza. O agrupamento dos riscos por causas raiz pode
possibilitar o desenvolvimento de respostas a riscos eficazes.
• Documentar resultados: o registro dos riscos será atualizado com as informações geradas por este
processo.
O processo
Entradas
Desse plano usaremos o plano de gerenciamento de riscos que como já vimos no capítulo anterior é o
documento que indica como os riscos serão identificados, gerenciados, controlados e tratados. Neste processo,
as principais informações que retiramos desse plano são: funções, responsabilidades, orçamentos e atividades
do cronograma para gerenciamento de riscos, categorias de risco, definição de probabilidade e impacto, matriz
de probabilidade e impacto e revisão das tolerâncias a risco das partes interessadas.
• Registro das premissas: neste documento estão as premissas que devem ser consideradas no projeto.
Lembre-se que premissas acrescentam riscos ao projeto, pois caso elas não se realizem podem prejudicar
o andamento do projeto.
• Registro dos riscos: O registro dos riscos é a saída do processo anterior, e conforme mencionamos ele
será progressivamente elaborado ao longo dos processos de planejamento do gerenciamento de riscos.
Neste ponto, o registro contém a lista dos riscos identificados.
• Registro das partes interessadas: além de indicar as partes interessadas responsáveis pelos riscos, este
registro pode indicar quais as partes interessadas que podem oferecer maior resistência ao projeto,
bem como aquelas que podem apoiá-lo integralmente.

Observe que mais uma vez temos os fatores ambientais da empresa como entrada de um processo. Neste
caso, os fatores mais importantes são: estudos do setor de projetos semelhantes e bancos de dados de riscos.

Aqui o Guia PMBOK® cita como ativos importantes as informações de projetos semelhantes concluídos
anteriormente, ou seja, Lições aprendidas, registro dos riscos de projetos anteriores etc.
Mais uma vez a opinião especializada é citada. Neste caso a ideia é recorrer a indivíduos que tenham
experiência com riscos em projetos semelhantes e recentes. Esses especialistas auxiliam na avaliação da
probabilidade e impacto de cada risco a fim de determinar sua localização na matriz de probabilidade e impacto
que veremos na sequência.
Coleta de dados
Várias técnicas de coleta de dados podem ser usadas neste processo. A mais comum é a entrevista, onde
o entrevistador verifica com os especialistas quais os possíveis riscos individuais que podem ocorrer durante o
projeto.
Análise de dados
Avaliação da probabilidade e impacto
A avaliação da probabilidade investiga a chance de cada risco ocorrer. Já a avaliação do impacto investiga
o efeito potencial sobre um objetivo do projeto. A probabilidade e o impacto são avaliados para cada risco
identificado utilizando-se técnicas de coleta de informações, tais como entrevistas, reuniões com especialistas,
brainstorming etc. Já vimos anteriormente exemplos de matrizes de probabilidade e de impacto. Na tabela a
seguir apresentamos um novo exemplo de matriz combinada com probabilidades e impactos.
Impacto nos objetivos do projeto
Escala Probabilidade Tempo Custo
Qualidade
(em dias) (em milhares)
Muito alto 61-99% > 40 > 200 Impacto muito significativo na
funcionalidade geral
Alto 41-60% 21-40 101-200 Impacto significativo na funcionalidade
geral
Médio 21-40% 11-20 51-101 Algum impacto em áreas chaves
Baixo 11-20% 6-10 11-50 Pequeno impacto nas funcionalidades
Muito Baixo 1-10% 1-5 1-10 Impacto mínimo nas funcionalidades
Nulo < 1% Sem alteração Sem alteração Nenhuma alteração nas funcionalidades
Exemplo: Durante uma sessão de brainstorming chegou-se ao consenso de que a probabilidade de um

risco “X” ocorrer ficaria entre 50 e 55%. Assim se em nosso projeto estivermos usando a tabela anterior
classificaríamos o risco como “Alto”. Nessa mesma reunião, chegou-se também ao consenso de que o impacto
no objetivo “Tempo” seria de apenas 5 dias. Usando a mesma tabela, teríamos que o impacto do risco “X” seria
“Muito baixo”. Assim, nosso risco “X” fica classificado:
• Probabilidade -> Alta;
• Impacto -> Muito baixo.
É importante que ao determinar o valor da probabilidade ou do impacto os avaliadores justifiquem porque

chegaram aos valores acordados. Valores aleatórios sem justificativa plausível só prejudica o processo de
gerenciamento de riscos.
Às vezes, os riscos com probabilidade e impacto visivelmente baixos não serão classificados, mas serão
incluídos em uma lista à parte de observação para monitoramento futuro.
Avaliação da qualidade dos dados sobre riscos
Uma análise qualitativa de riscos exige dados exatos e imparciais para ser confiável. A avaliação da
qualidade dos dados sobre riscos é uma técnica para analisar o grau de utilidade dos dados sobre riscos para
o seu gerenciamento. Ela envolve examinar até que ponto o risco é entendido, a sua exatidão, qualidade,
confiabilidade e integridade.
O uso de dados de baixa qualidade pode levar a uma análise qualitativa de riscos de pouca utilidade para o
projeto.
Outros parâmetros de avaliação
Existem outras características que podem ser consideradas ao se avaliar os riscos:
• Urgência: Alguns riscos não tão graves podem necessitar de uma resposta urgente, pois caso percam
os prazos podem se tornar mais graves. Indicadores de urgência devem ser considerados como gatilhos
para a execução de uma resposta ao risco. Exemplo: um risco que afeta positivamente alguns tipos de
projeto são as épocas de descontos em móveis. Se você tiver uma empresa que trabalhe com projetos
de decoração, essa época do ano deverá ser considerada como uma oportunidade que não pode ser
esquecida.
• Proximidade: esta característica está relacionada ao tempo, ou seja, prazos curtos.
• Dormência: é o período entre a ocorrência do risco e o seu impacto. É como uma rachadura em uma
barragem. Mais cedo ou mais tarde, ela pode causar uma inundação.
• Gerenciabilidade: É a facilidade para se gerenciar a ocorrência ou o impacto. Existem riscos ingerenciáveis,

tais como: novas regulamentações, fenômenos naturais etc. O que se pode nestes casos é gerenciar o
impacto.
• Capacidade de controle: Normalmente existe a possibilidade de se controlar o impacto de um risco caso

ele venha a se concretizar. No entanto, essa capacidade pode variar. Por exemplo, houve uma época em
que os bingos eram liberados no país. A partir do momento em que foram proibidos, não houve como
evitar o grande impacto que isso causou nos donos desses estabelecimentos - que foram obrigados a
fechá-los em questões de horas e demitir todo o pessoal contratado.
• Capacidade de detecção: grande parte dos riscos dá sinais de aviso de que vai acontecer. A habilidade a
ser desenvolvida é perceber tais avisos antes que efetivamente se concretizem.
• Conectividade: alguns riscos acontecem e propagam seus efeitos gerando outros riscos e causando
ainda mais estrago.
• Impacto estratégico: um risco pode afetar as metas estratégicas da organização. Por exemplo, a explosão
da plataforma Deepwater Horizon no Golfo do México em 2010 que matou 10 funcionários e prejudicou
o ecossistema da região por anos seguidos - quase levou à falência a Britisth Petroleum. O impacto foi
tão grande que a empresa teve que mudar de nome para BP de forma a não ser mais reconhecida como
a empresa irresponsável que praticamente destruiu a vida marinha do Golfo do México.
• Percepção: esta é a forma como as partes interessadas percebem o risco. Pessoas diferentes tem
percepções diferentes com relação ao risco.

Aqui as habilidades de facilitação podem ajudar na captura de informações precisas para a análise qualitativa
de dados.
Categorização de riscos
A categorização de riscos ajuda na otimização dos esforços, principalmente, relacionados aos planos de
respostas, pois é possível ter uma única resposta para dois ou mais riscos relacionados.
Durante a elaboração do plano de gerenciamento de riscos, foram definidas categorias de risco. É neste
ponto do processo que cada risco identificado será categorizado.
Matriz de probabilidade e impacto
A identificação dos riscos produz uma lista de riscos que deve ser priorizada a fim de determinar quais
riscos devem ser enfrentados antes. Uma das técnicas mais comuns para a priorização de riscos é a matriz
de probabilidades e impacto (PxI). Tal matriz concentra-se em priorizar riscos individuais, produzindo listas
ranqueadas.
Exemplo: A empresa BetaSucos S.A. está desenvolvendo um projeto para instalação de uma nova máquina
que realizará as misturas e o engarrafamento das bebidas. O gerente do projeto organizou uma reunião de
brainstorming com a participação da equipe de gerenciamento do projeto e das principais Partes interessadas
para que fosse realizada a Análise qualitativa de três riscos identificados pelo processo Identificar Riscos:
• Incompatibilidade na instalação elétrica
• Indisponibilidade de pessoal técnico
• Área do galpão não liberada a tempo
Foram usadas como referência para o estabelecimento dos valores de probabilidade e impacto as tabelas
indicadas a seguir:
Escala de Probabilidade
Avaliação Qualitativa Desprezível Baixo Moderado Alto Muito Alto
Probabilidade 5% 10% 20% 40% 80%
Tabela de Impactos:
Escala de Impacto
Objetivo do Desprezível Baixo Moderado Alto Muito Alto
Projeto 0.05 0.1 0.2 0.4 0.8
Custo Aumento Até 15% de Entre 15% Entre 30% Acima de
insignificante aumento e 30% de e 40% de 40% de
do custo do aumento aumento aumento
projeto
Cronograma Atraso Até 15% de Entre 15% e Entre 30% Acima de
insignificante atraso 30% de atraso e 40% de 40% de
atraso atraso
Escopo Redução do Áreas Áreas Redução Produto
escopo não menos importantes do escopo final é inútil
perceptível importantes do escopo inaceitável
do escopo são afetadas
são afetadas
Qualidade Degradação Apenas Redução de Redução de Produto
de qualidade implicações qualidade qualidade final não é
não mais críticas requer inaceitável utilizável
perceptível são afetadas aprovação do pelo cliente
cliente
Após as análises, chegou-se ao consenso de que os riscos teriam a seguinte distribuição de probabilidades
e impactos:
Descrição do risco Prob. Impacto
Incompatibilidade na instalação elétrica 0,4 0,8
Área do galpão não liberada a tempo 0,1 0,4
Indisponibilidade de pessoal técnico 0,2 0,4
Como a análise qualitativa de riscos gera uma lista de risco por ordem de gravidade, o gerente do projeto
sugeriu o uso da tabela a seguir indicada no Plano de gerenciamento de riscos para a elaboração do ranking.
Probabilidade AMEAÇAS OPORTUNIDADES
0.8 0.04 0.08 0.16 0.32 0.64 0.64 0.32 0.16 0.08 0.04
0.4 0.02 0.04 0.08 0.16 0.32 0.32 0.16 0.08 0.04 0.02
0.2 0.01 0.02 0.04 0.08 0.16 0.16 0.08 0.04 0.02 0.01
0.1 0.005 0.01 0.02 0.04 0.08 0.08 0.04 0.02 0.01 0.005
0.05 0.0025 0.005 0.01 0.02 0.04 0.04 0.02 0.01 0.005 0.0025
Impacto => 0.05 0.1 0.2 0.4 0.8 0.8 0.4 0.2 0.1 0.05
Para o 1º risco identificado temos que a probabilidade é 0,4 (40%) e o Impacto é 0,8(80%). Lançando esses
valores na tabela PxI chegamos ao resultado de 0,32 (32%).
Ao lançarmos os demais valores de probabilidade e impacto obtemos o seguinte ranking dos riscos
priorizados:
Descrição do risco Prob Impacto Total Ranking
Incompatibilidade na instalação elétrica 0,4 0,8 0,32 1º
Indisponibilidade de pessoal técnico 0,2 0,4 0,08 2º
Área do galpão não liberada a tempo 0,1 0,4 0,04 3º
Observe que os riscos marcados em vermelho devem ter atenção total, os em amarelo devem ser
acompanhados de perto e os em branco são riscos que podem ficar em uma lista à parte (lista de acompanhamento)
e serem verificados regularmente. Jamais deixe de acompanhar os riscos, pois eles podem mudar com o tempo.
Gráficos hierárquicos
Quando consideramos mais do que duas dimensões, a matriz de probabilidade x impacto não pode ser
usada. Dessa forma, outros tipos de gráficos podem ser usados. Neste exemplo, os eixos representam o impacto
e a probabilidade e as bolhas os impactos de cada risco.
Reuniões
São nas reuniões que as análises dos riscos individuais são feitos. De forma geral, é feito o seguinte:
Coletar e analisar Categorizar as Documentar

Priorizar riscos
dados causas dos riscos resultados
• Coletar e analisar dados: a avaliação dos riscos individuais depende da informação coletada a respeito
deles. É muito importante que a informação coletada esteja livre de preconceitos e receios não racionais.
• Priorizar riscos: os riscos deverão ser avaliados de acordo com a sua probabilidade de ocorrência e seu
impacto nos objetivos do projeto. Quanto mais prováveis e quanto maior o impacto, mais graves.
• Categorizar as causas dos riscos: os riscos podem ser categorizados por causas (fontes) de risco (a partir
da EAR), pela área do projeto afetada (a partir da EAP) ou por outra categoria útil para determinar as
áreas do projeto mais expostas aos efeitos da incerteza. O agrupamento dos riscos por causas raiz pode
possibilitar o desenvolvimento de respostas a riscos eficazes.
• Documentar resultados: o registro dos riscos será atualizado com as informações geradas por este
processo.
Saídas
Atualizações de documentos do projeto
Como em todos os processos de planejamento, pode ser que existam alterações a serem realizadas em
seus documentos. Entre eles estão os registros das premissas, registro das questões, relatórios de riscos e em
especial o:
• Registro dos riscos: O registro de riscos será atualizado novamente e desta vez conterá as seguintes
informações:
ДД A classificação relativa ou a lista de prioridades dos riscos do projeto: com a lista de riscos priorizados
o gerente de projetos pode se concentrar nos itens de alta importância para o projeto.
ДД Lista de riscos para análise e resposta adicionais: alguns riscos podem justificar análises adicionais,
inclusive a análise quantitativa de riscos, além de ação de resposta.
ДД Listas de observação de riscos de baixa prioridade: os riscos não avaliados como importantes no
processo de análise qualitativa de riscos podem ser colocados em uma lista de observação para serem
monitorados continuamente.
Realizar a análise quantitativa dos riscos (11.4)
A análise quantitativa de riscos é realizada nos riscos que foram priorizados pelo processo anterior e que
tenham probabilidade e impacto altos nas demandas concorrente do projeto. A principal diferença entre esta
análise e a análise qualitativa é que na análise qualitativa os riscos são vistos individualmente e não produzem
medições dos valores totais do impacto quando todos os riscos são vistos simultaneamente. O cálculo de
estimativas de valores totais de impacto é o foco da análise quantitativa. Observe que esta avaliação é mais
sofisticada que a análise qualitativa e requer conhecimento especializado tanto do gerente quando da equipe
que a executará.
Análise qualitativa de riscos Análise quantitativa de riscos
Endereça riscos individuais Faz previsões dos resultados do projeto
baseadas nos efeitos combinados dos riscos
Avalia probabilidades discretas de ocorrência Usa distribuição de probabilidades para
e impacto nos objetivos caso ocorram caracterizar probabilidade e impacto
Normalmente usa opinião de especialistas Usa métodos quantitativos que requerem
ferramentas especializadas
Prioriza riscos individuais para posterior Utiliza os riscos priorizados em cálculos mais
tratamento específicos
Em geral, a análise quantitativa de riscos é executada após a análise qualitativa, embora gerentes de
riscos experientes possam executá-la diretamente após a identificação dos riscos. Em alguns casos, a análise
quantitativa de riscos pode não ser necessária para desenvolver respostas a riscos eficazes.
De forma a ficar claro como a análise quantitativa é executada, mostramos um fluxo com os passos a serem
Selecionar Riscos Coletar e analisar Documentar

Priorizados dados resultados
• Selecionar riscos priorizados: nem todos os riscos priorizados na análise qualitativa deverão passar pela
análise quantitativa. Por exemplo, podemos definir que riscos que tenham resultados de probabilidade
x impacto (PxI) com valores muito altos devem passar obrigatoriamente pela análise quantitativa,
enquanto riscos com resultados (PXI) muito baixos deverão ser aceitos passivamente, pois o custo para o
seu tratamento é superior ao dano provocado ao projeto.
• Coletar e analisar dados: esta análise depende da informação coletada a respeito deles. É muito
importante que a informação coletada esteja livre de preconceitos e receios não racionais.
• Documentar resultados: o registro de riscos será atualizado com as informações geradas por este
processo.
O processo
Entradas
• Plano de gerenciamento de riscos: os principais elementos do plano de gerenciamento de riscos para
a análise quantitativa de riscos incluem funções e responsabilidades para realizar esse gerenciamento,
orçamentos e atividades do cronograma, categorias de risco, a EAR e revisão das tolerâncias a risco das
partes interessadas.
• Linhas de base do escopo, cronograma e custo: as linhas de base fornecem dados sobre os riscos
individuais que servem de insumo para os cálculos dos riscos gerais do projeto.
Documentos do Projeto
algum possível risco indicado. Entre eles temos:
• Registro das premissas: neste documento estão as premissas que devem ser consideradas no projeto.
Lembre-se que premissas acrescentam riscos ao projeto, pois caso elas não se realizem podem prejudicar
o andamento do projeto.
• Base das estimativas: a base das estimativas pode afetar a modelagem dos cálculos a serem realizados
por este processo.
• Estimativas e previsões de custos: tais estimativas fornecem uma avaliação do custo provável para
concluir as atividades programadas e muitas vezes indicam também um intervalo que nostra o grau
de risco. Quanto maior o intervalo, maior o risco. Por exemplo, há uma chance de 80% do projeto ser
concluído dentro do custo programado. Ou há uma variação prevista de 10% positiva e negativamente
nos custos orçados. Tais variações devem ser consideradas como possíveis riscos ao projeto.
• Estimativas de duração: estas estimativas funcionam da mesma forma que as estimativas de custo das
atividades. Elas fornecem a provisão de tempo para a execução das atividades e por consequência a
duração total do projeto, podendo incluir intervalos de risco. Quanto maior o intervalo, maior o risco.
Por exemplo, há uma chance de 10% do projeto não ser concluído no prazo previsto.
• Lista de marcos: os marcos do projeto definem metas a serem alcançadas e servem como ponto de
controle para os cálculos de riscos relacionados ao cronograma.
• Requisitos de recursos: fornecem um ponto de partida do qual a variabilidade a ser calculada é avaliada.
• Relatórios de riscos: estes relatórios descrevem a fonte geral dos riscos bem como o status atual do
projeto.
• Previsões do cronograma: estas previsões podem ser comparadas aos resultados dos cálculos da análise
quantitativa para que verifique se será possível alcançar as metas estabelecidas.


anteriormente, ou seja, lições aprendidas e o registro dos riscos desses projetos.
Ferramentas
Os especialistas no assunto, internos ou externos à organização validam os dados e as técnicas usadas
neste processo. Eles são necessários para identificar os impactos potenciais no custo e no cronograma, avaliar a
probabilidade e para definir entradas, tais como distribuições de probabilidades para as ferramentas.
Essa opinião especializada também é utilizada na interpretação dos dados. Os especialistas devem ser
capazes de identificar os pontos fracos das ferramentas, assim como seus pontos fortes. Além disso, também
podem determinar quando uma ferramenta específica pode ou não ser adequadas, considerando os recursos e
cultura da organização.
Coleta de dados
As entrevistas podem ser usadas para quantificar a probabilidade e o impacto dos riscos nos objetivos
do projeto. Especialistas, Partes interessadas e a equipe fornecem estimativas que irão alimentar as demais
ferramentas deste processo.
Por exemplo, as informações poderão ser usadas para o uso com a ferramenta distribuição de probabilidades
(mais especificamente, estimativa de três pontos), onde estimativas seriam coletadas nos cenários otimista
(baixo), pessimista (alto) e mais provável que é representada por uma distribuição triangular como a mostrada
na figura a seguir.

As habilidades de facilitação são utilizadas para tornar as reuniões mais eficientes deixando claro o seu
objetivo, mantendo o foco para atender esse objetivo, estimulando participação e ainda garantindo que as
decisões tomadas serão corretamente documentadas e executadas.
Representações da incerteza
As distribuições contínuas de probabilidades representam a incerteza nos valores, como durações de
atividades do cronograma e custos dos componentes do projeto. Os valores são obtidos nas entrevistas e
utilizados em modelagens e simulações a partir de ferramentas matemáticas, tais como o Matlab, EstatCamp
ou até mesmo o MS-Excel. A Figura a seguir mostra alguns exemplos de distribuições de probabilidade.
Aqui não apresentamos as vantagens ou desvantagens desta ferramenta, como fizemos com as demais,
porque ela é insumo para outras ferramentas não podendo existir sozinha. Por exemplo, ao utilizar a simulação
de Monte Carlo deve-se escolher qual a distribuição de probabilidade que será utilizada nos cálculos.
Análise de dados
Simulação
A técnica (ou método) mais usual de simulação é a conhecida técnica de Monte Carlo. Esta simulação
consiste em gerar valores aleatórios para cada distribuição de probabilidades dentro de um modelo com o
objetivo de produzir centenas ou milhares de cenários.
• Vantagens: Usado principalmente em análises de risco ligados ao cronograma e ao custo do projeto.

Permite avaliar todos os riscos elencados simultaneamente.
• Desvantagens: Pode ser extremamente complicado elaborar o modelo para a simulação. Necessário
pessoal e software especializados.
• Requisitos: Criação de bons modelos que tipicamente são elaborados a partir das estimativas de custo
e cronograma. Uso de ferramentas computacionais adequadas.
A escolha da distribuição estatística de probabilidade a ser utilizada é muito importante e pode levar a
diferenças significativas de resultados. As mais comumente usadas são: triangular, beta (PERT) e normal
(gaussiana).
Análise de sensibilidade
A análise de sensibilidade é uma comparação da importância relativa de uma variável em relação a outras.
Ou seja, a variável sensível é modelada com valor incerto enquanto todas as outras são mantidas nos seus valores
estáveis (fixos). O resultado dessa análise normalmente é demonstrado em um gráfico chamado diagrama de
tornado.
Esse diagrama é apresentado como um tipo especial de gráfico de barras, onde as categorias de dados são
listadas verticalmente e ordenadas de forma que a maior barra aparece na parte superior do gráfico, a segunda
maior aparece em segundo a partir do topo, e assim por diante. Ele é chamado assim porque o gráfico final se
parece muito com um tornado.
No gerenciamento dos riscos o diagrama de tornado ajuda a determinar quais riscos têm maior impacto
potencial no projeto, examinando como a incerteza associada a cada risco afeta o objetivo que está sendo
examinado.
Quanto mais longa a barra, maior a sensibilidade do objetivo do projeto em relação ao fator de risco. A
incerteza no parâmetro associado com a barra mais longa (no topo do gráfico) tem o máximo impacto no
resultado. Cada barra sucessiva logo abaixo tem menor impacto. As extremidades das barras horizontais indicam
de um lado o valor mais alto e do outro o valor mais baixo do fator avaliado. À direita do diagrama costuma-se
indicar a diferença entre esses valores (o mais alto e o mais baixo). Essa diferença representa a sensibilidade.
Fonte: http://blogtek.com.br/analise-sensibilidade-grafico-tornado/
Análise da árvore de decisão
Esta ferramenta não é citada como sendo deste processo, mas precisamos abordá-la pelo fato dela ser
usada em conjunto com a ferramenta Análise do valor monetário esperado.
Esta ferramenta fornece uma estrutura formal na qual as decisões e eventos incertos são conectados
sequencialmente da esquerda para a direita. As decisões, eventos incertos e resultados finais são representados
por nós e conectados por ramos. O resultado é uma estrutura em árvore com uma “raiz” à esquerda e vários
resultados à direita. As probabilidades de ocorrência de eventos e resultados para eventos e decisões são
adicionadas para cada nó na árvore.
• Vantagens: permite que a organização estruture as probabilidades de forma gráfica e de fácil visualização.
O resultado da árvore de decisão pode ser combinada com a Análise do valor monetário esperado.
• Desvantagens: às vezes é difícil construir a estrutura da árvore de decisão por conta das inúmeras
variáveis de risco do projeto. As probabilidades de ocorrência podem ser complicadas de estimar se não
tivermos dados históricos.
• Requisitos: a estrutura da árvore deve ser construída cuidadosamente. Todas as decisões que resultem
em valores diferentes devem ser mapeadas. Acesso à informação histórica e dados de boa qualidade
são essenciais.
Opções Probabilidades
0,2
1
0,8
0,3
A 2
0,7
0,1
0,9
Análise do valor monetário esperado (VME)
O valor monetário esperado (EMV: Expected Monetary Value) é uma técnica de gestão de risco que pode ser
empregada para medir e comparar os riscos associado a vários aspectos do projeto. A VME das oportunidades
será normalmente expressa em valores positivos, enquanto a dos riscos será expressa em valores negativos. A
VME é calculada multiplicando o valor de cada resultado possível por sua probabilidade de ocorrência.
A tabela a seguir mostra um exemplo de VME para 5 riscos.

Risco Probabilidade Impacto no custo VME
A 0,8 10.000 8.000 (10.000 x 0,8)
B 0,3 30.000 9.000
C 0,5 8.000 4.000
D 0,1 40.000 4.000
E 0,3 20.000 6.000
O conceito de VME é básico para a técnica da árvore de decisão. A decisão que será considerada é
representada à esquerda do diagrama por um quadrado (ou retângulo). As alternativas possíveis para a decisão
são representadas em cada ramo lógico da árvore. Os eventos correspondentes são representados por círculos
aos quais estão associados todos os resultados possíveis, suas probabilidades e impactos.
O cálculo do VME deve ser feito para cada resultado possível de cada evento. A seguir calcula-se a VME
de cada alternativa de decisão, apurando-se o valor líquido do respectivo ramo lógico da rede, que é definido
pela soma dos VMEs dos resultados possíveis de cada evento. A solução da árvore consiste em identificar a
alternativa mais vantajosa: a de menor custo, ou a de maior ganho, dependendo da situação.
A figura a seguir mostra a combinação da Árvore de decisão com a VME para um risco “Y”. Para esse risco
foram encontradas três possíveis soluções, e para cada uma delas foi calculado o VME. Considerando que os
valores indicados são positivos e representam ganhos, a melhor opção é a “1”.
• Vantagens: permite que o usuário calcule o valor esperado de um evento que inclui resultados não
esperados. Casa bem com a Árvore de decisão. Esta técnica inclui tanto a probabilidade quanto o impacto
monetário de um evento incerto. É simples de ser aplicada não necessitando de software especializado.
• Desvantagens: estimar o impacto pode ser muito complicado se não tivermos dados históricos. A técnica
apenas fornece um valor esperado de um evento incerto, no entanto decisões sobre riscos muitas vezes
requerem mais informações do que apenas o valor esperado.
• Requisitos: todos os eventos possíveis devem ser mapeados e incluídos no cálculo do VME. Acesso a
dados históricos e opinião especializada são essenciais.
Diagramas de influência
Estes diagramas mostram as relações de causa e efeito de um conjunto de entidades. Esse diagrama é
utilizado na Simulação de Monte de Carlo, para indicar quais elementos que têm maior influência sobre o
resultado chave esperado. Depois de passar pela Simulação de Monte Carlo, o resultado final do uso deste
diagrama é exibido em uma curva "S" ou Diagrama de Tornado.
Saídas
Os documentos do projeto poderão ser atualizados com as informações resultantes deste processo. O Guia
PMBOK® cita algumas atualizações possíveis:
• Avaliação geral da exposição geral ao risco do projeto: com os riscos existentes no projeto, a avaliação
geral indica a probabilidade de atingir os objetivos definidos no plano atual.
• Análise probabilística do projeto: são feitas estimativas dos possíveis resultados do cronograma e custo
do projeto, listando as datas de término e custos possíveis juntamente com seus níveis de confiança
associados. Essas saídas são usadas em conjunto com as tolerâncias a risco das partes interessadas para
permitir a quantificação das reservas para contingências dos custos e de tempo. Essas reservas para
contingências são necessárias para que o risco de ultrapassar os objetivos declarados do projeto fique
em um nível aceitável para a organização.
• Lista priorizada de riscos individuais: esta lista de riscos inclui os riscos que representam a maior ameaça
ou oferecem a maior oportunidade ao projeto.
• Tendências dos resultados da análise quantitativa de riscos: conforme a análise é repetida, pode ficar
evidente uma tendência que leva a conclusões que afetam as respostas a riscos.
• Respostas recomendadas aos riscos: a saída deste processo pode recomendar respostas aos riscos. Tais
recomendações serão então consideradas no processo seguinte, Planejar as respostas aos riscos.
Planejar as respostas aos riscos (11.5)
No planejamento das respostas aos riscos temos que encontrar formas de reduzir as ameaças ou eliminá-las
por completo. Se, ao invés de ameaças, estivermos tratando de oportunidades, o planejamento das respostas
aos riscos deverá tentar tornar as oportunidades mais prováveis e aumentar o seu impacto.
As respostas aos riscos levam em conta as atitudes das Partes Interessadas em relação ao risco e devem
estar alinhadas às convenções já estabelecidas no plano de gerenciamento de riscos.
Os riscos identificados e analisados anteriormente são as entradas para este processo. Devemos estabelecer
resposta para os riscos priorizados. Os que tem baixos valores de probabilidade e impacto só precisam ser
acompanhados.
Ao criar as respostas aos riscos (tanto positivos quanto negativos), tenha em mente que:
• As estratégias devem ser oportunas;
• O esforço selecionado deve ser apropriado para a gravidade do risco – evite gastar mais dinheiro para
evitar o risco do que custaria o seu impacto se ele ocorresse;
• Uma resposta pode ser usada para lidar com mais de um risco;
• Mais de uma resposta pode ser usada para lidar com o mesmo risco;
• Uma resposta pode lidar com uma causa raiz de risco, e consequentemente abordar mais que um risco;
• Envolva a equipe, outras partes interessadas e especialistas na seleção de uma estratégia.
Algumas definições importantes

• Risco residual: são os riscos que permanecem apesar das ações de evitar, transferir e mitigar planejadas
em resposta aos riscos. Incluem também os riscos aceitos.
• Risco secundário: a implementação de respostas aos riscos pode ter como consequência o surgimento
de novos riscos. Estes são chamados riscos secundários e devem ser também objeto de análise de ações
de resposta.
• Planos alternativos (workaround plans): quando ocorrem riscos que foram identificados e aceitos
passivamente, ou riscos que não foram antes identificados, é necessário planejar e implementar
respostas para lidar com os impactos e suas consequências para os objetivos do projeto. Estas situações
dão origem aos chamados “planos alternativos”, que definem o que comumente conhecemos por
“solução de contorno”, os quais devem ser documentados adequadamente, passando a integrar o plano
de resposta aos riscos.
• Gatilho (ou condição de gatilho): é um evento ou situação que indica que um risco está prestes a
ocorrer.
• Limites de riscos: medida do nível de incerteza ou nível de impacto em que uma parte interessada pode
ter um interesse específico. A organização aceitará o risco abaixo daquele limite. A organização não
tolerará o risco acima daquele limite de risco.
Reservas de contingência e gerencial

As reservas são provisões no plano do projeto para minimizar os impactos dos riscos nos custos e/ou no
cronograma.
Reserva de contingência
A reserva de contingência é calculada para incógnitas conhecidas (known unknowns), ou seja, itens que
identificamos no gerenciamento de riscos. Exemplo: eventuais atrasos na entrega de algumas atividades em
decorrência do período de chuvas em São Paulo.
Essa reserva serve para remediar o impacto dos riscos que ocorreram, ou seja, a contingência só será
executada quando o risco ocorrer. Assim, para cada risco identificado, definimos a reação a ser tomada caso ele
ocorra e estimamos o seu custo. Se o risco for fechado sem ocorrer, a sua reserva de contingência é liberada e
pode ser realocada em outra área do projeto.
Muitas vezes, é impossível alocar o valor total da contingência à reserva, pois tornaria o projeto inviável.
Nesse caso, usamos a técnica VME para obtermos valores mais realistas.
Na tabela a seguir temos cinco riscos identificados (A-E) com suas probabilidades de ocorrência, e impactos
previstos no custo. O valor total dos impactos é de R$108.000,00 e que se fosse solicitado como reserva de
contingência poderia tornar inviável o projeto.
Risco Probabilidade Impacto no custo Contingência (VME)

A 0,80 10.000 (0,8 X 10.000) = 8.000
B 0,30 30.000 (0,3 X 30.000) = 9.000
C 0,50 8.000 (0,5 X 8.000) = 4.000
D 0,10 40.000 (0,1 X 40.000) = 4.000
E 0,30 20.000 (0,30 X 20.000) = 6.000
Totais 108.000 31.000
Uma estimativa mais realista usa o VME, a partir da multiplicação da probabilidade pelo impacto gerando
um valor “mais razoável”. No nosso exemplo, teríamos como reserva de contingência R$ 31.000,00, que é um
valor muito mais fácil de ser aprovado pelo Patrocinador.
Observe que se o Risco “D” viesse a acontecer, a reserva de contingência não seria suficiente para cobrir o
impacto. Mas como a probabilidade desse risco ocorrer é de apenas 0,1 (10%) é tarefa do gerenciamento de
riscos acompanhá-lo para que a sua probabilidade não aumente a ponto de afetar o projeto.
O valor da reserva de contingência deve ser somada ao custo do projeto para gerar o valor da linha de base
de custo, conforme mostrado na tabela a seguir:
Custo do projeto R$ 200.000,00
Reserva de contingência R$ 31.000,00
Linha de base de custos do projeto R$ 231.000,00
Reserva gerencial
As reservas de gerenciamento são custos que não podem ser estimados já que se referem aos eventos
de riscos que não podem ser previstos, ou seja, incógnitas desconhecidas (unknown unknowns). Essas são
reservas orçamentárias para suportar o impacto de riscos não previstos, tais como eventos climáticos, mudanças
organizacionais, mudanças não previstas no escopo etc.
Não fazem parte da linha de base do custo, mas devem ser incluídas no orçamento total do projeto.
A definição de seu valor depende muito da precisão da estimativa dos custos dos pacotes de trabalho do
projeto. Deve-se evitar fazer reservas elevadas como 15% ou 20% do custo do projeto, que apesar de deixarem
o gerente confortável podem encarecer o projeto a ponto de inviabilizá-lo. Usualmente consideramos 5% do
valor da Linha de base de custo, mas esse valor deve ser adaptado às necessidades do projeto e da organização.
Custo do projeto R$ 200.000,00
Reserva de contingência R$ 31.000,00
Linha de base de custos do projeto R$ 231.000,00
Reserva gerencial (5%) R$ 11.500,00
Orçamento total do projeto R$ 242.550,00
A reserva de contingência é calculada e faz parte da linha de base do custo. Já a reserva de gerenciamento é
estimada (por exemplo, 5% do custo do projeto) e faz parte do orçamento do projeto, mas não da linha de base.
Além disso, a aprovação da alta direção é necessária para fazer uso da reserva de gerenciamento.
De forma a ficar claro como a análise qualitativa é executada, mostramos um fluxo com os passos a serem
Não
Identificar e Todos os
Selecionar riscos foram Planejar ações
respostas tratados?
Não
Riscos
Checar por riscos Documentar
residuais
residuais resultados
aceitáveis?
• Identificar e selecionar respostas: todos os riscos priorizados tanto na análise qualitativa quanto
na quantitativa deverão ser considerados neste processo. Reuniões podem ser feitas para que os
participantes possam sugerir respostas apropriadas. As melhores respostas serão então selecionadas e
passarão a compor o Registro de riscos.
• Planejar ações: para os riscos que serão tratados, são planejadas ações para eliminá-los, mitigá-los ou
transferi-los. Essas ações visam reduzir a exposição aos riscos alterando o planejamento do projeto.
Note que a intenção neste ponto é evitar que o risco ocorra.
• Checar por riscos residuais: nem sempre conseguimos eliminar todos os riscos. Os riscos que não foram
eliminados, mitigados ou transferidos são chamados de riscos residuais. Se estes riscos não estiverem em
níveis aceitáveis, novas respostas deverão ser identificadas na tentativa de eliminá-los. Caso contrário,
se estiverem em um nível aceitável, planos de contingência deverão ser elaborados.
• Documentar resultados: o registro de riscos será atualizado com as informações geradas por este
processo.
É importante saber que a resposta a um risco pode gerar riscos secundários, ou seja, são riscos que
surgem como resultado direto da implementação da resposta ao risco principal.
O processo
Entradas
• Plano de gerenciamento dos recursos: deste plano extrairemos informações a respeito dos recursos a
serem alocados para as respostas aos riscos.
• Plano de gerenciamento de riscos: Os principais elementos do plano de gerenciamento de riscos que

devem ser levados em conta neste processo incluem papéis e responsabilidades, definições de análise
de riscos, intervalos de tempo para revisões, limites para riscos baixos, moderados e altos.
• Linha de base dos custos: deste plano extrairemos informações a respeito das reservas de contingência
alocadas para as respostas aos riscos.
algum possível risco indicado. Entre eles temos:
• Registro das lições aprendidas: sempre que possível veja se existem lições aprendidas disponíveis,
pois respostas eficazes para riscos semelhantes já podem ter sido usadas e você pode aproveitar o
conhecimento já adquirido e registrado.
• Cronograma do projeto: o cronograma é usado para indicar em que momentos as respostas aos riscos
serão alocadas.
• Atribuições da equipe do projeto: recursos deverão ser alocados para a implementação das respostas
aos riscos, sendo assim este documento fornece a lista de pessoas do projeto que poderão participar
deste processo.
• Calendário dos recursos: do calendário extraímos as datas de disponibilidade dos recursos do projeto
que serão alocados para executar as respostas aos riscos.
• Registro dos riscos: o registro dos riscos inclui os registros identificados, as causas principais, as possíveis
respostas, os donos dos riscos, os sinais de alerta, a classificação relativa, os riscos que exigem respostas
urgentes, os riscos para análise adicional. Além do registro dos riscos, deve ser criada uma lista de
observação que conterá os riscos que possuem baixa prioridade. Esses riscos não oferecem perigo ao
projeto, mas não é por isso que devem ser esquecidos.
• Relatórios de riscos: estes relatórios descrevem a fonte geral dos riscos bem como o status atual do
projeto.
• Registro das partes interessadas: algumas partes interessadas podem ser alocadas para a execução das
respostas aos riscos.


anteriormente, ou seja, lições aprendidas e o registro dos riscos desses projetos.
Existem diversas estratégias possíveis de resposta aos riscos. Para cada risco, deve-se selecionar a estratégia
ou combinação de estratégias que retornem a melhor resposta, como veremos a seguir:
Especialistas podem e devem ser utilizados para estabelecer estratégias de respostas à ameaças,
oportunidades, contigência e riscos gerais do projeto.
Coleta de dados
Entre as técnicas que podem ser utilizadas, o Guia PMBOK® sugere a entrevista em que informações podem
ser coletadas a fim de se estabelecer as melhores formas de responder aos riscos.

Das habilidades interpessoais e de equipe existentes, sugere-se a facilitação, pois aprimora a eficácia do
desenvolvimento das respostas aos riscos individuais e do risco geral do projeto. O facilitador pode ajudar
os responsáveis pelos riscos a compreendê-los, idenficá-los, comparar estratégias alternativas e escolher a
apropriada.
Estratégias para ameaças

Para cada risco deve ser selecionada a estratégia ou associação de estratégias com mais probabilidade de
ser eficaz.
• Escalar: quando uma ameça excede a autoridade do gerente do projeto, ela é escalada para o nível
do programa, portifólio ou qualquer outra parte relevante da organização. Essas ameaças devem ser
comunicadas e aceitas pelo nível responsável, além disso, esse deve ser o nível afetado por essa ameaça.
As ameaças escaladas não são mais de responsabilidade do projeto, por isso não precisam mais ser
acompanhadas.
• Prevenir: envolve alterar o plano de gerenciamento para eliminar a ameaça, eliminando a causa do
problema (ex: remover um pacote de trabalho ou substituir recursos humanos).
• Mitigar: reduzir a probabilidade ou o impacto de uma ameaça, tornando-a um risco menor e removendo-a
da lista dos principais riscos do projeto. Qualquer redução nos riscos fará a diferença, mas a opção com
a maior probabilidade de redução de impacto deve ser a opção selecionada.
• Transferir (desviar, alocar): tornar outra pessoa ou organização responsável pelo risco, contratando
seguradoras, por exemplo. A transferência do risco implica também na transferência das respostas ao
risco. Mas atenção: transferir o risco não o elimina. Simplesmente passamos a responsabilidade para
outra pessoa ou organização quando fazemos isso. A transferência dos riscos deve ser incluída nos
termos e condições do contrato.
• Aceitar: não fazer nada. A aceitação ativa envolve a criação de planos de contingências para serem
implementados se os riscos ocorrerem. A aceitação passiva deixa que as ações sejam determinadas
quando os riscos ocorrerem.
Estratégias para oportunidades

Para cada risco deve ser selecionada a estratégia ou associação de estratégias com mais probabilidade de
ser eficaz.
• Escalar: quando uma oportunidade está fora do escopo do projeto ela é escalada para o nível do
programa, portifólio ou qualquer outra parte relevante da organização. Essas oportunidades devem
ser comunicadas e aceitas pelo nível responsável, além disso, esse deve ser o nível afetado por essa
oportunidade. As oportunidades escaladas não são mais de responsabilidade do projeto, por isso não
precisam mais ser acompanhadas.
• Explorar (o oposto de prevenir): procura eliminar a incerteza associado ao risco positivo, adicionando
trabalho ou mudando o projeto para assegurar que a oportunidade ocorra.
• Melhorar (o oposto de mitigar): aumentar a probabilidade e os impactos positivos de uma oportunidade.

Identificar os principais causadores desses riscos positivos ajuda a aumentar a probabilidade de
ocorrência.
• Compartilhar: envolve alocar parte ou a totalidade da oportunidade para um terceiro (criando uma
parceria) que tenha mais capacidade de concretizar essa oportunidade.
• Aceitar: não fazer nada. A aceitação ativa envolve a criação de planos de contingências para serem
implementados se os riscos ocorrerem. A aceitação passiva deixa que as ações sejam determinadas
quando os riscos ocorrerem.
Estratégias de resposta de contingência

Esta técnica é utilizada para riscos específicos normalmente de alto impacto onde se escolheu a estratégia
“Aceitar ativamente”. Como nessa estratégia nada será feito para diminuir a probabilidade ou o impacto, o
plano de contingência será executado assim que o evento de risco ocorra.
O plano de contingência é um documento onde estão definidas as responsabilidades estabelecidas em uma

organização, para atender a uma emergência. É um documento desenvolvido com o intuito de treinar, organizar,
orientar, facilitar, agilizar e uniformizar as ações necessárias às respostas de controle e combate às ocorrências
anormais.
Os planos de contingência devem se concentrar nos incidentes de maior probabilidade e não nos catastróficos
que, normalmente, são menos prováveis de acontecer.
Devem ser especificados gatilhos que acionam o plano de contingência.
• Vantagens: garante que ações já estejam pré-determinadas antes da ocorrência dos eventos. Permite
resposta rápida e focada. Melhora a imagem de profissionalismo do gerenciamento do projeto
• Desvantagens: pode passar a falsa sensação que o risco foi eliminado quando na verdade ele poderá
acontecer, e o plano só minimizará os seus efeitos.
• Requisitos: os gatilhos devem ser claramente definidos e rastreados. Os planos devem ser constantemente
validados. A organização deve liberar os recursos necessários planejados quando a condição de gatilho
ocorrer.
Estratégias para o risco geral do projeto

As estratégias citadas pelo Guia PMBOK são as mesmas para os riscos individuais, ou seja, prevenir, explorar,
transferir ou compartilhar, mitigar ou melhorar e por fim aceitar.
Análise de dados
• Análise de alternativas: esta técnica envolve a comparação de alternativas disponíveis para que se
possa escolher a mais apropriada.
• Análise custo-benefício: se o impacto de um risco individual pode ser quantificado em termos

monetários, a eficácia do custo das estratégias alternativas de resposta ao risco pode ser determinada
por intermédio desta análise.
Tomada de decisão
Estas técnicas são usadas para selecionar a melhor estratégia de respostas aos riscos. Pode-se utilizar a
análise de decisão envolvendo múlitiplos critérios que usa uma matriz de decisão que avalia e classifica
alternativas para que se possa selecionar a melhor de acordo com critérios pré-estabelecidos.
Saídas
Solicitações de mudança
As respostas planejadas podem resultar em uma solicitação de mudança nas linhas de base de custos e do
cronograma e em outros componentes do plano de gerenciamento do projeto. As solicitações são enviadas para
o processo Realizar o controle integrado de mudanças.

Os esforços de gerenciamento dos riscos criam mudanças no plano de gerenciamento do projeto, pois
pacotes de trabalho podem ser removidos, adicionados ou re-alocados. As estratégias de respostas a riscos,
depois de acordadas, devem ser fornecidas como feedback aos processos adequados de outras áreas de
conhecimento, inclusive ao orçamento e cronograma do projeto.
Este processo pode gerar alterações em praticamente todos os componentes do plano de gerenciamento
de riscos, incluindo os planos auxiliares e as linhas de base.

Os documentos do projeto também podem sofrer alterações nesta fase do projeto, principalmente o
registro de riscos que poderá ter:
• Riscos residuais: são os riscos que permanecem após o planejamento das respostas aos riscos. Os
riscos residuais devem possuir planos de contingência e planos alternativos, e devem ser registrados e
revisados ao longo do projeto a fim de avaliar se a sua classificação mudou.
• Planos de contingência: os planos de contingência descrevem as ações que deverão ser tomadas se
ocorrer uma oportunidade ou ameaça.
• Responsáveis pelas respostas aos riscos: para cada risco deve ser designada uma pessoa que seja a
responsável pela resposta ao risco. Muitas vezes a pessoa que acompanha o risco não é a mesma que
implementa a sua resposta. Isso ocorre, por conta de níveis de acesso a custos que somente alguns
recursos estão autorizados a fazer.
• Riscos secundários: a resposta a um risco pode gerar outros riscos (riscos secundários). Cabe a equipe
do projeto ficar atenta a esses tipos de riscos, registrando-os e monitorando-os
• Gatilhos de riscos: são os eventos que disparam a resposta de contingência.
• Reservas (contingência e gerencial): ter reservas de cronograma e de custos é parte indispensável do
gerenciamento de projetos.
Outros documentos que podem ser atualizados são o registro das premissas, previsões de custos, registro
das lições aprendidas, cronograma do projeto, atribuições da equipe do projeto e relatório de riscos.
Planejando as Aquisições
O gerenciamento das aquisições do projeto é uma área de conhecimento muito importante dentro das
organizações, principalmente, devido ao aumento constante da terceirização de serviços.
Como afirmou Tom Peters: “As empresas precisam trabalhar no que elas fazem de melhor e deixar as demais
áreas para empresas especializadas”. Ou seja, se preciso de cadernos, para que vou produzi-los internamente
se já existem empresas especializadas nisso? Mas também existe o outro lado da moeda, pois muitas vezes é
preferível estrategicamente produzir internamente algum produto a comprá-lo de fornecedores.
Assim, muitas vezes, em projetos, teremos que tomar decisões de fazer ou comprar. E é nesta área de
conhecimento que tais decisões serão tomadas.
O Guia PMBOK® só aborda a perspectiva do comprador.
É importante observar que podem existir duas situações:
Os processos desta área de conhecimento serão executados dependendo da forma como a organização
é estruturada. Caso ela seja matricial provavelmente possuirá um departamento responsável por todas as
aquisições, aluguéis e contratações realizadas e será esse departamento o responsável pelas aquisições do
projeto. Já em organizações totalmente orientadas a projetos, essa responsabilidade estará a cargo da equipe
do projeto.
O Guia PMBOK® recomenda o seguinte processo de planejamento:

• Planejar o gerenciamento das aquisições (12.1).
Contrato
Um dos principais elementos das aquisições é o contrato, documento legal entre comprador e fornecedor
que descreve um acordo mútuo gerando obrigações entre as partes e que serão gerenciados e controlados por
esta área de conhecimento.
O contrato deve refletir a complexidade das entregas e do esforço necessário e incluir termos e condições
objetivos, claros e detalhados sem gerar dupla interpretação (ambiguidade). Celebrar um contrato é um método
para alocar a responsabilidade pelo gerenciamento e compartilhar riscos potenciais.
Sua redação cuidadosa pode mitigar ou transferir riscos para o fornecedor, e sua aprovação e revisão deve
envolver especialistas em contratos, compras, aspectos jurídicos e disciplinas técnicas.
Cláusulas contratuais
Como vimos, o contrato é uma relação legal que pode se sujeitar a ações corretivas dos tribunais caso não
sejam cumpridas as suas cláusulas. É por isso que um contrato deve conter os seguintes componentes:
• Especificação do trabalho ou resultados esperados;
• Linha de base do cronograma;
• Relatórios de desempenho;
• Indicação do período de medição do desempenho;
• Papéis e responsabilidades;
• Definições de preços e condições de pagamento;
• Local de entrega;
• Critérios de inspeção e aceitação;
• Garantia e suporte;
• Penalidades e incentivos;
• Indicativo de taxas, impostos e adiantamentos;
• Limitações de responsabilidade;
• Seguros;
• Indicação de subcontratações;
• Tratamento das solicitações de mudanças;
• Mecanismo de soluções de disputas e rescisões.
Termos e condições
Os termos e condições são respostas planejadas aos possíveis riscos de aquisição. As respostas mais comuns
a todos os processos de aquisição são incluídas em termos e condições padrão (usados recorrentemente para
projetos semelhantes). As respostas específicas de um processo de aquisição podem ser incluídas como termos
e condições especiais (necessidades específicas do projeto).
Incentivos de contrato
Os incentivos de contrato são mecanismos contratuais destinados a sincronizar os objetivos do comprador
com o fornecedor. Existem diversos instrumentos, entre eles:
• Preço alvo ou preço estimado: é o valor da proposta do fornecedor (trata-se do preço-base do contrato).
• Teto do preço ou preço máximo: é o valor máximo que o comprador admite pagar.
• Custo alvo ou custo estimado: é o valor que o fornecedor espera gastar. Usado como referência para
estabelecer incentivos. Desvios neste custo serão compartilhados entre comprador e fornecedor.
• Remuneração fixa ou remuneração alvo ou lucro estimado ou lucro alvo: lucro obtido pelo fornecedor
caso não haja qualquer compensação de incentivo.
• Remuneração de incentivo: compensação atribuída ou retirada do fornecedor por desvios entre o custo
real e o custo alvo.
• Custo real: é o valor dos custos apurados ao final do contrato.
• Remuneração real ou lucro real: é o lucro do fornecedor ao final do contrato.
• Preço ou preço final: é o valor que o comprador vai pagar ao final do contrato.
• Fórmula de compartilhamento: descreve como os desvios entre o custo real e o custo alvo definido
no contrato serão compartilhados entre o comprador e o fornecedor. Por exemplo, uma proporção de
70%-30%, significa que 70% dos custos adicionais pertence ao comprador e 30% pertence ao vendedor.
• Ponto de premissa total: também chamado de point of total assumption (PTA), é aplicado nos contratos
de preço fixo com remuneração de incentivo (veremos o que é isso mais a frente). É o valor a partir do
qual o fornecedor será obrigado a arcar com todos os aumentos de custo. Assim, se os custos subirem
além desse ponto, a fórmula de compartilhamento acaba virando 0% para o comprador e 100% para o
fornecedor. É dado pela fórmula:
PTA = ((preço máximo - preço alvo)/proporção compartilhamento comprador) + custo alvo
Tipos de contratação
Conforme apresentado no Guia PMBOK® existem três tipos “básicos” de contrato: os de contratos de preço
fixo, os de custos reembolsáveis e os de tempo e materiais (uma combinação dos dois anteriores). É importante
observar que nada impede que os tipos sejam combinados para gerar um novo tipo de contrato que atenda às
necessidades do projeto.
Contratos de preço fixo ou preço fechado ou lump-sum

Neste tipo de contrato, o preço total dos insumos/equipamentos/materiais fornecidos é definido a partir de
um preço fixo, contendo ou não incentivos financeiros (premiação).
Os fornecedores são obrigados a concluir os fornecimentos por sua conta e risco, assumindo inclusive
desequilíbrios financeiros (prejuízo), caso não consigam justificar e/ou realizar seu escopo dentro de suas
margens.
O ideal é que se tenha o escopo e o prazo muito bem definidos, para que se possa garantir ou minimizar
alterações durante a implantação do projeto.
Um pedido de compra é uma forma simples de contrato de preço fixo em que uma parte emite unilateralmente
uma ordem de compra. O contrato é considerado aceito quando o fornecedor desempenhar o que foi solicitado.
Este tipo de contrato geralmente é usado para materiais e equipamentos.
Dentro desta categoria (contratos de preço fixo) o Guia PMBOK® ainda cita as seguintes variações:
Preço fixo garantido (PFG)
Esta modalidade de contrato é o preferido pelas organizações contratantes, porque o valor é previamente
definido, e não apresenta perspectivas de alteração, exceto caso seja modificado o escopo. O fornecedor se obriga
a assumir as consequências adversas que venham impactar o preço estabelecido, e concluir o fornecimento
integralmente. Somente no caso de alterações do escopo, os valores estabelecidos podem ser alterados.
Este tipo de contrato é o mais usado.
Exemplo: O preço do contrato é dado diretamente. Assim, caso seja indicado que o valor de um contrato
de preço fixo garantido é de R$ 800.000,00 temos que:
Preço final = R$ 800.000,00
Preço fixo com remuneração de incentivo (PFRI)
Esta modalidade permite um mínimo de flexibilidade às partes do contrato, pois prevê um desvio com
relação ao desempenho e incentivos ao fornecedor para o cumprimento de metas que são estabelecidas no
início do contrato. Em outras palavras, o fornecedor recebe um incentivo monetário caso atinja as metas
preestabelecidas em contrato. Neste tipo de contrato também é estabelecido um teto de preços, obrigando o
fornecedor ao total cumprimento do escopo, sem ônus adicional para a parte contratante.
O cálculo do valor final do contrato pode ficar complicado, por isso apresentamos um exemplo em detalhes
a seguir:
Temos as seguintes informações a respeito de um contrato fechado com a sua empresa (valores em R$):
Custo alvo: 10.000
Remuneração fixa: 3.000
Preço alvo: 13.000
Preço máximo: 13.900
Compartilhamento: 60/40
Supondo que o custo real do trabalho ficou em 12.000, qual é o preço final do contrato? E qual é o valor do
custo no ponto de premissa total?
Passo 1: calcular o preço alvo

Quando a empresa contrata o fornecedor, o preço do contrato é acertado como sendo:
Preço alvo = custo alvo + remuneração fixa
Preço alvo = 10.000 + 3.000
Preço alvo = 13.000

Passo 2: calcular o preço final
O preço final de um contrato é dado pelos custos reais mais a sua remuneração de incentivo (fixa) dada
pela fórmula:
Preço final = custo real + remuneração fixa

Preço final = 12.000 + 3.000
Preço final = 15.000 (ficou acima do preço alvo!)

Não se deve, neste momento, considerar que será pago o valor máximo (13.900), uma vez que o preço final
está acima desse valor. Devemos agora calcular o preço final utilizando a fórmula de compartilhamento e só
então checar se o preço final ultrapassou esse valor:
Preço final = custo real + remuneração fixa + %comprador x (custo alvo - custo real)
Preço final = 12.000 + 3.000 + 0,4 x (10.000 - 12.000)
Preço final = 15.000 + 0,6 x (-800)
Preço final = 14.200

Agora sim, podemos checar se o preço final é maior que o preço máximo. E como neste caso é, o preço final
do contrato passa a ser o preço máximo:
Preço final = preço máximo = 13.900

Passo 3: calcular o custo no ponto de premissa total
O ponto de premissa total é aquele a partir do qual o fornecedor assume todos os custos, assim a fórmula
de compartilhamento fica na prática: 0%comprador - 100%fornecedor
Inicialmente aplicamos a fórmula do PTA:
PTA = ((preço máximo - preço alvo)/proporção compartilhamento comprador) + custo alvo
PTA = ((13.900 - 13.000)/0,6) + 10.000
PTA = 11.500
Para calcular o custo real neste ponto, consideramos :
Custo real = preço máximo - PTA
Custo real = 13.900 - 11.500
Custo real = 2.400

Importante observar que a partir desse ponto (PTA), todo aumento de custo será absorvido pelo fornecedor,
uma vez que o preço pago não se alterará mais. Com isso, a parcela de lucro real se reduzirá cada vez mais,
podendo vir a ser negativo e gerar prejuízos ao fornecedor.
Preço fixo com ajuste econômico do preço (PF-AEP)
Esse tipo de contrato é utilizado quando o fornecimento demanda um período muito grande para sua
conclusão, gerando um relacionamento de longo prazo entre as partes. O contrato é a preço fixo, mas com
previsão de ajustes predefinidos em função de alterações do mercado e natureza do fornecimento. A cláusula
de reajuste do contrato deve se basear em índices financeiros confiáveis, de forma que as partes possuam
proteção contra os agentes externos ao contrato durante o ciclo de vida do projeto.
Exemplo: O valor de contrato será de R$300.000 e será reajustado anualmente de acordo com a taxa selic
ou similar vigente à época.
Contratos de preço fixo
Vantagens para o Não demanda esforço de controle dos custos
comprador reais do fornecedor.
Apresenta um risco de custo mais baixo que as
demais alternativas.
O planejamento financeiro é facilitado, pois o
preço é conhecido.
Pode ter incentivos.
Desvantagens para o Há um elevado esforço para definir o escopo
comprador antes do contrato.
O preço pode ser mais alto por incorporar o
custo do risco.
É um contrato pouco flexível.
Sem uma clara definição do escopo, existem
riscos elevados de solicitações de mudança que
tendem aumentar o valor final a ser pago.
Aplicação Existe um entendimento claro sobre o que
precisa ser feito.
Não existem recursos suficientes para controlar
os custos reais do fornecedor.
Contratos de custos reembolsáveis

Esta modalidade prevê o pagamento (reembolso) ao fornecedor de todos os custos reais incorridos para
concluir o previsto no escopo, acrescidos de uma remuneração, percentual, fixa ou concedida, mediante o
cumprimento de metas estabelecidas no cronograma.
Os custos considerados podem ser diretos (ou seja, tudo o que for diretamente alocado ao projeto), ou
indiretos (tais como, instalações). Frequentemente esses custos indiretos são fixados como uma porcentagem
do custo direto. Assim, a composição do preço desse tipo de contrato pode ficar:
Preço final = custos diretos + custos indiretos + remuneração
ou
Preço final = custos diretos + (%custos direto) + remuneração
Dentro desta categoria (contratos de custos reembolsáveis) o Guia PMBOK® ainda cita as seguintes
variações:
Custo mais remuneração fixa (CMRF)
O fornecedor é reembolsado pelos custos incorridos permitidos para realizar o previsto no escopo, e
recebe uma remuneração fixa, calculada a partir de um percentual do valor total estimado no início do projeto.
Normalmente, a remuneração é paga, observando-se o cumprimento das metas estabelecidas no cronograma.
Os valores de remuneração são alterados, somente caso haja ajuste no escopo.
Exemplo: O valor de contrato será de R$100.000 (remuneração) mais o custo dos materiais de acabamento.
Preço final = R$100.000,00 + R$240.000,00 (valores dos materiais)
Preço final = R$340.000
Custo mais remuneração de incentivo (CMRI)
O fornecedor é reembolsado pelos custos incorridos permitidos para realizar o previsto no escopo, e recebe
uma remuneração de incentivo pré-estabelecida, caso atinja as metas (marcos) estabelecidas no contrato.
Neste tipo de contrato, se os custos finais variarem acima ou abaixo dos valores estimados, é realizado um
compartilhamento de ganhos ou prejuízos, conforme uma fórmula de compartilhamento predeterminada.
O cálculo do valor final do contrato pode ficar complicado, por isso apresentamos um exemplo em detalhes
a seguir:
Temos as seguintes informações a respeito de um contrato fechado com a sua empresa (valores em R$):
Custo alvo: 10.000
Remuneração fixa: 3.000
Remuneração mínima: 2.200
Remuneração máxima: 4.500
Compartilhamento: 80/20
Se o custo real for de 17.000, qual será o preço final? E o lucro real?
Observação: As fórmulas aplicadas no exemplo do contrato de preço fixo com remuneração de incentivo são
válidas aqui. A diferença aqui é que existem valores de remuneração mínima e máxima; assim se a remuneração
real cair abaixo do mínimo ou acima do máximo, são aplicados esses valores.
Passo 1: calcular a remuneração real (lucro real)
Lucro real = Lucro estimado + %fornecedor x (custo alvo - custo real)
Lucro real = 3.000 + 0,2 x (12.000 - 17.000)
Lucro real = 2.000 (como o lucro mínimo é de 2.200, o lucro real passa a ser: 2.200)
Passo 2: calcular preço final
Preço final = custo real + remuneração
Preço final = 17.000 + 2.200
Preço final = 19.200
Custo mais remuneração concedida (CMRC)
O fornecedor é reembolsado pelos custos incorridos permitidos para realizar o previsto no escopo, e terá
uma remuneração fixa mais uma remuneração baseada no desempenho. Essa remuneração concedida não é
vinculada ao valor projeto, e é discutida e negociada previamente entre as partes.
Exemplo: O valor de contrato será composto por:

Valor dos materiais = R$100.000
Remuneração fixa = R$20.000
Remuneração concedida = R$30.000 (caso entregue componentes sem defeitos)
Assim, o preço final é:
Preço final = 100.000 + 20.000 + 30.000 = 150.000
Contratos de custos reembolsáveis

Vantagens para o Pode começar rapidamente, pois o esforço de
comprador definição do escopo é limitado.
O preço pode ser mais baixo por não incorporar
o custo do risco.
Pode incorporar incentivos.
O contrato é mais flexível.
Desvantagens para Exige um esforço significativo de administração,
o comprador pois terá que garantir que o fornecedor utilize
apenas os recursos absolutamente necessários e
que fature os recursos utilizados.
O risco de custo é mais alto que as demais
alternativas.
O planejamento financeiro é dificultado, pois o
preço não é conhecido.
Aplicação Existe indefinição no escopo do projeto.
Contratos por tempo e material (T&M)

São contratos que incluem aspectos dos contratos de preço fixo e de custos reembolsáveis.
São mais utilizados quando não há uma declaração de escopo muito precisa, e se assemelham mais aos
contratos de custos reembolsáveis, porque permitem modificações e estão sujeitos a aumentos de custos para
o comprador. Algumas organizações estabelecem tetos para este tipo de contrato, para evitar variações muito
elevadas em relação aos valores estimados originalmente.
Assim, executa-se o contrato a preço fixo para a parte em que o escopo está relativamente bem definido e
a custo reembolsável para a parte que ainda não está.
Exemplo: O valor de contrato será calculado a partir da quantidade de dias de trabalho de um programador
x R$700,00 com um teto de 30 dias.
Contratos por tempo e materiais

Vantagens para o O trabalho pode começar imediatamente, pois
comprador não é necessário compreender o escopo.
O contrato pode ter um limite de tempo e
custo.
Contratos por tempo e materiais
Desvantagens para o A margem do fornecedor aumenta
comprador linearmente com o custo do projeto.
Não existe um compromisso do fornecedor
com o sucesso do projeto.
O comprador deve gerenciar os recursos do
fornecedor.
Aplicação Há urgência em começar.
É necessário um contrato por um período
curto de tempo.
O comprador pretende manter o controle
absoluto sobre o trabalho.
O trabalho tem um baixo valor monetário.
São necessários recursos e não escopo.
Níveis de risco por tipo de contrato

Conforme foi apresentado, as modalidades de contrato praticadas permitem a implementação do projeto
de várias formas. No entanto, cada modalidade apresenta diferentes níveis de riscos tanto para o comprador
como para o fornecedor, conforme mostrado na figura a seguir.
Baixo Alto
Preço fixo
Preço fixo garantido
Preço fixo com incentivo na remuneração
Preço fixo com ajuste econômico do preço
Risco do Risco do
comprador Tempo e material fornecedor
Custos reembolsáveis
Custo mais remuneração fixa
Custo mais remuneração de incentivo
Custo mais remuneração concedida
Alto Baixo
Comprador x Fornecedor
Algumas definições importantes:
• O fornecedor também pode ser chamado de: vendedor, prestador de serviço, licitante, fonte selecionada.
• O comprador também pode ser chamado de: cliente, contratante principal, contratante, organização
compradora, solicitante do serviço, adquirente.
O fornecedor normalmente irá gerenciar o trabalho como um projeto quando a aquisição não for apenas de
material, bens ou produtos comuns.
Nesses casos:
• O comprador se torna o cliente e, portanto, é uma importante parte interessada do projeto para o
fornecedor.
• A equipe de gerenciamento de projetos do fornecedor está preocupada com todos os processos de

gerenciamento, não apenas com os dessa área de conhecimento.
• Os termos e condições do contrato se tornam entradas importantes para muitos processos de

gerenciamento do fornecedor.
• O contrato pode realmente conter as entradas (por exemplo, principais entregas, marcos importantes,
objetivos de custo) ou pode limitar as opções da equipe (por exemplo, muitas vezes é necessária a
aprovação pelo comprador de decisões relativas à formação de pessoal em projetos de design).
Ciclo de vida do contrato

Administrar adequadamente todo o processo de contratação tornou-se fator decisivo de competitividade,
gestão e governança para que as empresas possam maximizar o desempenho dos contratos, reduzir as perdas
e os custos com materiais e serviços e ainda garantir a governança das transações de negócios.
A grande maioria das empresas já possui um ciclo de gestão de contratos. A seguir apresentamos um modelo
simplificado a título de exemplo.
• Contratação: o ciclo de vida de um contrato inicia-se no processo de contratação. É neste momento que
a decisão de compra ou venda, para suprir uma necessidade, torna-se efetiva.
• Elaboração: após o processo de contratação, inicia-se a elaboração propriamente dita do contrato.
• Repositório: todos os contratos e aditivos da empresa devem ser armazenados de preferência em um

banco de dados único, onde serão gerenciados e consultados.
• Gerenciamento: com o contrato fisicamente arquivado, todas as informações contratuais permanecem

ativas e são gerenciadas com eficiência.
• Governança: além do gerenciamento propriamente dito do objeto do contrato, é fundamental garantir

a conformidade com os regulamentos e estratégias da empresa.
O fluxo de aquisições
A seguir apresentamos uma sugestão do fluxo do processo de aquisições.
Início
Analisar e decidir fazer ou Classificar propostas /

comprar cotações recebidas
Especificar o trabalho a
Selecionar fornecedores
adquirir
Solicitar informações de Fornecedor Não

1
potenciais fornecedores escolhido?
Sim
Definir critérios para Negociar e estabelecer

seleção de fornecedores acordos
Gerenciar acordos e
Elaborar solicitação de
desempenho do
propostas / cotações
fornecedor
1
Solicitar propostas / Requer Sim

Solicitar mudanças
cotações alterações?
Não
Realizar reuniões com Encerrar aquisições e

fornecedores acordos
Fim
Analisar e decidir fazer ou comprar
A chamada análise de fazer ou comprar, do inglês make or buy, deve preceder a decisão de comprar ou
adquirir o trabalho de um fornecedor externo ao projeto. O plano de gerenciamento das aquisições deve
orientar a realização desta análise, quais aspectos e fatores considerar, quem são os responsáveis envolvidos,
entre outros. Pode ser criado um modelo para orientar a análise, que integrará os chamados documentos de
aquisição.
Especificar o trabalho a adquirir

A especificação do escopo do projeto descreve todo o trabalho a ser realizado, que pertence ao escopo
(do projeto). Ao decidir fazer parte deste trabalho como uma aquisição do projeto, parte da descrição dessa
especificação servirá como base para a equipe elaborar a especificação do trabalho das aquisições. Por sua vez,
esse documento servirá de fonte para que a equipe do fornecedor a ser contratado entenda todo o trabalho a
ser realizado. Ele contém o detalhamento técnico, normas e padrões de qualidade a serem respeitados, enfim,
todas as informações necessárias à plena compreensão, pela equipe do fornecedor, do trabalho a realizar.
Em alguns casos, especialmente em projetos do governo, a empresa contratante não tem competência
técnica suficiente para elaborar a especificação do trabalho das aquisições e contrata um fornecedor para
elaborá-la. Esse mesmo fornecedor, no entanto, não participa do processo de seleção de fornecedores que
executarão o projeto. Isso acontece para evitar qualquer tipo de conflito de interesses que possa inviabilizar a
lisura do processo de contratação.
Solicitar informações de potenciais fornecedores

Alguns processos de seleção de fornecedores podem incluir a solicitação de informações a respeito dos
potenciais fornecedores, por exemplo, para saber se têm interesse em prestar determinado serviço ou fornecer
determinado produto para o projeto. Podem ser coletadas referências de trabalhos anteriores realizados pelos
potenciais fornecedores para conhecer os resultados e desempenho alcançados por eles na ocasião.
A solicitação de informações (SDI), do inglês Request for Information (RFI), regularmente, ocorre antes de
convidar os potenciais fornecedores a participar de um processo de seleção ou por vezes, pode ocorrer como
parte da solicitação de proposta.
Definir critério para seleção de fornecedores

Antes de convidar potenciais fornecedores é muito importante definir quais são os critérios desejados que
eles devam possuir para que possam ser selecionados. Sem isso, a seleção de um fornecedor pode ser bem
confusa e totalmente subjetiva.
Os critérios podem levar em consideração aspectos da empresa fornecedora como, por exemplo, local da
prestação do serviço, faturamento e/ou o número de funcionários e técnicos especializados com certificação
profissional regulamentada por um órgão de classe. Os critérios podem considerar aspectos técnicos como o
processo, tecnologia e padrões de trabalho, e até a abordagem de gerenciamento praticada pela equipe do
fornecedor, entre outros. O desempenho do fornecedor em projetos anteriores, seja na mesma empresa que
empreende o novo projeto ou em outra, pode ser parte do critério para sua classificação.
Elaborar solicitação de propostas / cotações

Caso o projeto precise adquirir um produto específico como, por exemplo, um pacote do software de
prateleira, um material para a obra de construção civil como um tipo de cimento, ou até mesmo, um automóvel
para o qual, no máximo, serão escolhidos os acessórios a instalar, é recomendado criar uma solicitação de
cotação (SDC), do inglês request for quotation (RFQ). Regularmente, para esse tipo de produto, há diferentes
fornecedores que já mantém em seu estoque o tal produto. O foco de uma cotação é obter melhores preços,
prazo de entrega e condição de pagamento. A aquisição é mais simples e não requer muita especificação e a
disponibilidade do item a ser adquirido para o projeto é quase imediata.
Por outro lado, caso o projeto necessite adquirir um serviço ou produto diferenciado, que requer
customização ou adaptação antes de estar disponível para o projeto, é recomendado que a equipe do projeto
organize uma solicitação de proposta (SDP), do inglês request for proposal (RFP). Regularmente, a SDP pode
orientar o conteúdo e forma da proposta que o fornecedor deve respeitar. Alguns critérios de seleção do
fornecedor podem constar da SDP, pelo menos parcialmente. Assim o fornecedor já saberá antecipadamente
como será classificado.
Um aspecto muito importante a ser incluído na SDP é o modo como o desempenho do fornecedor será
avaliado durante a realização do trabalho como, por exemplo, a pontualidade das entregas parciais e final,
a qualidade da entrega, o número de não-conformidades em uma auditoria de garantia da qualidade, entre
outros. É recomendado que sejam programadas auditorias de qualidade e diligências até o local de realização do
trabalho do fornecedor. Também um exemplo ou minuta do contrato a ser praticado, quando e se o fornecedor
for escolhido, pode integrar a SDP.
Outras informações importantes que devem constar da SDP são o tipo de contrato a ser praticado e a
minuta de contrato.
Solicitar propostas / cotações

O envio da solicitação de proposta ou de cotação aos potenciais fornecedores, também conhecido como
convite para licitação (CPL), pode ser realizado após o processo ou planejamento da aquisição estar definido.
Quando os fornecedores potenciais já estão identificados, a especificação do trabalho das aquisições está
pronta, o critério de seleção e demais aspectos para conduzir a aquisição já estão formalizados na solicitação de
proposta (SDP), basta enviá-la aos potenciais fornecedores que concorrerão pelo fornecimento.
Por vezes a SDP é formalizada como um edital que é publicado para que potenciais fornecedores tomem
conhecimento do projeto e se candidatem ao fornecimento. No caso de um edital de concorrência no setor
público, o Estado (governos federal, estadual ou municipal) precisa publicar o edital no Diário Oficial da União
(DOU) ou dependendo da aquisição, via sites de pregão eletrônico do governo.
Em resposta à SDP os fornecedores convidados elaboram e apresentam suas propostas. Eventualmente um

fornecedor convidado pode declinar do fornecimento por diferentes razões como, por exemplo, por entender
que não tem a competência técnica requerida pelo fornecimento, ou ainda, por entender que o trabalho tem
uma dimensão maior que a sua empresa tem capacidade para assumir.
A partir da publicação ou envio da solicitação, regularmente, o processo de aquisição é conduzido por

uma área especializada em comprar ou contratar fornecedores como, por exemplo, uma área de compras ou
procurement, ou mesmo, uma área de contratos. Essa área conduzirá o processo de aquisição, negociará termos
e condições conforme definido e concretizará a contratação do(s) fornecedor(es), com o devido apoio da equipe
técnica do projeto.
Realizar reunião com fornecedores

Após receberem e analisarem a solicitação os potenciais fornecedores podem ter dúvidas sobre o trabalho
a realizar e também sobre aspectos da contratação. Por esta razão é costumeiro que a SDP disponha uma forma
para que o fornecedor se comunique com a equipe no sentido de esclarecer a eventual dúvida. Regularmente
essa comunicação ocorre inicialmente por meio de um e-mail disponibilizado na SDP e que alcança a área que
conduz a aquisição, como a área de compras ou contratos.
Outra prática utilizada é a organização de reuniões com os potenciais fornecedores. Essas reuniões são
também conhecidas como bidder conferences. Nesta ocasião os fornecedores podem tirar suas dúvidas. As
dúvidas são esclarecidas durante a reunião e também compartilhadas com todos (via e-mail, por exemplo), pois
nem todos os fornecedores comparecem às reuniões.
Classificar propostas / cotações recebidas

Após o entendimento do trabalho a realizar os fornecedores apresentam suas propostas para o fornecimento.
A área que conduz o processo de aquisição (compras ou contratos) pode aplicar o critério definido para classificar
as propostas recebidas. A classificação pode considerar além do preço, prazos e condição de pagamento, outros
aspectos técnicos do fornecimento e, também por este motivo, terá o devido apoio técnico da equipe do projeto.
Selecionar fornecedor(es)
A classificação da proposta de um fornecedor em relação aos demais não determina imediatamente o
vencedor a ser contratado para o projeto. Antes disso, seguindo orientações que devem estar indicadas na SDP,
o fornecedor precisa apresentar certidões negativas de débitos junto a órgãos públicos como INSS, prefeitura,
além de comprovantes de recolhimento do FGTS, entre outros. Além destas comprovações pode ser requerido
do potencial fornecedor a apresentação de outras informações de crédito e que demonstrem a sua “saúde
financeira” e condição de assumir o compromisso do fornecimento. Também essas comprovações por parte do
fornecedor podem alterar a sua classificação e até eliminá-lo do processo de seleção de fornecedores.
Fornecedor(es) definido(s)?
A proposta que apresentar o conteúdo esperado e adequado aos requisitos do fornecimento especificados
na ETAq, com melhor pontuação resultante da aplicação do critério de seleção definido e cujo fornecedor
demonstre a competência e capacidade requeridos pelo fornecimento, definirá o(s) fornecedor(es) a ser(em)
contratado(s).
O processo de classificação e escolha do fornecedor pode levar a uma situação que exija solicitar nova
rodada de propostas de novos potenciais fornecedores, por exemplo, se os primeiros não se qualificarem para
o fornecimento.
Negociar e estabelecer acordo(s)

A área especializada em negociar, comprar e contratar fornecedores, como a área de compras ou procurement
ou de contratos, continuará o seu trabalho até o estabelecimento de um acordo com o(s) fornecedor(es)
definido(s). Normalmente esse acordo se formaliza por meio de um contrato no qual as partes envolvidas,
representantes legais do cliente (o projeto) e do fornecedor, são qualificadas. Os termos, direitos e obrigações
de cada parte são estabelecidos e constam no acordo/contrato. Datas de entrega parciais e final, assim como,
a respectiva contrapartida de pagamento também constam do acordo. A própria especificação do trabalho das
aquisições tende a integrar o acordo/contrato como um de seus anexos ou apêndices, também conhecidos
como aditivos do contrato.
No sentido de estabelecer um acordo legítimo entre as partes envolvidas a área jurídica das empresas,
do cliente e do fornecedor, é consultada. Por vezes, a área jurídica da empresa que empreende o projeto
(cliente) é consultada desde a sugestão da prévia ou minuta de contrato com as cláusulas a serem praticadas
na contratação.
Gerenciar acordo(s) e desempenho do fornecedor
O plano de gerenciamento das aquisições deve incluir a orientação de como o desempenho do fornecedor
será avaliado durante a realização de seu trabalho. Esta orientação se torna explicita ao fornecedor desde
a apresentação da solicitação de proposta (SDP) enviada ao potencial fornecedor. Observe que o plano de
gerenciamento das aquisições não é enviado ao fornecedor, sendo assim pode conter mecanismos de avaliação
do desempenho que não são explicitamente compartilhados com o fornecedor. Esse plano pode conter métricas
ou indicadores de desempenho (do fornecedor) que são apurados internamente pela equipe do projeto.
O fornecedor conhece as datas de entrega dos trabalhos contratados, das entregas parciais e final. Ele pode
saber que serão realizadas diligências para auditar o trabalho em andamento, apoiados por listas de verificação
ou checklists da qualidade. É importante que o fornecedor conheça os critérios para a aceitação de cada entrega
que ele realizará para o projeto. Além disso, o fornecedor, deverá apresentar o seu relatório de desempenho
(status report) com suas medições e demais informações. Pode inclusive alertar a equipe para questões em
aberto e que dependam da sua atuação (do cliente ou equipe do projeto) e respectiva solução, para que o
trabalho do fornecedor não seja prejudicado.
Por outro lado, a equipe pode apurar a sua versão para o desempenho do fornecedor, utilizando suas
métricas, seus indicadores de desempenho. Por exemplo, pode-se avaliar a pontualidade das entregas, o número
e gravidade das não-conformidades identificadas em auditorias de garantia de qualidade (durante as diligências
ao local do fornecedor) e também nas atividades do controle da qualidade para verificar cada entrega realizada,
com base no critério de aceitação definido, antes de formalizar o aceite da entrega realizada pelo fornecedor.
Normalmente, o acordo estabelecido entre o projeto e o fornecedor contratado contempla um sistema

de pagamentos. Por exemplo, o fornecedor pode receber o seu pagamento em contrapartida de uma entrega
realizada. Aliás, é uma boa prática estabelecer entregas parciais e frequentes do trabalho do fornecedor
para acompanhar o seu desempenho. Entregas menores e frequentes, além de serem mais fáceis de serem
gerenciadas, podem alertar para eventuais problemas com o fornecedor. Tais problemas podem ser tratados e
corrigidos mais cedo, colaborando para a obtenção de melhores resultados no projeto.
Não há uma regra para estabelecer a frequência ideal de entregas do fornecedor, porém, como todos temos
contas a pagar, regularmente, em frequência mensal, pode ser uma situação favorável a ambos, ao projeto e ao
fornecedor, definir a frequência mensal de pagamento ao fornecedor.
Requer replanejamento do projeto ou alteração do acordo?

Durante a realização do trabalho pelo fornecedor alguma mudança pode ser solicitada. Pode ser motivada
pelos resultados das atividades de gerenciamento da qualidade do projeto, quando não-conformidades foram
identificadas no trabalho ou nas entregas do fornecedor.
Além disso, o cliente do projeto pode solicitar uma mudança que impacta o trabalho já contratado e
negociado. Nesses casos, é possível que as atividades mudem, mesmo que já tenham sido planejadas e
negociadas anteriormente. Nesse caso, será necessária a formalização de uma solicitação de mudança no
trabalho do projeto, bem como poderá ser necessária a renegociação dos termos e condições já contratados.
Solicitar mudanças
A eventual solicitação de mudanças descreverá a necessidade e será gerenciada conforme o controle
integrado de mudança já definido para o projeto. Em função da possibilidade da mudança afetar também o
trabalho da aquisição, a avaliação do impacto no trabalho deve considerar todo o planejamento da aquisição,
inclusive a necessidade da revisão da especificação do trabalho das aquisições. A avaliação do impacto também
deve considerar a necessidade da revisão dos prazos, preços, entre outros. Em casos mais extremos, a avaliação
do impacto de uma mudança pode até desqualificar o fornecedor que está trabalhando para o projeto, porque a
mudança solicitada requer a aplicação de uma técnica ou processo para o qual o fornecedor não está preparado.
O gerenciamento que realiza uma aquisição precisa ter um processo de controle integrado de mudanças
que considere na avaliação do impacto, as implicações de uma renegociação de termos e condições contratados
com fornecedores. O impacto nas demais áreas de conhecimento tratadas pelo projeto também deve ser
considerado, conforme o controle integrado de mudanças definido para o projeto.
Encerrar aquisição(ões) e acordo(s)

O encerramento de uma aquisição se dá pela entrega final do trabalho realizado pelo fornecedor
acompanhado do respectivo termo de aceite emitido pela equipe do projeto. O aceite comprova a adequação
da entrega aos requisitos técnicos de qualidade definidos para o trabalho, que regularmente constam na
especificação do trabalho das aquisições.
Se a formalização do acordo entre o projeto e o fornecedor ocorreu por meio de um contrato este também
será encerrado. É usual que a entrega final seja acompanhada do respectivo pagamento, conforme o sistema
de pagamentos definido entre as partes. O término do contrato pode ocorrer conforme o esperado e acertado
inicialmente, no prazo previsto, ou ainda, o término ser antecipado.
A entrega antecipada do trabalho pode também antecipar o término do contrato. A escolha do tipo de
contrato a ser praticado, por exemplo o tipo de contrato de preço fixo, também conhecido como preço global
ou fechado, se for incentivado, pode motivar o fornecedor a entregar mais cedo.
Por outro lado, o baixo desempenho do fornecedor durante a realização do trabalho, ou ainda, na qualidade
de suas entregas também pode motivar o término antecipado do contrato. Nesse caso o término pode ter o
acordo de ambas as partes e ser realizado o distrato, ou ainda, sem acordo entre as partes, o que pode motivar
um término litigioso. Nesse caso a disputa será realizada judicialmente.
O acordo formalizado entre as partes deve prever os termos e condições de término do contrato.
Fatores Críticos de sucesso

• Deve-se definir de forma clara e inequívoca o que será comprado/contratado.
• O gerente deve ter um bom conhecimento a cerca das cláusulas do instrumento contratual, para poder
assim melhor conduzir a relação cliente-fornecedor durante a vigência do contrato.
• A comunicação entre cliente e fornecedor também merece cuidados, sobretudo a formal, que se
transformará em adendos do contrato.
• Garantir que o contrato foi aprovado devidamente, respeitando as políticas e alçadas.
• Padronização e maior controle das cláusulas e termos contratuais.
• Rastreabilidade de mudanças e garantia de que se estará trabalhando sempre com a versão correta.
Planejar o gerenciamento das aquisições (12.1)
Este processo identifica quais necessidades do projeto podem ser melhor atendidas pela compra ou
aquisição de produtos ou serviços. Envolve ainda a consideração de como, o que, quanto, se e quando adquirir
e também a consideração e escolha de possíveis fornecedores. Adicionalmente, este processo inclui a análise
dos riscos envolvidos em cada decisão de fazer ou comprar; a análise do tipo de contrato planejado para ser
usado em relação à mitigação de riscos e transferência de riscos para o fornecedor.
O processo
Entradas
Do termo de abertura podemos extrair informações a respeito dos objetivos do projeto, a sua descrição,
o resumo dos marcos e dos recursos financeiros pré-aprovados. Essas informações são importantes para as
decisões de fazer ou comprar.
Documentos de negócios
• Business case: é importante alinhar as estratégias de aquisição com as informações constantes do
business case.
• Plano de gerenciamento de benefícios: este plano indica quando e quais benefícios estarão disponíveis
para as partes interessadas. Sendo assim, as datas de aquisição de materiais e equipamentos, bem
como assinaturas de contrato devem estar alinhados com esse plano.

Plano de gerenciamento do escopo: deste plano extraimos informações a respeito de como o escopo do
trabalho de terceiros e contratados será gerenciado.
Plano de gerenciamento da qualidade: neste plano são estabelecidos os padrões de qualidade que tanto a
empresa executora, quanto os demais contratados deverão adotar.
Plano de gerenciamento dos recursos: este plano contém informações a respeito de quais recursos serão
comprados ou arrendados.
Linha de base do escopo: esta linha de base contém o escopo que servirá de base para a construção da
especificação do trabalho que é uma das saídas deste processo. Além disso, a partir da especificação do escopo
do projeto pode-se avaliar o que será produzido internamente e o que será adquirido externamente.
• Lista de marcos: a lista de marcos deve conter as principais datas de entregas de fornecedores e
contratados.
• Designações da equipe do projeto: este documento contém a lista de habilidades da equipe do projeto.
É importante que pessoas treinadas em compras e aquisições participem dessas atividades. Caso não
existam pessoas disponíveis, o gerente do projeto deve providenciá-las.
• Documentação dos requisitos: a documentação dos requisitos, gerada durante o grupo de processo
de planejamento do escopo, pode dar informações importantes de forma a auxiliar em decisões de
fazer ou comprar e também com relação a requisitos de ordem legal/governamental, tais como: saúde,
proteção, segurança, seguros, meio ambiente, licenças, empregos etc.
• Matriz de rastreabilidade de requisitos: esta matriz é usada em conjunto com a documentação de

requisitos.
• Requisitos de recursos: este documento contém informações de requisitos de recursos necessários ao

processo de aquisições.
• Registro dos riscos: este registro contém os riscos identificados do projeto. Alguns riscos são transferidos
para fornecedores como parte do processo de aquisições.
• Registro das partes interessadas: este registro fornece a lista das partes interessadas e suas influências
no projeto. É importante verificar quais dessas partes pode influenciar as decisões relativas às aquisições.
Fatores Ambientais da empresa

Existem inúmeros fatores ambientais que podem afetar o projeto. No caso especifico das aquisições temos:
condições de mercado, produtos e serviços disponíveis, fornecedores da organização, termos e condições de
compra, requisitos locais etc.

Basicamente os ativos de processos organizacionais que afetam este processo estão relacionados aos
procedimentos e políticas de compras da organização.
As políticas organizacionais frequentemente restringem as decisões de aquisição. Essas restrições podem

incluir a limitação do uso de pedidos de compra simples, a exigência de que todas as compras acima de um
determinado valor usem um contrato mais longo, a exigência de contratos específicos, a limitação da capacidade
de tomar decisões de fazer ou comprar, e a limitação ou a exigência de tipos ou tamanhos específicos de
fornecedores.
Muitas vezes não é o gerente que executará a aquisição e sim o departamento responsável por isso dentro
da organização. Assim, o papel do gerente será o de suprir esse departamento com as informações necessárias
para que a aquisição seja realizada corretamente.
O Guia PMBOK® também cita como ativo de processo organizacional os tipos de contratos que já vimos:
preço fixo, custo reembolsável e tempo e materiais, bem como suas variantes.
A opinião especializada poderá ser utilizada de diversas formas, entre as quais citamos:
• Ajudar a definir os critérios de escolha de fornecedores.
• Definir termos e condições do contrato (a área jurídica da empresa será imprescindível aqui).
Coleta de dados
As equipes de aquisições pesquisam em diversas fontes os potenciais fornecedores para o projeto.
Análise de dados
A técnica de análise de dados usada aqui é a análise de fazer ou comprar que tem como objetivo garantir
que o trabalho será feito da melhor forma para o projeto de acordo com as políticas organizacionais da empresa
executora e de acordo com as expectativas das principais partes interessadas.
Fazer ou comprar faz referência ao trabalho interno ou externo. “Fazer” significa que o trabalho será feito
pela equipe interna do projeto ou um recurso interno já existente será usado. “Comprar” significa que a execução
do trabalho será repassada a um terceiro. Dentro do significado de “comprar”, pode ainda estar incluída uma
sub-análise para determinar a melhor opção entre adquirir ou arrendar/alugar o recurso.
Análise para seleção de fontes

Uma decisão de compra pode envolver diferentes critérios, tais como:
• Risco: o conjunto de fatores para determinar se um produto ou serviço deve ser feito internamente
ou comprado pode envolver o gerenciamento dos riscos. Por exemplo, uma empresa pode decidir
terceirizar um trabalho ainda que saia mais caro no final, pois desta forma ela está transferindo ou
compartilhando o risco relacionado a ele.
• Qualidade: uma organização pode ter uma equipe livre para a execução de um trabalho, porém esta
equipe é inexperiente ou não possui conhecimento avançado sobre o produto ou serviço a ser feito.
Para eliminar a possibilidade de desvios na qualidade, a organização pode optar por contratar uma
empresa com maior conhecimento técnico do trabalho a ser realizado.
• Disponibilidade: o gerente pode se deparar com situações onde equipamentos não estão disponíveis
no momento em que o projeto precisa deles. Neste caso, a melhor opção, ainda que saia mais caro,
pode ser a aquisição ou aluguel do equipamento para que o cronograma do projeto não seja afetado.
• Tipo de contrato: os tipos de contratos disponíveis ao gerente junto aos departamentos de aquisições
podem nortear a decisão por fazer ou comprar. Por exemplo, se apenas o contrato de preço fixo estiver
disponível para a aquisição de um serviço que não está com o escopo bem definido pode-se optar por
fazer o trabalho internamente ainda que o custo seja maior, pois é conhecido que contratos de preço
fixo não são recomendados para trabalhos que possam exigir mudanças durante a sua execução.
• Propriedade intelectual ou informação sensível estratégica: um trabalho pode custar mais barato se
terceirizado, porém dependendo da idoneidade do fornecedor, da sensibilidade da informação e das
leis de proteção à propriedade intelectual do país do fornecedor, pode-se optar por fazer o trabalho
internamente.
• Custos: um dos critérios mais comumente usados para a análise de fazer ou comprar é o custo. O critério
do custo é muito simples: se produzir for mais barato então a empresa opta por fazer, caso comprar seja
mais barato, então a empresa opta por comprar.
O uso da árvore de decisão pode ser muito útil, pois ela ajuda na avaliação de diversas opções fornecendo
os possíveis resultados de cada uma delas.
Reuniões
As reuniões são utilizadas como complemento para reunir potenciais licitantes para troca de informações.
Assim, todas as eventuais dúvidas poderão ser sanadas antes que os fornecedores enviem suas propostas.
Saídas
Plano de gerenciamento das aquisições
O plano de gerenciamento de aquisições descreve como os processos de aquisição serão gerenciados desde
o desenvolvimento da documentação de aquisição até o encerramento do contrato. Este plano pode incluir:
• Tipos de contratos a serem usados.
• Documentos de aquisição padronizados caso sejam necessários.
• Restrições e premissas que podem afetar as compras e aquisições planejadas.
• Estimativa de recursos e desenvolvimento do cronograma.
• Estabelecimento da orientação a ser oferecida aos fornecedores sobre desenvolvimento e a manutenção
de uma estrutura analítica do projeto contratado.
• Estabelecimento do formato que será utilizado para a especificação do trabalho das aquisições.
• Identificação de fornecedores pré-qualificados selecionados.
• Métricas de aquisição a serem usadas para gerenciar contratos e avaliar fornecedores.
• Coordenação de aquisições com outros projetos da organização.
• Identificação de obrigações contratuais de seguros para mitigar riscos do projeto.
Documentos de licitação
Esses documentos são utilizados em todos os processos de Aquisições, porém, possuem objetivos e formatos
distintos que variam de acordo com o processo em que se está. Tais documentos devem ser:
• Estruturados para propiciar respostas corretas e completas;
• Rigorosos para garantir consistência, e respostas equivalentes;
• Flexíveis para permitir sugestões dos fornecedores quanto às melhores formas de atender aos requisitos.
Devem incluir:
• Especificação do trabalho;
• Descrição da forma desejada de resposta; e
• Quaisquer cláusulas contratuais necessárias.
Conforme o tipo de solicitação poderá ser usado um dos seguintes documentos de aquisição abaixo:
Nome do documento Sigla Uso
Solicitação de Informação / SDI Coletar informações do fornecedor
Request for Information RFI (pré-qualificação).
Pode ser usado para determinar quais
produtos estão no mercado para
atender uma necessidade da empresa.
Solicitação de Cotação / SDC Buscar cotação da aquisição.
Request for Quotation RFQ Discussões entre os concorrentes não
são necessárias.
Preço é o fator principal na negociação.
Solicitação de Proposta / SDP Escopo deve estar claro, bem definido e

Request for Proposal RFP mensurável.
Solicitação de proposta técnica/
comercial.
Exige proposta mais elaborada e
critérios mais complexos.
Convite para licitação CONV Comprador especifica detalhadamente
o produto e a solução.
Fornecedor responde com uma licitação
que especifica o preço.
É importante observar que a complexidade e o nível de detalhes desses documentos variam com a
complexidade e riscos associados à solução. E em contratos governamentais, o conteúdo e a estrutura desses
documentos são definidos por leis (por exemplo: a lei 8.666 de 1993).
Especificação do trabalho das aquisições

Na especificação do trabalho (ET) das aquisições é feita a descrição em detalhes do trabalho a ser realizado
ou dos produtos a serem entregues. Deverá ser redigida de tal forma que os fornecedores que serão consultados
entendam o que deverá ser entregue e que também possam elaborar suas propostas.
Deve-se ter em mente que o que está implícito para quem está escrevendo pode não estar para quem está
lendo, por isso, este documento deve fornecer informação suficiente para o vendedor criar e precificar uma
proposta aderente a necessidade do projeto.
Para que serve a especificação do trabalho?

Sempre que for necessário solicitar a intervenção de um fornecedor externo, ou interno, deve ser criado
esse documento. Ele ajuda a esclarecer o que é que o cliente espera do seu fornecedor e os prazos em que o
trabalho deve ser concluído.
A criação de uma especificação de trabalho, para ser disponibilizada aos fornecedores, é um passo
fundamental para que estes compreendam melhor a sua empresa e as suas necessidades. Este documento é a
maneira formal de comunicar aos fornecedores as razões que sustentam determinada necessidade contribuindo
de forma decisiva para que o fornecedor, desde uma fase inicial do projeto, tenha a percepção correta sobre
aquilo que o cliente deseja.
Critérios de seleção de fontes

Outro ponto importante neste processo diz respeito à elaboração dos critérios que serão utilizados para
a avaliação de propostas. Eles deverão ser adequados ao cenário em que se encontra o projeto, ou seja,
devem ser aderentes às necessidades do projeto, caso contrário poderão levar ao aumento desnecessário dos
preços da proposta ou à eliminação precoce de um potencial proponente. Os critérios podem ser obrigatórios
(eliminatórios ou pré-requisitos) ou facultativos (classificatórios), avaliando o fornecedor ou o produto/serviço.
Vários critérios poderão ser considerados, como preço, prazo de entrega, experiência do fornecedor, nível
de atendimento das especificações e qualificações específicas.
Decisões de fazer ou comprar

Esta saída é resultado da execução da ferramenta análise fazer ou comprar. Caso seja decidido fazer o
item internamente, o plano de aquisições deve definir os processos e acordos internos da organização. Mas
caso seja decidido comprar, os demais processos desta área de conhecimento deverão ser executados (caso a
organização não possua nenhum processo interno de aquisições).
Solicitações de mudanças
As decisões de fazer ou comprar geram solicitações de mudança que deverão ser processadas pelo processo
Realizar o controle integrado de mudanças, que será visto quando abordarmos o grupo de processos de
monitoramento controle.
Por exemplo, durante a elaboração do escopo, definiu-se que seria necessário um componente específico
(do tipo Single Sign On) para o controle de login de usuários. Após algumas avaliações chegou-se a um impasse,
se o componente fosse desenvolvido internamente, seriam necessários mais quatro meses do que o previsto
para a entrega do software. Há também a opção de comprar o componente de fornecedores da solução, no
entanto o projeto também atrasaria, mas neste caso apenas dois meses. Além do atraso, o custo de aquisição
do componente e da sua manutenção estão muito além do orçamento do projeto. Sendo, assim a opção fazer
internamente seria a opção a ser escolhida, o que geraria mudanças no escopo, custo, prazo, critérios de
qualidade etc que precisam ser avaliados e controlados pelo Controle integrado de mudanças.
Como em todos os processos de planejamento, podem ocorrer alterações a serem realizadas nos documentos
do projeto. Por exemplo, as decisões de fazer internamente determinados itens do escopo podem afetar os
documentos de requisitos, matriz de rastreabilidade dos requisitos e registro dos riscos, entre outros.
Planejando as Partes Interessadas
Este é o último processo de planejamento. Mas mesmo sendo o último, não é o menos importante.
Um dos grandes erros em um projeto é acreditar que apenas o cliente e o patrocinador são os únicos
interessados nele.
Como já vimos no grupo de processos de Iniciação, as partes interessadas são pessoas e organizações
ativamente envolvidas no projeto ou cujos interesses podem ser afetados como resultado da sua execução ou
do seu término. Eles podem também exercer influência sobre os objetivos e resultados do projeto.
A equipe de gerenciamento precisa dedicar uma atenção especial ao gerenciamento das partes interessadas,
determinando suas necessidades e expectativas e, na medida do possível, gerenciando sua influência em
relação aos requisitos para garantir um projeto bem sucedido.
Gerenciar uma parte interessada importante de forma negligente pode arruinar o projeto, por isso o
gerente do projeto deve dedicar especial atenção à este processo.
O Guia PMBOK® recomenda o seguinte processo de planejamento:
• Planejar o gerenciamento das partes interessadas (13.2).
com sucesso.

• Identificar os envolvidos logo no início do projeto;
• Estabelecer os critérios de comunicação de cada parte interessada;
• Ficar sempre atento, pois novas partes interessadas poderão surgir à medida que o projeto progride;
• Estabelecer planos de ação para gerenciar as expectativas das principais partes interessadas.
Planejar o gerenciamento das partes interessadas
(13.2)
Planejar o gerenciamento das partes interessadas tem como objetivo desenvolver estratégias para quebrar
as resistências das partes interessadas, entender suas necessidades e garantir seu engajamento no projeto.
O gerenciamento das partes interessadas é praticamente um trabalho “full-time”, ou seja, o gerente do

projeto e sua equipe estarão constantemente verificando se as expectativas estão sendo atingidas, e se tais
partes estão causando impactos tanto positivos quanto negativos no projeto.
O envolvimento e o poder de influência das partes interessadas variam de acordo com o progresso do
projeto. É muito importante que elas sejam engajados bem no início, pois são delas muitas das decisões
importantes relativas a custos, escopo e prazos de entrega.
É comum que a medida que o projeto progride, o envolvimento das partes interessadas se reduza, mesmo
assim, é dever do gerente do projeto e de sua equipe mantê-las informadas e engajadas com o projeto.
Principais partes interessadas (stakeholders)

Partes interessadas no projeto são pessoas e organizações ativamente envolvidas no projeto ou cujos
interesses podem ser afetados como resultado da execução ou do seu término. Elas podem também exercer
influência sobre os objetivos e resultados do projeto.
Como exemplo de partes interessadas podemos citar:
• Cliente: é a pessoa (ou organização) que recebe o produto (resultado) do projeto. É dele, geralmente,
a responsabilidade por definir requisitos e verificar se o produto está de acordo com esses requisitos.
• Usuário: é a pessoa (ou grupo de pessoas) que efetivamente usará o produto do projeto. Por exemplo,
a empresa A contrata a empresa Z para desenvolver e implantar um novo sistema de Contas a Pagar. A
empresa A é cliente e os funcionários do seu departamento Financeiro são os usuários.
• Patrocinador: é a pessoa (ou grupo de pessoas) da alta direção que disponibiliza os recursos financeiros
e apoia integralmente o projeto. Quando o gerente de projeto se depara com questões que estão fora
de sua alçada é para o patrocinador que ele deve pedir ajuda. O patrocinador detém o maior grau de
autoridade no projeto e são dele as decisões importantes em caso de divergência. O patrocinador é
provavelmente a Parte Interessada mais importante do projeto.
• Organização executora: é a organização responsável pela execução do trabalho e pelo gerenciamento

dos recursos. Observe que não há obrigatoriedade da empresa executora ser a mesma empresa que
gerencia o projeto.
• Gerente funcional (ou de linha): o gerente funcional pode disponibilizar recursos para o projeto,
negociando com o gerente do projeto os recursos envolvidos. Ele também pode estar envolvido no
planejamento e no controle das atividades relativas à sua área. É comum ocorrerem conflitos de
interesse entre o gerente funcional e o gerente do projeto por recursos.
• Equipe do projeto: são todos aqueles envolvidos nas atividades previstas do projeto. Podem ser:
especialistas, clientes, usuários, fornecedores, parceiros e a equipe de gerenciamento do projeto.
• Equipe de gerenciamento do projeto: o gerente não é necessariamente o único elemento que gerencia
o projeto. Essa responsabilidade pode ser compartilhada com uma parte da equipe do projeto.
As partes interessadas podem exercer influência sobre o projeto, suas entregas e sobre os membros da
equipe do projeto.
O processo
Entradas
É no termo de abertura que as principais partes interessadas são indicadas.

Plano de gerenciamento dos recursos: este plano contém informações sobre os papéis e responsabilidades
de todos os envolvidos.
Plano de gerenciamento das comunicações: as comunicações e o engajamento das partes interessadas são
fortemente vinculados, já que as partes interessadas devem sempre estar informadas sobre o andamento do
projeto
Plano de gerenciamento de riscos: este plano contém informações sobre os limites de riscos que as partes
interessadas estão dispostas a correr e assim pode ajudar a desenvolver estratégias de engajamento e controle
dessas partes.
• Registro de premissas: algumas premissas e restrições podem ter sido elaboradas por alguma parte
interessada muito importante, por isso devemos tê-la em consideração ao preparar este plano.
• Registro de mudanças: este registro contém as principais mudanças efetuadas no escopo do projeto. A
maior parte das mudanças vêm das partes interessadas .
• Registro das questões: muitas vezes a solução de problemas apontados no registro das questões exigirá
a participação de uma parte interessada.
• Cronograma do projeto: algumas entregas do projeto podem estar vinculadas a participação de alguma
parte interessada, por isso é importante que o cronograma reflita isso.
• Registro de riscos: alguns riscos vêm justamente de partes interessadas que de alguma forma podem
prejudicar o projeto.
• Registro das partes interessadas: este registro fornece a lista das partes interessadas e suas influências
no projeto.
Acordos
Ao planejar o engajamento das partes interessadas devemos também considerar os eventuais fornecedores
e contratados, porque eles também são partes interessadas no projeto.

Fatores ambientais são qualquer norma, guia de processos ou sistema organizacional que pode influir
no desenvolvimento do projeto. No caso específico deste processo, podem envolver a cultura, a estrutura
organizacional e o ambiente da empresa.

Os ativos de processos organizacionais são políticas, modelos ou informações históricas que podem
influenciar ou impactar no projeto. No caso específico deste processo podem envolver lições aprendidas e
os registros de Partes interessadas de projetos anteriores. Nesses documentos podemos obter importantes
informações a respeito de como é a dinâmica de trabalho das partes interessadas e quais as melhores estratégias
para lidar com elas.
Entre em contato com outros gerentes de projeto, membros da equipe que já participaram de outros
projetos, gerentes do departamento de recursos humanos etc. Seu superior imediato também pode ser uma
boa fonte de apoio neste processo.
Não exite em buscar a opinião e o conhecimento especializado de grupos ou pessoas. Você pode obter
essas informações a partir de consultas individuais (reuniões, entrevistas) ou em painéis (grupos de discussão,
pesquisas de opinião etc).
Imagine a seguinte situação, você acaba de ser promovido a gerente de projetos (meus parabéns!!) e
como um bom GP está preparando seu plano de projeto. Neste momento você está entrando na parte de
planejamento do gerenciamento das partes interessadas.
Muito bem. Você conhece bem o seu chefe, mas mal teve contato com o chefe dele. E só conhece “de
nome” os chefes de outros departamentos que irão fornecer recursos humanos para o seu projeto. E para
piorar, é bem provável que essa turma não te conheça. E agora? Como fazer para engajar todas essas pessoas
para que seu projeto seja visível e bem quisto?
Coleta de dados
Uma técnica de coleta de dados sugerida é o benchmarking, que utiliza informações de outras organizações
para estabelecer as suas melhores práticas.
Análise de dados
As técnicas aqui sugeridas são a análise de premissa e restrições que podem afetar o projeto, e a análise de
causa-raiz que avalia possíveis motivos para o apoio ou a falta dele por parte das principais partes interessadas.
Tomada de decisão
Para a tomada de decisão pode ser utilizada a técnica de priorização, já que a depender da parte interessada,
alguns itens do projeto devem ser realmente priorizados.
Mapeamento mental
Já vimos o que é um mapa mental. Aqui pode-se elaborar um mapa com as principais partes interessadas e
seus relacionamentos com a organização e com o projeto.
Matriz de avaliação do nível de engajamento das partes interessadas
O nível de engajamento deve ser estabelecido para que possa ser comparado com o nível de engajamento
desejado em determinada fase do projeto. O nível de engajamento pode ser classificado da seguinte forma:
• Desinformado: não tem conhecimento do projeto e impactos potenciais. Este é um tipo que pode vir a
ser prejudicial ao projeto, pois caso venha a ter conhecimento sobre o projeto de forma tardia pode se
sentir “traído” e jogar contra.
• Resistente: é ciente do projeto e de seus impactos, e mesmo assim é resistente a ele. Realmente não
dá para agradar a todos. Muitas vezes encontraremos pessoas que são contra, algumas vezes por serem
contra tudo, ou muitas vezes por não estarem convencidos de que serão beneficiados de alguma forma.
• Neutro: sabe que o projeto existe, mas não quer se envolver. Mesmo sendo neutro, este tipo pode ser
prejudicial ao projeto, pois muitas vezes precisaremos de seu apoio e ele simplesmente não retornará
as ligações tampouco e-mails.
• Dá apoio: sabe que o projeto existe e o apoia. Aqui temos uma parte interessada que realmente é
benéfica ao projeto. Embora não atue ativamente, sempre estará falando bem do projeto e tentará
convencer os tipos anteriores a mudarem de opinião.
• Lidera: sabe que o projeto existe e está ativamente engajado em garantir o êxito do projeto. Geralmente
são os patrocinadores que se encaixam neste nível.
Vamos a um exemplo. A tabela a seguir mostra três partes interessadas com diferentes níveis de
engajamento. O “C” representa o engajamento Corrente (atual) e o “D”, o engajamento Desejado. Veja que
somente o Diretor de Inovação apresenta o nível de engajamento Corrente igual ao Desejado. Os demais
deverão ser “trabalhados” para que evoluam até o nível desejado.
Parte interessada Desinformado Resistente Neutro Dá apoio Lidera

Diretor financeiro C D
Diretor Suporte TI C D
Diretor Inovação DC
O engajamento das partes interessadas no nível desejado durante todo o ciclo de vida do projeto é
essencial para o êxito do projeto.
Reuniões
As reuniões podem ser usadas para reunir os especialistas e a equipe para definir o nível de engajamento
das partes interessadas que serão acrescentados ao plano de gerenciamento.
Saídas
Plano de gerenciamento das partes interessadas
O plano resultante deste processo é parte integrante do plano de gerenciamento do projeto e tem como
objetivo identificar estratégias requeridas para engajar efetivamente as principais partes interessadas. O ideal é
que este plano contenha as seguintes informações:
• Informações recolhidas do registro das partes interessadas;
• Tabela com os níveis correntes e desejados de engajamento;
• Requisitos de comunicação especificados por fase do projeto;
• Informação a ser distribuída, incluindo: linguagem, formato, conteúdo, nível de detalhe etc;
• Frequência da distribuição das informações.

Apostila 3 Se o Planejamento

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila 3 Se o Planejamento

Enviado por

Direitos autorais:

Formatos disponíveis

SEJA PMP ®

O planejamento apresenta as seguintes características:

• É um processo permanente e contínuo, ou seja, a função de planejar é realizada a todo momento

Segundo o Guia PMBOK®, desenvolver o plano de gerenciamento de projeto é o processo de documentação

O plano de gerenciamento do projeto é atualizado principalmente pelos processos de planejamento,

Saídas de outros processos

Fatores ambientais da empresa

Ativos de processos organizacionais

Habilidades interpessoais e de equipe

Planos auxiliares Descrição Área de

Plano de É o documento que 4 – integração

• Planejar o gerenciamento do escopo (5.1);

• Coletar os requisitos (5.2);

• Definir o escopo (5.3);

• Criar a EAP (5.4).

Escopo projeto x escopo produto

O gerenciamento e o controle do escopo do projeto difere do gerenciamento e controle do escopo do

Escopo Medição Critério de aceitação

Scope Creep e Gold Plating

Fatores críticos de sucesso

Plano de gerenciamento do projeto

Fatores ambientais da empresa

Ativos de processos organizacionais

Plano de gerenciamento dos requisitos

Os itens recomendados que este plano deve conter são:

• Como serão as atividades para coletar e gerenciar os requisitos;

• Como as mudanças serão tratadas;

• Como será a estrutura de rastreabilidade dos requisitos;

• Como será o gerenciamento da configuração.

• Requisitos de facilidade de uso ou de usabilidade: referem-se ao esforço para utilizar ou aprender

• Requisitos de confiabilidade: referem-se à frequência de ocorrência de falhas. Exemplo: “A impressora

• Requisitos de eficiência: referem-se ao desempenho do produto/serviço e estão associados à eficiência,

• Requisitos éticos - exemplo: código de ética do cliente, do PMI, da empresa etc.

• Requisitos legais - exemplo: leis, normas ABNT etc.

O sucesso do projeto é diretamente influenciado pela atenção na captura e gerenciamento dos

Plano de gerenciamento do projeto

• Plano de gerenciamento do escopo: o plano de gerenciamento do escopo do projeto fornece orientação

• Plano de gerenciamento dos requisitos: este item é um componente do plano de gerenciamento do

Fatores ambientais da empresa

Ativos de processos organizacionais

• Requisitos: é necessária a participação de um grupo representativo de partes interessadas. Deve ser

• Vantagens: facilidade de aplicação, processo e análise; facilidade e rapidez no ato de responder;

• Requisitos: as informações a serem recolhidas precisam ser públicas.

• Vantagens: serve como complementação de informações obtidas por outros métodos.

• Desvantagens: pode ser um processo demorado dependendo da quantidade de informação a ser

Método de Descrição Vantagem Desvantagem

Análise de decisão envolvendo múltiplos critérios

• Requisitos: critérios de avaliação devem estar bem definidos.

• Desvantagens: por se tratar de um método um pouco demorado o “diagrama de afinidades” não é

• Vantagens: possibilita visualizar claramente os requisitos e estimula a criatividade dos participantes.

Habilidades interpessoais e de equipe

• Requisitos: é necessária a participação de um grupo representativo de partes interessadas. Deve ser

• Requisitos: o observador deve ter experiência na técnica.

• Vantagens: agrega informações de diversas áreas.

O Guia PMBOK® cita três técnicas famosas:

Roteiro para construção

Fluxo de dados Fluxo de dados

Exemplo de diagrama de contexto:

Existem dois tipos de protótipos:

Protótipos descartáveis ou exploratórios: o protótipo é descartado após a fase inicial de identificação de

• Vantagens: identificação antecipada de erros e possíveis modificações, reduzindo custo de

É muito importante que as principais partes interessadas aprovem a documentação de requisitos,

Matriz de rastreabilidade dos requisitos