Gerenciamento Cronograma Custos Projetos v4 20181105

MÓDULO 1 1
GERENCIAMENTO DO
CRONOGRAMA E DOS
CUSTOS EM PROJETOS
P324 Paula, Fábio
Gerenciamento do Cronograma e dos Custos / Fábio Paula.

Revisado e atualizado por Leonardo Monteiro de Magalhães – 1. ed.
rev. atual. e ampl. - Rio de Janeiro: Grupo Ibmec Educacional, 2018.
125 p.; 20x26 cm

Inclui bibliografia
1. Gerenciamento de projetos 2. Cronograma em projetos –

estimativa e desenvolvimento 3. Cronograma em projetos – controle
e outros métodos 4. Gerenciamento dos custos em projetos I. Fábio
Paula II. Ibmec Online III. Título.
CDD: 658.404
SUMÁRIO
CAPÍTULO 1 GERENCIAMENTO DO CRONOGRAMA EM PROJETOS 8
Unidade 1 A conceituação 11
Unidade 2 O planejamento do gerenciamento do cronograma e a definição

das atividades 14
Unidade 3 O sequenciamento das atividades 23
CAPÍTULO 2 GERENCIAMENTO DO CRONOGRAMA EM PROJETOS –

ESTIMATIVA E DESENVOLVIMENTO 31
Unidade 1 A estimativa da duração das atividades 34
Unidade 2 Os comportamentos prejudiciais ao sucesso do projeto 41
Unidade 3 O desenvolvimento do cronograma 44
CAPÍTULO 3 GERENCIAMENTO DO CRONOGRAMA EM PROJETOS –

CONTROLE E OUTROS MÉTODOS 61
Unidade 1 Controlar o cronograma 64
Unidade 2 Método da Corrente Crítica 70
Unidade 3 Método Ágil em Gerenciamento de Projetos 76
CAPÍTULO 4 GERENCIAMENTO DOS CUSTOS EM PROJETOS 90
Unidade 1 Conceituação 93
Unidade 2 Estimar os custos 102
Unidade 3 Determinar o orçamento 107
Unidade 4 Controlar os custos 112

4 ESTRATÉGIA EMPRESARIAL
INTRODUÇÃO
O gerenciamento eficaz de um projeto Logo, se o projeto não for entregue em

demanda um conhecimento amplo de tempo, a oportunidade será perdida. E
seu gerente. Porém, de todas as áreas se os custos ultrapassarem os ganhos
que são igualmente importantes para que estimados, haverá prejuízo. Ou, ainda,
os resultados do projeto sejam positivos, em uma situação em que o projeto é
a gestão do cronograma e dos custos, feito para implementar a redução de
frequentemente, recebe maior atenção das custos, quanto mais atrasado, mais
empresas e dos gestores. dinheiro será perdido. Além disso, o
custo da iniciativa não pode ultrapassar
A preocupação com essas duas áreas, a economia obtida.
independentemente do nível de
maturidade da gestão de projetos da Por esse motivo, a disciplina
companhia, está diretamente atrelada Gerenciamento do Cronograma e
aos motivos pelos quais o projeto foi dos Custos em Projetos se propõe
demandado. A demanda costuma ser feita a ajudar o aluno a gerenciar melhor
para aproveitar uma oportunidade de o cronograma e o custo de seus
negócios em uma determinada época e projetos, utilizando as melhores práticas
que possui um determinado retorno. disponibilizadas pelo Guia PMBOK®,
além de outras difundidas na literatura
sobre Gerenciamento de Projetos.
MÓDULO 1 5
OBJETIVOS DA DISCIPLINA
Após concluir o estudo da disciplina Gerenciamento do Cronograma e dos Custos em Projetos,

você será capaz de:
■■ entender os principais conceitos referentes a tempo e a custo em projetos;
■■ planejar e controlar o tempo em um projeto, utilizando as melhores práticas indicadas

no Guia PMBOK®;
■■ desenvolver e controlar um cronograma de maneira eficiente, utilizando as melhores

práticas indicadas no Guia PMBOK®;
■■ planejar e controlar os custos de um projeto, utilizando as melhores práticas indicadas

no Guia PMBOK®.
MENSAGEM DO PROFESSOR
Caro(a) aluno(a),
Caro(a) aluno(a),
Você inicia agora uma jornada por um assunto muito importante em sua formação. Quando
abordamos temas como cronograma e custos, referimo-nos a dois dos fatores mais valo-
rizados pelas empresas, em momentos decisivos em relação ao projeto: escolher, iniciar,
cancelar ou continuar. Isso se deve ao fato de que tempo e custo são fundamentais para que
a oportunidade de negócios, a qual o projeto se propõe a implementar, tenha um retorno
positivo, geralmente financeiro. Outro ponto importante em relação a esses fatores é o fato
de serem fundamentais na estruturação da gestão de projetos das companhias, pois, ge-
ralmente, é por meio do planejamento e do controle do cronograma e dos custos que essa
estruturação começa a ser implementada. Por outro lado, também representam restrições
significativas em grande parte das situações.
Esperamos que este curso ajude você a entender melhor como planejar, monitorar e contro-
lar o cronograma e os custos de seus projetos, de forma que possa atender às necessidades
da empresa para a qual trabalha ou venha a trabalhar. Lembre-se de aproveitar ao máximo
os recursos oferecidos no material didático da disciplina e as interações que terá com seu
professor on-line e seus colegas. Use o espaço para discutir os conceitos tratados em cada
capítulo e tente associá-los à sua realidade. Seu engajamento é essencial para o alcance do
sucesso nesta jornada.
Bons estudos!
Equipe Ibmec online
DIRETRIZES PEDAGÓGICAS
Tenha sempre em mente que você é o principal agente de sua aprendizagem!
Para um estudo eficaz, siga estas dicas:
■■ organize o seu tempo e escolha os melhores dias e horários para você estudar;
■■ consulte a bibliografia e o material de apoio caso tenha alguma dúvida;
■■ releia o conteúdo sempre que achar necessário;
■■ leia as indicações de textos complementares, faça os exercícios de feedback automático

e participe dos fóruns com o seu professor e colegas de turma.
Para o sucesso nessa disciplina e o total aproveitamento do conteúdo, é imprescindível que

você reflita sobre os conceitos teóricos tentando aplicá-los na prática.
Não deixe de participar das discussões encadeadas no ambiente virtual de cada capítulo.
Elas são indispensáveis para um melhor aproveitamento do curso.
Bons estudos!
8 GERENCIAMENTO DO CRONOGRAMA E DOS CUSTOS EM PROJETOS
Capítulo 1
GERENCIAMENTO DO
CRONOGRAMA EM PROJETOS
CAPÍTULO 1 9
INTRODUÇÃO
Sempre que nos deparamos com um projeto, pronto na data marcada para o procedimento
desde uma simples reorganização das pastas de administrativo), ou o impacto financeiro pode ser
rede de uma empresa até a construção de uma significativo (digamos que uma companhia tenha
hidrelétrica, devemos ter consciência de que iniciado um projeto para adaptar seu sistema
esse trabalho foi demandado para atender a uma contábil a uma nova norma legal, e esse prazo não
necessidade da companhia ou para aproveitar é cumprido, acarretando multas de valores muito
uma oportunidade. Devido a essa necessidade, elevados). Dessa forma, o gerenciamento do
na maioria das vezes urgente, a primeira coisa cronograma é um dos fatores mais importantes
que, frequentemente, o demandante do projeto do processo de Gerenciamento de Projetos.
nos pergunta é: “Quanto tempo você acha que é
possível para fazer o projeto?”. Por isso, propomos, neste capítulo, que você
passe a conhecer as técnicas, as ferramentas, as
O tempo é muito importante para um projeto entradas e as saídas dos processos que compõem
porque, dependendo do prazo estipulado para a área de conhecimento de Gerenciamento
a entrega, a oportunidade pode ser perdida do Cronograma do Projeto, baseadas no Guia
(imagine, por exemplo, que sua empresa precise PMBOK®, além de outros conceitos e técnicas
fazer um projeto básico de uma ponte para encontrados na literatura. Com esse ferramental,
participar de uma licitação, e o projeto não fica você poderá gerenciar o tempo do projeto dentro
das necessidades da companhia.
OBJETIVOS DO CAPÍTULO
Ao completar este capítulo de estudo, você estará apto a:
■■ entender os conceitos relativos a tempo em projetos;

■■ empregar as ferramentas e as técnicas para definir adequadamente as atividades de
um projeto;
■■ empregar as ferramentas e as técnicas para sequenciar corretamente atividades de
um projeto.
Para melhor compreensão das questões que envolvem o gerenciamento do cronograma e

dos custos em projetos, este capítulo está dividido em:
Unidade 1 – A conceituação
Unidade 2 – O planejamento do gerenciamento do cronograma e a definição das atividades
Unidade 3 – O sequenciamento das atividades

CAPÍTULO 1 11
UNIDADE 1
A CONCEITUAÇÃO
O gerenciamento do cronograma do projeto é tão importante que ele pode fazer a diferença
entre o sucesso e o fracasso de um projeto. É dentro de um cronograma que estão definidas
as durações e o sequenciamento lógico das atividades, assim como a disponibilidade dos
recursos, com seus respectivos custos para realização das tarefas necessárias para que o
projeto flua de modo a atingir seus objetivos.
De acordo com o Guia PMBOK®, os processos que compõem a disciplina de gerenciamento

do cronograma de projetos são os seguintes:
1. Processos de planejamento
■■ planejar o gerenciamento do cronograma: é a etapa em que serão definidas as diretrizes
do gerenciamento do cronograma, ou seja, os planos e as políticas que orientarão como
será feita essa gestão durante o projeto;
■■ definir as atividades: nessa fase, a equipe do projeto define uma lista das atividades que
devem ser realizadas para completar seu escopo;
■■ sequenciar as atividades: esse é o momento de identificar a relação de dependência

entre as atividades listadas no processo anterior;
■■ estimar a duração das atividades: nessa etapa, estima-se a quantidade de tempo neces-
sário para finalizar as atividades do projeto;
■■ desenvolver o cronograma: é o momento no qual se analisam conjuntamente as restri-

ções, os recursos, a duração, o sequenciamento e as relações de dependência entre as
atividades para elaborar o cronograma do projeto.
2. Processos de monitoramento e controle

■■ controlar o cronograma: etapa na qual se controlam as mudanças no cronograma, após
aprovação das solicitações de mudança no processo de controle integrado de mudanças.
Acompanhe, na figura a seguir, uma visão geral do gerenciamento do cronograma do projeto

Figura 1 - Visão geral do gerenciamento do cronograma do projeto
Visão geral do gerenciamento

do cronograma do projeto
6.1 Planejar o Gerenciamento

6.2 Definir as Atividades 6.3 Sequenciar as Atividades
do Cronograma
1 Entradas 1 Entradas 1 Entradas

1 Termo de Abertura do Projeto 1 Plano de gerenciamento do Plano de gerenciamento do
2 Plano de Gerenciamento do projeto projeto
Projeto 2 Fatores ambientais da 2 Documentos do projeto
3 Fatores ambientais da empresa 3 Fatores ambientais da
empresa 3 Ativos de processos organi- empresa
4 Ativos de processos organizacionais 4 Ativos de processos organi-
zacionais zacionais
2 Ferramentas e Técnicas
2. Ferramentas e Técnicas 1 Opinião especializada 2 Ferramentas e técnicas
1 Opinião especializada 2 Decomposição 1 Método do diagrama de
2 Análise de dados 3 Planejamento em ondas precedência (MDP)
3 Reuniões sucessivas 2 Integração e determinação de
4 Reuniões dependência
3 Saídas 3 Antecipações e esperas
1 Plano de Gerenciamento do 3 Saídas 4 Sistema de informações de
Cronograma 1 Lista das atividades gerenciamento de projetos
2 Atributos das atividades
3 Lista de marcos 3 Saídas
4 Solicitações de mudança 1 Diagramas de rede do
5 Atualizações do plano de cronograma do projeto
gerenciamento do projeto 2 Atualizações dos documentos
do projeto
6.4 Estimar as
6.5 Desenvolver o Cronograma 6.7 Controlar o Cronograma
Durações das Atividades
1 Entradas 1 Entradas 1 Entradas

1 Plano de Gerenciamento 1 Plano de gerenciamento do 1 Plano de gerenciamento do
do projeto projeto projeto
2 Documentos do projeto 2 Documentos do projeto 2 Documentos do projeto
3 Fatores ambientais da 3 Acordos 3 Dados de desempenho do
empresa 4 Fatores ambientais da empresa trabalho
4 Ativos de processos 5 Ativos de processos organi- 4 Ativos de processos organi-
organizacionais zacionais zacionais
2 Ferramentas e técnicas
2 Ferramentas e técnicas 2 Ferramentas e técnicas
1 Análise de rede do cronograma
1 Opinião especializada 2 Método do caminho crítico 1 Análise de dados
2 Estimativa análoga 3 Otimização de recursos 2 Método do caminho crítico
3 Estimativa paramétrica 4 Análise de dados 3 Sistema de informações de
4 Estimativas de três pontos 5 Antecipações e esperas gerenciamento de projetos
5 Estimativa “bottom-up” 6 Compressão de cronograma 4 Otimização de recursos
6 Análise de dados 7 Sistema de informações de 5 Antecipações e esperas
7 Tomada de decisões gerenciamento de projetos 6 Compressão de cronograma
8 Reuniões 8 Planejamento ágil de grandes
entregas 3 Saídas
3 Saídas 1 Informações sobre o
1 Estimativas de duração 3 Saídas desempenho do trabalho
2 Bases das estimativas 1 Linha de base do cronograma 2 Previsões do cronograma
3 Atualizações dos documentos 2 Cronograma do projeto 3 Solicitações de mudança
do projeto 3 Dados do cronograma 4 Atualizações do plano de
4 Calendários do projeto
gerenciamento do projeto
5 Solicitações de mudança
5 Atualizações dos documentos
6 Atualizações do plano de
gerenciamento do projeto do projeto
7 Atualizações de documentos do
projeto
Fonte: Guia PMBOK® (2017, pág. 174).

CAPÍTULO 1 13
O padrão ISO e o PMBOK
O novo padrão ISO 21500:2012 – Guia em Gerenciamento de Projetos, que é em grande

parte baseado na 4ª edição do Guia PMBOK®, considera como atividades de gerenciamento
de tempo os seguintes processos:
1. Sequenciar Atividades.
2. Estimar Duração de Atividades.
3. Desenvolver Cronograma.
4. Controlar Cronograma.
Para obter mais detalhes sobre a Norma ISO 21500 – Guindance on Project
Management – visite o site ISO (https://www.iso.org/standard/50003.html)
ou http://www.abntcatalogo.com.br/norma.aspx?ID=92033. Ele fornece
a descrição de conceitos e de processos que são considerados pela ISO
para formar boas práticas em gerenciamento de projetos.
INFORMAÇÃO
EXTRA
Na visão da ISO, o processo Definir Atividades faz parte do grupo de assunto Escopo (equi-
valente à área de conhecimento), enquanto o processo Estimar Recurso das Atividades faz
parte do grupo de assunto Recursos Humanos (tal como orienta a 6ª edição do PMBOK®,
que organizou este processo na área de conhecimento Recursos do Projeto).
O nosso curso, embora também possa compartilhar outras visões, se baseia no Guia
PMBOK®. Dessa forma, o grupo de processos que consideraremos como parte da área de
conhecimento Gerenciamento do Cronograma do Projeto é referente à primeira lista citada
no início desta Unidade.
UNIDADE 2
O PLANEJAMENTO DO GERENCIAMENTO DO CRONOGRAMA
E A DEFINIÇÃO DAS ATIVIDADES
A partir desta unidade, você poderá conferir, com mais detalhes, cada etapa dos processos
que compõem a disciplina de gerenciamento do cronograma do projeto, de acordo com o
Guia PMBOK®.
Planejamento do gerenciamento do cronograma
Planejar o gerenciamento do cronograma é o primeiro processo do Gerenciamento do Cro-

nograma do Projeto. Esse processo gera o Plano de Gerenciamento do Cronograma, que
reúne todas as políticas, procedimentos, diretrizes e definições de métodos e de ferramen-
tas que serão utilizados durante o planejamento, a execução, o monitoramento e o controle
do cronograma do projeto. Veja, na figura a seguir, um diagrama do fluxo de dados.
Figura 2 - Planejar o gerenciamento do cronograma: diagrama do fluxo de dados
4.1 Desenvolver
o termo de
abertura
do projeto
• Termo de abertura do projeto
Plano de Plano de
6.1 Planejar o
gerenciamento gerenciamento
gerenciamento
do projeto do projeto
do cronograma
Plano de gerenciamento do projeto:

• Plano de gerenciamento
• Plano de gerenciamento do escopo do cronograma
• Abordagem de desenvolvimento
Empresa/
organização
• Fatores ambientais da empresa

• Ativos de processos organizacionais
Fonte: Guia PMBOK®, 2017, p. 179.

CAPÍTULO 1 15
Esse plano integra o Plano do Gerenciamento do Projeto e, independentemente do seu nível

de formalidade, consiste em uma das principais partes desse documento. Portanto, a equipe
de gerenciamento do projeto deve trabalhar para construir um plano de gerenciamento do
cronograma coerente com a complexidade e as necessidades do projeto.
Plano de gerenciamento do cronograma
Por meio de reuniões da equipe do projeto, de opiniões de especialistas e de técnicas de

análise de dados previamente conhecidos pela organização, desenvolve-se o plano de geren-
ciamento do cronograma, que norteará todos os processos que veremos. O Guia PMBOK®
fornece, por exemplo, a seguinte lista de itens que podem compor esse documento:
■■ modelo de desenvolvimento do cronograma do projeto;
■■ duração do trabalho contínuo da equipe para concluir uma meta;
■■ nível aceitável de acurácia das estimativas;
■■ unidades de medida que serão utilizadas para cada recurso do projeto;
■■ relações entre procedimentos organizacionais, que permitem a consistência entre os

diversos artefatos do projeto (por exemplo, a Estrutura Analítica do Projeto (EAP) e o
cronograma);
■■ modelo de manutenção do cronograma do projeto;
■■ limites de controle definidos a partir dos quais a equipe de gerenciamento do projeto

tomará ações;
■■ regras de medição de desempenho;
■■ formatos de report.
A organização deve definir como adequar esses itens de acordo com sua própria metodolo-
gia de gerenciamento de projetos.
Definição das atividades
Definir as atividades é um processo fundamental para o projeto, pois essa etapa resulta
no conhecimento das atividades necessárias para realizar cada produto e subproduto, dos
itens fundamentais para a definição dos tipos de recursos necessários e do tempo em que
o projeto será realizado.
Será que definir as atividades é importante somente para a boa gestão

do tempo do projeto? Não! Também é essencial para a gestão dos custos,
dos recursos, da comunicação, dos riscos, da qualidade e das aquisições.
PARE PARA
PENSAR
De acordo com o Weideman Comparative Glossary of Project Management Terms v3.1, uma
atividade é “uma tarefa ou conjunto de tarefas que são executadas de forma a criar um
produto final”, o que nos permite dizer que definir as atividades é um passo natural após
termos o escopo do projeto bem definido e desmembrado. Essa definição e desmembra-
mento resultam nos pacotes de trabalho do projeto, que nada mais são, conceitualmente,
do que o conjunto de atividades necessárias para se obter um produto ou um subproduto.
Para definir as atividades do projeto, precisamos de inputs (entradas) importantes. Os prin-

cipais surgem do processo de planejamento do escopo, além de outros anteriores à existên-
cia do projeto. São eles:
■■ Plano de Gerenciamento do Projeto, que é assim subdividido:
■■ Plano de gerenciamento do cronograma: define a metodologia do cronograma, a

duração do planejamento e o detalhamento necessário para gerenciar o trabalho.
■■ Linha de base do escopo: conta com a Estrutura Analítica do Projeto (EAP), que
possui o desdobramento de todo o projeto até o nível de pacotes de trabalho, as
entregas, restrições e premissas do projeto, fornecendo a ideia do que é o projeto e
sua real necessidade e não deixando a equipe do projeto perder o foco durante os
sucessivos desmembramentos.
■■ Fatores ambientais da empresa: podem inserir atividades no projeto que, em outro

ambiente, talvez não fossem necessárias. Por exemplo, para uma empresa pública,
em um projeto que requer uma dada aquisição, por determinação legal, é necessário
inserir todas as atividades indispensáveis para a realização da licitação. Também são
exemplos a estrutura em si e a própria cultura organizacional, as informações publi-
cadas em bancos de dados comerciais e o Sistema de Informações de Gerenciamento
de Projetos (SIGP).
CAPÍTULO 1 17
■■ Ativos de processo organizacionais: podem ser um fator determinante na decom-

posição da EAP, já que uma empresa pode possuir: modelos de EAP preexistentes
para determinados tipos de projetos e um modelo de decomposição de atividades
para pacotes de trabalho que seguem determinado padrão; o repositório de lições
aprendidas; processos já existentes na organização; modelos com lista de atividades
padronizadas; e as políticas, procedimentos e diretrizes da organização pertinentes às
atividades do projeto.
A seguir, por meio de um diagrama do fluxo de dados, veja como planejar o gerenciamento
do cronograma.
Figura 3 - Diagrama do fluxo de dados
Documentos
Plano de do projeto
gerenciamento
do projeto
• Lista de atividades
• Atributos das atividades
Plano de gerenciamento
• Lista de marcos
do projeto:
6.2
Definir as
do escopo 4.6 Realizar o
atividades
• Linha de base do escopo controle integrado
das mudanças
Empresa/ • Solicitações de mudanças

organização
Plano de
gerenciamento
do projeto
Atualizações do plano de
gerenciamento de projeto:
• Linha de base do
cronograma
• Linha de base dos
custos

Opinião especializada
É necessário contemplar o conhecimento que as pessoas ou grupos adquiriram em projetos

anteriores, desde que pertinentes ao trabalho que está sendo executado no projeto vigente.
Decomposição
A decomposição é a principal técnica utilizada na definição das atividades do projeto. Con-

siste em dividir os pacotes de trabalho definidos na EAP, a fim de construir a lista das tarefas
necessárias para produzir cada um desses pacotes, de forma que sejam gerenciáveis e para
que cada tarefa seja realizada por meio dos recursos alocados, sem a necessidade de maior
controle que demande subdivisões.
Veja, a seguir, um exemplo de EAP, com seus pacotes de trabalho e as atividades definidas
para cada um.
Figura 4 - EAP simplificada de um casamento, com os pacotes de trabalho no segundo nível e as ati-
vidades abaixo
Casamento Nível 1
Cerimônia Nível 2
Evento civil Festa
Religiosa
Contratar Contratar Contratar Nível 3

cartório igreja salão
Fazer Fazer Contratar

certidão decoração buffet
Papéis Cerimônia Contratar

assinados realizada banda
Decorar
salão
Festa
realizada
Fonte: elaborada pelo autor, 2018.

CAPÍTULO 1 19
No exemplo dado, podemos observar que:

■■ o gerente do projeto considerou o evento civil, a cerimônia religiosa e a festa como paco-
tes de trabalho;
■■ os pacotes de trabalho, conforme recomenda a boa prática, são nomeados com

substantivos;
■■ para as atividades, foram colocados verbos no infinitivo, indicando que uma ação deve
ser realizada;
■■ cada um dos pacotes de trabalho teve a última atividade nomeada com uma ação no
particípio (-ado, -edo, -ido). Essas atividades são marcos, ou seja, eventos significativos
do projeto. São atividades com duração zero, que simplesmente identificam a entrega,
data importante ou evento pontual que deve ser destacado.
Na definição das atividades, existe uma escolha a ser feita pelo gerente de projeto: definir
o detalhamento das atividades. No caso exposto, o gerente foi pouco detalhista, colocando
como atividade grandes esforços que poderiam ser subdivididos, como a atividade “Deco-
rar salão” – que poderia, por exemplo, se transformar no pacote de trabalho “Decoração
do Salão”, com as atividades “Escolher tema da decoração”, “Definir tipos de iluminação” e
“Selecionar as flores”.
Essa escolha deve ser feita de acordo com a conveniência, para que as atividades não sejam
tão longas a ponto de os recursos destinados para sua execução se perderem. Essas ativida-
des também não podem ser divididas em partes muito curtas, para não gerar um excesso de
gerenciamento – se o gerente de projetos tiver que ligar a cada uma hora para saber sobre
o andamento da tarefa, isso vai gerar mais atraso ainda. Uma opção pode ser o direciona-
mento de acordo com o drive1 mais importante para o projeto.
Lembre-se de que cada atividade apresentada demandará tempo e dedicação do Gerente

de Projetos para ser gerenciada.
Se o projeto possuir uma data de entrega com muito risco de atraso,

é possível realizar um maior detalhamento das atividades do caminho
crítico. Porém, se o drive for custo, detalham-se melhor as atividades de
maior custo.
NA PRÁTICA
1 Direcionamento dado pela empresa para o projeto.

Durante a decomposição, é importante trazer especialistas no desenvolvimento dos pro-

dutos, tanto da equipe do projeto quanto externos, para opinar tecnicamente sobre esse
desdobramento. Outro apoio importante deve acontecer quando a empresa possui, recor-
rentemente, projetos de natureza semelhantes e quando o PMO2 desenvolve modelos de
EAP ou de pacotes de trabalho com sua decomposição.
Para entender melhor o que é um PMO e as diversas funções que ele

pode ter, consulte o livro Advanced Project Portfolio Management and
the PMO (KENDALL, Gerald; ROLLINS, Steven. Florida: J. Ross Publishing,
2003) ou o livro Leading Successful PMOs (TAYLOR, Peter. London:
Routledge, 2016).
INFORMAÇÃO
EXTRA
Os modelos de EAP podem ser utilizados pelo Gerente de Projetos para auxiliar na divisão de
seus pacotes de trabalho, sempre atentando para adequá-los às especificidades do projeto.
Planejamento em ondas sucessivas
A definição de atividades se torna mais complexa por algumas razões: quando o projeto é
muito grande e a visibilidade das atividades que compõem as entregas futuras é pequena;
quando o projeto tem um escopo aberto, seja por demandar um melhor conhecimento e
levantamento das necessidades, seja porque a técnica a ser utilizada ainda será escolhida;
ou por ser um projeto de criação. Em todos esses tipos de projetos, a técnica a ser utilizada
é o Planejamento em Ondas Sucessivas (Rolling Wave Planning).
2 Acrônimo de Project Management Office (Escritório de Gerenciamento de Projetos)

CAPÍTULO 1 21
Figura 5 - Desenvolvimento da EAP durante os ciclos de replanejamento no planejamento em ondas

sucessivas
Fonte: GITHENS, 1998, p. 2.
De acordo com Githens (1998), o Planejamento em Ondas Sucessivas (ou Rolling Wave Project
Planning - RWPP) deve conter os seguintes passos:
1. avaliação da estratégia de desenvolvimento, respeitando o produto e o ciclo de vida do

projeto;
2. desenvolvimento da duração dos ciclos ou das fases;
3. estimativa, em alto nível, do projeto;
4. detalhamento da primeira EAP;
5. definição da linha de base;
6. execução da primeira fase;
7. replanejamento da próxima fase.
Trata-se de uma abordagem iterativa de desenvolvimento de projetos baseada em fases e

que permite uma maior flexibilidade na definição do escopo. A EAP inicial é desenvolvida e,
a partir disso, de tempos em tempos, durante a fase de execução, é revista, e as próximas
entregas são detalhadas.
Vale destacar que essa técnica de planejamento é bastante similar às utilizadas no SCRUM e
em metodologias ágeis. Acompanhe a figura a seguir, que demonstra o desenvolvimento da
EAP nos ciclos de replanejamento em ondas sucessivas.
Reuniões
Reuniões formais ou informais devem ser realizadas de forma presencial ou virtual com os
membros da equipe e/ou especialistas, para definição das atividades que farão parte dos
pacotes de trabalho.
Saídas (outputs) do processo “Definir as Atividades”
Após a realização desse processo, o gerente de projetos deve ter como saídas os seguintes
itens:
1. Lista de atividades
Todas as atividades necessárias para executar o projeto, baseadas na EAP, devem ser
registradas no Plano de Gerenciamento de Projetos. Naturalmente, em outras ativida-
des do planejamento do projeto a serem executadas posteriormente, assim como no
sequenciamento de atividades ou no planejamento de resposta a riscos, essa lista pode
ser revista ou pode não ser completa quando o planejamento é feito em ondas sucessivas
ou técnicas ágeis.
2. Atributos das atividades

Os atributos das atividades são compostos por código da atividade, descrição da atividade,
duração, recursos necessários, atividades predecessoras e sucessoras, relacionamentos
lógicos, antecipações e esperas. Nem todos os atributos são gerados nesse momento,
sendo muitos deles preenchidos em fases posteriores do planejamento. Porém, os bási-
cos como código e descrição, por exemplo, são feitos neste item.
3. Lista de marcos
A lista dos marcos do projeto também é uma saída desse processo. É uma boa prática,
além de listar os marcos, definir seus atributos e se são obrigatórios ou opcionais.
4. Solicitações de mudança
Ocorrem quando mudanças são solicitadas no projeto para contemplar trabalhos que
foram identificados no decorrer do projeto, mas que, inicialmente, não faziam parte das
linhas de base do projeto.
CAPÍTULO 1 23
5. Atualizações no plano de gerenciamento do projeto

Qualquer alteração no plano de gerenciamento do projeto precisa passar por um con-
trole de mudanças. Os componentes que podem demandar solicitações de mudanças
são: a linha de base do cronograma e a linha de base dos custos, já que elas marcam a
conclusão do planejamento da duração das atividades e seus respectivos custos.
Uma vez que as atividades são definidas, é possível então fazer o seu sequenciamento.
UNIDADE 3
O SEQUENCIAMENTO DAS ATIVIDADES
O processo de sequenciar atividades é a parte do planejamento em que a equipe do projeto

define as relações lógicas entre as tarefas. Nesse momento, deve-se desenhar e registrar as
precedências e sucessões, além das lacunas (gaps) de tempo que ocorrem entre atividades
sequenciadas. Esse trabalho resultará em um cronograma mais realista possível, evitando
desvios que comprometam o prazo final do projeto. Acompanhe o diagrama a seguir.
Figura 6 – Sequenciar as atividades: diagrama do fluxo de dados
Plano de
gerenciamento
do projeto
Plano de gerenciamento
do projeto:
• Plano de gerenciamento do
cronograma
• Diagrama de rede do
• Linha de base do escopo
cronograma do projeto
Documentos 6.3 Documentos

do projeto Sequenciar do projeto
as atividades
Documentos do projeto:
• Atributos das atividades Atualizações de documentos
• Linha de atividades do projeto:
• Registro de premissas • Atributos das atividades
• Linha de marcos • Lista de atividades
• Registro de premissas
• Lista de marcos
Empresa/
organização

Fonte: Guia PMBOK®,2017, p. 187.

São entradas desse processo o Plano de Gerenciamento do Projeto (incluindo o Plano de

Gerenciamento de Cronograma e a Linha de Base do Escopo), os documentos do projeto, os
fatores ambientais da empresa e os ativos e processos organizacionais (esses dois últimos
já explicados anteriormente).
Documentos do projeto
Para a realização do processo, é fundamental ter uma série de documentos que são inputs
desse processo. Para início de conversa, precisamos da lista de atividades – o objeto do
sequenciamento. É muito comum que essa lista seja alterada durante o trabalho, pois, no
sequenciamento, é possível observar a falta de alguma atividade. Também é possível optar
por agregar mais atividades em uma única ou desagrupar uma atividade em outras mais
detalhadas.
Os atributos da atividade também são inputs do processo, pois a descrição que os inte-
gra ajuda no sequenciamento. Alguns atributos – por exemplo, atividades predecessoras e
sucessoras – são preenchidos no momento do sequenciamento das atividades, tal como os
relacionamentos de antecipação e espera.
A lista de marcos é outra entrada, já que os marcos funcionam como atividades para o
objetivo do sequenciamento. Essa lista possui, entre suas características, atividades prede-
cessoras e sucessoras, além de constar no cronograma da mesma forma que as atividades,
com a diferença de terem duração zero.
O último documento é o registro de premissas, no qual estão contidos os eventos ou

circunstâncias que podem ocorrer durante o projeto e que podem impactar a forma de
sequenciamento das atividades e o relacionamento entre elas, além de poder causar riscos
ao projeto.
Ferramentas e Técnicas
As ferramentas e técnicas utilizadas no sequenciamento das atividades são o método do

diagrama de precedência (MDP) com as relações de dependência e precedência, a integra-
ção e determinação dessas dependências, as antecipações e esperas e o método do dia-
grama de setas (MDS).
Método do Diagrama de Precedência (MDP)
Esse método possui a representação das atividades nos nós, em formato retangular. As
setas conectando os nós representam as relações de dependência, conforme você pode
conferir na figura a seguir.
CAPÍTULO 1 25
Figura 7 - Método do diagrama de precedência
B E I
A C G K
J
D F H
O MDP possibilita todas as relações de dependência ou precedência: relação término-início

(TI), término-término (TT), início-início (II) e início-término (IT), exemplificadas a seguir.
1. Relação Término – Início (TI)

É a relação mais comum em projetos – a atividade sucessora deve começar, obrigatoria-
mente, após o término da atividade predecessora.
Exemplo: escrever o livro (T) e publicar livro (I). O livro só pode ser publicado (I) depois de
ter sido completamente escrito (T).
2. Relação Término – Término (TT)

A atividade sucessora só termina após o término da atividade predecessora.
Exemplo: treinar usuários (T) e dar suporte (T).
3. Relação Início – Início (II)

A atividade sucessora se inicia após o início da atividade predecessora.
Exemplo: derramar concreto (I) e nivelar concreto (I).
4. Relação Início – Término (IT)

A atividade sucessora deve terminar somente após o início da predecessora.
Exemplos: fazer a prova (I) e estudar para a prova (T). O aluno estuda (T) até a prova iniciar
(I); se a prova for postergada, ele continua estudando. Outro exemplo é o do call center:
iniciar o novo sistema (I) e desligar o antigo sistema (T). O sistema antigo de call center (T)
só será desligado após a ativação do novo sistema (I).
A figura a seguir demonstra os tipos de dependências.

Figura 8 – Tipos de dependências
A maior vantagem desse método é a representação, de forma mais clara, das várias rela-
ções de dependência nos casos em que uma atividade tem mais de uma dependente. Além
disso, representar outros tipos de relações de precedência também é importante para mui-
tos projetos.
Figura 9 – Diagrama de rede pelo método de diagrama de precedência no MS Project
Fonte: elaborado pelo autor, 2018.
Por esse motivo, a maioria dos softwares de mercado possui o recurso da montagem com
esse método. O MS Project, por exemplo, tem essa técnica nativa na ferramenta, como
podemos ver na figura anterior.
CAPÍTULO 1 27
Integração e determinação de dependências
Para ambos os métodos de diagramação, há três tipos possíveis de dependência entre as

atividades: obrigatórias, arbitradas e externas. Conheça, com detalhes, cada uma:
■■ Dependências obrigatórias: são as dependências físicas entre as atividades. Elas são
inerentes à natureza do trabalho a ser realizado. A equipe do projeto não tem a opção
de fazer as atividades de forma independente. Por exemplo, é preciso projetar antes de
construir.
■■ Dependências arbitradas: são dependências escolhidas por conveniência, pela equipe

de gerenciamento de projeto e durante o sequenciamento de atividades. Geralmente,
adota-se essa sequência por lições aprendidas de projetos anteriores. Porém, existem
outras sequências aceitáveis, possibilitando, inclusive, o paralelismo das atividades em
um eventual atraso.
■■ Dependências externas: envolvem as atividades do projeto dependentes de atividades

externas. Esse tipo de dependência pode ocorrer quando um projeto é dependente de
outro, sendo uma atividade dependente do fim de outro projeto. Também pode ocorrer
esse tipo de dependência quando há aquisições nas quais o item adquirido deve ser
produzido pelo fornecedor, como em caso de importações, por exemplo, e também na
obtenção de licença ambiental para construção de um empreendimento.
■■ Dependências internas: envolvem as atividades do projeto dependentes de atividades

internas. Geralmente estão sob o controle da equipe do projeto.
O entendimento sobre os tipos de dependência, por parte da equipe de gerenciamento do

projeto, permite que ela tenha maior controle sobre o projeto, resguardando-se de depen-
dências externas sobre as quais ela não possua controle ou utilizando dependências arbi-
tradas para ter margem de manobra, caso ocorram problemas no andamento do projeto.
Antecipações e esperas
Outro recurso que se utiliza no sequenciamento de atividades é a presença de atrasos e de

antecipações. Existem atividades que precisam ser feitas algum tempo após a sua suces-
sora, e não imediatamente depois dela. Um exemplo disso seria o projeto de um carro: após
a pintura, deve-se esperar algum tempo para fazer o polimento. Na dependência das duas
atividades, esse tempo é documentado como um atraso necessário entre as duas tarefas.
Da mesma forma, pode ocorrer uma antecipação. A equipe do projeto de software pode ter
criado uma dependência arbitrária para começar a escrever a documentação do sistema
após o início da codificação. Porém, ela pode escolher antecipar essa atividade para algum
tempo antes de encerrar a anterior. Documenta-se, então, do mesmo modo, a antecipação.
Saídas
Após terminar o sequenciamento de atividades, o objetivo é que se tenha o Diagrama de

Rede do Cronograma do Projeto. Esse diagrama é a representação gráfica das atividades
e dos marcos do cronograma com suas relações lógicas. É uma ferramenta visual que deve
evidenciar, para a equipe de gerenciamento do projeto, todo o trabalho que deve ser execu-
tado e em que sequência ele deve ser realizado.
Com a realização desse processo de sequenciamento de atividades, as atualizações nos

documentos do projeto também precisam ser feitas nos atributos e na lista de atividades,
nos registros de premissas e na lista de marcos.
Diagramas de rede – métodos de diagramação
Após o estudo sobre os tipos de relações de precedência, é pertinente falarmos um pouco

sobre os métodos de diagramação, visto que os diagramas de rede são as ferramentas prin-
cipais do sequenciamento de atividades. Os diagramas possibilitam a visualização do cami-
nho que as atividades do projeto irão percorrer até que o resultado final seja atingido.
É possível, a partir do diagrama de rede, gerar o cronograma do projeto

e vice-versa, além de considerar as relações lógicas no controle do
cronograma. O diagrama de rede pode ser gerado tanto em um software
quanto manualmente.
VOCÊ SABIA?
Existem dois métodos principais para produzir diagramas: o primeiro foi apresentado ante-
riormente, o Método do Diagrama de Precedência (MDP); o segundo, mais antigo e menos
utilizado, é o Método do Diagrama de Setas (MDS). Nele, as atividades são representadas
pelas setas, com os nós representando as dependências entre as atividades. Nas setas, colo-
ca-se a descrição ou o código da atividade, e também é possível colocar a duração3, embora,
nesse momento, não necessariamente haja essa informação. Para conhecer melhor os dois
principais métodos para produzir diagramas, acompanhe as figuras a seguir.
3 Se tivermos a duração das atividades, podemos também representar o caminho crítico do projeto em ambas
as técnicas.
CAPÍTULO 1 29
Figura 10 – Método do diagrama de setas
D F
t=4 t=4
t= A
7
B G H
t = 15 t=5 t=2
t= C E
6 t = 11
No diagrama de setas, somente encontramos relações de dependência término-início. Além

disso, existe uma dificuldade de se representar a relação de dependência nos casos em que
a atividade tem mais de uma dependente. Dessa forma, utilizam-se atividades-fantasma,
que são representadas pelas linhas pontilhadas da figura anterior. Essas setas não possuem
descrição ou duração e somente servem para mostrar que uma atividade posterior depende
de uma anterior (atividade H dependendo das atividades E e F).
Por fim, tenha em mente que, embora a solução de atividades-fantasma funcione, ela torna
o diagrama um pouco confuso, dificultando a sua compreensão.
Gráfico de Gantt
O Gráfico de Gantt foi publicado em 1919 pelo engenheiro mecânico Henry Gantt, com o
objetivo de controlar a produção industrial. Essa ferramenta ainda é muito adotada em pro-
jetos nos dias atuais. Ela compõe o pacote de várias ferramentas de gerenciamento de pro-
jetos que estão no mercado e é utilizada como uma forma gráfica para que se entenda o
andamento e o desempenho dos membros da equipe do projeto.
Esse formato é uma representação gráfica do projeto que contempla as atividades, os paco-
tes de trabalho, as contas de controle, etc., em forma de barras, com o tamanho propor-
cional ao prazo de execução e com a representação das dependências entre elas. Também
mostra o andamento de cada atividade, preenchendo a barra da atividade conforme sua
execução.
Esse diagrama mostra os membros da equipe que irão executar a tarefa, desde que eles
estejam previamente associados a essa tarefa, e destaca o caminho crítico, entre outros
recursos que ajudam o Gerente de Projetos a analisar o desempenho.
A figura a seguir mostra o Gráfico de Gantt de um projeto, ao lado de seu cronograma, com
as barras na altura da descrição das atividades no cronograma.
Figura 11 - Gráfico de Gantt no MS Project
Fonte: Elaborado pelo autor, 2012.
O caminho crítico está pintado de vermelho (atividade de número 7, 8, 14 e 15), para con-
trastar com as outras atividades em azul. Se essas atividades sofrerem atrasos, o prazo final
do projeto será imediatamente impactado.
Resumo
Neste capítulo, estudamos o conceito de tempo na visão de projetos, além de adquirirmos
uma visão dos processos componentes desta disciplina, com suas entradas, ferramentas,
técnicas e saídas.
No processo de definir as atividades, observamos a técnica de decomposição, verifica-

mos como realizar o planejamento em ondas sucessivas e detalhamos todos os produtos
que são alcançados nessa atividade. No sequenciamento de atividades, compreendemos
melhor os tipos de dependências e de precedências que as atividades podem possuir.
Em seguida, conceituamos os diagramas de rede e os dois principais métodos: Método de

Diagrama de Setas (MDS) e Método de Diagrama de Precedência (MDP).
Por fim, analisamos a forma de visualização do diagrama de rede chamada Gráfico de Gantt,
muito utilizada nos softwares de gerenciamento de projetos.
Esperamos ter atingido o objetivo deste capítulo, fazendo com que você esteja capacitado
para realizar os processos iniciais do Gerenciamento do Cronograma, além de estar pre-
parado para ingressar nos próximos capítulos, nos quais as estimativas começarão a ser
realizadas.
CAPÍTULO 2 31
Capítulo 2
GERENCIAMENTO DO
CRONOGRAMA EM
PROJETOS – ESTIMATIVA E
DESENVOLVIMENTO
INTRODUÇÃO
De todas as ferramentas de gerenciamento de Além desses fatores, outros diversos prejudicam

projetos disseminadas nos dias atuais, talvez o as estimativas e a execução de um projeto.
cronograma seja a mais conhecida e utilizada. Por causa de tantas dificuldades, justifica-se
No cronograma, é consolidada grande parte das a elaboração de um capítulo que aborde as
informações do projeto. Por meio das diferentes estimativas e as dificuldades de sua realização.
visões dessa ferramenta é possível comunicar o Este capítulo descreve os conceitos referentes
andamento do projeto para as diversas partes às estimativas, bem como os processos de
interessadas. planejamento de cronograma, relacionados com a
realização dessas estimativas. Ao longo do curso,
Para o seu desenvolvimento, é preciso realizar você perceberá que esses conceitos não valem
uma série de estimativas, que pode ser somente para as estimativas relacionadas ao
considerada uma das tarefas mais complicadas planejamento do cronograma, mas também ao
do planejamento do projeto. Por mais experiente planejamento do custo.
que seja a equipe, nem todas as situações que
ocorrem durante a execução e possíveis de É importante ressaltar que, como o conteúdo
afetar tanto o cronograma, quanto o custo das do curso se baseia no PMBOK® e em sua última
atividades, são previsíveis. edição (6ª edição), em 2017, houve algumas
mudanças estruturais pertinentes à área de
Embora seja altamente recomendável, nem conhecimento “Gerenciamento do Cronograma
sempre o recurso responsável por executar uma do Projeto”, o processo “Estimar os Recursos das
atividade participa das estimativas relacionadas a Atividades”, que, antes, fazia parte desta área de
ela. Isso pode fazer com que a estimativa não seja conhecimento, foi transferido para a “Área de
condizente com a capacidade de realização. Conhecimento Gerenciamento dos Recursos do
Projeto”. Contudo, esse processo ainda é uma
entrada para que se possa estimar a duração das
atividades do projeto.
CAPÍTULO 2 33
Ao completar este capítulo de estudo, você estará apto a:
■■ conhecer e aplicar as melhores técnicas para a estimativa de duração de atividades;

■■ entender os comportamentos humanos prejudiciais às estimativas e ao sucesso do
projeto;
■■ entender o conceito e a composição de um cronograma de projeto;
■■ empregar ferramentas e técnicas para construir o cronograma;
■■ conhecer as diversas visões que o cronograma pode apresentar, e suas finalidades.

Unidade 1 – A estimativa da duração das atividades
Unidade 2 – Os comportamentos prejudiciais ao sucesso do projeto
Unidade 3 – O desenvolvimento do cronograma

UNIDADE 1
A ESTIMATIVA DA DURAÇÃO DAS ATIVIDADES
Estimar a duração das atividades de um projeto é uma das ações mais importantes e com-
plexas para a equipe de gerenciamento. Isso deve-se ao fato de que estimar é uma tarefa
em que a única certeza é o erro. Essa certeza surge pela própria definição da palavra esti-
mativa, que, de acordo com o dicionário Dicio (2018) “Cálculo de valor aproximado; avaliação
aproximada que se realiza sobre alguma coisa: estimativa de prejuízos”.
Com foco em projetos, o Guia PMBOK® (PMI, 2017, p. 746) conceitua o tema como “uma
avaliação quantitativa do valor ou resultado provável de uma variável, tal como custos do
projeto, recursos, esforços ou durações”.
Observa-se por essas definições, que estimativas, especialmente de duração, são muito ine-
xatas. Além disso, dependendo do momento em que a estimativa é feita, pode apresentar
maior, ou menor precisão. Isso significa que estimar uma atividade quando está prestes a
acontecer, diminui a probabilidade de erro, pois as condições ambientais na época da exe-
cução são mais próximas das atuais.
Nos casos em que a estimativa é feita com gordura, torna-se lógico esperar
que a tendência seja diminuir o prazo em que as atividades são realizadas,
o que resultaria em uma entrega adiantada do projeto. Porém, isso não
ocorre devido aos fenômenos, muito interessantes, que são inerentes
à natureza humana, dos quais destacamos três: a Multitarefa, a Lei de
Parkinson e a Síndrome do Estudante. Esses fenômenos serão detalhados
mais adiante.
NA PRÁTICA
Mas quais seriam os motivos das estimativas variarem tanto? Abaixo, listamos alguns deles,
baseado na literatura e na experiência em Gerenciamento de Projetos:
■■ opinião de especialistas com pouco conhecimento ou experiência na atividade;
■■ fatores imprevistos, como paradas no ambiente onde a atividade vai ser executada (fal-
tas de luz, greves etc.), condições climáticas que interferem na atividade, ou faltas ines-
peradas de um recurso;
■■ recursos não alocados, exclusivamente, para o projeto;

CAPÍTULO 2 35
■■ desvios normais inevitáveis e inerentes ao trabalho em si;
■■ erros e problemas de entendimento que provocam retrabalho;
■■ ocorrência de riscos não evidenciados;
■■ estimativa dada com gordura não correspondente à realidade.
Analisando os motivos citados, concluímos que é possível melhorar uma estimativa. E se um

plano de riscos for bem feito, os riscos das tarefas serão registrados e planos de ação mais
eficientes serão criados, melhorando a qualidade das previsões.
São entradas desse processo, o Plano de Gerenciamento do Projeto, os documentos do pro-

jeto, incluindo aí, os atributos das atividades e a lista de atividades, o registro de premissas e
das lições aprendidas, a lista de marcos, as designações da equipe do projeto, o registro de
riscos e os itens advindos do processo Estimar os Recursos das Atividades, como a estrutura
analítica de recursos (EAR – semelhante a uma EAP, mas com uma estrutura hierárquica
dos recursos), os requisitos de recursos (com identificação de tipo e quantidade de recur-
sos para realizar a atividade) e os calendários dos recursos (que vêm do processo Adquirir
Recursos e indicam o período de disponibilidade dos recursos), além dos fatores ambientais
da empresa e os ativos e processos organizacionais.
Figura 1 - Estimar duração das atividades: diagrama do fluxo de dados
Plano de
gerenciamento
de projeto
Plano de gerenciamento de projeto:

cronograma • Estimativas de duração
• Linha de base do escopo • Bases das estimativas
Documentos
do projeto 6.4
Estimar as Documentos
Durações das do projeto
Atividades
Documentos do projeto:
• Lista de atividades
• Registro das lições aprendidas
• Lista de marcos
Atualizações de documentos
• Designações da equipe do projeto
do projeto:
• Estrutura analítica dos recursos
• Calendários dos recursos
• Requisitos de recursos
• Registro dos riscos
Empresa/
organização


Técnicas para a produção de estimativas

Existem diversas técnicas para a produção de estimativas. Algumas das que serão descritas
a seguir, podem incluir outras técnicas. É o caso da estimativa de três pontos, em que cada
um pode ser estimado por analogia, parâmetro, entre outras.
Opinião especializada
Consiste no recrutamento de especialistas na execução das atividades do projeto para esti-
mar sua duração. Os especialistas podem realizar essa estimativa, com base na experiência,
no conhecimento, ou em dados históricos empíricos.
É possível coletar as opiniões especializadas, a partir de várias técnicas. O brainstorming

consiste na reunião presencial dos especialistas, para que cheguem a um denominador
comum. Outra forma é o método Delphi, em que os especialistas opinam anonimamente.
Define-se um facilitador, que será responsável por consolidar as opiniões dos especialistas
sobre a produção de estimativa para realizar as atividades do projeto. Essas opiniões são
tratadas e devolvidas aos especialistas para a realização de uma próxima rodada e essa
tarefa se repete até que se chegue a um consenso.
É válido ressaltar as vantagens e desvantagens do Método Delphi. Sobre isso, Carter e Beau-
lieu (1992, p. 5), apresentam o seguinte quadro:
Quadro 1 - Vantagens e Desvantagens do Método Delphi
VANTAGENS DESVANTAGENS
Fornece julgamentos do grupo selecionado, que

Permite aos participantes permanecerem anônimos.
pode não ser representativo.
Tende a eliminar posições extremas e forçar um

Demanda baixo custo de aplicação.
consenso médio.
Possibilita a isenção de pressão social, influência de Necessita de mais tempo em comparação com
personalidade e dominação individual. outras técnicas, como grupos nominais.
Promove a distribuição de informação e o debate

Apresenta solução temporária.
entre os participantes.
Conduz ao pensamento independente e à evolução

Exige habilidades em comunicação escrita.
gradual das opiniões.
Fornece uma perspectiva analítica ampla dos Demanda tempo adequado, cerca de 30 a 45 dias
problemas locais e relacionados, a partir de um para a realização de um processo com dois rounds, e
painel bem selecionado. comprometimento dos participantes.
Possibilita o alcance de consenso entre grupos

hostis.
Fonte: CARTER; BEAULIEU, 1992, p. 5.

CAPÍTULO 2 37
Estimativa análoga
Esse tipo de estimativa considera a duração de uma atividade semelhante, já realizada em

outro projeto, ou em momento anterior no mesmo projeto, parecida com a atividade atual
que se está realizando a previsão, a fim de fazer a estimativa da duração da tarefa.
Essa técnica pode ser utilizada, quando efetivamente as tarefas são muito semelhantes, situ-
ação na qual funciona bem. Também é utilizada, quando os detalhes da tarefa que se deseja
estimar não estão bem definidos, ou está repleta de incertezas, não restando alternativa a
não ser a analogia. Nesse caso, são fortemente utilizadas as boas práticas e as lições apren-
didas coletadas das bases de dados da companhia, bem como as informações de especialis-
tas e as informações históricas.
De acordo com o PMBOK® (PMI, 2017, p. 200), “a estimativa análoga é geralmente menos
dispendiosa e consome menos tempo que outras técnicas, mas também é menos precisa”.
Estimativa paramétrica
A estimativa paramétrica é uma estimativa quantitativa. Ela é utilizada quando uma atividade
consiste em várias atividades do mesmo tipo, ou quando existe uma métrica de realização
da atividade e um valor padrão de duração da produção da unidade do que está sendo feito.
Por exemplo, um programador produz 1.000 linhas de códigos, trabalhando 200h por
mês, utilizando a linguagem de programação Assembly, logo, ele produzirá uma média
de 5 linhas/hora. Esse valor poderia ser um parâmetro para a duração de outras ativida-
des de programação de um projeto que utilize essa mesma linguagem de programação.
Agora, se outro projeto demanda uma programação em Python, esse parâmetro pode
não ter muita utilidade.
Podemos criar estimativas paramétricas de diversas formas. São elas:
Análise de regressão (diagrama de dispersão)
É uma técnica que permite explorar uma série de variáveis de entrada e inferir a relação com
os resultados de saída. Com base nisso é possível estabelecer a existência de um relaciona-
mento matemático, ou estatístico, para o uso de estimativas paramétricas futuras.
A análise da regressão pode ser usada como um método descritivo da análise de dados,
como o ajustamento de curvas, sem que necessitem de suposições acerca dos processos
que permitiram gerar os dados. Regressão designa também uma equação matemática, que
descreve a relação entre duas, ou mais variáveis.
Qual exemplo teríamos para isso? Supomos que a Área de Compras de uma organização
tenha em seus limites mínimo e máximo, um prazo entre dois e três meses, para realizar todo
o processo de compra (variável dependente) de um determinado equipamento. Sabe-se, no
entanto, que toda vez que um equipamento vem de um grupo de fornecedores da Itália, ou
quando o euro oscila mais que o dólar, ou até, quando a especificação dos equipamentos
pode ser atendida por fornecedores americanos (todos esses fatores e quaisquer outros mais
são chamados de variáveis), o processo leva quase três meses em vez de dois meses. Então,
você levanta os dados de cada uma das possíveis variáveis que impactam o tempo de compra
e traça essas informações em um gráfico, Em seguida faz ajustes para ver qual impacto, por
exemplo, que uma oscilação maior, ou menor do dólar, causa no tempo de compra.
As organizações usam a análise de regressão para compreender correlações entre fatores,

tentar predizer o futuro e facilitar o processo de tomada de decisão.
Para obter maior conhecimento sobre a técnica estatística da regressão

e como utilizá-la, leia o livro de estatística básica Estatística para
Administração e Economia (MCCLAVE; BENSON; SINCICH, 2009).
INFORMAÇÃO
EXTRA
Curva de aprendizado
A teoria da curva de aprendizado “aplica-se à previsão do custo ou do tempo de trabalho

futuro, assumindo ciclos de trabalho repetitivos com condições de trabalho iguais ou seme-
lhantes em relação à tecnologia, clima e trabalhadores, sem atraso entre duas atividades
consecutivas” (MÁLYUSZ; VARGA, 2016, p. 105).
Normalmente, o aumento na retenção de informações é mais agudo, após as tentativas

iniciais, equilibrando-se gradualmente, o que significa haver, cada vez menos, retenção de
informação nova após cada repetição.
A curva de aprendizado também pode representar a dificuldade inicial de aprender algo e,

em certa medida, o quanto há para se aprender depois de familiaridade inicial.
CAPÍTULO 2 39
Como modelo do funcionamento da curva de aprendizado, observa-se que, para um pintor

o qual precisa pintar várias portas, a vigésima a ser pintada, levará menos tempo que a pri-
meira. O motivo é o aumento de eficiência, devido à repetição.
Estimativa heurística
Trata-se de uma regra geral comumente aceita. Por exemplo, 80/20 onde 80% dos proble-
mas surgem por 20% das causas. Considerando a aplicação de Heurística em cronograma,
podemos avaliar que o trabalho de documentação de um software representa 20% da dura-
ção total do projeto.
Estimativa de três pontos
Para realizar a estimativa com essa técnica, é preciso considerar os riscos da estimativa mais
provável e, a partir das estimativas análoga, paramétrica, opinião de especialistas etc., efe-
tuar três estimativas para a tarefa:
■■ mais provável – aquela que normalmente seria considerada a partir da média das ativi-
dades semelhantes, ou da previsão do especialista.
■■ otimista – uma estimativa considerando o melhor caso, ou seja, a ocorrência dos riscos
positivos da atividade.
■■ pessimista – uma estimativa baseada no pior caso, considerando-se os riscos que

podem acontecer na realização da tarefa.
Após fazer as três estimativas, define-se a duração da atividade do cronograma com um dos
seguintes cálculos:
(P + M + O )
a) Distribuição triangular:
3
b) Distribuição BETA:
(P + 4M + O)
6
No primeiro caso (a), utiliza-se uma média simples, sendo que o risco “Mais Provável” tem
o mesmo peso dos riscos Otimista e Pessimista. Já no segundo caso (b), também conhecido
como Project Evaluation and Review Technique (PERT)1, utiliza-se uma média ponderada, com
o risco “Mais Provável”, tendo um peso maior que os demais.
1 O método Project Evaluation and Review Technique (PERT) é diferenciado do método CPM (Critical Path Method),
que considera somente a estimativa mais provável. Esses termos não são mais utilizados pelo Guia PMBOK®.
Vale ressaltar que as informações Pessimistas, Otimistas e Mais Prováveis ajudarão a calcu-
lar o Desvio Padrão e Variância da atividade. De acordo com a fórmula PERT, tem-se:
Desvio padrão:
(P − O )
6
Variância:
(P − O )  2
6
Sendo:
M = Mais provável,
P = Pessimista,
O = Otimista
Estimativa Bottom-up
Quando existe uma dificuldade em se fazer a estimativa de duração de uma atividade, pode-
mos quebrá-la em tarefas menores, até o nível mínimo, no qual se pode fazer uma previsão.
Após estimar os recursos de cada uma dessas tarefas, eles são somados para que se faça a
estimativa da atividade original.
Ao se subdividir a atividade original, as tarefas resultantes podem ter, ou não, relações

de dependências entre elas. Caso existam, essas relações devem ser documentadas e as
dependências utilizadas no momento da estimativa bottom-up.
O conceito de estimativa bottom-up, também é aplicado no cálculo dos recursos necessários

para todos os níveis da EAP, desde os pacotes de trabalho, até o projeto como um todo.
A estimativa das durações é feita na atividade de nível mais baixo (ou bottom) e, depois,
esses valores são somados, considerando as dependências entre as atividades, para se esti-
mar as durações dos níveis acima, até se alcançar a estimativa de duração do projeto inteiro.
A estimativa da duração das atividades, resultado dos processos

realizados, a partir das técnicas expostas nessa unidade, são registradas
nos atributos das atividades, junto com a previsão do tempo de duração e
alguma indicação da faixa de resultados possíveis como: +- 5 dias, 5% para
menos e 10% para mais, etc.
VOCÊ SABIA?
CAPÍTULO 2 41
Análise de dados
Análise de dados também podem ser utilizadas nessas estimativas. São divididas em aná-
lise de alternativas e análise de reservas.
Análise de alternativas: utilizada para avaliar se existem alternativas melhores, ou mais viá-
veis para o projeto. Pode ser usada para comparar se é melhor usar um recurso mais, ou
menos experiente para aquela atividade, qual técnica de compressão de cronograma é preferí-
vel, se é melhor comprar, alugar ou desenvolver por conta própria uma solução, por exemplo.
Análise de reservas: utilizada para determinação das reservas de contingência e gerencial.

Reservas de contingência (às vezes chamadas de reservas de cronograma), estão relacionadas
aos riscos identificados no projeto, que podem gerar retrabalhos. Essa reserva pode ser um
percentual da atividade, ou um período de trabalho pré-estabelecido. Já a reserva gerencial é
o valor retido do projeto para os riscos desconhecidos que podem impactar o gerenciamento.
Tomada de decisão
Incluem as técnicas que podem ser utilizadas no processo de estimar duração das ativida-
des. Dentre elas destacam-se a votação, que leva em consideração uma escolha coletiva, a
decisão autocrática, em que uma pessoa assume a responsabilidade pela decisão, e a aná-
lise de decisão envolvendo critérios múltiplos, em que é utilizada uma abordagem analítica,
para definir critérios (como níveis de riscos, incerteza e avaliação) de como as decisões
serão avaliadas.
Reuniões
As reuniões acontecem com a equipe de projeto, para estimar no projeto as durações das
atividades.
UNIDADE 2
OS COMPORTAMENTOS PREJUDICIAIS AO SUCESSO DO PROJETO
De acordo com estudos da psicologia, existem diversos fatores de natureza humana, que
prejudicam o sucesso dos projetos, tanto no momento da realização das estimativas, pois
tendem a ser maiores do que o necessário, quanto no momento da execução da tarefa. Des-
tacaremos três fenômenos muito frequentes em projetos: a multitarefa, a Lei de Parkinson
e a síndrome do estudante.
Multitarefa
Frequentemente, o mesmo recurso é responsável pela execução de tarefas sequenciais em

um projeto. Quando essa sequência não possui dependências obrigatórias, ou seja, o profis-
sional não precisa terminar uma antes de começar a outra, existe uma tendência natural de
intercalar as tarefas. Por que isso acontece? Devido ao tédio de se executar uma única tarefa
por vez, ou por causa de eventuais pressões exercidas por seus clientes, quando estes são
diferentes, para que ele conclua cada tarefa.
Isso quando não acontece também as interrupções corriqueiras do ambiente de trabalho,

que desviam a atenção e tiram o foco do profissional. Tais como, resolver um problema de
última hora para o diretor, responder e-mails e mensagens de celular, solicitando alguma
ação específica, etc.
O recurso gasta um tempo para adaptação entre a execução de uma atividade e outra, isto
é, para se acomodar ao ambiente de uma nova tarefa, ou até mesmo para descansar, se
desligar da tarefa anterior e se conectar a uma nova. Ao intercalar pedaços de tarefas, esses
intervalos se multiplicam, o que aconteceria com menos frequência, se a execução de um
único trabalho fosse até o fim. Podemos observar como isso ocorre, na figura a seguir.
Figura 2 - Tarefas sequenciais sem multitarefa e com multitarefa
Tarefa para “A” Tarefa para “B” Tarefa para “C”

completada completada completada
ajuste
ajuste
ajuste
Tarefa p/ Projeto A Tarefa p/ Projeto B Tarefa p/ Projeto C
Tarefa para “B” Tarefa para “C”

completada completada
Tarefa para “A”
completada
ajuste
ajuste
ajuste
ajuste
ajuste
ajuste
ajuste
ajuste
ajuste
A B C A B C A B C
Fonte: ELDER, 2006, p. 4.
A multitarefa, nesses casos, além de atrasar a entrega de todas as tarefas em conjunto, tam-
bém atrasa as tarefas individualmente. Se uma pessoa pode se beneficiar do resultado da
tarefa A, ela só irá fazer isso mais tarde, com a multitarefa.
CAPÍTULO 2 43
A multitarefa não é necessariamente prejudicial. Ela pode ser benéfica,

quando o recurso está aguardando algum elemento que permita
a continuidade da execução da atividade. Dessa forma, em vez de
permanecer parado, o recurso trabalha em outra atividade e otimiza seu
tempo útil.
PARE PARA
PENSAR
Lei de Parkinson
A chamada Lei de Parkinson constata que o trabalho se expande para preencher o tempo
disponível. Esse fenômeno ocorre, porque, mesmo que estimar a duração de uma tarefa
com precisão seja quase impossível, essas estimativas tornam-se compromissos.
O gerente de projeto deve concentrar seu esforço em entregar o projeto como um todo, no
prazo e não em exigir que as tarefas, individualmente, não tenham atrasos. Esse esforço
provoca um acréscimo automático de prazo de incertezas, embutido nas tarefas. Além disso,
os responsáveis por entregas maiores que agregam várias tarefas realizadas por diferentes
recursos, colocam a sua margem, assim como o gerente de projeto adiciona uma gordura
no prazo do projeto como um todo.
Esse encadeamento de aumentos de prazo pode acabar se chocando com as restrições de

tempo do projeto. Quando isso acontece, o gerente do projeto precisa cortar a gordura e
deve solicitar a mudança da estimativa das tarefas. Por outro lado, o responsável por elas,
já ciente de que isso costuma ocorrer, tenta estimar a gordura a ser futuramente cortada.
Além disso, quanto maior a incerteza da tarefa, maior a gordura necessária para garantir
uma probabilidade grande da entrega ser realizada no prazo. Dessa forma, muitas vezes,
encontramos prazos onde metade ou mais é gordura adicionada e o resto seria o prazo
médio para se concluir a tarefa, caso não acontecessem imprevistos.
É nesse momento em que a Lei de Parkinson nos afeta. Se as tarefas fossem realizadas
no prazo correto, o projeto seria entregue adiantado, pois em boa parte das tarefas, não
ocorreriam imprevistos. Mas essa ocorrência geraria lições aprendidas que fariam com que
o gerente de um próximo projeto com tarefas semelhantes, questionasse os prazos dados
com folga. Logo, o executor da tarefa, mesmo sem intenção, provoca a realização da tarefa
no prazo dado, evitando ser questionado sobre esse prazo posteriormente. Isso gera um
atraso sistemático na maioria dos projetos, desperdiçando recursos da organização.
Para maiores detalhes sobre a lei de Parkinson, consulte o artigo

Parkinson’s law (PARKINSON, 1955).
INFORMAÇÃO
EXTRA
Síndrome do estudante
A Síndrome do Estudante é o fenômeno no qual o executor da tarefa, ciente da folga no

prazo, começa a realizá-la no momento limite ao risco de atrasar, geralmente acabando a
tarefa no prazo. Possui esse nome porque, geralmente, o aluno costuma começar a estudar
para a prova, ou a fazer um trabalho em cima da hora, quando bate o desespero do minuto
final, às vezes passando por sufoco e estudando de madrugada, mesmo que o prazo tenha
sido estabelecido com bastante antecedência.
Podemos considerar esse fenômeno como uma das formas de atuação da Lei de Parkinson,
pois também acarreta o preenchimento automático da gordura das atividades. Essa sín-
drome também nos incentiva a crer que as pessoas sabem estimar o tempo para realizar as
tarefas com mais precisão, do que, normalmente, o fazem. Isso porque elas sabem calcular
o momento limite que devem começar a fazer a tarefa, diminuindo os riscos de atraso.
Para minimizar os efeitos da Síndrome do Estudante, foi proposta uma maneira alternativa
para a confecção do cronograma – o método da corrente crítica. Esse método será deta-
lhado mais adiante.
UNIDADE 3
O DESENVOLVIMENTO DO CRONOGRAMA
Após produzirmos o diagrama de rede com o sequenciamento das atividades e de termos

estimado sua duração e os recursos necessários, chegou o momento de desenvolver o cro-
nograma do projeto. Muitas pessoas resumem o gerenciamento de projetos em: confeccio-
nar e controlar o cronograma. Embora o gerenciamento dos projetos seja muito mais do
que isso, essa ideia mostra a importância desse processo. O cronograma é uma ferramenta
que contempla vários aspectos do projeto:
CAPÍTULO 2 45
■■ define as datas de início e de fim para cada atividade e, consequentemente, do projeto

como um todo;
■■ contempla os recursos e quando eles serão utilizados;
■■ registra o andamento das atividades;
■■ verifica se o projeto está atrasado, o risco de estourar, etc.
Figura 3 - Desenvolver o cronograma: diagrama do fluxo de dados
Plano de Plano de
de projeto de projeto
• Linha de base do
cronograma
Plano de gerenciamento de projeto:
cronograma
• Linha de base do escopo Atualizações do plano de
gerenciamento do projeto:
cronograma
Documentos • Linha de base dos custos
do projeto
6.5 4.6 Realizar o

Documentos do projeto: Desenvolver controle
• Atributos das atividades o cronograma integrado
• Lista de atividades de mudanças
• Lista de marcos
• Designações da equipe do projeto
• Estrutura analítica dos recursos
• Calendários dos recursos
• Requisitos de recursos
• Registro dos riscos • Cronograma do projeto
• Dados do cronograma
• Calendários do projeto
12.2
Conduzir Documentos
as aquisições do projeto
• Acordos
Atualizações de documentos
do projeto:
Empresa/ • Registro de premissas
organização • Estimativas de duração
• Fatores ambientais da empresa • Requisitos de recursos
• Ativos de processos organizacionais • Registro dos riscos

Após o fim do planejamento, uma linha de base (baseline) do cronograma deve ser salva,
para que se possa compará-la com o progresso real do projeto. O cronograma passa a
representar um compromisso da equipe de gerenciamento do projeto com o patrocinador.
O desenvolvimento do cronograma é apoiado por diversas ferramentas computacionais de

gerenciamento de projetos, as quais consideram as relações de precedência, as restrições
de datas, os recursos, dentre outros, e calculam as datas de início e de término das ativida-
des e do projeto, apresentam os marcos do projeto, além de calcularem, automaticamente,
o caminho crítico, as folgas e outros conceitos, que veremos mais adiante.
Na figura a seguir, você poderá verificar um exemplo de cronograma no MS Project, uma das
diversas ferramentas de gerenciamento de projetos disponíveis no mercado.
Figura 4 - Exemplo de cronograma na ferramenta MS Project®
Fonte: Elaborado pelos autores, 2018.
Restrições de datas
Nesse momento, já temos o sequenciamento de atividades, os recursos estimados e sua

duração. O próximo passo necessário para construir o cronograma, é definir as restrições de
data de cada atividade, assim já poderemos ter o cronograma do projeto, calcular o caminho
crítico e as folgas.
A teoria de gerenciamento de projetos apresenta os seguintes tipos de restrição de datas.

CAPÍTULO 2 47
Figura 5 - Restrições de datas
É uma restrição flexível, pela qual uma atividade deve ser rea-
O Mais Tarde Possível
lizada em sua data de início, o mais tarde possível.
É uma restrição flexível, em que a tarefa é iniciada na sua

O Mais Breve Possível
data de início, mais cedo possível.
É uma restrição semiflexível. A atividade pode terminar mais

Não Terminar Antes de tarde, possibilitando a escolha de começar mais tarde, porém
com uma data definida antes da qual ela não pode terminar.
É uma restrição semiflexível, em que a atividade pode termi-

Não Terminar Depois de nar mais cedo, oferecendo a opção de começar cedo, mas
com uma data máxima para terminar.
É uma restrição inflexível, pela qual se define uma data para a

Deve Iniciar em
atividade começar a ser executada.
É uma restrição inflexível, pois requer uma data para a ativi-

Deve Terminar em
dade terminar.
É uma restrição semiflexível, em que se define uma data, an-

Não Iniciar Antes de
tes da qual, a tarefa não pode começar.
É uma restrição semiflexível, pois se define uma data depois

Não Iniciar Depois de
da qual, a tarefa não pode começar.
Caminho crítico
Esta é uma das principais técnicas para o desenvolvimento do cronograma e seu posterior
controle. Consiste na sequência de atividades do diagrama de rede, que tem a maior dura-
ção, dentre todos os caminhos do cronograma. Dessa forma, nenhuma das atividades pos-
sui folga, ou seja, as mesmas devem ser iniciadas exatamente na data prevista, já que um
eventual atraso impacta na data final do projeto.
O caminho crítico auxilia o gerente de projeto a:

■■ comprovar a duração do projeto;
■■ identificar onde é melhor concentrar esforços;
■■ ajudar a comprimir o projeto durante o planejamento e sempre que houver mudanças;
■■ identificar as atividades passíveis de atraso, sem atrasar o projeto.
Um projeto pode ter um, ou mais caminhos críticos, pois mais de uma sequência de atividades
pode ter a mesma duração total e essa ser a maior duração de todos os caminhos do projeto.
A figura a seguir, tirada do software MS Project, destaca em vermelho, o caminho crítico no grá-
fico da Gantt. Havendo algum atraso nessas atividades, o prazo final do projeto é impactado.
Figura 6 - Caminho crítico destacado em vermelho no MS Project®
Para efetuar o cálculo do caminho crítico, sugerimos um procedimento que define as datas
de início e de término mais cedo e mais tarde das atividades, bem como calcula as folgas
e verifica as atividades com folga zero. O caminho em que todas as atividades apresentam
folga zero é o caminho crítico.
Passo 1: definição do início e término mais cedo das atividades

Para a definição do início e do término mais cedo, das atividades, ou do caminho de ida,
devemos utilizar as fórmulas:
Início mais cedo (IMC)= início mais cedo predecessora + duração predecessora
Caso haja mais de uma predecessora, utiliza-se aquela que tem a data mais tardia dentre as
datas de “início mais cedo”.
Término mais cedo (TMC)= início mais cedo + duração - 1

CAPÍTULO 2 49
Para a demonstração do cálculo desse e dos próximos passos, utilizaremos como exemplo
o diagrama de redes da Figura a seguir, considerando que a primeira tarefa A começa no dia
1 de março.
Figura 7 - Diagrama de Redes utilizado no exemplo
Os retângulos na parte de
cima de cada tarefa
representam o início e o
término mais cedo, da B – 11 d C–6d
esquerda para a direita.
A–5d F–5d G–2d
D–4d E–5d Os retângulos de baixo,

representam o início e
término mais tarde.
Calculando-se as datas de início e de término mais cedo pelas fórmulas dadas, temos os
cálculos mostrados no quadro a seguir.
Quadro 2 - Cálculo das datas de início e término mais cedo
PREDECESSORA INÍCIO MAIS TÉRMINO MAIS

ATIVIDADE DURAÇÃO
UTILIZADA CEDO CEDO
A - 5 01/mar 05/mar
B A 11 06/mar 16/mar
C B 6 17/mar 22/mar
D A 4 06/mar 09/mar
E D 5 10/mar 14/mar
F C 5 23/mar 27/mar
G F 2 28/mar 29/mar

Passo 2: definição do início e término mais tarde das atividades

Para a definição do início e do término mais tarde das atividades, ou do caminho de volta,
devemos fazer o cálculo de trás pra frente, começando pela última atividade. As fórmulas
utilizadas são as seguintes:
Término mais tarde = menor Início mais tarde das atividades sucessoras - 1
Início mais tarde = término mais tarde – duração + 1
Calculando-se as datas de início e de término mais tarde pelas fórmulas sugeridas, temos os
cálculos mostrados no quadro a seguir.
Quadro 3 - Cálculo das datas de início mais tarde e de término mais tarde
SUCESSORA INÍCIO MAIS TÉRMINO MAIS

ATIVIDADE DURAÇÃO
UTILIZADA TARDE TARDE
A B 5 01/mar 05/mar
B C 11 06/mar 16/mar
C F 6 17/mar 22/mar
D E 4 14/mar 17/mar
E F 5 18/mar 22/mar
F G 5 23/mar 27/mar
G - 2 28/mar 29/mar
Passo 3: Calculando as folgas do projeto

Antes de calcular as folgas, precisamos definir dois tipos de folgas:
3. Folga livre – o quanto uma atividade pode atrasar sem comprometer a data da próxima
atividade na rede.
FL= IMC (sucessora) – TMC (predecessora)

CAPÍTULO 2 51
4. Folga total – o quanto uma atividade pode atrasar sem alterar a data final do projeto.
FT= IMT – IMC ou TMT – TMC (sempre de uma mesma atividade)
Calculando-se as folgas, temos a situação da figura a seguir. Considerando que o caminho

crítico é a sequência de atividades que possui folga zero, podemos verificar que o caminho
crítico desse projeto é:
A→B→C→F→G
Figura 8 - Diagrama de rede com datas de início e de término mais cedo e mais tarde, e folgas calculadas
Folga = 0 Folga = 0
6/mar 16/mar 17/mar 22/mar
B – 11 d C–6d
Folga = 0
Folga = 0 Folga = 0
1/mar 5/mar 23/mar 27/mar 28/mar 29/mar
A–5d F–5d G–2d
1/mar 5/mar
Folga = 8 Folga = 8
D–4d E–5d
Fonte: Elaborada pelos autores, 2018.
Ao elaborar o caminho crítico e as durações do diagrama de rede, é preciso atentar ao fato

de que o primeiro dia de trabalho já conta na atividade. Então se uma atividade D, tem dura-
ção de 4 dias e ela começa no dia 6 de março, ela terminará no dia 9 de março (começaria
na manhã do dia 6 e terminaria ao final do dia 9/3, por exemplo). Ou seja, a conta não é 6
de março + 4 dias, pois isso faria a atividade terminar no dia 10 (resultando numa duração
de 5 dias e não 4 dias).
Otimização de recursos
Durante a construção do cronograma e após a identificação do caminho crítico, uma técnica
de análise permitirá avaliar a rede e diminuir riscos de atraso – é o nivelamento de recur-
sos. Com essa técnica, são analisadas as disponibilidades dos recursos críticos compartilha-
dos entre atividades do projeto, verificando se estão sobrecarregados e possibilitando que
sejam utilizados de maneira mais eficiente.
Em caso de sobrecarga, pode-se atrasar uma atividade, subdividi-la a fim de que comece a
ser executada, ou ainda parar e recomeçar quando o recurso estiver disponível. O gerente
de projetos pode providenciar a alocação ou contratação de um novo recurso, ou priorizar
as atividades do caminho crítico e, fazendo o nivelamento, transferir recursos entre as ativi-
dades. Esse deslocamento pode modificar o caminho crítico do projeto.
O nivelamento, quando feito sem considerar a alocação de novos recursos, geralmente

aumenta o prazo, já que o caminho crítico anterior se mantém, mas outros caminhos pas-
sam a ter durações maiores, gerando novos caminhos críticos. Entretanto, o nivelamento
de recursos é fundamental para que o gerente de projetos mantenha o controle do crono-
grama, afinal se existem recursos com excesso de alocação, certamente as tarefas atrasarão.
Outra questão em que essa técnica ajuda é no equilíbrio entre os recursos do projeto. Sem
utilizá-la, muitos recursos podem ficar deslocados em boa parte do tempo, enquanto outros
permanecem com excesso. Esse fenômeno é minimizado com o nivelamento.
A maioria dos softwares de construção de cronograma auxilia no nivelamento de recursos,

inclusive executando-o de forma automática, de acordo com configurações a serem escolhi-
das pelo gerente do projeto.
Figura 9 - Nivelamento de recursos, utilizando o MS Project®

CAPÍTULO 2 53
Outra técnica que pode ser utilizada é a estabilização dos recursos, que consiste em ajus-
tar os recursos para trabalhar dentro dos limites de folga das atividades. Diferente do nivela-
mento de recursos, o caminho crítico, a data de conclusão e os custos permanecem os mes-
mos, porém esta técnica não tem a capacidade de otimizar todos os recursos do projeto.
Análise de dados
Análise de cenário “E-se”

Busca avaliar cenários para prever efeitos positivos ou negativos no projeto. É uma aná-
lise do questionamento “E se?”, de situações pertinentes ao projeto como, por exemplo, “E
se trocarmos o recurso?”, “E se a entrega atrasar?”, “E se o equipamento não funcionar?”,
“E se modificarmos as atividades?”. Utiliza-se o cronograma para computar cada um dos
cenários levantados, a fim de preparar um plano de resposta para tratar os impactos que
possam ocorrer.
Simulação de Monte Carlo

A simulação de Monte Carlo é um modelo que se baseia em técnicas estatísticas para apoiar
a montagem do cronograma do projeto. Essa técnica utiliza a geração de números aleató-
rios para atribuir valores às variáveis do sistema que se deseja investigar.
Em um projeto, pode-se utilizar essa técnica na avaliação de prazo, custos e riscos. Nosso
foco será em sua utilização, para apoiar o desenvolvimento do cronograma, ou seja, no
prazo. Para isso, no momento da estimativa de duração de cada atividade, deve ser definido
o tempo nos cenários otimista, mais provável e pessimista. Além disso, o gerente de projetos
deve escolher um tipo de distribuição para as probabilidades de duração de cada atividade.
A aplicação das simulações de Monte Carlo, nos dias atuais, deve ser apoiada por ferramen-
tas específicas para esse objetivo tais como o @Risk, o SimulAr e o Crystal Ball®. Essas ferra-
mentas funcionam como plug-ins do MS Excel, sendo facilmente utilizadas por quem possui
conhecimentos básicos de estatística.
Figura 10 - Distribuição normal escolhida para a distribuição das probabilidades da duração de uma
atividade de um projeto na ferramenta SimulAr®
Deve ser escolhida como variável de saída, a soma das durações das atividades dos diversos
caminhos do diagrama de redes do cronograma. Posteriormente, seleciona-se a quantidade
de simulações que serão executadas, por exemplo, dez mil, e são dadas como saída, após
as iterações, todas as estatísticas da duração do caminho do diagrama de rede em questão,
além de outras informações importantes, como a probabilidade de se concluir o projeto em
determinada data, ou com um determinado custo, a probabilidade de uma tarefa específica
estar no caminho crítico por verificar locais de convergência de várias atividades no dia-
grama de rede, assim como o risco geral do projeto.
Figura 11 - Resultados da simulação de duração de um caminho da rede do projeto na ferramenta SimulAr

CAPÍTULO 2 55
Antecipações e esperas
Dentro do processo de Sequenciar Atividades, antecipações e esperas “são refinamentos
aplicados /.../ para produzir um cronograma viável ajustando o tempo de início das ativida-
des sucessoras” (PMI, 2017, p. 214). Desta forma, por exemplo, se houver necessidade de
adiantar a atividade predecessora frente à sua sucessora, o cronograma deve refletir isso.
Compressão do cronograma
Quando o cronograma do projeto mostra ao final da sua elaboração que o projeto vai ter-
minar após a data estipulada como limite pelo cliente, ou, até mesmo, quando atividades
do caminho crítico atrasam, a equipe de gerenciamento do projeto precisa comprimir o
cronograma.
Existem dois métodos de compressão do cronograma que permitem acelerar a entrega –

paralelismo (ou fast-tracking) e compressão (ou crashing). O gerente do projeto deve sempre
analisar a opção que causa menor impacto negativo no projeto.
Paralelismo (ou fast-tracking)

O paralelismo ocorre quando o gerente do projeto deixa de executar atividades em sequên-
cia, para fazê-lo em paralelo. Geralmente, é necessário abdicar as relações de dependências
arbitradas, estabelecidas para diminuir o risco do projeto. Dessa forma, o risco de haver
retrabalho aumenta.
Nos exemplos a seguir é possível conferir a aplicação do método paralelismo. Neles, pode-
mos perceber que não houve alteração na duração das atividades, contudo, houve redução
na duração do pacote de trabalho.
Figura 12 - Cronograma do MS Project® antes do paralelismo
Após aplicar a técnica do paralelismo, temos:

Figura 13 - Cronograma do MS Project® depois do paralelismo
Compressão (ou crashing)
A compressão ocorre acelerando uma, ou mais atividades específicas, por adicionar recur-
sos ao projeto, ou fazer uso de horas extras. Essa possibilidade, invariavelmente, aumenta o
custo de determinada atividade, além de ter aplicabilidade restrita à natureza das atividades.
Nos exemplos a seguir, é possível conferir a aplicação do método de compressão. É possível

perceber que houve a necessidade de alocar um recurso a mais para trabalhar na atividade,
fazendo que sua duração fosse menor (coisa que não ocorreu no método anterior) e tam-
bém impactando no custo da mesma, por conta da alocação do recurso extra.
Figura 14 - Cronograma do MS Project® antes da compressão
Após aplicar a técnica de compressão, temos:
Figura 15 - Cronograma do MS Project® depois da compressão
Existem atividades que não podem ser comprimidas, como nos casos em que dependem de
uma reação química que demora a ocorrer. Além disso, conforme anteriormente citado, ao
acrescentarmos um recurso às atividades, nem sempre temos o prazo diminuído propor-
cionalmente. Outro fato é que o uso de horas extras, geralmente resulta em uma produtivi-
dade menor do recurso devido ao cansaço e ao estresse, além de aumentar a probabilidade
de erros, elevando o risco de retrabalho.
CAPÍTULO 2 57
Sistema de Informações de gerenciamento de projetos (SIGP)

De acordo com o PMBOK® (PMI, 2017, p.95), o “SIGP fornece acesso a ferramentas de sof-
tware de tecnologia da informação (TI), [...] Coleta e relatório automatizados sobre os princi-
pais indicadores de desempenho (KPI) podem fazer parte deste sistema.”
O SIGP também faz parte das ferramentas e técnicas que podem ser utilizadas no processo
de Desenvolver o Cronograma.
Planejamento Ágil de grandes entregas

Se por um lado o PMBOK® destaca uma série de processos que podem ser realizados no
ciclo de vida de um projeto, mas não destaca como necessariamente gerenciá-lo, uma meto-
dologia ágil, como o Scrum, por exemplo (geralmente usado no desenvolvimento de softwa-
res), pode apoiar muito bem esta parte. Por outro lado, sabe-se que existem uma série de
projetos que não podem ser gerenciados plenamente usando o Scrum. Desta forma, a ideia
da utilização de uma metodologia ágil, não é desagregar das boas práticas sugeridas pelo
guia PMBOK®, mas, sim, fazer com que elas se complementem.
Saídas
As saídas do processo “desenvolver cronograma” são a linha de base do cronograma, o
cronograma do projeto propriamente dito, os dados do cronograma, calendário do projeto,
solicitações de mudança – quando houver – e as atualizações do plano de gerenciamento do
projeto e dos documentos do projeto.
Linha de base (baseline)

Após o final da fase de planejamento do projeto, assim como após o replanejamento oriundo
de solicitações de mudanças aprovadas no processo Controle Integrado de Mudanças,
alguns documentos importantes formam a linha de base ou baseline do projeto.
As linhas de base de um projeto são:
■■ linha de base de escopo – declaração de escopo, EAP e dicionário

da EAP;
■■ linha de base de custo – orçamento do projeto dividido em fases;
■■ linha de base de cronograma – versão do cronograma com as datas
de base de início e de término.
VOCÊ SABIA?
Os documentos que formam as linhas de base são aprovados pela equipe do projeto e pelo
patrocinador e, com base neles, o desempenho do projeto é medido. Normalmente, para
se mudar algum documento da linha de base, é necessária uma solicitação de mudança.
Porém, isso pode ser flexibilizado para simplificar o processo de gerenciamento de projetos,
exigindo que as solicitações de mudança somente aconteçam, quando houver mudança de
escopo, de prazo, de custo, ou de qualidade esperada de uma entrega.
Formas de visualização do cronograma

O cronograma pode ser visualizado de várias formas diferentes, dependendo do interesse
da pessoa para qual se deseja informar. Pode ser desde uma lista de atividades com todas
as informações referentes exibidas ao lado de cada uma – visão utilizada pela equipe de
gerenciamento de projetos, na maior parte das vezes em que é preciso fazer alterações no
cronograma –, até um diagrama de marcos, que pode ser utilizado em uma apresentação,
em fórum gerencial.
Lista ou planilha de atividades

Nesse formato de visualização, todas as informações referentes às atividades se apresen-
tam em colunas ao lado de sua descrição – duração, recurso, data de início, data de fim, etc.
A descrição das atividades, normalmente, vem identificada, de modo que as atividades dos
pacotes de trabalho sejam facilmente percebidas como partes integrantes do mesmo grupo.
A lista, ou tabela, é o formato de cronograma mais reconhecido, porém mais difícil de ser
compreendido. Geralmente, é utilizado pela equipe de gerenciamento do projeto, que
conhece bem as tarefas e suas inter-relações.
Figura 16 - Cronograma em forma de lista ou planilha de atividades

CAPÍTULO 2 59
Gráfico de Gantt
Trata-se de uma representação gráfica do projeto em forma de barras horizontais, mais fácil
de ser lida e melhor compreendida por usuários que não conhecem tão bem o projeto. Tam-
bém é uma forma de se representar o diagrama de rede, pois tem identificadas as relações
de precedência entre as atividades.
Figura 17 - Gráfico de Gantt tirado do MS Project®
Diagrama de Marcos
Essa visão mostra somente as datas das entregas mais importantes do projeto. É mais
utilizada para comunicação com clientes, patrocinadores e executivos, apresentando, ape-
nas, o que interessa diretamente a esse público.
Figura 18 - Cronograma em forma diagrama de marcos
Nesta figura é possível observar que as atividades foram filtradas para apresentar apenas
os marcos do projeto.
Assim, ao avaliar os diferentes processos de gerenciamento, planejamento e aplicação de

cronogramas, é possível ter uma perspectiva mais ampla, para tomar decisões a respeito
dos melhores métodos para cada tipo de projeto.
Resumo
Na primeira unidade deste capítulo, em Estimativa da duração das atividades, mostra-
mos a complexidade de se efetuar estimativas e explicamos diversas técnicas, que minimi-
zam a margem de erros.
Em seguida, na unidade Comportamentos prejudiciais ao sucesso do projeto, aborda-

mos, mais especificamente, os comportamentos humanos que prejudicam as estimativas
do projeto e a execução das suas atividades dentro de um prazo estipulado.
Em Desenvolvimento do cronograma, esclarecemos as diversas técnicas para a constru-

ção do cronograma do projeto, abordamos assuntos sobre restrições de datas e explicamos
como elaborar essa ferramenta pelo método do caminho crítico. Apresentamos as formas
de compressão do cronograma com foco no nivelamento de recursos. Em seguida, discuti-
mos o conceito de linha de base, listando as diversas linhas de base componentes em um
projeto. Por fim, analisamos a simulação de Monte Carlo, bem como as diversas formas de
visualização do cronograma.
Esperamos ter atingido o objetivo deste capítulo, fornecendo ferramentas para que você
realize esses processos do gerenciamento do cronograma.
CAPÍTULO 3 61
Capítulo 3
GERENCIAMENTO DO
CRONOGRAMA EM PROJETOS –
CONTROLE E OUTROS MÉTODOS
INTRODUÇÃO
Para muitas pessoas que executam projetos, Entendemos também que, com o crescimento e
mas não possuem conhecimentos técnicos mais a adesão aos métodos ágeis de gerenciamento
aprofundados sobre as melhores práticas, o de projetos, seria necessário dedicarmos uma
cronograma é a única ferramenta existente. Ele é unidade exclusiva para abordar alguns métodos
um meio pelo qual se realiza todo o planejamento existentes e os softwares utilizados para auxiliar o
e se controla a execução, sem o auxílio de outras seu gerenciamento.
ferramentas fundamentais, como planos de
gerenciamento, planos de comunicação ou EAP. Dessa forma, acreditamos que você possa dedicar
atenção especial às boas práticas existentes na
Após a elaboração do cronograma, é chegado o literatura, com foco em construir e gerir o seu
momento de, efetivamente, executar o projeto. cronograma da melhor maneira possível e com o
Para isso, é necessário que se faça o controle de objetivo de atingir os melhores resultados no seu
todas as atividades, respeitando a quantidade de projeto.
recursos para sua execução e os prazos previstos
para suas entregas.
Como forma de enriquecimento do nosso

conteúdo, é apresentado, neste capítulo, o
método da corrente crítica baseado na Teoria
das Restrições – uma alternativa ao método do
caminho crítico – que busca reduzir a duração
do projeto por meio de corte das margens de
segurança (ou daquelas gordurinhas do projeto) e
da utilização de buffers.
CAPÍTULO 3 63
Após concluir o estudo deste capítulo, você será capaz de:
■■ empregar as ferramentas e as técnicas do Guia PMBOK® para controlar o cronograma;

■■ conhecer e empregar o Método da Corrente Crítica para a construção de cronogramas;
■■ conhecer os métodos ágeis em gerenciamento de projetos.

Unidade 1 – Controlar o cronograma
Unidade 2 – Método da corrente crítica
Unidade 3 – Método ágil em gerenciamento de projetos

UNIDADE 1
CONTROLAR O CRONOGRAMA
Após a confecção do cronograma, o gerente do projeto começa efetivamente a fazer o moni-

toramento e o controle do projeto, pois adquire condição de acompanhar o andamento das
atividades do projeto e de entender seu controle ou possíveis atrasos.
Controlar o cronograma é um processo que tem como principais objetivos:

■■ determinar seu atual andamento;
■■ controlar os fatores que propiciam as mudanças;
■■ determinar uma mudança no projeto;
■■ gerenciar as mudanças conforme elas ocorrem.
Na realidade, a variável tempo é incontrolável. O gerente do projeto pode controlar outros

itens, considerando a medição do tempo como um indicador que baliza o momento em que
uma ação deve ser tomada sobre esses fatores. Os principais itens que podem ser contro-
lados são:
■■ se a quantidade de fatores de produção (pessoas e materiais) é suficiente para a execu-
ção do projeto no prazo;
■■ se os fatores de produção não estão sendo utilizados em atividades diferentes das des-
critas no projeto;
■■ se a produtividade efetivamente realizada foi a esperada durante as estimativas de

duração das atividades;
■■ se não está sendo feita atividade além do previsto no escopo do projeto;
■■ se mudanças não estão sendo realizadas sem o efetivo controle previsto no plano de
gerenciamento de projetos;
■■ ajuste de partes futuras do projeto para lidar com os atrasos, evitando solicitar uma
prorrogação de prazo.
São entradas do processo de Controlar Cronograma: o plano de gerenciamento do projeto

– já com os planos de gerenciamento e cronograma e as linhas de base de cronograma,
escopo e medição do desempenho –; os documentos do projeto, tais como o registro de
lições aprendidas, os calendários do projeto e dos recursos; o cronograma e os dados do
cronograma, conforme figura a seguir.
CAPÍTULO 3 65
Figura 1: Controlar o Cronograma: Diagrama do Fluxo de Dados.
Plano de 4.5
gerenciamento Monitorar e
de projeto Controlar o
• Informações Trabalho do
sobre o Projeto
Plano de gerenciamento do projeto desempenho do
• Plano de gerenciamento do trabalho
4.6
cronograma Realizar o
• Linha de base do cronograma Controle
• Linha de base do escopo • Solicitações de Integrado
• Linha de base da medição do mudança de Mudanças
desempenho
Documentos
do projeto
6.6 Plano de
Controlar gerenciamento
Documentos do projeto o cronograma de projeto
• Calendários do projeto Atualizações do plano de
• Cronograma do projeto gerenciamento do projeto
• Calendários dos recursos • Plano de gerenciamento do
• Dados do cronograma cronograma
• Linha de base do cronograma
4.3 • Linha de base dos custos
Orientar e • Linha de base da medição do
Gerenciar o desempenho
Trabalho do
Projeto Documentos
• Previsões do
cronograma do projeto
• Dados de desempenho do
trabalho Atualizações de documentos
do projeto:
Empresa/ • Bases das estimativas
organização • Registro das lições aprendidas
• Cronograma do projeto
• calendários dos recursos
• Ativos de processos organizacionais • Registro dos riscos
• Dados do cronograma
Fonte: Guia PMBOK®, 2017, pág. 223.
Entram, também, o processo Orientar e Gerenciar o Trabalho do Projeto, que também é

entrada para os outros processos de controle e monitoramento (escopo, custo, qualidade,
recursos, comunicações, riscos, aquisições e partes interessadas), e, por fim, os ativos e pro-
cessos organizacionais.
Sistema de controle de mudanças
Todas as mudanças no projeto (principalmente as que afetam as restrições – escopo, crono-

grama, custo, qualidade, satisfação do cliente, recursos e riscos –, afetando o cliente final)
devem ser feitas via processo formal chamado Controle Integrado de Mudanças. Esse pro-
cesso deve ser realizado tanto no momento em que o cliente necessita de uma mudança
no escopo do produto quanto no momento em que a equipe de gerenciamento do projeto
necessita executar ações corretivas que alterarão a linha-base do cronograma, modificando,
consecutivamente, o prazo final de entrega do projeto. Essas mudanças devem ocorrer de
acordo com o Plano de Gerenciamento de Projeto e geralmente são introduzidas por meio
de um formulário de solicitação de mudanças, cujo exemplo pode ser encontrado na figura
a seguir.
Figura 2 – Exemplo de um formulário de solicitação
Solicitação de Mudança Idt:<Identificador do Projeto>
Título: <Título do Projeto>
Órgão: <Nome do Órgão ou Unidade Cliente>
Cliente: <Nome do Contato no Cliente>
Área Responsável: <Área responsável Gerente do Projeto: <Nome completo do gestor do projeto>
pelo projeto>
Área do Aprovador: <Sigla da Área do Aprovador: <Nome completo do aprovador>
aprovador>
Código <Obrigatório - código Data da requisição <Data da solicitação da

sequencial da solicitação.> mudança.>
Título da Mudança <Obrigatório - título para solicitação da mudança.>
Requisitada por <Obrigatório - nome do responsável pela solicitação de mudança.>

Tipo de Mudança
() Escopo () Orçamento
() Cronograma () Qualidade
Descrição da mudança solicitada
<Obrigatória - citar e descrever a mudança solicitada, informando que produto(s) e/ou serviço(s) que
será(ão) gerado(s) e/ou afetado(s) com a sua realização.>
Justificativa
<Obrigatória - sucinta descrição da motivação para a realização da mudança solicitada - Porque o
projeto deve ter essa mudança?>
Impacto se não realizada
<Informar o que pode acontecer ao projeto se não houver a mudança solicitada>
Essa solicitação deve ser sempre analisada pelo Comitê Integrado de Mudanças, podendo
ser aprovada ou rejeitada pelo patrocinador ou pelo comitê. Tanto o cronograma quanto
os documentos que foram afetados pela mudança devem ser alterados. Uma nova linha de
base do cronograma deve ser gerada sempre após uma mudança aprovada nesse artefato.
CAPÍTULO 3 67
É recomendado manter o controle de versão dos documentos e cronogramas anteriores,

com suas linhas de bases antigas, caso haja necessidade de resgatar alguma informação.
É importante ressaltar que o gerente de projetos deve eliminar as causas da necessidade

de mudanças. E, geralmente, isso está relacionado a uma gerência de projetos deficiente,
pois alguma parte interessada foi deixada de lado durante o levantamento de requisitos. Em
outras palavras, o bom gerenciamento de projetos deve buscar minimizar os impactos de
futuras solicitações de mudanças. Ainda que as mudanças ocorram, é preciso que sejam as
de menor impacto possível para o projeto. Para isso, o Gerente de Projetos deve enfocar em:
■■ finalizar os requisitos finais com antecedência;
■■ prever reservas para o cronograma e os custos;
■■ ter funções e responsabilidades claras para aprovar as mudanças.
Sobre o processo de mudanças, abrange as seguintes etapas:

■■ avaliação do impacto;
■■ criação de opções/alternativas;
■■ obtenção de aprovação interna da solicitação de mudança;
■■ obtenção de aprovação do cliente (caso necessário).
Caso as solicitações de mudança ocorram com muita frequência, é necessário analisar a

possibilidade de encerrar o projeto e iniciar um novo com os requisitos mais completos.
Medição de desempenho e análise da variação
As técnicas de medição de desempenho de prazo incluem a Análise de Valor Agregado (AVA)

– quantia orçada para a quantidade de trabalho efetivamente terminada na atividade e que
possui os indicadores de Variação de Prazo (VPR) e o Índice de Desempenho de Prazos
(IDP). Esses índices permitem avaliar a extensão das variações no cronograma do projeto.
Veja que a Variação de Prazo (VPR) é igual ao Valor Agregado (VA) menos o Valor Planejado (VP):
VPR = VA - VP
Já o Índice de Desempenho de Prazos (IDP) é a relação entre VA e VP. Pode ser utilizado para
prever a data de término do cronograma. Quando esse índice é menor que 1, significa que
o projeto está atrasado; se for maior que 1, o projeto está adiantado; e, se for igual a 1, o
projeto caminha conforme previsto.
IDP = VA / VP
Outra forma de medição de desempenho de prazo do projeto ocorre via gráficos de barras
de comparação do cronograma. A maioria dos softwares atuais de gerenciamento de projeto
viabiliza essa análise, em que o gerente do projeto atualiza o status das atividades (e uma
barra de andamento é desenhada concomitantemente, representando o andamento plane-
jado). A figura a seguir mostra a utilização do gráfico de barras para análise do cronograma.
Figura 3: Utilização de gráfico de barras para análise do cronograma
Data de status
Barra do prazo Barra do prazo

original revisado
(baseline)
Barra do prazo
Barra do processo real
físico (% complete): 75%
(physical % complete):
15% Barra de horas
realizadas
(% trabalho): 63%
Fonte: Barcaui et al., 2006.
A medição do desempenho oferece subsídios para a análise das variações. Portanto, quando
um desempenho não satisfatório é identificado, é preciso analisar os desvios, para que
sejam implementadas ações corretivas.
Para conhecer melhor a técnica de medição de desempenho de prazo via

gráfico de barras de comparação de cronogramas, consulte Barcaui et al.
(2006).
INFORMAÇÃO
EXTRA
Muitas vezes, os desvios não são suficientemente impactantes para justificar uma ação cor-
retiva. Em outras situações, esses desvios necessitam de ações enérgicas, inclusive com a
participação do patrocinador do projeto.
CAPÍTULO 3 69
Logo, é importante a elaboração de um relatório em que se avalie o impacto dos desvios (se
ele vai alterar a data final de entrega do projeto, se a atividade com desvio tem folga sufi-
ciente para suportá-lo, etc.), a necessidade de ação corretiva, seu detalhamento e a expecta-
tiva do resultado. Caso não seja necessário, justifica-se no relatório.
Relatórios de acompanhamento
Em muitos projetos, recomenda-se um relatório de acompanhamento de periodicidade

estabelecido no Plano de Gerenciamento. O documento pode ser produto de uma reunião
periódica da equipe de projeto ou produzido fora de uma reunião e deve alcançar o nível de
acompanhamento necessário, conforme a complexidade do projeto.
Figura 4 – Modelo de Relatório de Acompanhamento do Projeto
Relatório de Acompanhamento do Projeto Idt:<Identificador do Projeto>
Título: <Título do Projeto>
Órgão: <Nome do Órgão ou Unidade Cliente>
Cliente: <Nome do Contato no Cliente>
Área Responsável: <Área responsável Gerente do Projeto: <Nome completo do gestor do projeto>
pelo projeto>
Área do Aprovador: <Sigla da Área do Aprovador: <Nome completo do aprovador>
aprovador>
Objetivos do Projeto
Ocorrências Relevantes
Previsões da Próxima Semana
INDICADORES CUSTO H.H. PRAZO AVANÇO FÍSICO

Situação
Planejamento Até a Data 73%
Real Até a Data 73%
Planejado Total (LB Atual) 05/07/2011 05/05/2012
Projetado Total 31/05/2012
Projetado Total (LB 0) 05/07/2011 05/05/2012
Desvio 9%
SITUAÇÃO GERAL Pontos de Atenção
Pontos de Atenção
Descrição Status Ação Proposta Responsável Quando
Geralmente, as informações constantes nesse tipo de relatório abrangem o status do pro-

jeto, os desvios de prazo e de custo, as ações que foram realizadas no período e as que
serão realizadas no próximo, pontos de atenção importantes a serem comunicados aos
interessados do projeto, entre outras informações.
Embora haja outros canais de comunicação, o relatório é uma forma de

cliente, patrocinador e demais envolvidos saberem previamente que, com
determinado período preestabelecido, receberão informações sobre o
andamento das atividades e poderão tomar as providências necessárias
para eventuais desvios.
VOCÊ SABIA?
Vale destacar pontos importantes que devem constar nos relatórios de acompanhamento:
■■ índices claros e objetivos;
■■ informação precisa e atual;
■■ cronograma atualizado;
■■ situação do projeto e de suas atividades;
■■ progresso – o que já foi realizado e o que ainda falta;
■■ projeções – normalmente de custo, prazo e escopo;
■■ acompanhamento dos riscos.
É importante levar em consideração o público que irá receber as informações, haja vista que
um grupo pode desejar informações mais detalhadas, como coordenadores e gerentes, por
exemplo, enquanto outro pode desejar algo mais genérico, como diretores (destacando os
problemas que só essa esfera poderia resolver). Mas isso varia de acordo com a realidade
de cada organização.
UNIDADE 2
MÉTODO DA CORRENTE CRÍTICA
O método da corrente crítica (Critical Chain Project Management – CCPM) é uma filosofia
utilizada para o desenvolvimento de cronograma e controle do projeto. Esse método foi
introduzido por Eliyahu M. Goldratt na década de 1990 e apresentado em seu livro Criti-
cal Chain (1997). Baseado em um algoritmo derivado da Teoria das Restrições, também do
mesmo autor, pode levar à execução de projetos que são de 10% a 50% mais rápidos que as
metodologias tradicionais, como a do Caminho Crítico.
CAPÍTULO 3 71
A corrente crítica possui semelhanças com o caminho crítico. Porém, considera, além das
relações de precedência entre as atividades, as dependências de recursos (enquanto no
método do caminho crítico, os recursos são considerados infinitos). Para conhecer as princi-
pais diferenças entre as duas filosofias, acompanhe o quadro a seguir.
Quadro 1 – Diferença entre Caminho Crítico e o Método da Corrente Crítica
A UTILIZAÇÃO DE Essas dependências não são identificadas no diagrama de rede e,

DEPENDÊNCIAS DE por isso, são denominadas implícitas. Porém, são registradas e leva-
RECURSOS das em consideração.
A corrente crítica não busca o melhor caminho possível para chegar ao

AUSÊNCIA DE
fim do projeto, pois as incertezas inerentes às tarefas são impeditivas
PROCURA DE UMA
nesse sentido. Dessa forma, procura-se um caminho suficientemente
SOLUÇÃO ÓTIMA
bom.
Busca, em vez de inserir gordura nas atividades, incluir um buffer no

IDENTIFICAÇÃO
final da corrente crítica (project buffer) e um ao final de cada caminho
E INSERÇÃO DE
que se une à corrente crítica (feeding buffer). Isso possibilita a dimi-
BUFFERS
nuição de até 50% na duração de cada atividade individualmente.
MONITORAR OS Em vez de controlar as atividades, o gerente do projeto monitora a

BUFFERS DO PROJETO taxa de consumo dos buffers.
O método propõe a eliminação de marcos de projeto e uma redução na estimativa da ati-

vidade de acordo com algoritmos preestabelecidos. Esses algoritmos garantem, em média,
50% de redução no tempo de execução de cada tarefa. Por fim, os buffers são montados no
final da corrente crítica e de cada caminho que se liga a ela, utilizando 50% do total da esti-
mativa retirada, anteriormente, de todas as atividades dos caminhos.
Corrente crítica de recursos (CCR)
Podemos ver, pela figura a seguir, a diferença entre o caminho crítico de um projeto e a cor-
rente crítica de recursos.
Figura 5 – Caminho crítico x Corrente crítica
Recurso A Recurso B Recurso A Recurso A Recurso B Recurso A

20 d 20 d 20 d 20 d 20 d 20 d
Tarefa 1 Tarefa 2 Tarefa 3 Tarefa 1 Tarefa 2 Tarefa 3
Recurso C Recurso C Recurso C Recurso C Recurso C Recurso C
20 d 12 d 20 d 20 d 12 d 20 d
Recurso B Recurso D Recurso D Recurso B Recurso D Recurso D
20 d 20 d 20 d 20 d 20 d 20 d
A corrente crítica de recursos tem sempre maior duração porque as tarefas são deslocadas
para frente com base na disponibilidade dos recursos que devem executá-las, após o nive-
lamento desses recursos.
Como montar a corrente crítica
A partir de agora, apresentaremos uma exemplificação simplificada da montagem de uma

corrente crítica. Para isso, consideremos o diagrama de rede da figura a seguir.
Figura 6 - Diagrama de rede do exemplo
Recurso A Recurso B Recurso A

40 d 40 d 40 d
Tarefa 1 Tarefa 2 Tarefa 3
Recurso C Recurso C Recurso C

40 d 24 d 40 d
Recurso B Recurso D Recurso D

40 d 40 d 40 d
Fonte: elaborado pelo próprio autor, 2012.
Essa figura mostra o cronograma inicial, sem ponderar a dependência de recursos e as esti-
mativas de duração das tarefas, calculadas da maneira tradicional.
1. A primeira tarefa para montar a corrente crítica é retirar as gorduras das estimativas de
duração das atividades, as quais podem representar até 50% de sua duração. A realização
dessa estimativa insere na atividade uma segurança que aumenta a probabilidade de que
ela seja cumprida no prazo. Por causa de fenômenos como a Multitarefa, a Lei de Parkin-
son e a Síndrome do Estudante, a tarefa acaba sendo realizada em seu prazo máximo,
atrasando o projeto.
CAPÍTULO 3 73
Figura 7 – Distribuição de probabilidades de duração de uma atividade (a maior parte da estimativa,

nesse caso, é margem de segurança)
Probabilidade
SUA
MEDIANA ESTIMATIVA
SEGURANÇA
Tempo
50% 30%
2. Logo, ao removermos essa margem de segurança nas estimativas de atividade das tare-
fas, obtemos o cronograma encurtado de maneira significativa.
Figura 8 – Retirada da margem de segurança da estimativa de tempo das atividades

40 d 40 d 40 d 20 d 20 d 20 d
Recurso C Recurso C Recurso C Recurso C Recurso C Recurso C
40 d 24 d 40 d 20 d 12 d 20 d
40 d 40 d 40 d 20 d 20 d 20 d
3. O próximo passo é identificar a corrente crítica – conceito análogo ao caminho crítico,

mas considerando a dependência de recursos, além das relações de precedência. Para
isso, é preciso nivelar os recursos das atividades, retirando a superalocação. Em seguida,
o caminho sem folgas deve ser identificado, considerando tanto as relações de precedên-
cia quanto o nivelamento de recursos.
Figura 9 – Nivelamento de recursos e destaque para a corrente crítica identificada

20 d 20 d 20 d 20 d 20 d 20 d
Recurso Recurso
Recurso C C Recurso C Recurso C C
Recurso C
20 d 12 d 20 d 20 d 12 d 20 d
20 d 20 d 20 d 20 d 20 d 20 d
4. Após a identificação da corrente crítica, modificamos a data de início das tarefas para a
data de início mais tarde. O método da corrente crítica defende a utilização da data de iní-
cio mais tarde para diminuir o risco de retrabalho nessas atividades diante da ocorrência
de mudanças, além de ser bom para o fluxo de caixa do projeto. Isso também minimiza o
desperdício de tempo por diminuir as folgas nas tarefas.
Figura 10 - Ajuste das atividades para a data de início mais tarde
Recurso A Recurso B Recurso A

20 d 20 d 20 d
Recurso C Recurso C Recurso C
20 d 12 d 20 d
Recurso B Recurso D Recurso D
20 d 20 d 20 d
Nessa etapa, o gerente deve inserir o buffer do projeto (project buffer) após a corrente crí-
tica e os feeding buffers nas ligações entre outros caminhos e a corrente crítica. Existem
vários métodos para o cálculo dos buffers, sendo o mais simples aquele que representa a
metade de todas as gorduras que foram retiradas das atividades individualmente. Dessa
forma, mantém-se uma margem de segurança garantida pelos buffers, enquanto diminui-se
o prazo de entrega. Na figura a seguir, o projeto duraria 200 dias após o nivelamento de
recursos sem a utilização da corrente crítica (e passaria a durar 150 dias considerando o
buffer do projeto).
CAPÍTULO 3 75
Figura 11 - Cronograma do projeto com os buffers
Recurso A Recurso B Recurso A Buffer

20 d 20 d 20 d 10 d
Recurso C Recurso C Recurso C Buffer
20 d 12 d 20 d 26 d
Buffer Recurso B Recurso D Recurso D Buffer do projeto

20 d 20 d 20 d 20 d 50 d
O gerente, durante a execução, passa a gerenciar os buffers (e não mais as entregas das ati-
vidades, feitas individualmente). Para cada buffer, dependendo de seu consumo, há atitudes
predefinidas a serem tomadas, a saber:
0 a 1/3 do buffer consumido

Nenhuma ação é requerida do gerente do projeto. Afinal, é considerado um consumo den-
tro da margem de erro aceitável.
Entre 1/3 e 2/3 do buffer consumido

O gerente de projeto deve definir um plano de ação, com os gestores dos recursos do pro-
jeto, para voltar ao nível anterior de consumo do buffer.
Entre 2/3 e o total do buffer consumido

Deve existir um plano de ação, criado durante o planejamento do projeto, para essas situações,
a fim de que o gerente realize sua aplicação até o consumo do buffer voltar ao primeiro terço.
Críticas sobre o método da corrente crítica
Primeiramente, vale ressaltar que o método da corrente crítica não é a salvação do geren-
ciamento de projetos e que existem algumas limitações sobre sua aplicação. Os autores
Raz, Barnes e Dvir (2003) destacam dois problemas: o primeiro dele está na margem de
segurança alocada pelo especialista na tarefa, haja vista que nem todas as pessoas colocam
a mesma quantidade de gordura numa atividade; o segundo ponto é se os especialistas
concordarão em reduzir suas estimativas de duração e mesclar seus fatores de segurança
individuais no projeto com os feeding buffers.
Por outro lado, o método traz alguns benefícios interessantes, como:
“...o desenvolvimento de um cronograma mais realista e, consequentemente, mais asser-

tivo, o desenvolvimento de projetos executivos com um menor lead time, um sistema
mais dinâmico e mais flexível que permite haver mudanças no escopo do projeto até uma
data mais tarde, sem prejuízos ao cronograma, um produto final de maior qualidade (já
que, na maior parte do tempo, os recursos estarão dedicados a uma única tarefa, ou ao
menos a um menor número de tarefas), e um controle mais efetivo do desenvolvimento
dos projetos.” (SILVA, Éverton M.; RODRIGUES, Luis H.; LACERDA, Daniel P., 2012, p.15).
De qualquer maneira, trabalhar com o método da corrente crítica, por ser uma metodologia,
é mais eficaz do que não trabalhar com nenhuma metodologia. Raz, Barnes e Dvir (2003,
p.31) sugerem que se a sua organização não possui um planejamento efetivo de projeto e
processos de controle, executa um número relativamente grande de projetos similares em
um ambiente matricial, e sua principal preocupação é cumprir prazos, o método da corrente
crítica pode ser benéfico.
UNIDADE 3
MÉTODO ÁGIL EM GERENCIAMENTO DE PROJETOS
O método ágil engloba uma série de metodologias e frameworks direcionados inicialmente

para solucionar problemas no gerenciamento e desenvolvimento de softwares.
Alguns autores apontam o surgimento do método ágil com o sistema de fabricação da Toyota,
hoje conhecido como Lean Manufacturing – que, dentre suas ferramentas, inclui o kanban –,
enquanto outros destacam o artigo de Takeuchi e Nonaka, The New New Product Development
Game, publicado na década de 1980 (RIGBY, D; SUTHERLAND, J; TAKEUCHI, H., 2016).
O fato é que as metodologias ágeis cresceram e se desenvolveram nos últimos anos e foram
adotadas no Guia PMBOK®, em sua 5ª edição, ganhando mais ênfase com a introdução de
algumas ferramentas e técnicas, como sprint e planejamento de iteração, como destacado
no processo Desenvolver o Cronograma.
O manifesto ágil
Em um encontro histórico em fevereiro de 2001, em uma estação de esqui em Utah, nos

Estados Unidos, 17 importantes desenvolvedores se reuniram para discutir sobre os méto-
dos leves (como era chamado originalmente o método ágil) de desenvolvimento de softwa-
res em contraponto aos métodos pesados existentes na época. Criaram assim o manifesto
ágil, com 12 princípios para orientar a forma de se trabalhar com projetos.
CAPÍTULO 3 77
Veja, no quadro a seguir, os 12 princípios do Manifesto Ágil.
Quadro 2 – Doze princípios do Manifesto Ágil
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada

1
de software com valor agregado.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.

2 Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o
cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos me-

3
ses, com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto

4
por todo o projeto.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o su-

5
porte necessário e confie neles para fazer o trabalho.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe
6
de desenvolvimento é através de conversa face a face.
7 Software funcionando é a medida primária de progresso.

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,
8 desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefi-
nidamente.
9 Contínua atenção à excelência técnica e bom design aumenta a agilidade.
10 Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.
11 As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então
12
refina e ajusta seu comportamento de acordo.
Fonte: Agile Manifesto, 2001.
O manifesto destaca que as pessoas e suas interações são mais importantes do que proces-
sos e ferramentas; que trabalhar em software é mais importante do que fazer a sua docu-
mentação; que a colaboração com o cliente é mais importante do que as negociações e
contratos; e que responder às mudanças é mais importante do que seguir um plano.
Os métodos ágeis
O método ágil engloba uma série de conceitos, como o desenvolvimento iterativo e incre-
mental e os times auto-organizáveis e multifuncionais, que buscam o envolvimento mais
próximo dos usuários (clientes) para o desenvolvimento da solução, possibilitando assim
uma maior chance de retorno do investimento feito.
O modelo tradicional de desenvolvimento, baseada no modelo em cascata (waterfall), des-

crito por Royce (1970), prevê uma sequência de fases, em que uma se inicia apenas após o
término da anterior. Isso faz com que o produto final só seja entregue no término da última
fase. Tentava-se, com esse método, impor uma previsibilidade no processo, sem mudanças
ou alterações.
Figura 12 – Modelo em cascata
Requisitos
do sistema
Requisitos
do software
Análise
Design
do programa
Codificação
Teste
Operações
Fonte: ROYCE, 1970.
O próprio autor, contudo, falava dos riscos que esse modelo trazia, visto que era necessá-
ria uma especificação bem detalhada do que o cliente queria (e nem sempre ele tem plena
consciência de tudo o que necessita). Como o desenvolvimento é feito de uma só vez e o
cliente não terá a chance de fazer novas solicitações, há uma inclinação de se colocar mais
funcionalidades do que seria necessário. Outro ponto importante diz respeito ao seguinte
fato: se os requisitos forem alterados, isso afetará o prazo final da entrega. Da mesma forma,
se um erro ocorrer, ele só será percebido muito tarde, na fase de testes.
Já o desenvolvimento ágil tem uma abordagem iterativa e incremental. A construção é feita por
partes (incrementos), em vários ciclos de desenvolvimento (iterações). Dessa forma, se tem um
resultado, há um produto mínimo viável (minimum viable product – MVP) em cada ciclo.
CAPÍTULO 3 79
Figura 13 – Abordagem iterativa e incremental
Iteração 1
Iteração 2
Iteração 3
Iteração 4
Iteração 5
Requisito Requisito Requisito Requisito Requisito
Análise Análise Análise Análise Análise
Construção Construção Construção Construção Construção
Teste Teste Teste Teste Teste
Liberação Liberação Liberação Liberação Liberação
mês 1 mês 2 mês 3 mês 4 mês 5
Existe uma série de métodos para trabalhar com o desenvolvimento ágil. Alguns enfocam o
gerenciamento do fluxo de trabalho (como o Scrum e o Kanban), outros abordam a prática
(como a modelagem ágil e a programação extrema). Também há aqueles que oferecem
suporte às especificações e ao desenvolvimento de requisitos (FDD), além daqueles que
cobrem todo o ciclo de desenvolvimento (DSDM, RUP).
A seguir, acompanhe uma lista de frameworks ágeis:

■■ Agile modeling (chamada inicialmente de extreme modeling, é um suplemento a outras
metodologias ágeis);
■■ Crystal;
■■ Desenvolvimento Adaptável de Software (Adaptive Software Development - ASD);
■■ Desenvolvimento Guiado por Funcionalidades (Feature-Driven Development - FDD);
■■ Desenvolvimento Rápido de Aplicação (Rapid Application Development - RAD);
■■ Disciplined Agile Delivery;
■■ Kanban;
■■ Lean Startup / Lean Software Development;
■■ Metodologia de Desenvolvimento de Sistemas Dinâmicos (Dynamic Systems Develop-
ment Method - DSDM);
■■ Processo Unificado Ágil (Agile Unified Process – AUP, que é uma simplificação da Rational
Unified Process - RUP);
■■ Programação Extrema (Extreme Programming - XP);
■■ Scrum;
■■ Scrumban (um híbrido entre Scrum e o Kanban).
De acordo com a 12ª publicação do State of Agile (2018), as metodologias mais utilizadas são
o Scrum, ScrumBan e o Scrum/XP híbrido, com 70% de adesão. Outras metodologias híbri-
das têm 14%; o Kanban, 5%; o desenvolvimento iterativo, 3%; Lean Startup e Programação
Extrema (XP), aproximadamente 1% cada; e outros métodos têm, aproximadamente, 6%.
Nesta unidade, são apresentados o Scrum e o Kanban.
Benefícios do método ágil

Olhando o manifesto do método ágil, é possível ter uma ideia dos benefícios que ele pode
trazer, visto que a forma de conduzir o projeto está baseada nessas orientações.
Dentre os benefícios que o método ágil pode trazer, destacam-se a habilidade de gerenciar
as mudanças de prioridade, a visibilidade e transparência do projeto (com entregas mais
curtas, mais rápidas e mais simples, é mais fácil ter uma ideia do que está acontecendo), o
alinhamento com o negócio, o aumento da produtividade, da moral da equipe e da quali-
dade da entrega, a redução do risco e dos custos dos projetos.
Scrum
Ao contrário do que se pensa, o Scrum não é um processo ou metodologia de gerencia-
mento de projetos; é um framework que reúne uma série de técnicas, princípios, práticas
e valores que permitem à equipe do projeto fazer entregas de alto valor em um ambiente
instável e complexo. De fato, o Scrum é melhor aplicado em ambientes caóticos, nos quais
a tecnologia é mais complexa e quando não se conhece suficientemente bem os requisitos.
No entanto, para que as entregas aconteçam, é necessário priorizar o que será desenvolvido
antes e o que pode ser deixado para os ciclos seguintes.
Como as entregas são feitas de forma gradual, ajustes, alterações e correções de erro ao
longo do processo não têm um impacto tão grande quanto teriam em um modelo de desen-
volvimento tradicional, em cascata. Isso possibilita, assim, maior qualidade das entregas.
O Scrum é fundamentado na teoria de controle de processos empíricos e segue três princí-

pios: transparência (para fazer de maneira honesta o que precisa ser feito), inspeção (com
frequência que não atrapalhe o trabalho – geralmente uma vez a cada duas semanas) e
adaptação. Esse ciclo de inspecionar o que está sendo feito e adaptar uma melhor maneira
de fazer aprendendo com os erros do passado leva a constantes aprimoramentos das entre-
gas, seja durante o desenvolvimento ou na entrega final do produto.
Esses princípios, no entanto, só se fortificam quando são baseados nos 5 valores do Scrum:
comprometimento (em atingir os resultados), coragem (para fazer o trabalho certo, mesmo
nas adversidades), foco (nos trabalhos da sprint), sinceridade (quando a equipe e os stake-
holders abrem o jogo sobre os desafios a serem vencidos) e respeito (pela independência e
capacidade de cada um).
CAPÍTULO 3 81
Papéis do Scrum
Para que o Scrum seja adotado, é fundamental a existência de três papéis na equipe do
Scrum (Scrum team): o Product Owner, o Scrum Master e o Development Team. Também é
necessário que seus trabalhos sejam respeitados pela organização.
Product Owner: é aquela pessoa que, conhecendo as necessidades dos clientes, promove
a visão do produto, especificando as características que esse produto precisa ter e qual item
do backlog do produto deve ser priorizado (de acordo com a demanda dos stakeholders).
Responsável por monitorar o progresso das entregas. Geralmente é um Gerente de Produ-
tos ou Patrocinador do Projeto.
Scrum Master: é um facilitador (não um gerente de projeto) que exerce a função de lide-
rança servidora para a equipe do Scrum e que tem a responsabilidade de remover entraves
no trabalho, manter a equipe produtiva e disseminar para a organização a teoria, as regras,
os valores e as práticas do Scrum. Deve garantir que os artefatos do Scrum (definidos a
seguir) sejam transparentes. Ele é a autoridade no Scrum, e, para isso, precisa ter grande
conhecimento do Scrum. Geralmente é um Gerente de Projeto.
Development Team: é o Time de Desenvolvimento (não é a equipe do projeto!) multifuncio-

nal auto-organizado, composto geralmente de 3 a 9 pessoas, que tem a responsabilidade de
desenvolver e entregar um incremento de produto potencialmente utilizável em cada sprint
e atingir a meta do Product Owner. Essa equipe não precisa de um gerente de projetos, visto
que suas expertises permitem que eles tomem a decisão em conjunto para definir a melhor
forma de alcançar os resultados.
Eventos do Scrum
São os cinco eventos compulsórios do Scrum, com duração fixa (ou time boxed), para inspeção
e adaptação da sprint, que ajudam a manter a transparência e a tornar mais produtiva a equipe
do Scrum. É papel do Scrum Master organizar e facilitar esses eventos (sprint, Planejamento da
sprint, Reuniões diárias, Revisão da sprint e Retrospectiva da sprint, detalhados a seguir).
Sprint: é o coração do Scrum. É composto pelas iterações, eventos que duram 1 mês ou
menos, em que os backlogs do produto são desenvolvidos pelo Time de Desenvolvimento
e entregues em forma de um incremento de produto ou produto final. Cada sprint pode
ser considerada um projeto de um mês de duração. E uma sprint começa após o término
da anterior. Caso seu objetivo se torne obsoleto, a sprint pode ser cancelada pelo Product
Owner, e todo o backlog do produto deve ser revisto.
Planejamento da sprint (sprint planning)
É uma reunião da equipe do Scrum, de, no máximo, 8 horas (para cada sprint de 1 mês), para
planejar o trabalho necessário na sprint. Nessa reunião, dividida em dois tópicos, o Product
Owner apresenta os itens do backlog do produto que devem ser feitos. Em seguida, é dis-
cutido como o trabalho será feito, para que os itens possam ser decompostos; e as tarefas,
estimadas.
Reuniões diárias (daily Scrum)
São reuniões diárias com horário e local fixos, de aproximadamente 15 minutos de duração,
em que cada integrante do Time de Desenvolvimento responde a três perguntas feitas pelo
Scrum Master (mas este não necessariamente precisa estar presente):
■■ O que eu fiz ontem para atingir a meta da sprint?
■■ O que farei hoje para atingir a meta da sprint?
■■ Existem impedimentos para não atingir a meta da sprint?
Revisão da sprint (sprint review)
Reunião de 4 horas realizada no fim de cada sprint para o Time de Desenvolvimento demons-
trar para o Product Owner e stakeholders o resultado da sprint. Quaisquer necessidades de
revisão são discutidas nessa reunião.
Retrospectiva da sprint (sprint retrospective)
Reunião da equipe do Scrum feita depois da revisão da sprint e antes da sprint seguinte, para
avaliar o que funcionou e o que pode ser melhorado para a próxima sprint.
Artefatos do Scrum
Uma boa forma de compreender o Scrum é através do framework a seguir. Nele é possível
observar como os três artefatos se relacionam com os eventos do Scrum.
CAPÍTULO 3 83
Figura 14 – Framework Scrum
Reunião
Diária 24 horas
Tarefas do
backlog 2a4
expandidas semanas
pelo time
Backlog da sprint
} Backlog do Produto
Priorizado pelo Product Owner
Incremento do produto
potencilmente utilizável
Fonte: adaptada de SLIGER, 2011.
Backlog do produto
Composto por todas as funcionalidades que precisam ser desenvolvidas no projeto, obede-
cendo aos critérios de aceitação do Product Owner, ordenados por grau de importância (essa
priorização também é conhecida por grooming e pode ser feita em uma reunião de refina-
mento com a equipe). O Product Owner apresenta a visão do produto, com as informações
sobre que deve ser o produto e o que fazer de acordo com a visão do cliente, de modo que
isso possa ser desmembrado em requisitos para o desenvolvimento (o backlog do produto).
Temos, assim, as histórias de usuário (ou user stories), que descrevem os requisitos do pro-
duto de maneira mais simplificada e objetiva, normalmente descritas em pequenos cartões.
Nesses cartões, são apresentados o ator da história (o interessado pela funcionalidade), a
ação (o que ele deseja e precisa ser feito) e o objetivo (o resultado da ação ou benefício).
Para pontuar as histórias de usuário e permitir um desenvolvimento mais veloz, foi criado
o conceito de story point, que seria uma unidade relativa de medida. De acordo com COHN
(2005), story point é uma união da quantidade de esforço necessária para o desenvolvimento
de uma funcionalidade, juntamente com o seu nível de complexidade e risco envolvido. O
Time de Desenvolvimento pontua as histórias de usuário obedecendo a esses critérios.
Backlog da Sprint
Refere-se às funcionalidades que serão desenvolvidas em cada sprint. O item (história de usu-
ário) com maior prioridade será o primeiro a ser desenvolvido na sprint, que é decomposta
em tarefas. Essa definição é feita na reunião de planejamento da sprint e se baseia a quan-
tidade de funcionalidades e na capacidade de desenvolvimento da equipe. Essa estimativa

de desenvolvimento pode ser feita através de uma das técnicas apresentadas nesta apostila
ou, no caso de desenvolvimento de softwares, através da contagem dos pontos de função.
Os itens a serem desenvolvidos precisam caber dentro do período da sprint, do contrário,
devem ser desmembrados em partes menores. Se, no decorrer da sprint, houver alguma
necessidade de mudança, o Time de Desenvolvimento deve negociar com o Product Owner.
Incremento do produto potencialmente utilizável
É um produto (ou incremento de um produto) apto a ser lançado no mercado e que possui
todas as funcionalidades as quais o Time de Desenvolvimento entenda que estejam definiti-
vamente prontas (baseando-se em suas regras preestabelecidas).
Acompanhamento
O acompanhamento pode ser feito através das técnicas burndown e burnup, as quais vere-
mos a seguir.
Burndown
O gráfico de burndown representa uma prática comum para acompanhar a evolução do

desenvolvimento e as entregas dos incrementos. O eixo vertical representa os pontos que
existem para serem desenvolvidos, enquanto o eixo horizontal representa a quantidade de
sprints (também dividida em dias). Acompanhe a figura a seguir.
Figura 15 – Gráfico burndown Gráfico Burndown
100
90 90
83 Realizado Previsto
80
STORY POINTS
70
65
60 59
50 47
40 42
34
30
20 19
10
5
0 0
1 2 3 4 5 6 7 8 9 10
SPRINTS - DIAS

CAPÍTULO 3 85
Nele é possível comparar o trabalho diário realizado com o que havia sido previsto e, no
decorrer das sprints, ir queimando quantos pontos faltam para terminar aquele incremento
de produto. Nas reuniões diárias, esse gráfico é muito utilizado pela equipe de desenvolvi-
mento. É uma forma também de demonstrar transparência no que está sendo feito.
Burnup
Uma outra forma de observar a evolução das entregas é através do gráfico burnup, que esta-
belece a quantidade máxima de pontos a serem desenvolvidos. Confira a seguir!
Figura 16 – Gráfico burnup

140
120
100
STORY POINTS
98
Realizado
80 85
70 Previsto
60 55
45
40
35
30
25
20
10
0 5
1 2 3 4 5 6 7 8 9 10
SPRINTS - DIAS
Veja que, no eixo horizontal, a quantidade de pontos vai se acumulando ao longo das sprints
até chegar à quantidade limite.
Estimativas e decisões
A estimativa de tempo dos backlogs de produtos que serão desenvolvidos pode se dar atra-
vés de uma série de técnicas. Além daquelas já apresentadas e sugeridas pelo Guia PMBOK
(2017) e presentes nos módulos 1 e 4, pode-se destacar: o Poker do Planejamento e o Fist of
Five, que veremos a seguir.
Poker do Planejamento
De acordo com Greening (2002, apud COHN, 2005, p.56), a melhor maneira para uma equipe
ágil fazer estimativa é através do poker do planejamento. Essa técnica segue o mesmo prin-
cípio do método Delphi e reúne a opinião especializada, a estimativa análoga e a decompo-
sição em uma forma rápida e confiável de fazer estimativas.
Para fazer essa estimativa – e levando em consideração o Time Scrum (mas podendo ser
qualquer outro) –, cada membro do time de desenvolvimento recebe um deck de cartas,
numeradas com os seguintes valores: 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Esses valores são base-
ados em um modelo simplificado da sequência de Fibonacci, e cada número representa um
story point, que seria a quantidade de pontos relacionados a um nível de dificuldade para
desenvolver a história do usuário.
O Product Owner lê, então, a história do usuário (story point), inicialmente pela história mais
simples, para poder criar um parâmetro em que a funcionalidade mais fácil receba 1 ponto.
Os membros refletem sobre o assunto, escolhem uma carta e apresentam ao mesmo tempo.
Os valores são confrontados; e as disparidades, questionadas. Depois de algumas rodadas,
chega-se a um consenso. Todo esse processo é intermediado pelo Scrum Master e se repete
até todas as estimativas serem concluídas.
Fist of Five
É uma técnica em que os participantes expressam seu voto (sobre uma decisão que está em
discussão) levantando de um a cinco dedos. A quantidade de dedos indica o nível de apoio
ou não ao assunto discutido.
Dos resultados possíveis, temos: o punho fechado, que demonstra total objeção; 1 dedo
demonstra que mudanças precisam ser feitas; 2 dedos indicam que há objeções que pre-
cisam ser discutidas; 3 dedos são usados para apoiar com ressaltas, mas a ideia pode ser
levada a diante; 4 dedos apoiam a decisão; e 5 dedos indicam apoio à decisão e destacam
que a ideia deve ser implementada primeiro.
Se alguém levantar menos do que três dedos, a pessoa tem a chance de expressar o seu
ponto de vista. A votação é levada até se chegar a um consenso.
O importante, como se pôde perceber, é não perder muito tempo para decidir as coisas.
Kanban
Kanban é um termo japonês que significa cartão (ou sinalização), sendo utilizado como sistema
de sinalização de reabastecimento de estoque. Taiichi Ohno, engenheiro da Toyota, utilizou o
Kanban para garantir um controle mais eficiente dos processos e eliminar funções desneces-
sárias da linha de montagem, dando base assim para o Sistema Toyota de Produção. Dessa
forma, Kanban se tornou um método voltado para produção enxuta e para o just in time.
Na área de desenvolvimento tecnológico, o método foi aplicado primeiramente por David J.

Anderson. Anderson (2013) destaca que o Kanban usa cinco propriedades centrais para criar
uma série de comportamentos ágeis na organização: visualizar o fluxo de trabalho, limitar o
CAPÍTULO 3 87
trabalho em progresso, medir e gerenciar o fluxo, tornar as políticas de processos explícitas

e utilizar modelos para reconhecer oportunidades de melhorias.
Para trabalhar com o Kanban, é necessário ter um fluxo de trabalho estabelecido, para,
então, baseando-se em uma lista de prioridades, definir qual tarefa será desenvolvida pri-
meiro. Cada tarefa deve ser uma descrita em um cartão, e os cartões serão apresentados
em um quadro Kanban de tarefas. É possível utilizar esse método juntamente com o Scrum,
por exemplo. A figura a seguir exemplifica um quadro Kanban.
Figura 17 – Quadro Kanban
A Fazer Fazendo Feito

Tarefa Tarefa Tarefa Tarefa
C D B A
Tarefa
Z
Os itens mais prioritários, definidos pelo gerente, cliente (ou pelo Product Owner) ou então
pelo Time de Desenvolvimento são apresentados no topo do repositório de cartões na lista
de coisas “a fazer”. Os itens urgentes usam um cartão vermelho; os que requerem atenção,
amarelo; e os de condições normais, verdes.
Assim que o profissional responsável pela execução terminar de fazer sua

tarefa, ele puxa a mais prioritária dessa lista (“a fazer”) e inicia sua execução
(colocando o cartão na lista “fazendo”). Ao término da tarefa, o cartão vai
para a lista de tarefas concluídas (“feito”). É possível observar que esse
modelo é um tipo de sistema puxado (pull system).
É comum ter outras seções (colunas) no quadro, de acordo com o fluxo de

trabalho da organização. Uma seção “verificar” depois da seção “fazendo”
é bem comum, por exemplo, em desenvolvimento de aplicativos ou em
NA PRÁTICA outras, como “análise”, “produção” e “teste”.
A quantidade de itens puxados vai depender da capacidade de execução e das particula-

ridades de cada organização. Novamente, uma técnica para estimar o trabalho pode ser
aplicada nesse momento. O importante é dosar a quantidade de trabalho para não ter ocio-
sidade nem afetar a produtividade e não sobrecarregar a pessoa e produzir perdas (para
não afetar a qualidade da entrega). No próprio quadro Kanban, é possível observar se há
acúmulo de tarefas em uma seção – basta observar a quantidade de cartões dentro dela.
É possível também estabelecer métricas para acompanhar a evolução e, dessa forma, pro-
por melhorias. Uma delas é o lead time, que vai do momento em que uma tarefa é criada até
o momento em que ela é concluída; outra é o ciclo de tempo, que começa no momento em
que a tarefa inicia o seu progresso e vai até a sua conclusão final; e existe também o tempo
de reação, que é a diferença entre o tempo em que a tarefa é criada e o seu início.
Dessa forma, e baseando-se na Teoria das Restrições, é possível buscar as oportunidades de

melhorias ao questionar se o problema está nas pessoas, nos processos, nos equipamentos
ou nas políticas.
Os softwares de gerenciamento de projetos
Gerenciar um projeto não é uma tarefa tão simples, pois existem várias atividades que pre-
cisam ser desempenhadas de forma organizada, cada uma com suas respectivas datas e
recursos. Gravar tudo isso na cabeça ou em anotações no caderno é praticamente inviável
e, para nos ajudar nesse processo, existe a tecnologia.
Atualmente, no mercado existem centenas de ferramentas que auxiliam o gerenciamento

de projetos. Há softwares que vão desde uma versão mais simples, são gratuitos, com pou-
cas funcionalidades, até os pagos para instalação em seu computador/servidor, plataforma
web ou integrados com seu smartphone.
Qual software sua empresa deve escolher, o mais vendido no mercado

ou aquele que atende à realidade da empresa? Ele deve se adequar mais
rapidamente às boas práticas do que os outros fazem ou amadurecer
gradativamente?
Independentemente de qual software escolher, vai depender da maneira

como a organização gerencia seus projetos, do nível de detalhamento de
PARE PARA que precisa e também do quanto a empresa tem para investir, seja nas
licenças ou nos treinamentos.
PENSAR
CAPÍTULO 3 89
Com o avançar das metodologias ágeis de gerenciamento de projetos, a gama de softwares

aumentou significativamente. No entanto, o mais comum continua sendo o MS Project®,
utilizado por mais de 20 milhões de usuários – mas existem vários, tal como o Oracle Prima-
vera P6, bastante usado em projetos de engenharia e construção, e muitos outros, como o
VersionOne, Jira, Trello, Zoho Projects, CA Agile Central, Planview LeanKit, BaseCamp, Asana,
Aceproject, Teamwork Project ,etc.
Vale destacar que, com o método ágil, uma série de outras ferramentas também são asso-
ciadas ao gerenciamento, como o Excel, Google Docs, Microsoft TFS, HP Quality Center/ALM,
dentre outros.
Resumo
No terceiro módulo da disciplina Gerenciamento do Cronograma e dos Custos em Projetos,
você pôde perceber a importância do controle do cronograma para o gerente de projetos.
Conceituamos essa ferramenta analisando seus componentes.
No Controle do cronograma, tratamos do sistema de controle de mudanças – quando é

necessário modificar o cronograma durante o andamento do projeto. Também pudemos
entender melhor como analisar a variação entre a linha de base e o cronograma atual, além
de verificarmos como os relatórios de projeto auxiliam no acompanhamento.
Foi apresentado, em seguida, o método da corrente crítica, como uma forma alternativa
ao caminho crítico para a construção de cronogramas.
Por fim, apresentamos alguns métodos ágeis de gerenciamento de projetos, dando ênfase
ao Scrum (ótimo de se trabalhar em ambientes complexos e instáveis), e ao método Kanban,
que pode ser trabalhado em conjunto ao Scrum e ajuda na organização e visualização das
tarefas. No final, ainda destacamos uma série de softwares que podem auxiliar você no
gerenciamento ágil de projetos.
Esperamos ter atingido o objetivo deste módulo, contribuindo na sua compreensão sobre a
importância do cronograma e no desenvolvimento de habilidades para construir e controlar
essa ferramenta da melhor maneira possível.
Capítulo 4
GERENCIAMENTO DOS CUSTOS

EM PROJETOS
CAPÍTULO 4 91
INTRODUÇÃO
O Gerenciamento dos Custos em Projetos é uma Essa realidade se conecta ao Gerenciamento

área de conhecimento importante e complexa. dos Custos em Projetos, primeiramente, porque
Como as palavras “prejuízo” e “retrabalho” deixam a estimativa dos custos, no momento de sua
qualquer um preocupado, há uma atenção ainda escolha, será refinada no período da estimativa
maior no planejamento e no controle de custos. de custos no planejamento do projeto. Depois,
porque mudanças no orçamento do projeto
Sabe-se que os recursos monetários são finitos modificam seu ROI, muitas vezes, justificando seu
para todas as companhias, assim, a escolha de cancelamento.
se realizar um projeto abrange abdicar outro,
deixar de aumentar a produção ou investir em Sendo assim, neste capítulo, você conhecerá
marketing para aumentar a receita. Desta forma, as entradas, as técnicas, as ferramentas e as
grande parte das empresas escolhem seus saídas dos processos componentes da área de
projetos a partir de um processo que antecede conhecimento do Gerenciamento dos Custos,
o gerenciamento de projetos. Assim, comparam- baseadas na versão de 2017 do Guia PMBOK®,
se os retornos sobre o investimento (ROI) dos assim como outros conceitos e técnicas
projetos, que é a diferença entre o retorno encontrados na literatura. Com esse ferramental,
financeiro e seus custos, embora muitos projetos acreditamos que você possa gerenciar o custo
tenham o ROI indefinido e nebuloso (KENDALL et do projeto dentro das necessidades de uma
al., 2003). No caso de alguns projetos sociais e do empresa.
governo, por exemplo, pode ser mais complicado
aferir um retorno financeiro, contudo, os projetos
precisam justificar sua viabilidade e seu retorno.
Após concluir o estudo deste capítulo, você será capaz de:
■■ entender os conceitos relativos a custos em projetos;

■■ empregar as ferramentas e técnicas para estimar os custos das atividades e determinar
o orçamento do projeto;
■■ conhecer e aplicar o conceito de Curva S;
■■ empregar as ferramentas e as técnicas para controlar os custos das atividades, com
foco no Gerenciamento de Valor Agregado (GVA).

Unidade 1 – Conceituação
Unidade 2 – Estimar os custos
Unidade 3 – Determinar o orçamento
Unidade 4 – Controlar os custos

CAPÍTULO 4 93
UNIDADE 1
CONCEITUAÇÃO
Antes de apresentar os processos do Gerenciamento dos Custos em Projetos, é fundamen-

tal compreender os conceitos que se relacionam aos custos. De acordo com Costa et al.
(2014), os termos listados a seguir devem ser corretamente entendidos e utilizados pelo
Gerente de Projetos.
Quadro 1: Definição de termos a serem utilizados pelo Gerente de Projetos.
Dispêndio financeiro reconhecido contabilmente para a obtenção de

GASTO
um produto ou serviço.
Aplicação de recursos no processo de criação de um resultado especí-

CUSTO
fico, sendo que só é reconhecido quando utilizado para este fim.
DESPESA Gastos não relacionados à produção de um resultado específico.
DESEMBOLSO Pagamento resultante da aquisição de um bem ou serviço.
PERDA Quando o bem ou o serviço é consumido de maneira involuntária.
INVESTIMENTO Bem ou serviço adquirido e ainda não utilizado ou estocado.
Decisão de negócios que define o valor pelo qual o resultado será

PREÇO
vendido.
Fonte: COSTA et al., 2014.

Além disso, de acordo com o Guia PMBOK® (PMI, 2017), os processos que compõem a disciplina
de Gerenciamento dos Custos em Projetos podem ser analisados conforme o quadro a seguir.
Quadro 2: Processos de Gerenciamento dos Custos.
PLANEJAR O GERENCIAMENTO DO CUSTO ESTIMAR OS CUSTOS
Faz parte do conjunto de processos de Faz parte do conjunto de processos de pla-

planejamento. É a etapa em que são nejamento. Nesta etapa, a equipe do projeto
definidas as diretrizes do gerenciamento estima a quantidade de recursos monetários
dos custos. Disto, saem os planos e as necessários para executar as atividades do
políticas sobre como será feita a gestão projeto.
dos custos.
DETERMINAR O ORÇAMENTO CONTROLAR OS CUSTOS
Faz parte do conjunto de processos de Faz parte do conjunto de processos de mo-

planejamento. Processo em que são nitoramento e controle. Neste processo, é
somados os custos das atividades para feita a atualização do orçamento do projeto e
determinar o custo total do projeto e são gerenciadas as mudanças necessárias na
definir a linha de base de custos que será linha de base de custos a partir do processo
formalmente autorizada. de controle integrado de mudanças.
Fonte: PMI, 2017.
Por outro lado, temos, também, o novo padrão ISO 21500:2012 (Guia em Gerenciamento de
Projetos), baseado no Guia PMBOK®, que considera como atividades de gerenciamento de
custos: estimar custos, desenvolver orçamento e controlar custos.
Para obter mais detalhes sobre a Norma ISO 21500:2012 (Guia em

Gerenciamento de Projetos), você pode acessar o site a seguir, onde
encontrará descrições minuciosas sobre conceitos e processos
fundamentais para boas práticas em gerenciamento de projetos.
Leia mais a respeito no link: <www.abntcatalogo.com.br/norma.
aspx?ID=92033>.
INFORMAÇÃO
EXTRA
CAPÍTULO 4 95
Na sequência, você pode observar a visão geral dos processos pertinentes ao Gerencia-
mento dos Custos em Projetos, segundo o Guia PMBOK® (PMI, 2017).
Figura 1: Visão geral do Gerenciamento dos Custos em Projetos.
Visão geral do gerenciamento

doS custos do projeto
7.1 Planejar o 7.2 Estimar 7.3 Determinar

gerenciamento dos custos os custos o orçamento
.1 Entradas .1 Entradas .1 Entradas

.1 Termo de abertura do .1 Plano de gerenciamento .1 Plano de gerenciamento
projeto do projeto do projeto
.2 Plano de gerenciamento .2 Documentos do projeto .2 Documentos do projeto
do projeto .3 Fatores ambientais da .3 Documentos do negócio
.3 Fatores ambientais da empresa .4 Acordos
empresa .4 Ativos de processos .5 Fatores ambientais da
.4 Ativos de processos organizacionais empresa
organizacionais .2 Ferramentas e técnicas .6 Ativos de processos
.2 Ferramentas e técnicas .1 Opinião especializada organizacionais
.1 Opinião especializada .2 Estimativa análoga .2 Ferramentas e técnicas
.2 Análise de dados .3 Estimativa paramétrica .1 Opinião especializada
.3 Reuniões .4 Estimativa “bottom-up” .2 Agregação de custos
.3 Saídas .5 Estimativas de três .3 Análise de dados
.1 Plano de pontos .4 Revisão de informações
gerenciamento dos custos .6 Análise de dados históricas
.7 Sistema de informações .5 Reconciliação dos
de gerenciamento de projetos limites de recursos financeiros
.8 Tomada de decisões .6 Financiamento
.3 Saídas .3 Saídas
.1 Estimativas de custos .1 Linha de base dos custos
.2 Bases das estimativas .2 Requisitos de recursos
.3 Atualizações dos financeiros do projeto
documentos do projeto .3 Atualizações de documentos
do projeto
7.4 Controlar os custos
.1 Entradas
.1 Plano de gerenciamento do projeto
.2 Documentos do projeto
.3 Requisitos de recursos financeiros do projeto
.4 Dados de desempenho do trabalho
.5 Ativos de processos organizacionais
.2 Ferramentas e técnicas
.1 Opinião especializada
.2 Análise de dados
.3 Índice de desempenho para término
.4 Sistema de informações de gerenciamento de projetos
.3 Saídas
.1 Informações sobre o desempenho do trabalho
.2 Previsões de custos
.3 Solicitações de mudança
.4 Atualizações do plano de gerenciamento do projeto
.5 Atualizações de documentos do projeto

Com a figura anterior, é possível analisar os processos desde o planejamento até o controle
dos custos. Contudo, para se ter uma ideia do impacto dos custos de um projeto, precisa-
mos ir além e compreender outros conceitos, como o custeio pelo ciclo de vida do produto.
Custeio pelo ciclo de vida do produto
De acordo com Atkinson et al. (2015), a metodologia do custeio pelo ciclo de vida do pro-
duto permite que os gestores tenham uma visão geral e administrem os custos de forma
abrangente, evitando que decisões precipitadas ou errôneas comprometam a estrutura de
custos do projeto. Isto significa que considerar os custos em todas as fases do ciclo de vida
é fundamental para o processo de tomada de decisão.
O ciclo de vida, tratando-se de custos, possui as fases conforme vemos no quadro a seguir.
Quadro 3: Custeio pelo ciclo de vida do produto.
Pesquisa e desenvolvimento
Nesta fase ocorre a projeção do produto ou são feitas as avaliações para a escolha
1 da solução utilizada para produzir os resultados do projeto. Todos os custos refe-
rentes aos testes de possibilidades, cursos e pesquisas para conhecer as soluções
disponíveis devem ser considerados neste momento.
Desenvolvimento do produto
Esta fase é o projeto em si, em que o produto será confeccionado de acordo com os
2 resultados obtidos na fase de pesquisa e desenvolvimento. Neste momento, os cus-
tos a serem considerados são os materiais, a mão de obra e o rateio dos recursos
indiretos disponibilizados pela companhia, como luz, custos administrativos etc.
Manutenção e operação
3 Quando o produto já está em uso, após o fim do projeto, incorre em gastos de ope-
ração e manutenção durante o tempo em que está operando.
Descarte
Nesta fase, incorremos em custos logísticos do descarte. Também podemos ter cus-
4 tos se o material a ser descartado precisar de tratamento especial, como o material
radioativo. Além disso, alguma receita também pode ser auferida ou o produto des-
cartável pode ser alienado nesta etapa.
Fonte: ATKINSON et al., 2015.

CAPÍTULO 4 97
Ao avaliar um projeto para se tomar a decisão sobre sua realização, é fundamental avaliar
os custos totais referentes a todas as fases do ciclo de vida. Os custos também devem ser
considerados no caso de um projeto ser reavaliado após mudanças, pois os custos futuros
necessitam ser comparados ao retorno estimado, desconsiderando os custos já incorridos
(custos afundados), que não são recuperáveis.
Tipos de custos
Os custos foram criados para atender a necessidades de gestão. Segundo Wernke et al.
(2004), os tipos de custos são classificados de acordo com o quadro a seguir:
Quadro 4: Classificação quanto aos tipos de custos.
CLASSIFICAÇÃO CATEGORIAS
Quanto à tomada de decisões Relevantes Não relevantes
Quanto à identificação Diretos Indiretos
Quanto ao volume produzido Variáveis Fixos
Fonte: WERNKE et al., 2004.
O conhecimento dos tipos de custos é muito importante para o Gerente de Projetos, pois
proporciona uma gestão equilibrada, tratando de formas diferentes os custos de naturezas
diversas. A seguir, você irá conhecer mais detalhadamente a respeito dos tipos de custos.
Custos relevantes e não relevantes
A classificação pondera a capacidade de tomada de decisão em relação aos custos. Quando o

Gerente de Projetos pode e lhe convém considerar determinado custo para tomar uma decisão,
este se torna relevante. Sendo assim, custos variáveis de um projeto são, geralmente, relevan-
tes, pois estão diretamente ligados à quantidade produzida. Uma aquisição para um projeto,
que pode ser substituída por mão de obra interna, por exemplo, também é um custo relevante.
Já os custos não relevantes são os que não podem ser alterados pelo Gerente de Projetos
ou que são tão pequenos que não convém ponderá-los. Alguns custos fixos, como o rateio
dos custos administrativos da empresa que caem no projeto, são considerados como não
relevantes por não poderem ser alterados e por não influenciarem nas decisões. Da mesma
forma, o café comprado para a equipe pode ser não relevante por ter um custo tão baixo
que não cabe controlá-lo.
Custos diretos e indiretos
Com relação aos custos diretos e indiretos, podemos classificá-los conforme o quadro a seguir.
Quadro 5: Custos diretos e indiretos.
Exemplos
Os custos diretos são os que podem ser
diretamente atribuídos ao projeto. São os Matéria-prima; mão de obra direta; encargos e salários da equi-
custos naturalmente identificáveis e que pe; aquisições de equipamentos feitas para o projeto; viagens e
não necessitam de rateio. gastos de diárias para atividades diretamente ligadas ao projeto;
amortizações de equipamentos utilizados somente no projeto.
Exemplos
Os custos indiretos são os inerentes à
manutenção das atividades da empresa
e recaem no projeto por meio de rateio. Aquisição de instalações; eletricidade, telefonia e água; manu-
Eles são difíceis de serem reduzidos, pois tenção predial, referente às instalações da empresa; encargos
estão, geralmente, fora de controle do e salários da equipe administrativa, financeira, jurídica etc.;
Gerente do Projeto. encargos e salários da diretoria; impostos e contribuições sobre
o lucro; material de escritório.
Classificar os custos de maneira correta é fundamental para um orçamento mais coerente

do projeto, principalmente no que diz respeito aos custos diretos.
Custos fixos e variáveis
Com relação aos custos fixos e variáveis, podemos classificá-los de acordo com o quadro a
seguir.
Quadro 6: Custos fixos e variáveis.
Os custos fixos são os que não variam em Exemplos

uma relação diretamente proporcional a
quantidade de trabalho do projeto. Eles Matérias-primas; mão de obra direta; viagens e gastos de
tendem a se estabilizar, mesmo se o trabalho diárias para atividades diretamente ligadas ao projeto; ele-
do projeto aumentar ou diminuir. Para alguns tricidade, telefonia, água etc.; material de escritório.
custos, pode-se até ter uma variação, porém
sempre discreta.
Exemplos
Os custos variáveis são os que alteram de
forma diretamente proporcional ao trabalho
do projeto. A quantidade de asfalto para Aquisição de instalações; encargos e salários da equipe do
produzir uma estrada é proporcional ao seu projeto; aquisições de equipamentos para o projeto; amor-
tamanho. Da mesma forma, a quantidade tizações de equipamentos utilizados somente no projeto;
em horas de mão de obra necessária sofre o manutenção predial, referente às instalações da empresa;
mesmo tipo de variação. encargos e salários da equipe administrativa, financeira,
jurídica etc.; encargos e salários da diretoria.

CAPÍTULO 4 99
Um exemplo de custo fixo é o caso de uma máquina perfuradora de túneis para um pro-
jeto de expansão do metrô. Se o projeto possui somente um equipamento, o custo de sua
aquisição é fixo, mesmo aumentando a produtividade da máquina. Porém, se o túnel for
escavado pelos dois lados, haverá a necessidade de se comprar outra máquina, dobrando o
tipo de custo, ainda que ela fique parada por algum tempo. Temos, também, que a quanti-
dade de concreto necessária para fazer o revestimento do túnel é diretamente proporcional
ao tamanho do túnel. Da mesma forma, a quantidade de horas de mão de obra necessária
também sofre o mesmo tipo de variação.
Custos incorridos ou afundados
Custos incorridos ou afundados é um conceito contábil e econômico que se aplica aos cus-
tos já feitos, mas que o resultado vislumbrado para o investimento dos recursos não é rea-
lizado. Isto significa que o dinheiro gasto não oferecerá o resultado desejado, mas, por ser
irrecuperável, não deve influenciar na decisão de continuidade ou interrupção do projeto.
Os recursos considerados custos incorridos ou afundados possuem custo de oportunidade

zero, ou seja, não podemos aplicar o investimento em outra oportunidade porque já foram
utilizados. Por exemplo, imagine um projeto para iniciar uma nova linha de produção de
vestuário em que:
■■ a expectativa de retorno é de R$ 500.000 em 10 anos;
■■ o custo de implantação é de R$ 300.000;
■■ a matéria-prima utilizada é importada e, por causa de oscilações dos cambiais, a expec-

tativa de retorno cai para R$ 200.000;
■■ o projeto já está em andamento;
■■ já foram gastos R$ 250.000.
Que decisão você tomaria? Parar ou continuar a execução do projeto?
Como o valor já gasto é incorrido ou afundado, a comparação é o retorno de R$ 200.000 con-

tra R$ 50.000 ainda a serem gastos (= implantação – gasto já realizado). Portanto, o projeto
deve continuar.
Em contrapartida, se a nova expectativa de retorno fosse de R$ 30.000, deveríamos parar

o projeto, pois, se tivermos R$ 450.000 já gastos, o prejuízo ainda assim será menor. Neste
momento, a decisão deve ser racional, e não emocional. Afinal, não adianta lamentar o ocor-
rido, é preciso considerar o custo como afundado e olhar para o futuro.
Custo de oportunidade
O custo de oportunidade indica o valor da melhor oportunidade de negócios que temos de

renunciar quando aplicamos determinada quantidade de recursos em um projeto. Este con-
ceito advém da escolha entre investimentos. Isto é, todo dinheiro pode ser investido, na pior
das hipóteses, com o retorno de uma aplicação financeira de baixo risco, como poupança ou
renda fixa. Uma empresa possui alternativas ainda mais rentáveis (aumento da produção,
investimento em outro produto ou em projetos para atender variadas oportunidades de
negócios), por isso, escolhe-se um projeto por avaliar que o seu retorno será maior do que
outro investimento não realizado. O valor maior entre eles é o custo de oportunidade.
Um exemplo prático pode ser o de uma incorporadora que possui

dois terrenos. Um está situado em uma área onde a empresa já possui
outros empreendimentos e sabe que um prédio de 10 andares dará uma
receita de 30 milhões de reais. No outro, localizado em um bairro menos
explorado pela companhia, também pode ser construído um prédio de 10
andares pelo mesmo custo. Porém, com a crescente valorização da área,
estima-se obter uma receita de 35 milhões com o último terreno. Deste
modo, ela escolhe investir na área nova, pois o custo de oportunidade
NA PRÁTICA seria de 30 milhões de reais.
Pode-se utilizar um conceito diferente, pelo qual o custo de oportunidade faz parte do custo
dos projetos. É recomendável que o custo de oportunidade utilizado seja o retorno de um
investimento com razoável nível de segurança, e não a oportunidade de maior retorno pos-
sível. Esta prática leva a uma melhor avaliação durante o processo de escolha dos projetos
a compor o portfólio.
Iniciando o gerenciamento do custo (planejar o gerenciamento do custo)
Planejar é o primeiro processo de gerenciamento dos custos, resultando no Plano de Geren-

ciamento dos Custos, em que se reúnem todas as políticas, os procedimentos, as diretrizes
e as definições de métodos e ferramentas que serão utilizados durante o planejamento, a
execução, o monitoramento e o controle dos custos do projeto.
CAPÍTULO 4 101
Figura 2: Planejar o gerenciamento de custos – diagrama do fluxo de dados.
4.1 Desenvolver
o termo de
abertura
do projeto
• Termo de abertura do projeto
dos custos
Plano de Plano de
7.1 Planejar o
gerenciamento
do projeto do projeto
dos custos
Plano de gerenciamento do projeto

cronograma
• Plano de gerenciamento dos riscos
Empresa/
organização

O plano de gerenciamento do custo é parte integrante do plano do gerenciamento do pro-

jeto. Independentemente de sua formalidade, é uma das principais partes do documento.
Sendo assim, a equipe de gerenciamento do projeto deve trabalhar para construir um plano
de gerenciamento de custos coerente com a complexidade e as necessidades do projeto.
Plano de gerenciamento de custo
A partir de reuniões da equipe do projeto, opiniões de especialistas, técnicas de análise

previamente conhecidas pela organização (benchmark1) ou pela experiência profissional da
equipe do projeto, desenvolve-se o plano de gerenciamento de custos. O Guia PMBOK®
oferece como exemplo uma lista de itens que podem compor o documento:
■■ nível de acurácia aceitável das estimativas;
■■ nível de precisão dos valores (se será em milhares de reais, centavos etc.);
■■ unidades de medida que serão utilizadas no gerenciamento de custos do projeto;
■■ ligação entre procedimentos organizacionais que permitem a consistência entre os ele-

mentos do projeto, como a EAP e suas contas de controle com o orçamento;
1 Benchmark é o processo de comparação das melhores práticas de uma empresa com performance superior na
área analisada
■■ regras para medição de desempenho, como a Análise de Valor Agregado;
■■ limites de controle definidos além dos quais a equipe tomará ações;
■■ formatos de report;
■■ descrição dos processos de gerenciamento de custo.
UNIDADE 2
ESTIMAR OS CUSTOS
São muitas as dificuldades para se estimar com boa acurácia. No caso das estimativas de
prazo, elas se resumem em saber quanto tempo os recursos levarão para realizar determi-
nada atividade e, considerando as relações de precedência e o nivelamento de recursos, em
somar as durações das atividades do caminho crítico para definir a duração do projeto.
No caso dos custos, existem os seguintes fatores:

■■ Falta de controle de variáveis que afetam os custos diretos. Entre os fatores, o valor por
hora/Homem de determinados recursos e o preço de alguns insumos do projeto, espe-
cialmente quando são importados e se submetem a variações de câmbio;
■■ Geralmente, os custos indiretos incidentes no projeto são incorporados de acordo com

algum critério corporativo. Este, como forma de rateio, não é controlado pela equipe do
projeto, por isso, se a empresa como um todo passa a consumir recursos de maneira
ineficiente, os custos do projeto aumentam;
■■ Observa-se que empresas com pouca maturidade em gerenciamento de projetos prio-

rizam o prazo e fazem menos restrições com relação aos custos. Isto porque o controle
de custos é mais difícil de ser realizado do que o do cronograma, além de que, na visão
imediatista de boa parte dos patrocinadores, o projeto ser entregue no prazo é mais
importante do que estar dentro do custo. A priorização acaba por provocar a alocação
de mais recursos no projeto, compressões de cronograma e outros fatores que elevam
os custos.
A estimativa de custos, portanto, torna-se importante e deve ser tratada com seriedade.
Afinal, manter o projeto dentro do custo é uma condição necessária para que ele alcance os
resultados esperados para a companhia, uma vez que, se os custos ficarem maiores do que
o retorno financeiro, sua realização não se justifica.
CAPÍTULO 4 103
O diagrama do fluxo de dados do processo para estimar os custos oferece uma visão geral
das entradas necessárias para se iniciar uma estimativa de custos.
Fontes de estimativas
A estimativa de custos se integra com vários processos do gerenciamento de projetos. Neste

sentido, ela recebe os insumos de processos da disciplina de escopo, cronograma, riscos e
recursos, conforme podemos observar na figura a seguir.
Figura 3: Diagrama do fluxo de dados do processo para estimar os custos.
Plano de
gerenciamento
do projeto
Plano de gerenciamento do projeto

• Plano de gerenciamento dos custos
• Plano de gerenciamento • Estimativa de custos
da qualidade • Bases das estimativas
7.2 Documentos
Documentos Estimar do projeto
do projeto os custos
• Cronograma do projeto Atualizações de documento do
• Requisitos de recursos projeto
• Registro dos riscos • Registro de premissas
Empresa/ • Registro dos riscos
organização

No plano, temos:
■■ Plano de gerenciamento do projeto: plano de gerenciamentos dos custos e da qua-
lidade, além da linha de base do escopo, com a descrição do produto, as premissas, as
restrições e o que não está no escopo do projeto.
■■ Documentos do projeto: registro das lições aprendidas, que pode incluir as situações
identificadas ou vivenciadas anteriormente e que podem impactar o projeto de alguma
forma; cronograma do projeto, em que são registradas as estimativas de recursos e de
duração das atividades; requisitos de recursos, que identificam os recursos necessários,
como pessoas, materiais e equipamentos para realizar uma atividade; e registro de ris-
cos, considerando os custos de mitigação e do plano de resposta caso o risco ocorra.
■■ Empresa/organização: fatores ambientais da empresa e ativos de processos organiza-

cionais que definem a aplicação de alguns custos, as políticas e os modelos de estimati-
vas, além das condições em que a empresa está inserida no mercado.
Técnicas para produção de estimativas
As técnicas para produzir as estimativas de custo são basicamente as mesmas utilizadas

para produzir as estimativas de tempo.
Do mesmo modo como ocorre na estimativa de prazos, a estimativa de custos pode ser
realizada pela opinião de especialistas. Além dos especialistas na execução das atividades,
outros tipos devem ser utilizados. Também é possível concluir determinados assuntos a
partir de técnicas, como o brainstorming e o método Delphi.
Utilizando dados históricos ou opinião de especialistas, a estimativa análoga, por sua vez,
considera os custos de atividades semelhantes, ocorridas anteriormente ou de outros proje-
tos. Assim, quanto maior a semelhança entre as atividades, maior será a precisão da estimativa.
A utilização de dados históricos pode nos fazer chegar a fórmulas simples para estimar os
custos. Stewart, Wyskida e Johannes (1995) apresentaram a seguinte fórmula:
Cp = Ce x (Sp / Se)ⁿ
Em que:
Cp = custo total da atividade.
Ce = custo de uma atividade similar.
Sp = tamanho da atividade (comprimento, área, capacidade etc.).
Se = tamanho da atividade similar (comprimento, área, capacidade etc.).
n = expoente para o tipo de atividade.
A fórmula possui um expoente porque o custo da atividade não varia de forma diretamente
proporcional ao seu tamanho. Por causa da curva de aprendizado e dos ganhos de escala, a
variação é amortecida por um fator que varia, geralmente, entre 0,60 e 0,95.
A estimativa análoga é considerada uma estimativa top-down, sendo muito utilizada em

casos em que o custo é uma restrição forte do projeto. Se o custo do produto é definido de
cima para baixo, pela alta administração, o Gerente do Projeto deve utilizá-la.
CAPÍTULO 4 105
Esta técnica consiste em dividir o custo predeterminado para o projeto entre os subprojetos,
entre os pacotes de trabalho e, por fim, entre as atividades. A equipe de gerenciamento do
projeto deve ficar atenta para garantir o equilíbrio entre os custos das atividades e ponderar
as opiniões especializadas e as lições aprendidas para que os custos inviáveis não sejam
estabelecidos.
Temos, ainda, a estimativa paramétrica, que é uma estimativa quantitativa utilizada

quando temos atividades ou projetos do mesmo tipo. Como realçado pelo Guia PMBOK®
(2017), esta técnica pode utilizar modelos estatísticos altamente complexos, que podem
fazer estimativas com elevado grau de precisão ou utilizar fórmulas simples.
Consideremos a atividade de construção de trilhos para uma ferrovia:

sabe-se que, para o tipo de trilho que está sendo construído, um
quilômetro gera o custo de R$ 100 mil, assim, se a ferrovia tiver 50 km de
extensão, seu custo será de R$ 5 milhões.
PARE PARA
PENSAR
Já a estimativa bottom-up é utilizada quando o Gerente do Projeto conhece o conteúdo

das atividades e deseja ter mais precisão dos pacotes de trabalho. Desta forma, ele detalha
ainda mais cada elemento de custo das atividades para estimar o custo unitário de cada um
(multiplicado pela quantidade necessária). Em seguida, ele considera a soma de todos os
elementos de custo e estima o custo total da atividade.
Uma parte importante da estimativa de custos é a faixa de estimativas

possíveis. Por isso, além de prever o custo das atividades, o Gerente do
Projeto deverá estimar sua margem de erro, por exemplo, 10% para
menos e 20% para mais, ± R$ 10 mil etc.
VOCÊ SABIA?
Por fim, temos a estimativa de três pontos. Nela, deve-se considerar os riscos da estima-
tiva mais provável e, a partir da estimativa análoga, paramétrica, opinião de especialistas
etc., efetuar três estimativas para o custo da tarefa, conforme vemos no quadro a seguir.
Quadro 7: Estimativa dos três pontos.
MAIS O custo que normalmente seria considerado, avaliando-se a média das

PROVÁVEL atividades semelhantes ou o que o especialista acredita que irá acontecer.
Estimativa de custo com base no melhor caso, ou seja, na ocorrência dos

OTIMISTA
riscos positivos da atividade.
Estimativa de custo baseada no pior caso, considerando-se os riscos que

PESSIMISTA
podem ocorrer durante a realização da tarefa.
Fonte: Guia PMBOK®, 2017.
Após fazer as três estimativas, define-se o custo da atividade do cronograma com um dos
seguintes cálculos:
(P + M + O )
a) Distribuição triangular =
3
(P + 4M + O)
b) Distribuição beta =
6
Análise de dados
Tal como ocorreu na estimativa de duração, a análise de dados também pode ser utilizada
para estimar os custos das atividades. A análise é dividida em análise de alternativas, aná-
lise de reservas e custo da qualidade.
■■ Análise de alternativas: utilizada para avaliar e selecionar quais são as melhores opções
para o projeto. Imagine, por exemplo, uma organização se deparando com um dilema:
selecionar um profissional mais experiente, com remuneração mais alta; ou um com
menor experiência e remuneração mais baixa? Neste caso, é preciso levar em conside-
ração que o seguro do equipamento sendo utilizado pelo profissional mais experiente é
bem mais baixo do que se for operado pelo profissional de menor experiência.
■■ Análise de reservas: utilizada para determinar a reserva de contingência, ou seja, o

orçamento destinado para lidar com os riscos identificados na linha de base dos custos.
CAPÍTULO 4 107
■■ Custo da qualidade (CQD): custos que podem estar associados à qualidade das entre-
gas, produtos ou serviços do projeto, como o custo de prevenção, relacionado à preven-
ção da má qualidade; os custos de avaliação, relacionado a como aferir a qualidade do
que está sendo entregue; e o custo de falha, relacionado à não-conformidade.
Sistema de Informações de Gerenciamento de Projetos (SIGP) e tomada de

decisão
O SIGP fornece as ferramentas adequadas para que as estimativas de custos possam ser
realizadas. O Gerente do Projeto pode utilizar as planilhas de orçamento ou análises extraí-
das do sistema ERP2 da própria organização para fazer essas estimativas.
Além disso, temos a tomada de decisão, que inclui as técnicas que podem ser utilizadas no
processo de estimar os custos das atividades.
UNIDADE 3
DETERMINAR O ORÇAMENTO
Na língua portuguesa, orçar e estimar os custos possuem significados semelhantes. De

acordo com o dicionário Aurélio, o verbete “orçar” possui a seguinte definição: “1. Calcu-
lar, computar; estimar, esmar; 2. Fazer o orçamento de; avaliar, calcular, estimar; [...] 6.Ter
aproximadamente o valor de [...]”. A diferença entre os processos de estimar os custos e
determinar o orçamento reside, então, no fato de que o orçamento do projeto, além de
determinar a quantidade de recursos financeiros autorizada para a execução, estima o fluxo
de caixa. Portanto, a determinação do orçamento do projeto faz com que seu cronograma
seja dependente da política de financiamento da empresa.
2 Enterprise Resource Planning (ERP) é uma plataforma de software que integra todos os dados e processos de
uma organização.
Figura 4: Diagrama do fluxo de dados do processo de determinar o orçamento.
Plano de
gerenciamento
do projeto
Plano de gerenciamento do projeto Plano de

• Plano de gerenciamento dos custos gerenciamento
• Linha de base do projeto
dos custos
da qualidade
7.3
Documentos Determinar
do projeto o Orçamento
7.4
Controlar
os Custos
• Requisitos de recursos • Requisitos de
• Registro dos riscos recursos financeiros
do projeto
Documentos
de negócio
Documentos
• Business case do projeto
• Plano de gerenciamento de Atualizações de
benefícios documento do projeto
• Estimativa de custos
12.2 • Registro dos riscos
Conduzir as
Aquisições
• Acordos
Empresa/
organização

Para determinar o orçamento, uma das entradas advém do processo de conduzir as aqui-
sições, que pode contemplar os materiais e equipamentos comprados para o projeto, por
exemplo.
CAPÍTULO 4 109
Agregação de custos
Para ter o orçamento é necessário agregar os custos estimados das atividades nos respectivos
pacotes de trabalho da EAP, que devem ser alocados em suas contas de controle (relacionadas
a centros de custo da organização). A realização dos pacotes de trabalho de uma determinada
conta de controle pode permanecer dependente da disponibilidade da liberação de recur-
sos, pela gerência responsável por aquele centro de custo. Essas contas são agregadas nos
subprojetos, que, por sua vez, são integrados no projeto como um todo, formando o Orça-
mento no Término (ONT). A partir de então, as reservas passam a ser consideradas.
Conheça os dois tipos de reserva em projetos:

■■ Reserva de contingência: orçamento para tratar os riscos identificados do projeto e
já aceitos no plano de resposta a riscos. Caso o risco ocorra, a ação do plano deve ser
realizada e as novas atividades no projeto são alocadas. O custo dessas atividades que
compõe a reserva será previamente autorizado e controlado pelo Gerente do Projeto.
Orçamento no Término + Reserva de contingência = Linha de Base de Custo
■■ Reserva gerencial: orçamento para tratar mudanças não previstas no projeto e que não
estavam no plano de resposta a riscos. Esta reserva não está sob a gestão do Gerente de
Projetos e deve ser autorizada pelo patrocinador do projeto.
Linha de Base de Custo + Reserva gerencial = Orçamento de custos para a organização
Para a organização, o custo total estimado para o projeto também considera a reserva
gerencial, que é responsabilidade do patrocinador, conforme vemos na figura a seguir.
Figura 5: Componentes do orçamento do projeto.
Reserva
Orçamento
gerencial
do projeto
Reserva de
Linha de Contas de
contingência
base controle
dos custos Reserva de
Estimativas de contingência
custos do das atividades
pacote
Estimativas de
Quantidade total
de trabalho
custos das
atividades
Componente do orçamento do projeto
Assim, o orçamento do projeto vai muito além das estimativas de custo das atividades.
Fluxo de caixa do projeto e Curva S
Na definição do processo de determinar o orçamento, não somente o valor financeiro orçado

para o projeto compõe suas saídas, isto porque também cabe determinar a distribuição do
orçamento no tempo e as necessidades de financiamento. O Orçamento no Término (ONT),
autorizado e distribuído no tempo, compõe a Linha de Base de Custo.
Os maiores gastos acontecem, geralmente, na fase de execução do projeto, com menor

incidência nas demais fases. Desta forma, a linha de base assume a figura em forma de S.
De acordo com a Curva S encontrada e com as políticas de financiamento de projetos da

companhia, é definida a forma com que os recursos serão aportados. O montante total de
recursos é a soma da linha de base dos custos com as reservas gerenciais. Comumente,
estes aportes são de quantidades determinadas, de tempos em tempos, apresentando uma
curva em formato de escada, como se pode verificar na figura a seguir.
Figura 6: Linha de base dos custos, gastos e requisitos de recursos financeiros.
Orçamento do projeto
Reserva gerencial
ONT
Valores cumulativos
Requisitos de
recursos financeiros
Linha de Gastos
base dos custos
Tempo
Veja um exemplo de geração da Curva S para o projeto de desenvolvimento de um software

de logística de uma rede de supermercados. Na figura a seguir, temos a EAP do projeto, com
os custos já agregados de seus pacotes de trabalho.
CAPÍTULO 4 111
Figura 7: EAP do projeto de desenvolvimento de software de logística.
Software de logística
R$ 810.000
Levantamento de Protótipo Desenvolvimento Homologação Implantação

solução R$ 50.000 R$ 105.000 R$ 460.000 R$ 135.000 R$ 60.000
Especificação Módulo de compras Módulo de compras Módulo de compras Módulo de compras

R$ 20.000 R$ 40.000 R$ 180.000 R$ 50.000 R4 25.000
Módulo de Módulo de Módulo de Módulo de

Levantamento de recebimento recebimento recebimento recebimento
requisitos R$ 30.000 R$ 30.000 R$ 140.000 R$ 40.000 R$ 15.000
Módulo de Módulo de Módulo de Módulo de

distribuição distribuição distribuição distribuição
R$ 35.000 R$ 140.000 R$ 45.000 R$ 20.000
Fonte: Elaborada pelo autor, 2012.
De acordo com o cronograma do projeto, foi feita uma planilha de distribuição dos custos
dos pacotes de trabalho por mês, para os 16 meses previstos para a realização do projeto.
Ao verificarmos a linha de custo mensal, podemos observar que os custos dos meses no
meio do projeto são maiores do que no início e no final.
Figura 8: Orçamento do projeto de desenvolvimento de software de logística.

ATIVIDADES/MESES M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16
Especificação 10 10
Levantamento de requisitos 10 20
Protótipo – compras 5 15 20
Protótipo – recebimento 5 15 10
Protótipo – distribuição 10 15 10
Desenvolvimento – compras 40 40 40 40 20
Desenvolvimento – recebimento 30 30 30 40 10
Desenvolvimento – distribuição 40 40 40 20
Homologação – compras 10 20 20
Homologação – recebimento 10 20 10
Homologação – distribuição 10 20 15
Implantação – compras 15 10
Implantação – recebimento 10 5
Implantação – distribuição 10 10
Custo mensal 10 20 25 20 45 65 80 70 110 110 80 70 45 35 15 10
Custo acumulado 10 30 55 75 120 185 265 335 445 555 635 705 750 785 800 810

Traçando a curva dos custos acumulados do projeto, obtemos a Curva S, verificada na figura
a seguir.
Figura 9: Curva S do projeto de desenvolvimento de software de logística.
900
800
700
600
500
Custo Mensal
400 Custo Acumulado
300
200
100
0
M1 M2 M3 M4 M5 M6 M7 M8 M9 M10M11M12M13M14M15M16
Na figura é possível observar a maior incidência dos custos no meio do projeto, pertinentes à
fase de execução, vista nos gráficos de barra. O acumulado ao longo do tempo é demonstrado
por uma linha, chamada de Curva S, justamente pelo formato que ela assume.
UNIDADE 4
CONTROLAR OS CUSTOS
O processo de controlar os custos visa monitorar os custos do projeto e entender as causas

de suas variações, de forma a oferecer subsídios para o Gerente de Projeto na tomada de
providências. Este processo gerencia as mudanças na linha de base de custos, sendo, tam-
bém, uma entrada para o processo de realizar o controle integrado de mudanças.
CAPÍTULO 4 113
Figura 10: Diagrama do fluxo de dados do processo de controlar os custos.
Plano de 4.5 Monitorar e

gerenciamento controlar o
do projeto • Informações trabalho do projeto
sobre o
desempenho
Plano de gerenciamento do projeto do projeto
• Plano de gerenciamento dos custos
4.6 Realizar o
• Linha de base dos custos
controle integrado
• Linha de base da medição do • Solicitações de mudanças
desempenho de mudanças
Documentos Plano de
do projeto gerenciamento
7.4
do projeto
Controlar os
custos
Atualizações do plano
de gerenciamento de projeto
de custos
• Linha de base dos custos
7.3 • Linha de base da medição
Determinar do desempenho
o orçamento
• Previsões de custos
• Requisitos de recursos financeiros
do projeto
Documentos
do projeto
Atualizações de
4.3 Orientar e
documento do projeto
gerenciar o
trabalho
• Bases das estimativas
do projeto
• Estimativas de custos
• Dados de desempenho do trabalho • Registro dos riscos
Empresa/
organização
Os objetivos da atividade da fase de monitoramento e controle são, entre outros:

■■ gerenciar mudanças conforme suas ocorrências;
■■ garantir que mudanças não autorizadas não sejam implementadas;
■■ assegurar que custos do projeto não sejam acima do autorizado ou fora do aceitável;
■■ monitorar o desempenho dos custos e do trabalho do projeto;
■■ informar as partes interessadas sobre as mudanças.

A principal ferramenta utilizada para controlar os custos de um projeto, assim como o cro-
nograma, é o Gerenciamento de Valor Agregado (GVA)3.
Gerenciamento de Valor Agregado
Para fazer o acompanhamento do projeto, levando em consideração as medidas de escopo,

tempo e custos, utiliza-se o método GVA. Se não houver a integração das três dimensões,
entende-se que o projeto está fora do custo ou do cronograma.
Para cumprir o objetivo, a metodologia monitora três variáveis básicas por meio do tempo:
■■ Valor Planejado (VP): é o valor orçado para produzir as atividades e os pacotes de tra-
balho planejados para o projeto até a data que está se relatando. Temos o valor plane-
jado através da fórmula VP=ONT x PFP, em que:
ONT = Orçamento no Término

PFP = Progresso Físico Previsto
■■ Valor Agregado (VA): é o valor orçado para produzir as atividades e os pacotes de tra-
balho do projeto efetivamente executados até a data que está se relatando. Obtemos o
valor agregado pela fórmula VA=ONT x PFR, em que:
ONT = Orçamento no Término

PFR = Progresso Físico Realizado
■■ Custo Real (CR): é o valor gasto para produzir as atividades e os pacotes de trabalho do
projeto efetivamente executados até a data que está se relatando.
As variações com relação ao custo e ao prazo podem ser medidas tanto em termos monetá-
rios como em forma de índices.
■■ Variação de Prazo (VPR): é a variação entre o Valor Agregado e o Valor Planejado em
um determinado momento, o que reflete o desempenho com relação ao prazo. Ela pode
ser calculada com a fórmula VPR=VA –VP, em que:
VA = Valor Agregado
VP = Valor Planejado
O valor negativo significa que o projeto está atrasado; um valor positivo significa que o
projeto está adiantado; e zero indica que o cronograma está conforme o planejado.
3 É possível encontrar referências ao termo EVA, que é o acrônimo de Earned Value Analysis, traduzido do inglês
como Gerenciamento de Valor Agregado.
CAPÍTULO 4 115
■■ Variação de Custo (VC): é a variação entre o Valor Agregado e o Custo Real em um

determinado momento, o que reflete o desempenho com relação ao custo. Pode ser
observada a partir da fórmula VC=VA –CR, em que:
VA = Valor Agregado
CR = Custo Real
O valor negativo significa que o projeto gastou mais do que o previsto para executar o
trabalho efetivamente realizado, enquanto que um valor positivo significa que o projeto
gastou menos. Zero indica que projeto gastou o que foi orçado para o que foi realizado.
■■ Índice de Desempenho de Prazo (IDP): tem o mesmo significado da Variação de Prazo,

mas em formato de índice. É o resultado da divisão entre o Valor Agregado e o Valor
Planejado. Ele pode ser calculado com a fórmula IDP = VA , em que:
VP
VA = Valor Agregado
VP = Valor Planejado
Quando o IDP é menor do que 1, significa que o cronograma está atrasado, enquanto
que valores maiores do que 1 significa que o cronograma está adiantado. Quando o IDP
é igual a 1, indica que o cronograma está sendo rigorosamente cumprido.
■■ Índice de Desempenho de Custo (IDC): tem o mesmo significado da Variação de Custo,

mas em formato de índice. É o resultado da divisão entre o Valor Agregado e o Custo
VA
Real. Ele pode ser calculado com a fórmula IDC = , em que:
CR
VA = Valor Agregado
CR = Custo Real
Quando o IDC é menor do que 1, significa que as atividades já realizadas tiveram seu
orçamento estourado, enquanto que valores maiores do que 1 significa que as ativida-
des tiveram custo menor do que o previsto. Quando o IDC é igual a 1, o custo das ativi-
dades efetivamente realizadas até o momento foi rigorosamente respeitado.
Imagine um projeto com quatro meses de duração, com orçamento total

de R$ 2.000,00 e que teve seu primeiro mês encerrado, gastando R$ 500,00
dos R$ 600,00 que estavam previstos. Contudo, apenas 1/3 do trabalho
(progresso físico) planejado para o primeiro mês foi executado.
Com isso, é possível identificar as seguintes informações:
VP = R$ 600,00
CR = R$ 500,00
VA = VP x progresso físico = R$ 600,00 x 1/3 = R$ 200,00
Para calcular as variações de prazo e custo, com os respectivos índices,

teríamos:
Prazo:
VPR = VA – VP = R$ 200,00-R$ 600,00 = – R$ 400,00
NA PRÁTICA IDP = VA/VP = (R$ 200,00) / (R$ 600,00) = 0,33…
Custo:
VC=VA – CR = R$ 200,00 – R$ 500,00 = – R$ 300,00
IDC= VA / CR = (R$ 200,00) / (R$ 500,00) = 0,4
Estas informações revelam que, naquele momento, o projeto gastou mais

do que o previsto e ainda está atrasado.
Até aqui, vimos indicadores que nos permitem analisar a situação do projeto enquanto ele
progride. Contudo, dependendo dos motivos e da magnitude dos desvios, o Gerente de Pro-
jetos pode adotar atitudes diferentes, por exemplo:
■■ aceitar os desvios, se estiverem dentro das margens de erro aceitas;
■■ negociar solicitações de mudança com o patrocinador para obter novo prazo ou custo;
■■ negociar a decisão de cancelar o projeto com o patrocinador;
■■ comprimir o cronograma para correções de prazo;
■■ encontrar soluções técnicas mais baratas para corrigir desvios de custo;
■■ negociar mudanças de escopo com o patrocinador.
No entanto, com os indicadores vistos, não é possível assumir decisão. Para esta tomada,
é necessário ter uma estimativa de quando o projeto vai terminar e quanto vai custar ao
final. É possível estimar novamente o prazo e o orçamento com a nova realidade, do mesmo
modo com que foi feito no planejamento, mas, para isto, o Gerente tem de parar a equipe
para gerar novas previsões, o que provocaria ainda mais desvios.
CAPÍTULO 4 117
Neste contexto, o Gerenciamento de Valor Agregado fornece técnicas para que a equipe de
gerenciamento de projeto possa calcular as estimativas, sem precisar realizar novas estima-
tivas bottom-up. Primeiramente, deve-se identificar a natureza do desvio.
Observe as três possibilidades a seguir:

■■ Situação 1: o desvio ocorreu por algum problema pontual e o resto do projeto será exe-
cutado no ritmo originalmente orçado;
■■ Situação 2: o desvio ocorreu por problemas de custo que serão recorrentes no projeto,
sendo que o ritmo executado até agora será mantido até o final do projeto;
■■ Situação 3: o desvio ocorreu por problemas de custo e de prazo que serão recorrentes
no projeto, sendo que o ritmo executado até agora será mantido até o final do projeto.
Identificada a natureza do desvio, o Gerente calcula a Estimativa no Término (ENT) e a Esti-

mativa para Terminar (EPT). A primeira variável informa o quanto é a estimativa de custo
total para o projeto, ou seja, nas condições atuais, qual deveria ser o novo Orçamento no
Término (ONT). A segunda variável, por sua vez, informa o quanto deverá ser gasto do
momento atual para o futuro, pois o que já foi gasto (CR) não é recuperável. Estes valores
são importantes para a decisão de o projeto continuar ou ser cancelado.
Para cada situação o cálculo é feito por fórmulas diferentes. Vamos analisar cada uma a
partir de agora!
Cálculo da situação 1
O custo realizado até o momento é aceito, já que não tem como recuperá-lo. Além disso, o
trabalho feito até o final é calculado, diminuindo o orçamento no término pelo valor orçado
do que já foi produzido. Assim, temos que:
ENT = CR + ONT – VA
EPT = ENT – CR
Continuando com o exemplo, teríamos a seguinte situação:
ENT = CR + ONT – VA
ENT = 500 + 2000 – 200
ENT = R$ 2.300,00
EPT = ENT – CR
EPT = 2300 – 500
EPT = R$ 1.800,00
Assume-se que o Índice de Desempenho de Custo para o resto do trabalho do projeto será
igual ao encontrado até o momento da medição. Desta forma, faz-se uma divisão do orça-
mento no término pelo índice. Assim, temos:
ONT
ENT =
IDC
EPT = ENT - CR
ONT
ENT
= (cumulativo )
IDC
2000
ENT =
0,4
ENT = 5.000
Considera-se que, além do desempenho de custo ser mantido até o final do projeto, o
desempenho de prazo com desvio (diferente de 1) também será mantido. Desta forma, a
estimativa no término deve ser ponderada tanto pelo IDC quanto pelo IDP. Vejamos:
 ( ONT - VA ) 
ENT = CR +  
 (IDC x IDP ) 
EPT = ENT - CR
 ( 2000 - 200 ) 
ENT = 500 +  
 ( 0,4 x 0,33…) 
 1800 
ENT = 500 +  
 0,133… 
ENT = 500 + 13.500
ENT = 14.000
EPT = ENT – CR
EPT = 14.000 – 500
EPT = 13.500
CAPÍTULO 4 119
Percebe-se que o EPT, nos três casos, possui a mesma fórmula de cálculo. Ela será a nova
estimativa orçada para o fim do projeto, menos o custo realizado até o momento do cálculo.
Todos os cálculos diferenciados de acordo com a natureza do desvio são feitos no cálculo da
estimativa no término.
Por fim, podemos calcular a projeção do Índice de Desempenho de Custos que devemos
atingir para que o projeto termine de acordo com o objetivo definido, ou mantendo o ONT
original ou a ENT. Esta projeção se chama Índice de Desempenho para o Término (IDPT),
sendo que sua fórmula de cálculo é expressa do seguinte modo:
IDPT =
(ONT - VA )
(ONT - CR )
Se o ONT for utilizado.
IDPT =
(ONT - VA )
(ENT - CR )
Se o ENT for utilizado.
Se o índice for maior do que 1, será mais difícil concluir. Se for menor que 1, será mais fácil.
Já se for exatamente 1, será igual para concluir o projeto.
Considerando o exemplo da situação 1, temos:
=
IDPT
(ONT - VA )
(ONT - CR )
IDPT =
( 2000 - 200 )
( 2000 - 500 )
1800
IDPT =
1300
IDPT = 1,38
IDPT =
(ONT - VA )
(ENT - CR )
IDPT =
( 2000 - 200 )
( 2300 - 500 )
1800
IDPT =
1800
IDPT = 1
Se levarmos em consideração a situação 3, temos:
=
IDPT
(ONT - VA )
(ENT - CR )
IDPT =
( 2000 - 200 )
( 5000 - 500 )
1800
IDPT =
4500
IDPT = 0,4
A seguir, temos um quadro com os principais termos do MS Project®.
Quadro 8: Nomenclatura utilizada no PMBOK® e no MS Project®.
GUIA PMBOK® MS PROJECT

Sigla Descrição Sigla Descrição
ONT Orçamento no Término - Custo da linha de base
VP Valor Planejado COTA Custo Orçamentado do Trabalho

Agendado
VA Valor Agregado COTE Custo Orçamentado do Trabalho

Entregue
CR Custo Real CR Custo Real
VPR Variação de Prazo VC Variação de Cronograma
VC Variação de Custo CV Variação do Custo
IDP Índice de Desempenho de Prazo IDA Índice de Desempenho de

Agendamento
IDC Índice de Desempenho de Custo IDC Índice de Desempenho de Custo
ENT Estimativa no Término EAT Estimativa ao Término
EPT Estimativa para Terminar - -
IDPT Índice de Desempenho para IDAC Índice de Desempenho a Concluir

Término
Fonte: Elaborado pelo autor, 2018.
CAPÍTULO 4 121
Os cálculos são feitos automaticamente em uma série de softwares de gerenciamento de

projetos. Contudo, a nomenclatura e as abreviações dos termos são um pouco diferentes
em alguns casos.
Análise do desempenho
De posse de todos os indicadores calculados pelas técnicas de Gerenciamento de Valor

Agregado, o Gerente de Projeto apresenta como resultado do processo de controle de cus-
tos, junto ao valor das variáveis, a análise do desempenho de custos do projeto.
Figura 11: Gerenciamento do Valor Agregado no MS Project®.
Uma das análises que pode ser feita é a análise das variações. Nela, analisam-se as causas
dos desvios entre o realizado e o orçado para saber se o problema se encontra nos custos
unitários dos recursos, na quantidade de recursos diferente do que foi estimado ou em
ambos. Nesta análise, considera-se a margem de erro que foi especificada na estimativa
de custos, sempre tendo em vista que a margem de aceitação deve diminuir com o tempo,
quando se adquire mais informações sobre o projeto.
Também deve ser realizada a análise de tendências, que consiste em examinar se o pro-
jeto está melhorando ou piorando, se as estimativas devem ser revistas ou que ações devem
ser realizadas de acordo com o que tende a acontecer com o projeto no futuro.
Resumo
Neste capítulo você conheceu os tipos de custos de projetos e outros importantes conceitos
relacionados a custos, além de ter uma visão dos processos componentes desta disciplina,
com entradas, ferramentas, técnicas e saídas.
No processo de estimar os custos, verificamos os insumos que são fonte das estimativas e
de que processos eles surgem. Também vimos técnicas para estimar os custos das ativida-
des. Para determinar o orçamento, entendemos como agregar os custos das atividades para
formar o orçamento do projeto. Compreendemos, também, o conceito de Curva S, como
ocorre sua construção e sua importância para o fluxo de caixa do projeto. Já em controlar os
custos, abordamos a aplicação do sistema de controle de mudanças para alterar a linha de
base de orçamento e demonstramos a técnica de Gerenciamento de Valor Agregado (GVA).
Esperamos ter atingido o objetivo deste capítulo, oferecendo as ferramentas para que você
seja capaz de realizar os processos de Gerenciamento do Custo do Projeto, maximizando o
resultado do produto do projeto para sua empresa.
CAPÍTULO 4 123
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT. Associação Brasileira de Normas Técnicas. ISO 21500:2012. 2012.
AGUIAR, Gilberto de; ALVES, Custodio da Cunha; HENNING, Elisa. Gerenciamento de pro-
jetos: simulação de Monte Carlo via a ferramenta simular. In: XXX ENCONTRO NACIONAL
DE ENGENHARIA DE PRODUÇÃO, 2010, São Paulo. Anais eletrônicos... São Paulo: Enegep,
12-15 out. 2010. Disponível em: <http://www.abepro.org.br/biblioteca/enegep2010_tn_
sto_120_783_17492.pdf>. Acesso em: 25 set. 2018.
ANDERSON, David J. Kanban: successful evolutionary change for your technology business.
Seattle: Blue Hole Press, 2013.
ATKINSON, Anthony A. et al. Contabilidade gerencial: tomada de decisão e execução da

estratégia. 4 ed. São Paulo: Editora Atlas, 2015.
BARCAUI, André B. et. al. Gerenciamento do tempo em projetos. 4. ed. Rio de Janeiro: FGV
Editora, 2013.
BEEDLE, Mike et al. Manifesto para o desenvolvimento ágil de software. Disponível em:
<http://www.manifestoagil.com.br/>. Acesso em: 25 set. 2018.
CARTER, Keith A.; BEAULIEU, Lionel J. Conducting a community needs assessment: primary
data collection techniques. Florida: Florida Cooperative Extension Service, 1992. Disponível
em: <https://commdev.org/userfiles/files/1880_file_HE06000.pdf>. Acesso em: 25 set. 2018.
COHN, Mike. Agile estimating and planning. Nova Jersey: Prentice Hall PTR, 2005.
COLLABNet. The 12th Annual State of Agile Report. 2018. Disponível em: <https://explore.
versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report>. Acesso em:
01 jun. 2018.
COSTA, Christina M. B. et. al. Gerenciamento de custos em projetos. 5 ed. Rio de Janeiro:
FGV Editora, 2014.
DICIO. Dicionário Online de Português. Estimativa. 2018. Disponível em: <https://www.

dicio.com.br/estimativa/>. Acesso em: 19 set. 2018.
ELDER, A. As cinco doenças do gerenciamento de projetos: por que seus projetos atrasam
e o que fazer sobre isso. No Limits Leadership, Inc., 2010. Disponível em: <https://www.eli-
rodrigues.com/wp-content/uploads/2010/11/CincoDoencasDoGP.pdf>. Acesso em: 25 set.
2018.
FAYAD, Mohamed E.; SCHMIDT, Douglas C.; JOHNSON, Ralph E. Implementing application
frameworks: object-oriented frameworks at work. Nova Jersey: Willey, 1999.
FOGGETTI, Cristiano. Gestão ágil de projetos. São Paulo: Pearson Education do Brasil, 2014.
GITHENS, Gregory D. Rolling wave project planning. Long Beach: 29th Annual Project Man-
agement Institute, 1998.
GOLDRATT, Eliyahu M. Critical chain. Great Barrington: North River Press, 1997.
______. The goal. Great Barrington: North River Press, 1992.
HASTINGS, W. K. Monte Carlo sampling methods using Markov chains and their applications.
Biometrika, Oxford, vol. 57, n. 1, 1970.
JÚNIOR, Valdo Noronha Péres. Gerenciamento de projetos através da corrente crítica.

Disponível em: <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/471>.
Acesso em: 13 mai. 2018
KENDALL, Gerald I.; ROLLINS, Steven C. Advanced project portfolio management and the
PMO. Boca Raton: J. Ross, 2003.
MÁLYUSZ, Levante; VARGA, Anita. (2016) “An Estimation of the Learning Curve Effect on Proj-
ect Scheduling with Working Days Calculation”, Periodica Polytechnica Architecture, 47(2),
pp. 104-109.
MASSARI, Vitor L. Gerenciamento ágil de projetos. 2 ed. Rio de Janeiro: Brasport, 2018.
MAX’S. Wideman comparative glossary of project management terms. 2017. Disponível

em: <http://www.maxwideman.com/pmglossary/PMG_A01.htm>. Acesso em: 25 set. 2018.
MCCLAVE, James T.; BENSON, P. George; SINCICH, Terry. Estatística para administração e
economia. 10 ed. São Paulo: Pearson/Prentice Hall, 2009.
METROPOLIS, Nicolas. The beginning of the Monte Carlo method. Los Alamos Science, n.
15, 1987. Disponível em: <https://library.lanl.gov/cgi-bin/getfile?00326866.pdf>. Acesso em:
25 set. 2018.
MINETTO, Elton L. Frameworks para desenvolvimento em PHP. Rio de Janeiro: Novatec,

2007.
MULCAHY, Rita et al. PMP® exam prep. 9 ed. Minnetonka: Rmc Pubns Inc., 2018.
PARKINSON, C. Northcote. Parkinson’s law. Saint Louis: The Economist, 1955.

CAPÍTULO 4 125
PMI. Project Management Institute. Um guia do conhecimento em gerenciamento de

projetos (Guia PMBOK®). 6 ed. Atlanta: PMI Publications, 2017.
RAZ, Tzvi; BARNES, Robert; DVIR, Dov. A critical look at critical chain project management. Proj-
ect Management Journal, 34, 2003. Disponível em: <https://csbweb01.uncw.edu/people/
rosenl/classes/OPS100/A%20Critical%20Look%20at%20Critical%20Chain%20Project%20
Management.pdf>. Acesso em: 25 set. 2018.
RIGBY, Darrell K.; SUTHERLAND, Jeff; TAKEUCHI, Hirotaka. The secret history of agile innova-
tion. Harvard Business Review, abr. 2016. Disponível em: <https://hbr.org/2016/04/the-se-
cret-history-of-agile-innovation>. Acesso em: 01 jun. 2018.
ROVAI, Ricardo Leonardo; SILVA, Marcello Muniz; CAMPANÁRIO, Milton de Abreu. Metodolo-
gias de estimativa de prazos, custos e orçamentos em projetos de T.I. In: I CONTECSI CON-
GRESSO INTERNACIONAL DE GESTÃO DE TECNOLOGIA E SISTEMAS DE INFORMAÇÃO, 2004,
São Paulo. Anais… São Paulo: USP, 2004.
ROYCE, Winston W. Managing the development of large software systems. Los Angeles:
TRW, 1970. Disponível em: <http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.
pdf>. Acesso em: 25 set. 2019.
SAAD NETO, Emílio Georges. Uma avaliação de ferramentas de gerenciamento de múlti-

plos projetos. Recife: Universidade Federal de Pernambuco, 2008.
SILVA, Éverton Maurer da; RODRIGUES, Luis Henrique; LACERDA, Daniel Pacheco. Aplicabili-
dade da corrente crítica da teoria das restrições no gerenciamento de projetos executivos de
engenharia: um estudo de caso em uma refinaria de petróleo. Revista Gestão & Produção,
São Carlos, v. 19, n. 1, p. 1-16, 2012. Disponível em: <http://www.scielo.br/pdf/gp/v19n1/
a01v19n1.pdf>. Acesso em: 25 set. 2018.
STEWART, Rodney D.; WYSKIDA, Richard M.; JOHANNES, James D. Cost estimator’s refer-
ence manual. 2 ed. Nova York: John Wiley & Sons, Inc, 1995.
SUTHERLAND, Jeff. Scrum: a arte de fazer o dobro de trabalho na metade do tempo. 2 ed.
São Paulo: Leya, 2016.
VARGAS, Ricardo. Análise de valor agregado: revolucionando o gerenciamento de prazos e

custos. 6 ed. São Paulo: Ed. Brasport, 2013.
WERNKE, Rodney. Gestão de custos: uma abordagem prática. 2 ed. São Paulo: Editora Atlas,
2004.

Gerenciamento Cronograma Custos Projetos v4 20181105

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

Gerenciamento Cronograma Custos Projetos v4 20181105

Enviado por

Direitos autorais:

Formatos disponíveis

MÓDULO 1 1

Gerenciamento do Cronograma e dos Custos / Fábio Paula.

125 p.; 20x26 cm

1. Gerenciamento de projetos 2. Cronograma em projetos –

CAPÍTULO 1 GERENCIAMENTO DO CRONOGRAMA EM PROJETOS 8

Unidade 2 O planejamento do gerenciamento do cronograma e a definição

Unidade 3 O sequenciamento das atividades 23

CAPÍTULO 2 GERENCIAMENTO DO CRONOGRAMA EM PROJETOS –

Unidade 1 A estimativa da duração das atividades 34

Unidade 2 Os comportamentos prejudiciais ao sucesso do projeto 41

Unidade 3 O desenvolvimento do cronograma 44

CAPÍTULO 3 GERENCIAMENTO DO CRONOGRAMA EM PROJETOS –

Unidade 1 Controlar o cronograma 64

Unidade 2 Método da Corrente Crítica 70

Unidade 3 Método Ágil em Gerenciamento de Projetos 76

CAPÍTULO 4 GERENCIAMENTO DOS CUSTOS EM PROJETOS 90

Unidade 2 Estimar os custos 102

Unidade 3 Determinar o orçamento 107

Unidade 4 Controlar os custos 112

O gerenciamento eficaz de um projeto Logo, se o projeto não for entregue em

Após concluir o estudo da disciplina Gerenciamento do Cronograma e dos Custos em Projetos,

■■ entender os principais conceitos referentes a tempo e a custo em projetos;

■■ planejar e controlar o tempo em um projeto, utilizando as melhores práticas indicadas

■■ desenvolver e controlar um cronograma de maneira eficiente, utilizando as melhores

■■ planejar e controlar os custos de um projeto, utilizando as melhores práticas indicadas

Tenha sempre em mente que você é o principal agente de sua aprendizagem!

Para um estudo eficaz, siga estas dicas:

■■ consulte a bibliografia e o material de apoio caso tenha alguma dúvida;

■■ releia o conteúdo sempre que achar necessário;

■■ leia as indicações de textos complementares, faça os exercícios de feedback automático

Para o sucesso nessa disciplina e o total aproveitamento do conteúdo, é imprescindível que

Ao completar este capítulo de estudo, você estará apto a:

■■ entender os conceitos relativos a tempo em projetos;

Para melhor compreensão das questões que envolvem o gerenciamento do cronograma e

Unidade 2 – O planejamento do gerenciamento do cronograma e a definição das atividades

Unidade 3 – O sequenciamento das atividades

De acordo com o Guia PMBOK®, os processos que compõem a disciplina de gerenciamento

■■ sequenciar as atividades: esse é o momento de identificar a relação de dependência

■■ desenvolver o cronograma: é o momento no qual se analisam conjuntamente as restri-

2. Processos de monitoramento e controle

Acompanhe, na figura a seguir, uma visão geral do gerenciamento do cronograma do projeto

Figura 1 - Visão geral do gerenciamento do cronograma do projeto

Visão geral do gerenciamento

6.1 Planejar o Gerenciamento

1 Entradas 1 Entradas 1 Entradas

1 Entradas 1 Entradas 1 Entradas

Fonte: Guia PMBOK® (2017, pág. 174).

O padrão ISO e o PMBOK

O novo padrão ISO 21500:2012 – Guia em Gerenciamento de Projetos, que é em grande

2. Estimar Duração de Atividades.

Planejamento do gerenciamento do cronograma

Planejar o gerenciamento do cronograma é o primeiro processo do Gerenciamento do Cro-

Figura 2 - Planejar o gerenciamento do cronograma: diagrama do fluxo de dados

• Termo de abertura do projeto

Plano de gerenciamento do projeto:

• Fatores ambientais da empresa

Fonte: Guia PMBOK®, 2017, p. 179.

Esse plano integra o Plano do Gerenciamento do Projeto e, independentemente do seu nível

Plano de gerenciamento do cronograma

Por meio de reuniões da equipe do projeto, de opiniões de especialistas e de técnicas de

■■ duração do trabalho contínuo da equipe para concluir uma meta;

■■ nível aceitável de acurácia das estimativas;

■■ unidades de medida que serão utilizadas para cada recurso do projeto;