MSP13 Edicao Lancamento Revisao Gabriel.003-Site-0800

1
MS PROJECT 2013:
Uma Abordagem Sistemática
Gabriel Cardozo Prado, MCTS, SpP

Marcus
Gabriel Possi, Prado,
Cardozo MCTS, MCTS,
SpP SpP
Marcus Possi, MCTS, SpP
Editora
MS Project 2013
Uma Abordagem Sistemática
1ª Edição
Gabriel Cardozo Prado, MCTS, SpP

Marcus Possi, MCTS, SpP
IV
MS Project 2013: Uma Abordagem Sistemática

Copyright ( C ) 2013 Editora Ecthos.
Todos os direitos para a língua portuguesa reservados pela Editora Ecthos.
De acordo com a lei 9.601 de 19/2/1998, nenhuma parte deste material poderá ser reproduzida, transmitida e gravada, por qualquer
meio eletrônico, mecânico, por fotocópia e outros, sem a prévia autorização, por escrito, da Editora.
Editor: Marcus Possi

Diagramação: Gabriel Cardozo
Revisor: Marcus Possi
Várias Marcas Registradas aparecem no decorrer deste livro. Mais do que simplesmente listar esses nomes e informar quem possui
seus direitos de exploração, ou ainda imprimir os logotipos das mesmas, o editor declara estar utilizando tais nomes apenas para
fins editoriais, em beneficio exclusivo da Marca Registrada, sem intenção de infringir as regras de sua utilização.
Aqueles que registraram esse material na forma eletrônica, por ocasião da compra ficam informados e declaram estar cientes de:
estarem autorizados a imprimir seu conteúdo para fins de uso particular em até e não mais que duas vias; e respeitar os termos da
lei 9.601 de 19/2/1998. O direito da cessão da segunda via somente poderá ser feito mediante a “cessão de cópia exclusiva formal”
com o envio dessas informações por correio eletrônico a editora@ecthos.com.br para fins de registros e direitos com a resposta
específica e afirmativa para essa autorização dados pela editora.
Ficha Catalográfica
da Silva, Gabriel Cardozo Prado e Possi, Marcus
Rio de Janeiro: Editora Ecthos, 2013-08-20

I – Título
ISBN: 978-85-66491-01-2 (e-book)

ISBN: 978-85-66491-02-9 (impresso)
Editora Ecthos.
Rua Levi Miranda, 251, Freguesia JPA
Rio de Janeiro – Brasil – CEP: 22745-250
Tel: (21) 2456-1885
http://www.ecthoscd.com.br
editora@ecthos.com.br
V
Dedicatórias
Dedico esta obra à minha família, pilar que me sustenta, e à

Nathalia, companheira e sócia.
Mi tre amas vin.
Gabriel
Dedico esse trabalho aos meus filhos Luciana e Lucas Possi,

por serem tão legais num mundo não tão legal. Que façam a
diferença.
Marcus
VII
Agradecimentos
Agradeço primeiramente a Deus pelas luzes

que pôs em meu caminho na forma de
pessoas a iluminarem minha vida pessoal e
profissional, ao Eng. Marcus Possi, pelos anos
de trabalho, parceria e muito aprendizado, e à
Editora Ecthos pela confiança e incentivo ao
desbravamento de novos horizontes.
Gabriel
Agradeço a Deus pela oportunidade de

compartilhar, e a todos que me apoiam e que,
eventualmente, até suportam vários
destemperos meus por conta das atividades
que realizo de forma tão intensa e às vezes
conturbadas.
Marcus
IX
Prefácio
Temos em nossas mãos muito mais do que um livro de referência ou um manual para uma ferramenta.
MS Project 2013: Uma Abordagem Sistemática é um convite para que estudantes, planejadores e
gestores de projeto possam deslumbrar o potencial deste software em um contexto prático de sua
aplicação em conjunto com as melhores práticas preconizadas pelo Project Management Institute.
Para os leitores que ainda não conhecem os trabalhos de Marcus Possi e seus parceiros (neste caso o
Gabriel Cardozo Prado), fiquem atentos não só a qualidade técnica dos exemplos e demonstrações de
aplicação da ferramenta, mas também aos vínculos estabelecidos com as boas práticas somados a uma
pitada - muitas vezes apimentada - de observações críticas e desafiadoras para que possamos
ultrapassar os limites do convencional e possamos atingir maturidade em planejamento!
Usuários mais avançados de versões anteriores poderão ter o impulso de “saltar” para as telas do
software que lhes parecem diferentes e poderão perder - neste processo - uma oportunidade para
criar um vínculo consistente entre práticas, metodologias e a ferramenta. Aqui vale o lembrete que
para um livro com “uma abordagem sistemática”, o leitor irá se beneficiar em também realizar uma
“leitura sistemática”, revendo os conceitos dos quais já está familiarizado enquanto descobre novos
contextos e conteúdos.
A leitura ordenada (sem saltos expressivos para questões técnicas da ferramenta que se deseje
conhecer) também terá um valor particularmente especial para aqueles profissionais que já investiram
o seu tempo em edições anteriores do PMBOK® e agora precisem se atualizar em relação aos novos
processos apresentados no PMBOK® 5ª edição, bem como a inclusão de um novo grupo de processos
(Gerenciamento das Partes Interessadas).
Em suma, é um livro didático e completo. O seu uso permitirá aos leitores a aplicação de todas as
funcionalidades do MS Project relacionadas às áreas de conhecimento de gerenciamento de Escopo,
Tempo e Custo; também serão abordados temas importantes relacionados à Integração, Gestão das
Partes Interessadas, Recursos, Qualidade, Comunicação, Riscos e Aquisições.
No caso especial do Gerenciamento de Riscos, os autores trazem uma aplicação interessante de

funções do MS-Project (Atividades Inativas) como mecanismo para apoiar este importante grupo de
processos, atendendo assim a modelagem de planos de contingência e estudos sobre alterações do
escopo. A conceituação aqui apresentada poderá interessar inclusive gestores de projetos que não
estão habitualmente envolvidos com a rotina de cronogramas e a aplicação de ferramentas, auxiliando
assim na ampliação das oportunidades de sucesso em projetos.
Boa leitura!
Peter Mello, PMP, SpS, PMP

Skype: petersmello
XI
Apresentação
Este livro, ainda na fase de pré-lançamento, foi especialmente produzido na

forma impressa para uma apresentação formal no I Fórum Global de
Gerenciamento de Projetos, que aconteceu no Centro de Convenções
Sulamérica, Centro, Rio de janeiro de 19 a 22 de Agosto de 2013, promovido
pelo PMIRio.
Sendo no Brasil o primeiro livro de MSProject 2013 pela editora Ecthos,

produzido e registrado como publicação eletrônica desde Novembro de 2012,
utilizado em mais de três turmas de Capacitação em Ferramentas de apoio a GP
como livro de referência para estudos de profissionais e estudantes, este material
se propõe a apresentar essa ferramenta em uma linguagem diferenciada, com
aplicações e exemplos práticos de todos os seus recursos no modo "stand
alone". Sendo notoriamente a solução de apoio ao gerenciamento de projetos
mais popular do mercado, este livro indubitavelmente ajudará a entender tudo o
que o aplicativo faz e não faz, com condições de contorno às suas limitações, no
apoio permanente ao gerenciamento de projetos.
Adicione o endereço www.ecthoscd.com.br e localize a editora.
Boa Leitura e bom trabaho,
Marcus Possi
XIII
Sumário
1. Capítulo 01: Introdução .............................................................................................. 1
1.1. Introdução Teórica ao planejamento de projetos ................................................................... 1
1.1.1. Globalização e as Estruturas Econômicas ........................................................................ 1
1.1.2. As Organizações e os Impactos das suas mudanças ........................................................ 1
1.1.3. O Projeto .......................................................................................................................... 2
1.1.4. O Estudo do Gerenciamento dos Projetos ....................................................................... 3
1.1.5. Fases dos Projetos e o seu Ciclo de Vida .......................................................................... 5
1.1.6. Os Interessados do Projeto .............................................................................................. 5
1.1.7. Os Processos e o Projeto .................................................................................................. 6
1.2. Introdução à Ferramenta MS Project 2013 ............................................................................ 11
1.2.1. O Ambiente de Trabalho ................................................................................................ 12
1.2.2. Criação de um Novo Projeto .......................................................................................... 18
1.2.3. Configurações Iniciais da Ferramenta ............................................................................ 20
1.2.4. Documentação do Projeto ............................................................................................. 29
1.3. Gerenciamento de Integração do Projeto ............................................................................. 31
1.3.1. Fundamentos da INTEGRAÇÃO ...................................................................................... 31
1.3.2. Gerenciamento de Integração do Projeto...................................................................... 32
2. Capítulo 02: Gerenciamento do Escopo ..................................................................... 37

2.1. Conceitos de Gerenciamento do Escopo ............................................................................... 37
2.1.1. Processo de Planejar o Escopo do Projeto ..................................................................... 39
2.1.2. Processo de Coletar os Requisitos do Projeto ................................................................ 40
2.1.3. Processo de Definir o Escopo ......................................................................................... 42
2.1.4. Criação da Estrutura Analítica do Projeto ...................................................................... 45
2.1.5. Os Processos de Controle do Gerenciamento do Escopo .............................................. 47
2.2. Uso da Ferramenta - Escopo .................................................................................................. 48
2.2.1. Criação da EAP................................................................................................................ 49
2.2.2. Documentação da EAP ................................................................................................... 64
XIV
3. Capítulo 03: Gerenciamento do Tempo ..................................................................... 77

3.1. Conceitos de Gerenciamento do Tempo ............................................................................... 77
3.1.1. Planejar o Gerenciamento dos Prazos ........................................................................... 77
3.1.2. Definir as Atividades ...................................................................................................... 79
3.1.3. Sequenciar as Atividades ............................................................................................... 82
3.1.4. Estimar a Duração das Atividades .................................................................................. 88
3.1.5. Desenvolvimento Preliminar do Cronograma................................................................ 90
3.2. Uso da Ferramenta - Tempo .................................................................................................. 91
3.2.1. Definição das Atividades e Marcos ................................................................................ 92
3.2.2. Atributos das Atividades e Marcos .............................................................................. 105
3.2.3. Definição e documentação de atividades especiais .................................................... 116
3.2.4. Análise do cronograma preliminar do projeto............................................................. 125
4. Capítulo 04: Gerenciamento dos Recursos .............................................................. 153

4.1. Conceitos de Gerenciamento dos Recursos ........................................................................ 153
4.1.1. Estimar os Recursos da Atividade ................................................................................ 153
4.1.2. Alocar os Recursos na Atividade .................................................................................. 157
4.2. Uso da Ferramenta - Recursos ............................................................................................. 158
4.2.1. Definição dos Recursos ................................................................................................ 159
4.2.2. Documentação Básica .................................................................................................. 168
4.2.3. Alocação dos Recursos ................................................................................................. 177
4.2.4. Documentação Pós alocação ....................................................................................... 194
4.2.5. Análise do Cronograma pós alocação dos recursos ..................................................... 199
5. Capítulo 05: Gerenciamento dos Custos .................................................................. 223

5.1. Conceitos de Gerenciamento dos Custos ............................................................................ 223
5.1.1. Planejar os Custos do Projeto ...................................................................................... 223
5.1.2. Estimar os Custos ......................................................................................................... 224
5.1.3. Determinar o Orçamento ............................................................................................. 228
5.1.4. Controlar os Custos ...................................................................................................... 230
5.2. Uso da Ferramenta - Custo .................................................................................................. 232
XV
5.2.1. Estimativa dos Custos do Projeto ................................................................................. 233

5.2.2. Inclusão da Dotação Orçamentária .............................................................................. 239
5.2.3. Consolidação do Planejamento dos Custos ................................................................. 242
6. Capítulo 06: Gerenciamento dos Riscos................................................................... 249

6.1. Conceitos de Gerenciamento dos Riscos ............................................................................. 249
6.1.1. Planejar o Gerenciamento de Riscos............................................................................ 250
6.1.2. Identificar de Riscos ..................................................................................................... 250
6.1.3. Realizar a Análise Qualitativa de Riscos ....................................................................... 250
6.1.4. Realizar a Análise Quantitativa de Riscos..................................................................... 251
6.1.5. Planejar a Resposta a Riscos ........................................................................................ 251
6.1.6. Controle de Riscos ........................................................................................................ 252
6.2. Uso da Ferramenta – Riscos ................................................................................................. 253
6.2.1. Inactive Tasks (Atividades inativas) .............................................................................. 254
6.2.2. Plano de Ação Concomitante ao Projeto ..................................................................... 257
6.2.3. Plano de Ação Contingencial ao Projeto. ..................................................................... 259
6.2.4. Gerenciamento das Alterações do Escopo................................................................... 261
7. Capítulo 07: Desenvolvimento do Cronograma ....................................................... 263

7.1. Desenvolvimento Real do Cronograma ............................................................................... 263
7.1.1. Técnicas e Ferramentas................................................................................................ 263
7.1.2. O que se espera nas saídas .......................................................................................... 267
7.1.3. A importância de rever o Cronograma ......................................................................... 272
7.2. Uso da Ferramenta – Desenvolvimento do Cronograma..................................................... 273
7.2.1. Revisão do Cronograma ............................................................................................... 273
7.2.2. Critérios de Qualidade – Escopo, Tempo, Recursos e Custo ........................................ 275
7.2.3. Modelagens .................................................................................................................. 278
8. Capítulo 08: Monitoramento e Controle ................................................................. 293

8.1. Conceitos de Monitoramento e Controle ............................................................................ 293
8.1.1. Monitoramento e Controle .......................................................................................... 293
XVI
8.1.2. Apresentação Gráfica. .................................................................................................. 295

8.2. Uso da Ferramenta – Monitoramento e Controle ............................................................... 298
8.2.1. Etapa de Execução – Preparação da Ferramenta ........................................................ 300
8.2.2. Emissão de Planos de Trabalho .................................................................................... 303
8.2.3. Métodos de Monitoramento e Controle. .................................................................... 307
8.2.4. Indicadores de Desempenho ....................................................................................... 319
8.2.5. Critérios de Qualidade ................................................................................................. 323
9. Capítulo 09: Gerenciamento da Comunicação ......................................................... 325

9.1. Conceitos de Gerenciamento da Comunicação ................................................................... 325
9.2. Uso da Ferramenta – Monitoramento e Controle ............................................................... 327
9.2.1. Modos – Relatório (Print Preview) ............................................................................... 328
9.2.2. Comunicação do andamento do projeto ..................................................................... 332
9.2.3. Relatórios Visuais (Visual Reports)............................................................................... 333
9.2.4. Comparação de Projetos .............................................................................................. 335
9.2.5. Novos Relatórios do MS Project 2013.......................................................................... 338
10. Capítulo 10: Gerenciamento de Múltiplos Projetos ................................................. 351

10.1. Conceitos de Gerenciamento de Múltiplos Projetos ....................................................... 351
10.2. Uso da Ferramenta – Múltiplos Projetos ......................................................................... 353
10.2.1. Gerenciamento de Portfólios ....................................................................................... 353
10.2.2. Subprojetos .................................................................................................................. 359
10.2.3. Análise das medições do Projeto por arquivo Master ................................................. 364
11. Anexos ................................................................................................................... 367

A. Índice de Modos ...................................................................................................................... 367
B. Desenhos e Imagens no Diagrama de Gantt ........................................................................... 370
C. Organizador (Organizer) .......................................................................................................... 372
D. Filtros ....................................................................................................................................... 374
E. Criação de novo projeto a partir de arquivo Excel .................................................................. 382
XVII
F. Processos ................................................................................................................................. 386

i. Criar Tabela .......................................................................................................................... 386
ii. Criar Novo Filtro ................................................................................................................... 387
iii. Criar Novo Grupo ............................................................................................................. 388
iv. Criar Novo Modo .................................................................................................................. 389
MSProject 2013 – Uma Abordagem Sistemática 1
1. Capítulo 01: Introdução
1.1. Introdução Teórica ao planejamento de projetos
1.1.1. Globalização e as Estruturas Econômicas

“Globalização é um conceito inovador em conteúdo, porque sintetiza uma realidade dinâmica, de múltiplas dimensões e graves
implicações políticas, econômicas, sociais e culturais. É uma realidade à qual não se poderia fugir a não ser por uma hipotética
e hoje inviável autarcização da sociedade. Mas é também uma realidade que pode ser explorada com as cautelas e a
determinação necessárias para dela extrair benefícios, com pragmatismo e com sentido de realismo.”
Luiz Felipe Lampreia 1996- Ministro de Estado das Relações Exteriores no Brasil
O processo de globalização pelo qual passou a economia de todos os países do mundo

provocou uma significativa mudança na vida das organizações, associado aos avanços
tecnológicos. Em particular, os meios de comunicação e a Internet possibilitaram que
indivíduos e empresas gerassem mais riquezas através da aplicação do conhecimento
disponível, da inteligência individual e da vontade própria. A globalização também fez surgir
como consequência nova competências para assegurar o sucesso competitivo das
empresas. A crise gerada na época, caracterizada como proposta inovadora de trabaho e
ameaça aos empregos tradicionais, pode até ser comparada com a crise econômica recente
que à primeira vista gerou desconfortos. As mudanças tornaram-se intensas e ocorreram
sob rápida expectativa de resposta. Falar em mudanças é justificar a existência dos
“projetos”, termo que vamos utilizar muitas vezes daqui para frente. Esses projetos por vezes
podem significar a sobrevivência das organizações.
Mudanças são melhorias ou novas ideias.

Novas ideias – desenvolver algo que não existe, necessário ao processo ou produto já existente e criador de novo
processo ou produto; algo suplementar ao processo ou produto, que venha a demandar uma iniciativa multidisciplinar,
por vezes, em ambientes diversos que tragam para si a necessidade de desenvolvimento daquilo que ainda não existe,
envolvendo todos os atores possíveis no nicho do processo ou produto envolvido.
Melhorias – acrescentar, adaptar, ou mudar algo que já existe, necessário ao negócio ou à qualidade do produto ou
processo já existente, complementar a esses elementos; algo que venha a demandar uma iniciativa multidisciplinar,
por vezes, em ambientes diversos que tragam para si a necessidade de desenvolvimento daquilo que ainda não existe,
envolvendo todos os atores possíveis no nicho do processo ou produto envolvido.
1.1.2. As Organizações e os Impactos das suas mudanças

As organizações, como o próprio nome já diz, são um conjunto de recursos, regras e objetivos que são criados para promover
meios de dar à sociedade a ajuda que, sozinhos, os seus componentes, por mais bem intencionados que fossem, não seriam
capazes de alcançar. Essas organizações foram constituídas na sua origem para essa manutenção de necessidades, e, agora,
por que não dizer, para a manutenção das novas necessidades que nascem a cada dia, de forma intensa e inovadora. Poderíamos
dizer que o impacto nas organizações não é apenas aquele ocasionado pelo movimento do mercado, forçando a mudanças em
processos e produtos, mas também às consequências causadas internamente às suas equipes e processos de trabalho. A
mudança de um procedimento de trabalho, quando é necessário definir um grupo de projetos para atingir um resultado ou meta,
passa muitas vezes das estruturas tradicionais, funcionais de comando hierarquizado, levando à necessidade de equipes de
trabalho autodirigidas e times de trabalho voltados para fins específicos. Isso traz sentimentos estranhos e pessoais aos
organismos institucionais, como ciúmes, revoltas, medo e, consequentemente, atraso nos resultados esperados e perda de
recursos. Há mais de 10 anos que essa habilidade de administrar mudanças ou gerenciar projetos chegou ao Brasil. Assim,
contar com um profissional administrador como apoio chega quase a ser um luxo para projetos médios e pequenos. Por diversas
2 Gabriel Cardozo e Marcus Possi
vezes é lido na mídia impressa e nas conversas a expressão “gerente de projeto”. O profissional deve administrar o prazo, o
custo, os recursos humanos ou não, a qualidade e a extensão dos trabalhos a serem desenvolvidos de forma a que eles deem o
retorno exato e na medida daquele a que foram previstos. Sem perda de tempo e recursos e atualmente sem dano ambiental ou
social.
1.1.3. O Projeto
O gerenciamento de projetos é a realização de um projeto e, para ser desenvolvido com sucesso, são necessárias algumas
habilidades básicas. Habilidades Técnicas, Habilidades Interpessoais, Habilidades Administrativas, além do Entendimento do
Ambiente do Projeto. Essas habilidades reunidas pelo agente da mudança ou administrador devem buscar e trazer o equilíbrio.
O gerenciamento de projetos tem suas raízes nas experiências de gerenciar o desenvolvimento de sistemas complexos durante
a Segunda Guerra Mundial e, no início dos anos cinquenta, evoluiu para uma abordagem mais sistemática, passando pelo
Departamento de Defesa Americano e NASA e tornando-se também essencial à indústria de computadores. Nos anos setenta,
o gerenciamento de projetos foi reconhecido e estabelecido como abordagem de gerenciamento para diversas organizações
envolvidas no governo, na educação e privadas.
IPMA – International Project Management Association (Associação Internacional de Gerenciamento de

Projetos)
Associação sem fins lucrativos sediada na Europa, nasceu em 1965 e está presente em mais de 70 países do
mundo, reunindo cerca de 40.000 profissionais em gerenciamento de projetos. Tem como objetivo o incentivo à
profissionalização e ao desenvolvimento das práticas de gerenciamento de projetos, representada no Brasil pela
Associação Brasileira de Gerenciamento de Projetos – ABGP. O IPMA criou um documento chamado de Base de
Competências – IBC, na versão III, uma espécie de manual com as referências para o gerenciamento de projeto.
Através desse corpo de conhecimento podem-se tirar informações úteis para os projetos. Esse documento é livre
à cópia e pode ser adquirido no site do instituto: www.ipma.ch.
PMI – Project Management Institute (Instituto de Gerenciamento de Projetos)

Organização sem fins lucrativos sediada nos EUA, nasceu em 1969 e está presente em diversos países do mundo,
reunindo mais de 350.000 profissionais em gerenciamento de projetos. Tem como objetivo o incentivo à
profissionalização e ao desenvolvimento das práticas de gerenciamento de projetos. Esse trabalho está alinhado
à última versão do guia produzido por esse instituto, o PMBOK – Guide to the Project Management Body of
Knowledge. O PMI criou e mantém esse documento, traduzido aqui como Corpo de Conhecimento, como uma
espécie de guia com o registro parcial das práticas mais utilizadas e conhecidas para o gerenciamento de projeto.
Através desse corpo de conhecimento, podem-se tirar informações úteis para a administração dos projetos. Esse
documento não é livre à cópia e pode ser adquirido no site do instituto: www.pmi.org.
Devemos lembrar que, conforme comentado, os trabalhos executados

pelas empresas e organizações têm o objetivo de atender às
necessidades da sociedade na sua constante mudança. Esses trabalhos
são resultados de serviços repetitivos e continuados, e de serviços únicos
e temporários. Os serviços repetitivos podem ser chamados de
processos e os serviços únicos e diferentes entre si aqui serão chamados
de projetos. Independente da sua denominação esses trabalhos
possuem características comuns e bem evidentes. Eles são executados por funcionários, possuem recursos limitados, devem
ser planejados, executados, acompanhados e controlados. Os projetos, objeto deste tema, são diferentes dos processos, porque
pelas suas características possuem tempos limitados e únicos nos seus resultados. Devemos destacar que a singularidade e
existência limitada dos projetos é o que mais chama atenção na sua definição. Diz-se temporário, porque seu início e fim são
bem definidos e conhecidos, e únicos porque, embora possam produzir serviços ou produtos iguais, as condições de produção e
entregas com certeza obedecem a regras e condições diferenciadas, quer por regionalidade, temporariedade ou costumes
diferentes. Seus resultados finais são distintos e únicos. Como dito anteriormente, os projetos utilizam recursos humanos ou
profissionais e recursos materiais e financeiros limitados. O tempo de sua existência pode ser de horas, dias ou de anos. Mas o
mais importante é que eles fazem parte da estratégia de uma empresa em reação às mudanças que ocorrem a sua volta. Em
um processo, isto é, no trabalho continuado de produção, o ciclo início-fim reinicia continuamente sem fim. O resultado é repetido
sucessivamente para atender a uma demanda de mercado REPETINDO o produto desse processo. Outro aspecto importante a
ser observado em projetos se refere aos recursos. Enquanto numa fábrica – processo – as equipes são mantidas por tempo
INDEFINIDO, trabalhando, otimizando os processos internos, melhorando a qualidade aplicada ao produto final, nos projetos as
equipes são dispensadas ao atingirem seus objetivos. Essas equipes podem ser realocadas para outros projetos se possuírem
as características necessárias, ou simplesmente mudam de organização em busca de novos espaços. Os recursos de materiais
e equipamentos mudam de projeto para projeto, inviabilizando o conceito de “estoque”, dando a cada projeto um escopo de
compra de materiais e equipamentos diferente em especificações e condições. O caráter de único está associado à demanda
efetuada por um dos elementos de geração de mudanças comentado. A uma ação de mudança está associada normalmente
uma reação chamada projeto ou conjunto de projetos, que DIFERENTES entre si, atendem a essa ação.
1.1.4. O Estudo do Gerenciamento dos Projetos

O gerenciamento é a administração dos processos que são necessários para conduzir equipes, recursos e a expectativa dos
diversos envolvidos para atingir uma meta definida pela necessidade de mudança. O PMI – Project Management Institute –
instituição internacionalmente conhecida pela sua ação de apoio e fundamentação da área de controle e organização de
empreendimentos classificados como projetos, organizou e editou o PMBOK© 2012 (já citado), estruturando-o em 13 capítulos,
como descrito a seguir.
 O Capítulo 1 - A Introdução define os termos chaves e apresenta uma

visão geral do resto do documento.
 O Capítulo 2 - O Ciclo de Vida e Organização do Projeto descreve o
ambiente no qual o projeto opera. A equipe de Gerenciamento do
projeto deve compreender este contexto amplo – o Gerenciamento das
atividades diárias do projeto é necessário, mas não suficiente para
garantir o sucesso.
 O Capítulo 3 - Processo de gerenciamento de projetos de um projeto
descreve os cinco grupos de processos de gerenciamento de projetos
necessários para qualquer projeto e os processos de gerenciamento de
projetos que os compõem. Esse capítulo também descreve a natureza
multidimensional do gerenciamento de projetos.
 O Capítulo 4 - Gerenciamento da Integração do Projeto descreve os processos necessários para assegurar que os
diversos elementos do projeto sejam adequadamente coordenados. Ele é composto pelo desenvolvimento do plano do
projeto, execução do plano do projeto e controle geral de Mudanças.
 O Capítulo 5 - Gerenciamento do Escopo do Projeto descreve os processos necessários para assegurar que o projeto
contemple todo o trabalho requerido, e nada mais que o trabalho requerido, para completar o projeto com sucesso.
 O Capítulo 6 - Gerenciamento do Tempo do Projeto descreve os processos necessários para assegurar que o projeto
termine dentro do prazo previsto.
 O Capítulo 7 - Gerenciamento do Custo do Projeto descreve os processos necessários para assegurar que o projeto
seja completado dentro do orçamento previsto.
 O Capítulo 8 - Gerenciamento da Qualidade do Projeto descreve os processos necessários para assegurar que as
necessidades que originaram o desenvolvimento do projeto serão satisfeitas.
 O Capítulo 9 - Gerenciamento dos Recursos Humanos do Projeto descreve os processos necessários para proporcionar
a melhor utilização das pessoas envolvidas no projeto.
 O Capítulo 10 - Gerenciamento das Comunicações do Projeto descreve os processos necessários para assegurar que
a geração, a captura, a distribuição, o armazenamento e a pronta apresentação das informações do projeto sejam feitas
de forma adequada e no tempo certo.
 O Capítulo 11 - Gerenciamento dos Riscos do Projeto descreve os processos que dizem respeito à identificação, análise
e resposta a riscos do projeto.
 O Capítulo 12 - Gerenciamento das Aquisições do Projeto descreve os processos necessários para a aquisição de
mercadorias e serviços fora da organização que desenvolve o projeto.
 O Capítulo 13 - Gerenciamento dos Envolvidos do Projeto descreve os processos necessários para a identificação e
administração dos envolvidos direta ou indiretamente no projeto.
A ferramenta MSProject 2013 está em um nível mais maduro agora e, desde sua versão 2010, aponta para o apoio à gestão de
7 dessas áreas de conhecimento: Escopo, Tempo, Custos – de modo mais completo, e Recursos, Riscos, Aquisições e
Comunicação de modo mais tímido. A riqueza de relatórios e a integração à família Office na sua versão 365 mostra que o
processo de comunicação é alavancado por recursos visuais e integrado que dão à apresentação dos resultados obtidos nessa
ferramenta um ar extremamente caprichoso.
1.1.5. Fases dos Projetos e o seu Ciclo de Vida

Todo projeto é singular, apresentando suas próprias características, consequentemente, há sempre um grau de incerteza
associado a ele. As empresas possuem atividades operacionais, normais e recorrentes e projetos específicos. Em geral, essas
empresas segmentam seus projetos em fases, deste modo é possível controlá-los e gerenciá-los de forma mais eficiente,
procurando adaptá-los mais facilmente às atividades operacionais, normais e recorrentes. Essas fases quase que sempre
constituem o Ciclo de Vida do Projeto. Estas análises, ao
final de cada fase, podem ser denominadas saídas de fase
(phase exits), passagens de estágio (stage gates) ou pontos
de conclusão (kill points). Assim sendo, podemos dizer que
os pontos de conclusão (kill points) são fundamentais para o
gerenciamento do projeto, tornando-se uma ferramenta de
análise de cada uma das fases do ciclo de vida do projeto.
O controle gerencial de cada fase baseia-se no conjunto de
subprodutos característicos e específicos de cada fase. A maioria dos subprodutos de uma fase está intimamente relacionada ao
principal subproduto da mesma. Assim sendo, as fases do projeto são geralmente denominadas conforme o subproduto principal
gerado. O número de fases é variável. Em sua maioria, os projetos têm quatro ou cinco fases, mas alguns chegam a ter nove ou
mais. Ainda que numa mesma área de atuação, o ciclo de vida dos projetos é muito variável. Além disso, os subprojetos de um
projeto também têm seu próprio ciclo de vida com suas fases
particulares. Por exemplo, um projeto de um lançamento de um
novo produto no mercado pode estar na fase de “design”, que
pode ser considerada um subprojeto que tem suas respectivas
fases: conceituação, requisitos, desenho, implementação de
protótipo e aprovação. Em resumo, a definição de fases está
intimamente ligada aos responsáveis pelo projeto, não havendo
regras ou padrões estabelecidos para tal. As características em
comum dos ciclos de vida de projeto em geral são: Custos e
Recursos. No início do projeto há poucos integrantes na
equipe do projeto (recursos) e os custos são baixos. Durante o
desenvolvimento do projeto ocorre um significativo aumento de
custos e recursos envolvidos, que são drasticamente reduzidos conforme o projeto vai sendo concluído.
1.1.6. Os Interessados do Projeto

As partes envolvidas – Interessados (stakeholders) - são indivíduos e organizações diretamente envolvidos no projeto, ou aqueles
cujos interesses podem ser afetados, de forma positiva ou negativa, no decorrer do projeto ou mesmo após sua conclusão;
podem, também, exercer influências no projeto e seus resultados. É imprescindível que seja feito um trabalho de identificação
das partes envolvidas pelo Gerente de Projeto e sua equipe. Isso é tão importante que acaba por merecer um capítulo específico
e uma tratativa de área de conhecimento na última versão do guia PMBOK. É por conta da melhor gestão desses que observamos
uma maior probabilidade de sucesso aos projetos. O Gerente de Projeto é responsável por todas as atividades de Gestão do
projeto, devendo ser alocado ao projeto o mais cedo possível com autoridade e autonomia necessária. O Cliente pode ou não
ser o solicitante do projeto, mas fará uso do produto final gerado pelo mesmo. A organização Executora é aquela cujos
funcionários estão diretamente envolvidos na implantação e execução do projeto. Em alguns projetos pode haver mais de uma
organização executora. Os membros da equipe do projeto são aqueles que efetivamente realizam o trabalho propriamente dito.
O Patrocinador é aquele que defende a ideia da execução do projeto, é ele o responsável por levantar e aprovar recursos
financeiros para o projeto. O patrocinador pode estar dentro ou fora da organização executora. Os Interessados (Stakeholders)
podem ser classificados de diferentes formas: Internos e Externos; Proprietários e Acionistas; Fornecedores e Empreiteiros;
Membros da Equipe do Projeto e seus familiares; Agências do Governo (ANATEL, ANEEL, IBAMA, FEEMA, IPHAN, etc.);
Agências de Publicidade; Cidadãos; Intermediadores Permanentes ou Temporários; e até a Sociedade. As organizações também
são partes interessadas, assim, um projeto é ainda influenciado pela organização ou organizações que o estabelecem. A teoria
dos sistemas organizacionais descreve como uma empresa pode ser organizada para executar seus trabalhos. O PMBOK do
PMI cita três tipos de estruturas organizacionais: por Projetos, Funcional e Matricial, sendo essa última subdividida. Cada tipo é
descrito em termos do nível de autoridade do gerente de projeto. Pode-se dizer que, em geral, não encontramos organizações
puramente funcionais ou puramente por projetos ou, ainda, puramente matriciais. Na maioria das organizações modernas existem
todos estes tipos de estrutura, em diferentes níveis, como mostrado na figura a seguir.
1.1.7. Os Processos e o Projeto
Os projetos são compostos por processos. Um processo é “uma série

de ações que geram um resultado”. Os processos dos projetos são
realizados por pessoas, e existe uma interação e uma sobreposição
entre os processos do Gerenciamento de projetos e os processos
orientados a produto, durante todo o projeto. Esse diagrama será
intencionalmente repetido mais adiante, na seção Gerenciamento de
Integração do Projeto, e ele representa um fluxo de entrada e saída
com um ciclo de planejamento e execução que se exaure até o fim
do trabalho necessário a dar cabo das entregas do projeto. A isso
chamamos de ciclo de vida do gerenciamento. Os processos de
Gerenciamento de projetos podem ser organizados em cinco grupos,
cada um deles contendo um ou mais processos:
Processo de Iniciação – É a etapa inicial do projeto, quando

uma determinada necessidade é identificada e transformada em
um problema estruturado a ser resolvido por ele. Nessa fase, a
missão e o objetivo do projeto são definidos, bem como as
melhores estratégias são identificadas e selecionadas.
Processo de Planejamento – É a etapa responsável por
detalhar tudo aquilo que será realizado pelo projeto, incluindo
cronogramas, interdependências entre atividades, alocação de
recursos envolvidos, análise de custos, etc., para que, no final
dessa fase, ele esteja suficientemente detalhado para ser
executado sem dificuldades e imprevistos. Nessa fase, os planos
auxiliares de comunicação, qualidade, riscos, suprimentos e
recursos humanos também são desenvolvidos.
Processo de Execução – É a etapa que materializa tudo aquilo
que foi planejado anteriormente. Qualquer erro cometido nas
fases anteriores fica evidente durante esse processo. Grande
parte do orçamento e do esforço do projeto é consumida nessa
fase.
Processo de Controle – São as atividades que acontecem
paralelamente a todas as fases do projeto, com mais ênfase no
planejamento operacional e na execução do projeto. Tem como
objetivo monitorar e controlar aquilo que está sendo realizado
pelo projeto, de modo a acompanhar e, se necessário, propor ações corretivas e preventivas no menor espaço de tempo
possível quando existirem anormalidades. O objetivo do controle é comparar o desempenho e a produção realizada do
projeto com a prevista pelo planejamento. O objetivo do controle é
comparar o status atual do projeto com o status previsto pelo
planejamento, tomando ações corretivas em caso de desvio.
Processo de Encerramento – É a etapa em que a execução dos
trabalhos é avaliada através de uma auditoria externa ou externa
(terceiros), os livros e documentos do projeto são encerrados e
todas as falhas ocorridas durante o projeto são discutidas e
analisadas para que erros similares não ocorram em novos projetos
(aprendizado).
Os grupos de processos se ligam pelos resultados que produzem – o resultado ou saída de um grupo torna-se entrada para outro.
Entre grupos de processos centrais, as ligações são interativas - o planejamento alimenta a execução, no início, com um plano
do projeto documentado, fornecendo, a seguir, atualizações ao plano, na medida em que o projeto progride. Pode-se até dizer
que o planejamento seria dividido entre parte I e parte II, sendo a parte I o planejamento original e a parte II a revisão periódica
deste. Além disso, os grupos de processos do Gerenciamento de projetos não são separados ou descontínuos. A repetição dos
processos de iniciação, no início de cada fase, auxilia a manter o projeto focado nas necessidades de negócio que justificaram a
sua criação.
Os processos de Gerenciamento de projetos, que são comuns à maioria dos projetos na maioria das áreas de aplicação, estão
listados aqui e descritos em detalhe em todas as PMBOK© 2012 PMI, no capítulo de 5 a 13. As interações entre os processos
aqui ilustradas são também típicas na maioria dos projetos, na maioria das áreas de aplicação.
Os processos apoiados pela ferramenta MSProject 2013 estão destacados aqui.

Processos de Iniciação
Iniciação (Ref. PMBOK© 2012, PMI) – obter o comprometimento da organização para o
início da próxima fase do projeto. Nessa fase, o projeto garante a documentação e o
compromisso adequado para o início dos trabalhos do projeto.
Processos de Planejamento
O planejamento é de fundamental importância
num projeto, porque executar um projeto
implica em realizar algo que não tinha sido
feito antes. Como consequência, existem
relativamente mais processos nessa seção.
Entretanto, o número de processos não
significa que o Gerenciamento de projetos é
principalmente planejamento – a quantidade
de planejamento elaborada deve estar de
acordo com o escopo do projeto e com a
utilidade da informação desenvolvida. Os
relacionamentos entre os processos de
planejamento são mostrados nas figuras a
seguir. Estes processos estão sujeitos a
frequentes interações antes da
complementação do plano. Por exemplo, se a data inicialmente prevista para o término for inaceitável, os recursos do projeto, o
custo, ou mesmo o escopo podem necessitar de redefinição. Além disto, o planejamento não é uma ciência exata – duas equipes
distintas podem gerar planos muito diferentes para o mesmo projeto. Alguns dos processos de planejamento têm dependências
bem definidas, que fazem com que eles sejam executados essencialmente na mesma ordem, na maioria dos projetos. Por
exemplo, as atividades devem ser definidas antes do estabelecimento do seu cronograma e custo. Estes processos de
planejamento podem interagir várias vezes durante qualquer fase de um projeto. Anteriormente eram definidos processos
essenciais ou principais e facilitadores ou auxiliares. Essa classificação foi alterada e agora TODOS os processos são relevantes
e podem ser vistos na figura anterior.
Processos de Execução
Os processos de execução incluem os processos necessários para a garantia da execução
e de informações para os controles e replanejamentos.
Processos de Controle
O desempenho do projeto deve ser medido regularmente para identificar as variações do plano. Estes desvios são analisados,
dentro dos processos de controle, nas diversas áreas de conhecimento. Na medida em que são identificados desvios significativos
(aqueles que colocam em risco os objetivos do projeto), realizam-se ajustes ao plano através da repetição dos processos de
planejamento que sejam adequados àquele caso. Por exemplo, ultrapassar a data de término de uma atividade pode requerer
ajustes nos recursos humanos, na necessidade ou não de horas extras, ou no balanceamento entre o orçamento e os objetivos
de prazo do projeto. Controlar também inclui tomar ações corretivas, antecipando-se aos problemas.
Processos de Encerramento
Encerrar o projeto PMBOK© 2012 PMI, no capítulo 04 – gerar, reunir e disseminar informações para formalizar o término da fase
ou projeto. Encerramento dos Contratos PMBOK© 2012 PMI, no capítulo 12. Completar e liquidar o contrato, incluindo a resolução
de qualquer item pendente.
A INTEGRAÇÃO de todos esses processos, definida por uma área de conhecimento específica, inclui um conjunto de processos
exigidos para assegurar que os vários elementos do projeto estão apropriadamente coordenados.
1.2. Introdução à Ferramenta MS Project 2013
O Project começa a sua história em 1984, dentro do ambiente MS DOS, e em

1990 ganhou uma versão para o sistema operacional Windows. Em 1995 entra
no pacote Office, onde permanece até 1997. Na versão de 1998 encontramos
uma evolução com recursos do tipo trabalho. Na versão 2000, 2002, 2003 o
recurso tipo material aparece para compor os custos ou insumos do projeto. Em
2007 e 2010, recebe o recurso tipo custo – um recurso financeiro que não é
considerado como insumo para a composição de cálculos de desempenho ou
valor agregado, sendo desconsiderados para o controle do projeto até essa
versão 2013, todos sempre dentro da base Access de dados.
1.2.1. O Ambiente de Trabalho

Antes de se utilizar qualquer ferramenta, é conveniente nos familiarizarmos com o ambiente de trabalho, já que uma
vez compreendidos os conceitos básicos, funcionalidades e atalhos, poderemos otimizar nosso tempo e evitar futuras
dificuldades.
Desde a versão 2010, a ferramenta usa o conceito de Ribbon, já encontrada nos demais aplicativos da família Office
desde a sua versão 2007. Este conceito tem base em agrupamento de funções e comandos em conjuntos intuitivos,
assessorados por elementos gráficos e cores chamativas para facilitar sua memorização. Hoje a grande maioria dos
usuários já se adaptou à nova realidade da ferramenta, mas caso você seja um usuário de versão antiga e se sinta
perdido, a Microsoft disponibilizou uma página explicativa que pode ser acessada em
http://www.microsoft.com/project/en-us/ribbon_guide.aspx (verificado em 05/11/2012).
De modo a apresentar o ambiente de trabalho, o separamos em 12 áreas, mostradas na imagem abaixo, que serão
apresentadas a seguir.
1 Application Item ou Backstage
Seção encontrada em todos os aplicativos da família Office, com opções de controle e gestão da ferramenta bem
diversificados, mas muito comuns em qualquer aplicativo de computador.
Nesta área podemos encontrar os botões Info, New, Open, Save, Save As, Print, Share, Export, Close, Account e
Options.
Com os botões Export e Share, cujas opções na versão 2010 estavam agrupadas no botão Save & Send, a Microsoft,
se adequando ao atual contexto do mercado de informática, apresenta sua ferramenta com possibilidades de
colaboração e compartilhamento de informações.
Destaque para o botão account, no qual o usuário deve inserir login e senha de seu cadastro na Microsoft para se
beneficiar de algumas funcionalidades da ferramenta, como vinculação com SkyDrive, Facebook e resgate das
configurações pessoais em dispositivos diferentes.
2 Quick access toolbar
Se apresenta como uma barra de ferramentas customizável, na qual o usuário pode

adicionar os comandos que mais usa para acesso em apenas um clique. Chega-se
até a opção de customização (Customize Quick Access Toolbar) clicando-se na
seta encontrada à sua direita ( ).
Por padrão, esta barra apresenta as opções salvar, desfazer e refazer. Existe uma
lista de opções pré-definidas que podem ser selecionadas para apresentação na
barra, e qualquer outro comando da ferramenta pode ser inserido, usando-se a
opção More Commands… .
É possível ainda de ser apresentada abaixo do Ribbon, selecionando-se a opção

Show Below the Ribbon.
3 Tab
Tab, ou abas, são os principais agrupamento de comandos e funções da ferramenta, sendo o conceito de Ribbon
definido pelo conjunto de tabs que compõe o programa. As mais comuns são as Tarefas ou Tasks, Recursos ou
Resources, Projeto ou Project, Visualizar ou View, e Desenvolvedor ou Developer.
Task
Agrupa os recursos que atuam diretamente nas tabelas de atividade do aplicativo, editando, por exemplo, os
produtos, pacotes de trabalho, atividades e marcos.
Resource
De forma análoga à aba anterior, agrupa as ferramentas e opções que lidam com os recursos do projeto, como o
fazem os recursos de mão de obra, por exemplo.
Project
Reúne comandos de documentação e configuração do projeto, seus calendários, linha de base e relatórios.
Estreando na versão 2013, temos o ícone Apps for Office, com o qual a Microsoft pretende incentivar a criação de
aplicativos de terceiros para suas ferramentas do office.
View
Governa as opções de visualização das informações, como a seleção dos modos de visualização, tabelas, grupos,
filtros, opções de zoom, seleção de janelas entre outras.
Developer
Reúne ferramentas para desenvolvedores, e damos destaque para as opções de Macro. Muitas vezes
identificadas como recursos para usuários avançados,
existem usos muito simples que beneficiam todos os
usuários.
Caso não esteja visualizando esta aba, é possível que ela

esteja oculta. Para habilitá-la, você deve clicar com o botão
direito do mouse em alguma área branca (vazia) de qualquer aba, e selecionar a opção Customize the Ribbon e,
posteriormente, habilitar a opção Developer.
4 Tool tabs ou Contextual tab set
Existem abas que somente são apresentadas se cumprido certo contexto da ferramenta. Estas abas estão agrupadas
em conjuntos que as organizam de forma a melhor serem apresentadas ao usuário.
Abaixo temos exemplos de tool tabs, ou Contextual tab sets
A Task Sheet Tools, por exemplo somente pode ser vista quando o modo de visualização selecionado for do tipo Task
Sheet. Sobre modos de visualização falaremos no capítulo 2.
5 Contextual tab
Cada Contextual tab sets apresentada no item 4 acima somente possuía uma
aba. No entanto, é possível que cumprindo-se o critério para aparecimento do
tab set, este seja composto de mais de uma aba. No exemplo ao lado, criamos
uma aba chamada new tab que, juntamente da aba Format, é apresentada
sempre que o modo de visualização selecionado for do tipo Gantt Chart.
6 Group
Dentro das abas, os botões estão separados em grupos para melhor organização das funções das ferramentas.
7 Enhanced tooltip
Ao se permanecer com o ponteiro do mouse sobre um comando de uma aba, uma caixa de texto com informação é
exibida em auxílio do usuário. Existe a opção de desabilitar esta funcionalidade; para isso, o usuário deve ir ao
backstage, selecionar Options, na opção General, e em ScreenTip style marcar a opção desejada.
8 In-Ribbon gallery
Esse é um controle que apresenta uma coletânea de itens

relacionados ao que foi selecionado pelo item do “Ribbon”. Se o
conjunto de itens for muito extenso, então uma seta de expansão
é disponibilizada a ele.
No exemplo ao lado, mostramos a galeria de formatação pré-

definida das barras do diagrama de Gantt.
9 Dialog launcher
Esta opção pode ser encontrada no canto inferior direito de alguns grupos das abas da ferramenta, e expande as
opções apresentadas ao mostrar uma janela com novas possibilidades para o usuário. As janelas apresentadas serão
conhecidas pelos usuários das versões anteriores da ferramenta, já que vêm se perpetuando sem alterações
significativas.
Como exemplo, mostramos o grupo font,

encontrado na aba Task.
Mantendo o cursos do mouse no ícone
encontrado no canto inferior direito deste grupo,
podemos ver o ScreenTip informando a janela,
que ao ser clicada, torna-se visível, como
reproduzido abaixo.
10 Help
A opção de ajuda da ferramenta é acessível pelo ícone no canto superior direito ou a qualquer momento pelo botão
F1 do teclado. É necessário estar conectado à internet para usar a ajuda, cujo conjunto de dados se encontra na
grande rede.
Destacamos a possibilidade de buscar informações de campos
específicos da ferramenta na ajuda, muitas vezes com
exemplos elucidativos.
11 Unpin the ribbon button
É possível ocultar o Ribbon fazendo uso deste pequeno ícone,

ou mesmo com duplo clique na aba que esteja selecionada. O
mesmo para que o Ribbon reapareça.
12 Status bar
A status bar, encontrada em todos os aplicativos do Office, é

utilizada principalmente como acesso fácil ao zoom e transição
entre modos de visualização, ambos encontrados à direita.
É passível de customização. Para isso, clique com o botão direito e selecione a opção Customize Status Bar, e poderá
habilitar ou desabilitar um conjunto de informações pré-definidas.
1.2.2. Criação de um Novo Projeto

Para a criação de um novo projeto, devemos ir ao backstage (botão FILE) e selecionar a opção New. As opções que
surgem para a criação de um novo projeto são resumidas e mostradas abaixo, com exceção da opção New from
SharePoint Task List, que foge ao escopo deste livro, que apresenta a ferramenta na sua versão Microsoft Project
Professional 2013.
Seguindo a proposta do nosso livro, orientamos os leitores a selecionarem a opção Blanck Project, para construção
do seu projeto ao longo de nossas páginas.
Usando templates
Por padrão, a ferramenta vem com alguns templates instalados, e outros possíveis de serem acessados online.
Caso o usuário selecione um desses templates para a criação do seu projeto, encontrará diversas
configurações pré-definidas, como produtos, atividades e relatórios.
O usuário pode salvar seus projetos como template para uso posterior. Note que arquivos de template (.mpt)
possuem extensão diferente de arquivos de projetos (.mpp).
New from excel workbook
É possível criar o projeto a partir de informações contidas em arquivo de MS Excel. Selecionada esta opção,
o usuário é recepcionado por um assistente de importação que o ajuda no processo.
De modo a facilitar a importação, recomendamos que o cabeçalho das colunas no arquivo de Excel tenha
nome idêntico aos campos do MS Project para o qual se deseja importar os dados. Este procedimento é
especialmente útil quando se tem uma EAP (Estrutura Analítica do Projeto 1) já montada e estruturada no Excel
e desejamos importar essa EAP para o MS Project já indentada. O detalhamento desse procedimento pode
ser obtido no anexo E.
New from existing project
De modo semelhante à criação de projetos por templates, é possível criar projetos baseado em outro arquivo
de projeto já criado. Esta opção funciona da mesma forma que abrir o arquivo antigo e Salvar Como outro
arquivo.
Blank project
Selecionando esta opção, o usuário cria um projeto totalmente em branco. É esta opção que recomendamos
para o usuário seguir a leitura do nosso livro.
1
Apresentaremos o conceito de EAP no capítulo 2 do livro.
Ao se criar um novo arquivo, devemos já ter em mente o local onde ficará armazenado e o nome que receberá.
É importante que estas escolhas sejam realizadas em conjunto com os envolvidos no projeto e seguindo os
padrões organizacionais, caso existam. Recomendados que o nome do arquivo receba identificação da versão
para que seja facilmente reconhecido.
1.2.3. Configurações Iniciais da Ferramenta

Os ajustes a seguir devem ser feitos por conta do início dos trabalhos dentro da ferramenta MSProject, e são
imperiosos para o sucesso do operador na modelagem do projeto. Esse recurso tem a função de configurar uma série
de parâmetros do Microsoft Project 2013. É fundamental que isto ocorra antes do início do trabalho de planejamento,
evitando assim uma série de conflitos e situações desagradáveis. Quando houver um grupo de pessoas trabalhando
em um mesmo local ou em função de um mesmo projeto, é importante a configuração de alguns itens em especial.
Acessando o menu FILE-Options

encontramos no lugar das 10 abas
de ajustes anteriores, a tela
reproduzida ao lado:
Destacamos General, Display,
Schedule, Proofing, Save,
Language, Advanced,
Customize Ribbon, Quick
Access Toobar, e Trust Center.
A referência GENERAL.
O item “Screen Tip style”
configura a disponibilização, ou
não, de texto auxiliar para o usuário
que descansar o cursor do mouse
por alguns segundos em cima de
um ícone ou botão da ferramenta.
O item Default View deve ser feito

mantendo-o em "Task Sheet” em
vez do padrão “Gantt with
Timeline”. Isso garante que o
modo de visualização encontrado
ao se criar novos arquivos na
ferramenta contenha somente os
elementos necessários aos
primeiros passos da utilização do
arquivo.
"Always use these values

regardless of sign in to Office" deve
ser marcado caso o usuário deseje
que estas configurações sejam
utilizadas para qualquer usuário da
máquina, independente do login
realizado.
A referência DISPLAY.
O item “Calendar Type” deve ser mantido em Gregoriano.
Recomendamos todas as opções para “Show indicators and options buttons”. Quando marcadas, mostram
mensagens ao usuário, de acordo com as 4 opções. Abaixo temos um exemplo da opção "Deletions in the Name
columns".
Dentro de “Show these elements”, o item “Entry bar”, se marcado, torna visível uma barra de inserção de conteúdo
na área de trabalho, tal como barra de fórmulas do aplicativo MS Excel. Recomendamos que esta opção fique
marcada.
A referência SCHEDULE.
Os ajustes mais importantes são definidos em “Hours per Day”, “Hours per week” e “Days per month”. Eles devem
ficar em 8 horas por dia, 40 horas por semana e 20 dias por mês.
As unidades de alocação de recurso podem ser expressas no modo decimal ou percentual. Dessa forma, podemos
trabalhar com 100% de uma equipe ou com 1 equipe. Podemos alocar 50% de um equipamento no modo percentual
ou 0,5 no modo decimal.
Para a inclusão de novas atividades do projeto em montagem, a forma como elas “automaticamente” serão inseridas
é dada pelo conjunto de parâmetros que se segue, sendo que o parâmetro mais importante é “show assignment
unit as” mantido em “Decimal”.
A opção “New tasks created” pode ser de 2 tipos básicos: agendadas manualmente - “Manually scheduled” - e -
agendadas automaticamente - “Auto scheduled”. Vamos manter o ajuste como “Auto scheduled”.
O parâmetro “Auto scheduled tasks schedule on” deve mostrar “Project Start Date”.
Os parâmetros de entrada das durações – “Duration” - e trabalho – “Work” - devem ser ajustados para “Days” e
“Hours”.
Os tipos de atividade que existem nessa ferramenta para cálculo de agendamento de tempo e recursos são três:
“unidades fixas, duração fixa e trabalho fixo”. Esse tema será abordado mais adiante, porém é necessário que
tenhamos em mente que, até o domínio da ferramenta, ele deve ficar em “duração fixa” (“fixed duration”).
As novas “tarefas” podem ser

do tipo “Effort driven”-
“dirigidas ao esforço”, ou não.
Essa caixa deve ser mantida
desmarcada enquanto não
abordamos esse tópico em
detalhes.
Outra caixa importante é a de

“Tasks Will always honor
their constraint dates” que
significa a obediência às datas
de restrição que as atividades
podem ter. Uma vez que as
simulações acontecem
levando as datas de início e
término das atividades para
frente ou para trás nas suas
dependências, a obediência a
“não começar antes de” ou
“não terminar antes de” deve
ser mantida. A habilitação
desse item proporciona
simulações dinâmicas, como
os devidos indicadores de
quebras de restrição. Porém, o
uso de datas de restrição deve
ser cuidadoso, evitando
problemas para o gerente
durante o andamento do
projeto.
“New Schedule tasks have

estimated durations” – as
atividades novas possuirão duração estimada. Elas já são cadastradas com o campo “estimated” marcado,
denotando um ponto de interrogação junto à duração padrão de 1 dia.
O item “Updated manually Scheduled Tasks when editing links” e o item “Keep task on nearest working day
when changing to Automatically Scheduled mode” devem ficar desmarcados.
O item “Show task schedule warnings” deve ficar marcado e o “Show tasks schedule suggestions” deve ficar
desmarcado.
O item “Calculate project after each edit” deve ficar marcado como “on”.
O item "Updating task status updates resource status” garante que os campos de trabalho real e os custos
envolvidos com esse trabalho serão calculados automaticamente, assim que forem informados os valores de %
concluídos da atividade. Se estiver desmarcado, será necessário controlar também o trabalho real dos recursos, para
obter um controle preciso do trabalho realizado e dos custos envolvidos. Deve ser deixado marcado, e será explorado
mais à frente, uma vez que a intenção do planejamento é controlar o avanço físico (% concluída) e o avanço do
trabalho realizado (% trabalho).
O item "Inserted projects are calculated like summary tasks" define que as atividades externas ao projeto serão
tratadas como atividades
sumarizadas. Com isso, torna
possível uma melhor
administração do caminho
crítico do projeto principal.
Deve ser deixado marcado.
O item "Actual costs are

always calculated by
Project" garante que os
custos reais do projeto serão
calculados automaticamente,
de acordo com o percentual de
trabalho realizado. Se estiver
marcado, o custo real de uma
atividade só poderá ser
informado depois que a
atividade estiver 100%
concluída. Deve ser
desmarcado. O subitem “Edits
to total cost will be spread to
the status date” deve ficar
marcado.
O item "Default fixed cost accrual" define como será o padrão de distribuição de custos fixos ao longo do tempo.
Pode ser START, PRORATED ou END. Deixamos marcado como “PRORATED”.
Atenção: para preservar esses ajustes para todos os projetos, ou seja, para que fique registrado como regra de
trabalho, sempre que houver a opção “All projects”, essa deve ficar marcada.
A referência PROOFING.
Os ajustes dessa tela não são fundamentais para o funcionamento do agendamento das atividades ou cálculos de
custos ou recursos do sistema.
A referência SAVE.
Nessa opção, ajustamos todas as opções referentes ao comportamento de gravação do arquivo gerado pelo software.
Uma vez que existe a possibilidade de outros colaboradores estarem utilizando versões anteriores dessa ferramenta,
é possível definir que os arquivos
gravados pela versão do
operador estejam sempre
ajustados para “salvar” o
resultado do trabalho dentro da
versão ou forma de intercâmbio
de dados adequado.
A localização e destino dos

arquivos de modelo e trabalho
também podem ser redefinidos
permitindo o uso de mapas de
rede internas.
Quando estamos salvando as
informações do projeto em
versões anteriores ao MSProject
2010, existe uma certeza de
estarmos perdendo informações
alocadas em campos e estruturas
que as versões anteriores não
suportam. Não recomendamos a
função “Autosave”, já que, sempre que salvamos o arquivo, perdemos o histórico de alterações necessárias para o
funcionamento da opção “desfazer”,(undo).
A referência LANGUAGE.
Os ajustes dessa tela não são

fundamentais para o
funcionamento do
agendamento das atividades
ou cálculos de custos ou
recursos do sistema. Nela
podemos incluir outros
idiomas para alterar a
apresentação do software e
seu “front end”.
A referência ADVANCED.
Os ajustes dessa tela são importantes para o funcionamento do agendamento das atividades ou cálculos de custos.
O item "Set Auto filter on for new projects” pode ficar desmarcado.
O item “Open last file on startup” garante

que ao iniciar o software seja aberto,
automaticamente, o último arquivo
trabalhado. Deve ficar desmarcado.
O item "Prompt for project info for new

projects" fará possível a configuração de
informações sobre um novo projeto, assim
que for criado(informações como “START
DATE, STATUS DATE e CALENDAR”.
Deve ser deixado marcado.
O item “Undo levels” pode ser ajustado em

até 99 níveis de retrocesso a ações
promovidas pelo operador. Mas
aconselhamos deixar com o máximo de 20
retrocessos.
O item “Advice from Planning Wizard”

deve ficar desmarcado. Ele especifica quais
ajudantes de planejamento serão abertos a
partir da criação de um novo projeto. Esses
ajudantes podem ser sobre o uso do
MICROSOFT PROJECT, sobre as ações de
agendamento ou sobre erros ocorridos.
O item “Automatically add new resources

and tasks” deve ficar desmarcado.
Os itens com o uso do recurso “Allow cell

drag and drop”; edição direta dentro das
“células” (“Edit directly in cell”) de trabalho
nas planilhas de dados; as unidades de
trabalho e de tempo, entre outras; a caixa
de “Move selection after enter”, que
seleciona automaticamente o campo
seguinte após pressionar “enter” na planilha
de dados; e a caixa de “Ask to update
automatic links”, que força a apresentação
de uma tela de confirmação para
atualização de dados e campos ligados
através de ligações OLE do Windows; devem ficar marcados. Se desmarcados, essa edição só será possível através
da linha de edição (“Edit Bar”).
Os itens “Show external sucessors” e “Show external predecessors” devem ficar marcados.
“Automatic add New Views and table … to the Global” deve ficar desmarcado para não encher o sistema residente
na máquina.
Para as opções de cálculos de Valor Agregado ou Earned Value, "EARNED VALUE" especifica o método pelo qual
será calculado o valor acumulado do projeto. Pode ser feito através do percentual concluído – “% Completed” ou
através do percentual físico concluído – “Phisical % Completed”. A linha de base deve ficar referenciada como
“Baseline”.
O item “Calculation” configura padrões de comportamento do software para cálculos diversos, sendo que os itens
"Move end of completed parts after status date back to status date" e "Move start of remaining parts before
status date foward to status date" fazem com que as partes realizadas e não realizadas sejam reposicionadas no
tempo, atendendo a critérios ou premissas lógicas distintas. O primeiro garante que as partes concluídas apontadas
após a data de medição (status date) sejam trazidas para conclusão ANTES da data de medição, enquanto que o
segundo garante que as partes que não foram realizadas e estejam “programadas para” antes da data de medição,
sejam iniciadas imediatamente APÓS essas. Todos esses itens devem permanecer desmarcados. Mais detalhes no
capítulo 8 , “O reinício – preparação para a atualização do andamento do projeto” .
O item "Edits to total tasks % completed will be spread to the status date" fará uma distribuição uniforme das
alterações de percentual concluído das atividades, até a data de status do projeto. Deve ser mantido marcado.
O item "Calculate multiple critical paths" torna possível a visualização de mais de um caminho crítico. Deve ser
deixado desmarcado.
O item "Tasks are critical if slacks is less than or equal to" configura a definição dos níveis das folgas para a
classificação de "tarefas críticas". É um recurso que poderá ser explorado quando o operador se sentir mais seguro
dos recursos da ferramenta, permitindo análises de riscos mais acuradas. Trabalha em conjunto com a opção anterior
e deve ficar com seu valor em ZERO.
Atenção: para preservar esses ajustes para todos os projetos, ou seja, para que fiquem registrados como regra de
trabalho, sempre que houver a opção “All projects”, essa deve ficar marcada.
Resource leveling options

Existe um recurso no software que permite o reagendamento automático das atividades que serão responsáveis pela
realização dos pacotes de trabalho e os produtos principais do projeto, de forma a eliminar conflitos de falta de
recursos humanos pelo seu uso simultâneo, ajustando as datas de início à disponibilidade dos recursos existentes.
Essa tela será mais comentada na discussão de alocação de recursos e seus conflitos, capítulo 04 deste livro.
Esta funcionalidade é conhecida como nivelamento de recursos. No MS Project, existem opções de configuração do
nivelamento de recursos, e para chegarmos até elas devemos selecionar o botão Leveling Options, encontrado na
aba resource, como visto abaixo.
Na tela Resource Leveling, a opção “Look for overallocation on a” deve ser ajustada para uma base de “Hour by Hour”.
A opção de “Priority, Standard” deve ser preferida na maioria dos casos, e todas as caixas de marcação devem ficar
vazias no item “Resolving overallocations”.
Recomendamos ainda que a opção "Leveling calculations" seja mantida na opção manual, para que a mesma
somente seja ativada pelo usuário.
1.2.4. Documentação do Projeto

Na fase de iniciação o projeto é autorizado e seus primeiros documentos são criados. Integrar os documentos e
informações do projeto ao arquivo de MS Project deve ser tarefa cotidiana da equipe de planejamento, por isso
veremos como realizar a documentação inicial do projeto e como incluir o termo de abertura do projeto na Ferramenta.
Tendo o MS Project 2013 já sido configurado como descrito anteriormente, ao criarmos um

novo arquivo nos é apresentada a tela a seguir para o preenchimento das informações
necessárias para o início dos trabalhos.
Caso a tela Project Information não seja apresentada, é possível encontrá-la na aba Project.
A data de início PREVISTA deve ser informada (Start date) e o trabalho de agendamento
de pacotes de trabalho e atividades deve começar a partir da “DATA DO INÍCIO DO PROJETO” (Schedule from,
opção Project Start Date). A escolha do calendário de trabalho para o projeto também entra na tela de informações e
por princípio deve-se escolher o calendário padrão (trataremos de calendários no capítulo 03). Por definição, o
calendário padrão tem como dias úteis segunda a sexta, sendo que o sábado e domingo são considerados como dias
de repouso. O nível de prioridade desse projeto em relação aos outros pode variar de 0 (sem prioridade) a 1000
(totalmente prioritário e urgente).
As outras informações serão vistas

posteriormente com mais detalhes,
mas podemos informar que a “DATA
DE ESTATUS” é utilizada para
cálculo de Valor Agregado (índice de
desempenho de projetos), a “DATA
ATUAL” é utilizada para avaliação e
simulações do projeto para datas
futuras; os campos próprios ou
“customizados” serão abordados
ainda nessa etapa.
O botão inferior, que se refere à

palavra “ESTATÍSTICAS”,
apresenta uma tela contendo informações relevantes para certas análises de trabalho e custo desenvolvidos e
realizados.
Finalizando a documentação inicial do projeto na ferramenta, o Termo de Abertura do Projeto já explicado e

desenvolvido é incluído nessa hora dentro dos campos da janela obtida pelo item de menu em acesso “FILE- Info”,
especificamente no item “Project Information - Advanced Properties”.
O uso da Guia “Resumo” (“Summary”, em inglês) permite que sejam

armazenadas informações como: o autor do arquivo de trabalho, a
empresa, o nome do gerente e o link de referência.
No campo “Comments” é possível incluir até 32.000 posições de
caracteres,espaço suficiente para registrar o objetivo e descrição do
projeto. É possível utilizar esse campo para a inclusão do texto do
termo de abertura do projeto.
O campo “Hyperlink base” é muito útil quando houver o uso de
apontadores pré-definidos para páginas html a partir das atividades ou
pacotes de trabalho. Devemos observar que aqui "Author" se refere ao
profissional que administra o arquivo do aplicativo MSProject.
De modo a facilitar o acesso do usuário a essa tela, sugerimos que um atalho seja criado na Quick Access Toolbar.
Para isso, basta seguir o procedimento exposto anteriormente neste capítulo e adicionar à barra o comando Advanced
Document Properties ( ) .
1.3. Gerenciamento de Integração do Projeto

1.3.1. Fundamentos da INTEGRAÇÃO
Conceitualmente, a INTEGRAÇÃO inclui um conjunto de processos exigidos para assegurar que os vários elementos
do projeto estão apropriadamente coordenados. Os processos de gerenciamento de integração são, por natureza,
integrativos. O gerenciamento de integração do projeto envolve equilibrar os objetivos e alternativas concorrentes, a
fim de atender ou superar as necessidades dos interessados (stakeholders), abordando os processos de elaboração
do plano do projeto, a execução do plano do projeto e controle integrado de alterações. Estes três processos não
somente interagem entre si, como também com os processos das demais áreas de conhecimento. Vale a pena
ressaltar que, de acordo com a visão do PMI, a integração ocorre também em outras áreas; por exemplo, o escopo
do projeto e o escopo do produto precisam ser integrados, o trabalho do projeto necessita ser integrado com outros
trabalhos da organização, e produtos e várias características técnicas necessitam de integração. Para melhor
entendimento desta área de conhecimento, vale a pena recordar alguns conceitos como definições de gerenciamento
de projetos e as áreas de conhecimento, já apresentadas anteriormente. O gerenciamento de projetos compreende
cinco grupos de processos já citados: Processos de iniciação; Processos de planejamento; Processos de execução;
Processos de controle; e Processos de encerramento.
A tabela a seguir ilustra os processos de forma a melhor entendê-los no conjunto.
1.3.2. Gerenciamento de Integração do Projeto

O Gerenciamento de Integração do Projeto inclui os processos requeridos para assegurar que os diversos elementos
do projeto estão adequadamente coordenados. É responsável também pela criação e manutenção dos três
documentos principais do projeto:
✓ Termo de abertura do projeto - que autoriza formalmente o projeto.

✓ Plano de gerenciamento do projeto - que determina como o trabalho será realizado.
01 - Termo de Abertura do Projeto
O Termo de Abertura do Projeto é o primeiro documento produzido e dá origem básica ao projeto em si. Por isso, na
área de conhecimento interação, dentro das melhores práticas, temos um processo específico para o seu
desenvolvimento.
No registro do Termo de Abertura do Projeto, encontramos:
✓ Requisitos que satisfazem às necessidades, desejos e expectativas do cliente

✓ Patrocinador e outras partes interessadas
✓ Necessidades de negócios, descrição de alto nível do projeto ou requisitos do produto para o qual o projeto
é realizado
✓ Objetivo ou justificativa do projeto
✓ Gerente de projetos designado e nível de autoridade atribuída
✓ Cronograma de marcos sumarizado
✓ Influência das partes interessadas
✓ Organizações funcionais e sua participação
✓ Premissas organizacionais, ambientais e externas
✓ Restrições organizacionais, ambientais e externas
✓ Caso de negócios justificando o projeto, incluindo o retorno sobre o investimento
✓ Orçamento sumarizado.
02 - Plano de gerenciamento do projeto
O PLANO DE PROJETO é um documento consistente, coerente, formal, aprovado e usado para gerenciar a execução
do projeto, bem como o seu controle. O processo de elaboração do Plano do Projeto utiliza os resultados dos outros
processos para criar, inclusive, o planejamento estratégico. Este processo quase sempre se repete várias vezes. Tal
plano de projeto pode sofrer mudanças com o tempo, desde que sejam controladas. A maior parte do conteúdo de
um Plano de Projeto refere-se aos resultados dos processos das áreas de conhecimento, caracterizando assim a
INTEGRAÇÃO DO PROJETO.
Resumidamente, o Plano de Projeto deve conter no mínimo:
✓ Plano de Gerenciamento do Escopo

✓ Plano de Gerenciamento do Cronograma
✓ Plano de Gerenciamento de Custos
✓ Plano de Gerenciamento da Qualidade
✓ Plano de Gerenciamento de Recursos Humanos
✓ Plano de Gerenciamento das Comunicações
✓ Plano de Gerenciamento de Riscos e o Registro de Riscos
✓ Plano de Gerenciamento das Aquisições
✓ Plano de Gerenciamento dos Envolvidos
✓ Plano de Melhorias no Processo

✓ Lista de Marcos do Projeto
✓ Calendário de Recurso
✓ Linha de Base do Escopo, Cronograma, dos Custos e da Qualidade
03 - Registro das Partes Interessadas
O REGISTRO DAS PARTES INTERESSADAS ou ENVOLVIDOS DO PROJETO é um documento contendo o registro

das partes interessadas, com todos os detalhes relacionados a essas, incluindo:
✓ Informações de identificação - Nome, cargo organizacional, localização, papel no projeto, informações de
contato;
✓ Informação de Avaliação - Principais requisitos, expectativas principais, a influência potencial na fase do
projeto, no ciclo de vida com o maior interesse, e Stakeholder - classificação: interno / externo apoiador, /
neutro / resistência, etc.
Sendo dinâmico, como tudo em um projeto, esse cadastro deve ser atualizado periodicamente, pois as condições e
os próprios interessados podem ser alterados em função de sua participação. Isso de forma periódica permite verificar
como os interessados podem mudar de posição ou influência, em todo o ciclo de vida do projeto.
2. Capítulo 02: Gerenciamento do Escopo
2.1. Conceitos de Gerenciamento do Escopo
Escopo na Definição de Projeto: o termo

escopo deve ficar bem claro e livre de
dúvidas. Para que isto seja possível, vamos
assentar aqui, mais e mais vezes, a sua
definição.
Estendendo o conceito de projeto: “Projeto é um empreendimento não repetitivo, caracterizado por uma
sequencia clara e lógica de eventos, com início e fim, que se destina a atingir um objetivo claro, definido e
único, sendo conduzido por pessoas dentro de parâmetros pré-definidos de tempo, custo, recursos
envolvidos e qualidade.”
“Um objetivo claro, definido e único” – Com estes termos, a definição de projeto referência que o escopo do projeto
deve estar suficientemente especificado e divulgado a todos os participantes de forma que tenda a zero a
possibilidade de dúvidas quanto ao seu objetivo. É importante que o escopo seja de conhecimento de todos, esteja
disponível para consulta e esteja formalmente escrito de forma que todos os envolvidos percebam a mesma coisa.
Diferentes visões do mesmo escopo geralmente apontam para uma necessidade de melhora na descrição do mesmo.
Quanto mais detalhado o escopo, menor a chance de o projeto endossar a estatística de que a grande maioria dos
problemas em projetos advém de problemas com escopo. Esses dados vêm do Estudo de Benchmarking em Gestão
de Projetos 2003 a 2010 – PMIRIO. Essa informação pode ser completada com as diversas observações no
mecanismo causa-efeito que encontramos na prática da gestão no nosso dia a dia. O entendimento do que vai ser
executado ou produzido não se esgota apenas no documento, mas também em todos aqueles envolvidos no processo
de produção do “projeto”. A identificação e a administração, assim como, ao final, o atendimento às expectativas dos
envolvidos, devem ser uma realidade e uma prática. Não podemos montar o documento do escopo sem montar o
documento dos envolvidos e sua correlação.
Prosseguimos com a afirmação: “Escopo é todo o trabalho, e somente o trabalho,

necessário para que o produto ou serviço objetivo do projeto seja entregue ao seu final.”
Um escopo bem definido, de conhecimento de todos e aprovado pelo cliente, proporciona melhores condições para
atender às expectativas deste mesmo cliente, de forma que o andamento do projeto prossiga aderente com o que o
cliente espera obter ao final do projeto (fitness to use). A compreensão da importância desta área de conhecimento
proporcionará as condições necessárias para se continuar na eterna busca dos gerentes de projetos: “Fazer Melhor,
Mais Rápido, Com Qualidade e no Menor Custo”
O termo escopo é utilizado de duas formas:
Escopo do Escopo do produto são as características funcionais do produto ou serviço. São

Produto os atributos do produto ou serviço resultantes da execução do plano do projeto. A
sua conclusão é medida contra a especificação de requisitos do produto
Escopo do Escopo do projeto é todo o trabalho que deve ser realizado com a finalidade de
Projeto fornecer um produto ou serviço com os aspectos e funcionalidades especificadas.
A sua conclusão é medida contra o plano do projeto.
Dentre as dez áreas de conhecimento encontradas no PMBOK Copyright © 2012 PMI, o Gerenciamento do Escopo
do Projeto é a área que abrange os processos requeridos para garantir que o projeto inclua todo o trabalho necessário,
e somente o trabalho necessário, para complementar de forma bem sucedida o projeto. A fundamental preocupação
desta área de conhecimento está em definir e controlar o que está e o que não está incluído no projeto. Os principais
processos do Gerenciamento do escopo do projeto, que são detalhados no capítulo 5 do PMBOK Copyright © 2012
PMI, são:
Gerenciamento do Escopo do Projeto

Iniciação Planejamento Execução Controle Encerramento
Planejar o Escopo Verificar o Escopo
Coletar os Requisitos
Definir o Escopo Controlar as Alterações do
Escopo
Criar a EAP
Planejar o escopo – descrever como a equipe irá adquirir e documentar a administração do trabalho
do escopo do projeto e suas mudanças.
Coletar os Requisitos – descrever como a equipe irá adquirir e documentar os requisitos e
características dos participantes do projeto, e como isso interfere no escopo do projeto.
Definir o escopo – subdividir os principais subprodutos do projeto, constantes da declaração formal do
escopo, em componentes menores, de mais fácil gerenciamento.
Criar a EAP - decomposição hierárquica orientada aos produtos que, ao serem produzidos, atingem os
objetivos do projeto, e criar as entregas necessárias. É possível agendar, estimar custos, monitorar e
controlar o trabalho planejado contido nos componentes de nível mais baixo da EAP, denominados
pacotes de trabalho.
Verificar o Escopo – formalizar a aprovação do escopo do projeto.
Controlar as Alterações do Escopo – controlar as mudanças no escopo do projeto.
A conclusão do escopo do projeto é medida em relação ao plano do projeto, enquanto a conclusão do escopo do
produto é medida em relação aos requisitos do produto. Ambos os tipos de gerenciamento de escopo devem ser bem
integrados para garantir que o trabalho do projeto resulte na entrega do produto especificado. Os grupos de processos
que compõem esta área de conhecimento estão ligados através dos resultados que produzem. As “Saídas” de um
processo são as “Entradas” em outros processos, em que a fluidez na troca de informações é o motor que impulsiona
a integração entre as áreas de conhecimento do Gerenciamento de Projetos. Focando nestas ligações, cada processo
pode ser mais bem descrito e estudado segundo as características das Entradas, Técnicas e Ferramentas e Saídas.
Entradas Documentos ou itens documentáveis que sofrerão algum tipo de ação no processo.
Técnicas e Mecanismos aplicados aos Dados responsáveis pela geração dos Resultados. É o
Ferramentas agente que quando utilizado possibilita a geração dos Resultados do processo.
Saídas Documentos ou itens documentáveis que são o resultado do processo.
A ilustração ao lado identifica de modo gráfico a proposta do PMI em seu guia de apoio.
2.1.1. Processo de Planejar o Escopo do Projeto

O Guia de conhecimentos que o PMI promove é reciclado ou revisto de 4 em 4 anos. Nessa última revisão, ficou clara
a necessidade de explicitar o processo de
planejamento de cada uma das áreas de
conhecimento, e o escopo será a primeira a ser
abordada. Esse processo é aquele no qual a equipe do
projeto documenta formalmente os requisitos que
caracterizam, mais do que desejos, o sucesso do
projeto. Esse processo de trabalho define as diretrizes
de como o escopo do projeto deve ser desenvolvido,
escrito e documentado; como o escopo do projeto
deve ser validado em tempo de desenvolvimento ou de
sua produção; como as entregas devem ser
conduzidas e quais os documentos que devem apoiar
essa documentação; e, por fim, e talvez mais
importante, como as mudanças devem acontecer.
Entradas do processo
1 – Termo de Abertura do Projeto – Documento
gerado pelo processo de iniciação
anteriormente apresentado.
2 – Plano de Gerenciamento do Projeto –
Documento gerado pelo processo de iniciação
anteriormente apresentado.
3 – Fatores Ambientais e Ativos da
organização. – Informações particulares da
realidade e das condições corporativas e situacionais do ambiente no qual o projeto deve acontecer. Muitas
vezes, são apresentados como cultura da empresa ou como regras e normas de procedimento e conduta de
negócios.
Ferramentas e Técnicas utilizadas pelo processo

1 – Reuniões - As reuniões são os meios mais eficazes para definir as diretrizes já mencionadas. Os
especialistas ou conhecedores do histórico da empresa, dos fornecedores ou clientes, com alto grau de
maturidade em gestão, entendem os limites, as metas e o desejo do negócio, e utilizam técnicas para
desenvolver as primeiras diretrizes e particularidades para o desenvolvimento e o controle do escopo do
projeto.
2 – Opinião especializada - Como dito na técnica anterior, os profissionais mais conhecedores de casos,
história e condições de mercado, associados ao entendimento a técnicas de gestão, são os elementos mais
comuns nessa proposta de técnica.
Saídas do processo
1 – Plano de Gerenciamento do Escopo - Esse plano deve trazer base para as equipes desenvolverem cinco
ações básicas: definir – desenvolver – monitorar – controlar – verificar. Ele deve trazer processos para, no
mínimo, preparar o “escopo escrito”, a “estrutura EAP”, “meios de manutenção e aprovação da EAP”,
“aprovação das entregas da EAP”, e “controle da mudança”. Será parte do plano geral do projeto.
2 – Requisitos do Plano de gerenciamento - A forma como esses requisitos serão acompanhados e controlados
nos seus atributos de definição; como os requisitos do projeto devem ser analisados, documentados e
gerenciados; como as atividades dos requisitos serão planejadas, rastreadas e relatadas; como as mudanças
no produto serão conduzidas; como os impactos serão analisados, rastreados, monitorados e relatados, assim
como os níveis de autorização necessários para aprovar tais mudanças; como será o processo de priorização
de requisitos; como serão as métricas de medição e aprovação / aceite dos produtos e os motivos justificados
para usá-las; e como será a estrutura da matriz de rastreabilidade (histórico) .
2.1.2. Processo de Coletar os Requisitos do Projeto

Como já foi comentado, o gerenciamento do escopo tem influência direta no sucesso do projeto, assim como o
atendimento aos “desejos” e “necessidades” (requisitos) dos envolvidos. A causa dos retrabalhos e problemas de
cronograma podem ser facilmente mapeadas e, frequentemente, apontam uma baixa definição de escopo como
causa principal, assim como o mapeamento dos requisitos de gerenciamento do projeto e do produto do projeto.
Quanto maior o detalhamento do escopo do projeto, quanto mais crítico e quanto maiores forem as dificuldades para
o levantamento de informações, mais cuidados no gerenciamento do escopo são necessários. Esse processo é
aquele em que a equipe do projeto documenta formalmente os requisitos que caracterizam mais do que desejos, o
sucesso do projeto. Alguns itens que podem ajudar no entendimento desse processo: “requisitos de negócios” -
descrevem as necessidades de nível mais alto da organização; “requisitos das partes interessadas” - descrevem as
necessidades de uma das partes interessadas ou grupos de stakeholders; “requisitos da solução” - descrevem as
características, funções e características do produto, serviço ou resultado que vai atender ao negócio; “requisitos
funcionais” - comportamentos do produto; “requisitos não funcionais” - condições ambientais ou qualidades requeridas
para o produto ser eficaz; “requisitos do projeto” - as ações, processos ou outras condições que o projeto precisa
atender; “requisitos de qualidade”- qualquer condição ou critérios necessários para validar a conclusão bem sucedida
de uma prestação do projeto ou a realização de outro requisito do projeto.
1 – Termo de Abertura do Projeto – Documento gerado pelo processo de iniciação anteriormente apresentado.
2 – Plano de Gerenciamento do Escopo – Documento gerado pelo processo de iniciação anteriormente
apresentado.
3 – Plano de gerenciamento dos requisitos - Documento gerado pelo processo de iniciação anteriormente
apresentado.
4 – Plano de gerenciamento das partes interessadas - Documento gerado pelo processo de gerenciamento
dos envolvidos, usado para entender requisitos de comunicação das partes interessadas e do nível de
engajamento das partes interessadas, a fim de avaliar o nível de participação dos interessados nas diversas
atividades do projeto.
5 - Registro das partes interessadas – Documento de registro das partes interessadas, usado para identificar
as partes interessadas que podem fornecer informações sobre os requisitos.

1 – Entrevistas - abordagem formal ou informal de obter informações das partes interessadas de forma direta.
Entrevistando sempre profissionais experientes em projetos e as partes interessadas, peritos auxiliarão na
identificação e definição das características e funções essenciais das entregas do produto desejado.
2 - Análises de Documentos - usadas para obter os requisitos através da análise de documentação existente
e identificar informações relevantes para os requisitos. São usados os planos de negócio, contratos, pedidos
de proposta, documentação de software de aplicação, documentação de requisitos, entre outros.
3 – Dinâmicas de Workshops – os workshops são promovidos em sessões focadas que trazem os interessados
para uma reunião e definem os requisitos do produto. Workshops são considerados uma técnica básica para
a definição rápida das interferências dos requisitos funcionais e reconciliar as diferenças das partes
interessadas.
4 – Observações - maneira direta de ver profissionais e pessoas em seu ambiente e como eles desempenham
suas funções ou tarefas para realizar os processos e trabalhos relativos ao negócio ou ao projeto. É
particularmente útil para processos detalhados quando as pessoas que usam o produto têm dificuldade ou
relutam para articular as suas necessidades.
5 - Benchmarkings - envolve comparar as práticas reais ou planejadas, tais como processos e operações,
com aquelas de organizações equivalentes, de modo a identificar as melhores práticas, gerar ideias de
melhorias e fornecer uma base para medir o desempenho.
6 – Outras, como Diagramas de Contexto, Grupos Focais, Técnicas de Criação em Grupo, Tomada de
Decisões Técnicas em Grupo, Questionários e Pesquisas, e uso de Protótipos; podem ser pesquisadas como
apoio a essa construção de entendimento.
Saídas do processo
1 – Documentação dos Requisitos do Projeto - Conjunto de documentos que devem registrar os requisitos
detectados pelo processo, ainda que não todos, mas a maioria significativa deles. Uma melhor aproximação
e detalhamento pode acontecer ao longo do planejamento do projeto. É comum termos também um Plano de
Administração dos Requisitos do Projeto, que mostrará como esses requisitos serão acompanhados e
controlados nos seus atributos de definição.
2 – Matriz de Acompanhamento dos Requisitos do Projeto - Matriz que apresenta os requisitos, ligando-os às
suas origens e anotando o seu atendimento ou recusa ao longo do ciclo de vida do projeto. A implementação
dos requisitos na matriz de rastreabilidade ajuda a garantir que cada requisito adicione valor de negócio através
da sua ligação com os objetivos de negócio e de projeto, ajudando a garantir que os requisitos aprovados para
as documentações sejam entregues no final do projeto.
2.1.3. Processo de Definir o Escopo

A declaração do escopo do projeto é o documento resultante do esforço do detalhamento do escopo preliminar do
projeto apresentado no momento de sua criação. Durante o planejamento, o escopo do projeto é definido e descrito
mais especificamente porque as informações que compõem o escopo do projeto são progressivamente descobertas
e documentadas. Necessidades, desejos e expectativas das partes interessadas são analisados e convertidos em
requisitos. As premissas e restrições identificadas inicialmente como da organização ou externas são agora mais
detalhadamente analisadas e enriquecidas com as do próprio projeto. É importante que durante este processo estejam
envolvidos todos os principais participantes do projeto, em todos os níveis, desde o dono ou patrocinador do projeto,
passando por consultores, subcontratados, terceirizados e fornecedores.
1 – Fatores Ambientais da Empresa - Os fatores ambientais da empresa são as informações que auxiliam a
determinar se o escopo do projeto é grande ou pequeno, crítico ou rotineiro, e se o projeto necessitará de mais
ou menos esforço para o gerenciamento do seu escopo. Levam em conta itens como a cultura da organização
(um projeto é grande ou pequeno dependendo dos olhos de quem julga), infraestrutura, recursos humanos,
políticas de pessoal, ferramentas e condições de mercado. O conhecimento desses fatores é muito importante
para a condução dos trabalhos neste processo. Estão entre eles a chamada “Cultura” e estrutura
organizacional ou da empresa, normas governamentais ou do setor, o sistema de autorização do trabalho da
empresa, a tolerância a risco das partes interessadas, entre outros.
2 – Termo de abertura do projeto
3 – Documentação dos Requisitos do Projeto
4 – Plano de gerenciamento do escopo

1 - Análise de produtos - A análise do produto é fundamental pois é a técnica que proporciona o entendimento
do produto que resultará em seu detalhamento. Para cada tipo de projeto (construção, desenvolvimento de
sistema, reorganização organizacional...) um ou mais métodos já são usualmente aceitos para transformar os
objetivos do projeto em requisitos e entregas tangíveis. Decomposição do produto, análise de sistemas,
engenharia de sistemas, engenharia de valor, análise de valor e análise funcional são algumas das muitas
técnicas que podem ser aplicadas para um melhor entendimento do escopo do produto e do projeto.
2 – Identificação de alternativas - A identificação de alternativas é uma técnica usada para gerar diferentes
abordagens para a execução e realização do trabalho de um projeto. Frequentemente, a equipe do projeto
percebe que a identificação de alternativas proporciona melhores escolhas para o projeto. Diversas técnicas
de identificação de diferentes visões estão disponíveis para utilização. Algumas comumente utilizadas são:
✓ Brainstorming: método criativo de identificação de alternativas na qual de 4-12 pessoas são reunidas,
tomam conhecimento de um aspecto do projeto que serve de ponto de partida para a geração de
diferentes abordagens e, cada uma por vez, explicita sua visão sobre o tema. A ideia principal é a
geração de muitas abordagens e, para que isto ocorra, nenhuma das ideias explicitadas deve sofrer
qualquer tipo de crítica ou rejeição, uma vez que o interlocutor participante não deve ter sua
capacidade criativa diminuída. As ideias geradas devem ser documentadas para posterior análise.
✓ Pensamento Lateral: método mencionado por Edward de Bono em sua obra “Serious Creativity”,
baseia-se na procura pela resolução de problemas de maneira não ortodoxa, utilizando métodos
aparentemente ilógicos. Foi criado a partir de considerações sobre como os seres humanos podem,
através de percepções criativas, gerarem alternativas que os computadores, com suas lógicas
maravilhosas, não conseguiam. Das várias técnicas envolvendo o pensamento lateral, podemos
destacar a “provocação” aos integrantes da equipe, para fazê-los sair da linha natural de pensamento
lógico e o “questionamento dos paradigmas do projeto”, que envolve analisar diversos elementos que
compõem um cenário do projeto.
3 – Opinião Especializada - O conhecimento necessário para a formalização do detalhamento do escopo do
projeto pode envolver competências ausentes na equipe do projeto, de forma que cada projeto pode, ou não,
necessitar da presença de especialistas para serem utilizados durante o desenvolvimento da declaração do
escopo detalhada do projeto. São exemplos os consultores, as partes interessadas, incluindo clientes ou
patrocinadores; as associações profissionais e técnicas; os grupos da indústria; e os especialistas no assunto.
4 – Workshops - Conforme já apresentado, a participação dos principais atuantes na diversidade das
expectativas e áreas de especialização nestas sessões de trabalho ajuda a atingir um entendimento
interfuncional e comum dos objetivos do projeto e seus limites.
Saídas do processo
1 – Declaração do escopo do projeto - A declaração do escopo do projeto é o documento que, em detalhes,
descreve as entregas do projeto e o trabalho necessário para criar essas entregas, sendo a documentação
que servirá de base para tomada de decisões futuras no projeto e para confirmar ou desenvolver um
entendimento comum do escopo entre os principais interessados (stakeholders). Um planejamento mais
detalhado do projeto inclui o esforço necessário para a criação deste documento, que orienta o trabalho da
equipe do projeto durante a execução e fornece a linha de base para avaliar solicitações de mudanças ou
trabalho adicional, e verificar se estão contidos dentro ou fora (exclusões específicas) dos limites do escopo
do projeto.
A declaração do escopo detalhada do projeto inclui, direta ou indiretamente (referenciando outros
documentos), as seguintes informações:
✓ Objetivos do projeto. Descobrir os objetivos do projeto pode ser uma das atividades mais capciosas
do gerenciamento do projeto, pois não existem maneiras claras de fazê-lo, e a formalização dos
mesmos, com a descrição detalhada de cada objetivo, envolve mais percepção e experiência do que
metodologia. A identificação dos objetivos de um projeto comumente passa pela identificação dos
benefícios que o projeto proporcionará para a organização, a identificação do que o projeto fará para
suportar estes benefícios e quais os critérios que serão medidos para assegurar o atendimento destes
objetivos. O sucesso do projeto envolve satisfazer os objetivos identificados, que podem ser técnicos,
de negócios, custo, cronograma e qualidade. Os objetivos do projeto devem possuir metas (de custo,
cronograma, qualidade...), possuir atributos (como custo), uma métrica (como R$ Reais) e um valor
absoluto ou relativo.
✓ Descrição do escopo do produto. Descreve as características do produto ou serviço resultante do
projeto. A descrição do escopo do produto deve conter uma lista extensa com todas as características
deste produto. Caso os requisitos sejam muito extensos, estes podem compreender documento à
parte, e serem referenciados pela declaração do Escopo do projeto. Lembrar que a falta de
especificação significa dúvida na execução e no aceite do produto resultante do projeto, ou resulta
na entrega de um produto que não satisfaz o cliente do projeto. Essas características terão
normalmente menos detalhes nas fases iniciais e mais detalhes nas fases posteriores, conforme as
características do produto forem progressivamente elaboradas. Embora de conteúdo e forma
diferentes, as características do produto aqui descritas devem conter informações suficientes e serem
descritas com a clareza necessária para dar suporte à execução do projeto.
✓ Requisitos do projeto. Descreve as condições ou capacidades que devem ser atendidas ou possuídas
pelas entregas do projeto para satisfazer um contrato, norma, objetivos e especificações. Os
requisitos normalmente representam as necessidades, desejos e expectativas explicitadas pelas
partes interessadas.
✓ Limites do projeto. Descrições sobre o escopo que está incluído no projeto e descrições explícitas
sobre o que está fora do escopo (exclusões específicas).
✓ Entregas do projeto. As entregas incluem tanto as saídas que compõem o produto ou serviço do
projeto, como resultados auxiliares, como documentação e relatórios de gerenciamento de projetos.
Dependendo da declaração do escopo do projeto, as entregas podem ser descritas de forma
sumarizada ou detalhada.
✓ Critérios de aceitação de produtos. Descreve o processo e os critérios para aceitar os produtos
terminados, de forma que os mesmos não sejam definidos no momento da execução do projeto.
✓ Restrições do projeto. Lista e descreve as restrições, que são fatores que limitarão as opções da
equipe do projeto, referentes ao escopo do projeto. Quando um projeto é desenvolvido sob contrato,
as cláusulas contratuais serão geralmente restrições. Importante no conceito de Restrição: uma
restrição é encarada como uma verdade intransponível, da qual o projeto não poderá fugir e cujo
gerente de projetos deve perceber os impactos que trazem para o projeto como um todo.
✓ Premissas do projeto. As premissas são hipóteses assumidas para com o projeto. Não são verdades
absolutas. Uma premissa pode se mostrar certa ou errada, dada sua principal característica, que é a
incerteza de seu comportamento. Na declaração do escopo do projeto, são listadas as premissas
associadas ao escopo do projeto e os impactos associados a ela. Durante o planejamento, a equipe
do projeto identifica, documenta e valida as premissas. As premissas são progressivamente
descobertas, e é frequente existir na declaração do escopo do projeto mais premissas documentadas
do que as que foram documentadas nas fases iniciais do projeto.
✓ Organização inicial do projeto. São identificados os membros da equipe do projeto e as partes
interessadas. A organização do projeto também é documentada.
✓ Riscos iniciais definidos. Identifica os riscos conhecidos e que foram identificados nas fases iniciais
do projeto. Frequentemente, na declaração de escopo, são encontradas referências para os
documentos que são responsáveis pelo controle dos riscos do projeto.
✓ Marcos do cronograma. O cliente ou a organização executora podem identificar marcos e colocar
datas impostas nesses marcos do cronograma. Essas datas podem ser consideradas como restrições
do cronograma e são colocadas na declaração de escopo para fins informacionais apenas.
Frequentemente, na declaração de escopo são encontradas referências para os documentos que são
responsáveis pelo controle cronológico do projeto.
✓ Limitação de fundos. Descreve qualquer limitação dos recursos financeiros do projeto, uma limitação
do valor total ou uma limitação imposta em prazos especificados (marcos de limitações de recursos).
✓ Estimativa de custos. A declaração do escopo do projeto, por ser documento dos mais importantes
do gerenciamento do projeto, por vezes pode ter incluso em seu conteúdo informações referentes às
estimativas de custo do projeto. Frequentemente, estas informações são estimativas e na declaração
do escopo tem uma referência para o documento que trata detalhadamente do custo do projeto. Para
projetos de informática, a estimativa de custos pode envolver a utilização de métricas específicas,
tais como pontos de função e COCOMO.
✓ Requisitos do gerenciamento de configuração do projeto. Descreve o nível de gerenciamento de
configuração e controle de mudanças que serão implementadas no projeto. Para projetos de
desenvolvimento de software, as informações podem incluir procedimentos para determinar e
controlar versões de software, considerações sobre mudanças na configuração, rastreabilidade de
informações e considerações sobre a condução de revisões de software.
✓ Especificações do projeto. Identifica os documentos de especificação com os quais o projeto deve
estar de acordo, podendo ser desde normas internas a até mesmo informações de mercado
consideradas relevantes. Tem direta relação com as informações provenientes dos ativos
organizacionais.
✓ Requisitos de aprovação. Identifica informações a serem consideradas para aprovação de
componentes do projeto, tais como entregas, documentos e trabalho do projeto.
2 – Documentos do projeto (atualizações) - Talvez seja necessário atualizar os documentos do projeto. Nesse
caso específico, podem ser atualizados: o registro dos envolvidos, os requisitos de documentação e os
requisitos matriz de rastreabilidade.
2.1.4. Criação da Estrutura Analítica do Projeto

A Estrutura Analítica do Projeto – EAP - é o documento que representa a decomposição hierárquica do escopo do
projeto em componentes menores, orientada a produtos entregáveis, de mais fácil gerenciamento, de modo a não
só aumentar a precisão nas estimativas de custo, tempo e recursos envolvidos, como também auxiliar na
determinação clara das responsabilidades de cada envolvido e responsável pelo escopo do projeto. Cada subdivisão
do escopo do projeto, representada por cada nível descendente da EAP, representa uma definição cada vez mais
detalhada do trabalho do projeto. Os componentes da EAP, que não necessitam mais serem subdivididos, por já
representarem componentes pequenos o suficiente para beneficiar as estimativas e a atribuição de responsabilidades,
são chamados de pacotes de trabalho. É “no pacote de trabalho que acontece a atividade do projeto e nele é possível
estimar custos, monitorar e controlar o trabalho planejado”. A EAP representa o trabalho especificado na declaração
do escopo do projeto atual aprovada, de modo que, se não está na declaração do escopo, não pode estar
representado na EAP.
1 – Ativos de processos organizacionais
2 – Condições ambientais da empresa
3 – Documentação dos Requisitos do Projeto
4 – Plano de gerenciamento do escopo do projeto
5 – Declaração do Escopo do Projeto

1 – Decomposição - A decomposição é a técnica de subdividir o escopo do projeto em componentes
menores e mais facilmente gerenciáveis, até que o trabalho do projeto esteja definido até o nível de pacote
de trabalho, definidos em detalhe suficiente para suportar o desenvolvimento das atividades do projeto
(planejar, executar, controlar e encerrar). Esta decomposição pode basear-se nas entregas do projeto
documentadas na declaração do escopo do projeto. Também é representado na EAP o esforço de
gerenciamento do projeto, uma vez que este trabalho é inerente à existência do projeto e deve então ter
sua representação disponível na estrutura. O pacote de trabalho, por ser o elemento da estrutura analítica
do projeto que não está mais subdividido, é o ponto no qual o custo e o cronograma do trabalho podem
ser estimados de forma confiável. Projetos iguais podem ter EAPs diferentes. A EAP do projeto pode não
ser toda ela feita num mesmo instante, pois entregas futuras ou até mesmo subprojetos só terão suas
informações disponíveis em momentos posteriores. Nesse caso, a técnica utilizada é a chamada de
planejamento em ondas sucessivas ou planejamento iterativo evolutivo. Quanto mais decomposição uma
entrega tiver, maior será a capacidade de gerenciar e controlar o escopo representado. Porém, uma
excessiva decomposição pode ter como consequência o aumento improdutivo do esforço de
gerenciamento necessário para este controle, podendo ocasionar uma a ineficiência de recursos e uma
potencial diminuição na eficiência da realização do trabalho.
A decomposição do trabalho total do projeto normalmente envolve as seguintes atividades:
✓ Identificação das entregas e subprodutos do trabalho relacionado - Esta identificação pode ser
facilitada se as informações de escopo documentadas na declaração do escopo estiverem
escritas de forma clara e utilizando tópicos para a separação de informações correlatas. As
declarações de escopo que são escritas sem esta separação em muito dificultam o processo de
detalhamento e decomposição do escopo do projeto. As entregas e subprodutos nem sempre
são os elementos que fazem parte do primeiro nível de decomposição da EAP.
✓ Estruturação e organização da EAP - Esta estruturação e organização da EAP pode ocorrer de
várias formas. Um mesmo projeto, dependendo da equipe que o gerencia, pode criar EAPs com
organizações diferenciadas. A estruturação de um EAP comumente pode ser:
o Orientada ao Tempo (ciclo de vida do projeto), representando na EAP a cronologia de
acontecimentos do projeto. Desta forma, as entregas e decomposições são
representadas na estrutura, sendo colocadas da esquerda para a direita. Assim, os

primeiros acontecimentos do projeto estão mais à esquerda da estrutura e os trabalhos
do projeto que acontecerão na fases finais do projeto estão representados mais à direita
da estrutura.
o Orientada ao Custo, representando nos primeiros níveis da EAP os serviços ou tipos
de fornecimento que acontecerão durante o projeto.
o Orientada à Geografia do Projeto, representando nos primeiros níveis da EAP em que
o trabalho que representa o escopo do projeto será executado por seus participantes.
o Orientada aos Sistemas e Estruturas que naturalmente decompõem o produto que será
produzido pelo projeto.
o Orientada a áreas de responsabilidade, em que nos primeiros níveis da EAP as
responsabilidades são representadas e todo o escopo associado a cada um destes
elementos de responsabilidade faz parte de decomposições subsequentes.
✓ Decomposição dos níveis mais altos da EAP em componentes detalhados de nível mais baixo;
✓ Desenvolvimento e atribuição de códigos de identificação (code of accounts) aos componentes
da EAP. Cada elemento da EAP deve receber uma codificação única, unívoca, que a identifica
na EAP. Este código é importante e deve ser construído de forma a permitir que informações
como Custo possam ser sumarizadas de baixo para cima. Desta forma, o custo de uma entrega
é o somatório de custos dos elementos resultantes da decomposição desta entrega. Desta forma
chega-se ao custo do projeto.
✓ Verificar se o grau de decomposição do trabalho é necessário e suficiente. A decomposição
serve a um propósito, que é beneficiar as estimativas do projeto e auxiliar na identificação de
responsabilidades para com o escopo. Para cada elemento resultante da decomposição uma
verificação deve ser feita, uma vez que deve ser evitado o excesso de decomposições. Esta é a
chamada “regra do ser útil”. Esta verificação também deve investigar se os componentes de nível
mais baixo da EAP são os necessários e suficientes para o término das entregas de nível mais
alto correspondentes. Algumas outras verificações são:
o Verificar se durante a decomposição foi pensado que os pacotes de trabalho funcionam
como uma contribuição ao elemento que foi decomposto
o Verificar se aos componentes foram atribuídos nomes de simples reconhecimento e de
fácil relação com sua entrega relacionada
o Verificar se é possível a aplicação da regra de 8 horas ou 80 horas
o Verificar a possibilidade da aplicação da regra do período de Avaliação: nenhum pacote
de trabalho deve ser maior que a distância de tempo que separa dois marcos de revisão
de escopo do projeto. Estes marcos podem ser considerados desde reuniões de
verificação até marcos (milestones) constantes no cronograma.
Saídas do processo
1 – Linha de Base do Escopo - O escopo é a versão aprovada de uma declaração do escopo, da Estrutura
Analítica do Projeto (EAP) e do dicionário da EAP. Só pode ser alterado por meio de mudança formal pelos
processos de controle, e é usado como uma base para a comparação. Uma vez aprovado, ele é alterado
apenas por meio do controle de mudança formal. Os componentes da linha de base do escopo incluem:
✓ Declaração do escopo do projeto;
✓ EAP – que é uma decomposição hierárquica do escopo total do trabalho a ser realizado para atingir
os objetivos do projeto e criar os resultados necessários. A EAP deve ser finalizada pelo
estabelecimento do controle das contas dos pacotes de trabalho com um identificador exclusivo de
um código de contas. Estes identificadores fornecem uma estrutura para a somatória hierárquica dos
custos, cronograma e informações sobre recursos. Uma conta de controle é um ponto de controle de
gestão em que escopo, orçamento, custo real e programação são integrados e comparados com o
valor de ganho de desempenho durante o processo de medição. Contas de controle são colocadas
em pontos de gerenciamento selecionados na EAP. Cada conta de controle pode incluir um ou mais
pacotes de trabalho, mas cada um dos pacotes de trabalho deve ser associado a apenas uma conta
de controle.
✓ Dicionário da EAP. O dicionário da EAP é um documento que fornece informações detalhadas das
entregas, atividades, programação e informações sobre cada um de seus componentes. Deve conter:
Código identificador de conta, Descrição de trabalho, Premissas e Restrições, Organização
Responsável, Lista de Marcos do Cronograma, Atividades do Cronograma Associado, Recursos
Necessários, Estimativas de Custos, Requisitos de Qualidade, Critérios de Aceitação, Referências
Técnicas e Informações sobre acertos entre as partes.
2 - Atualizações dos Documentos de projetos - os documentos do projeto, que podem ser atualizados por conta
do desenvolvimento dessa atividade, incluem, mas a ela não estão limitados, a documentação de requisitos e
do projeto.
2.1.5. Os Processos de Controle do Gerenciamento do Escopo

Os processos relativos a esses e outros controles, incluindo os das outras áreas de conhecimento que serão tratadas
ao longo deste trabalho, serão abordados de forma integrada em um capítulo especial de Monitoramento e Controle,
mas podemos destacar e adiantar aqui:
✓ Verificar ou Validar o Escopo - Processo da formalização do aceite do escopo do projeto por todos os
envolvidos.
✓ Controlar o Escopo – Processo que apoia, sabidamente, a dinâmica dos projetos, regras e procedimentos
que são construídos, tendo por objetivo controlar quando e como as mudanças podem ocorrer. As
mudanças controladas são frequentemente chamadas de aumento do escopo do projeto e têm como
principais objetivos verificar os fatores que criam mudanças, para assegurar que essas sejam analisadas,
discutidas e acordadas antes da implementação das mesmas. Sem gerenciamento de alteração formal é
impossível garantir que as alterações de escopo propostas estejam coerentes com os objetivos
organizacionais que influenciaram e motivaram o surgimento e aprovação do projeto.
2.2. Uso da Ferramenta - Escopo

2.2.1. Criação da EAP
2.2.1.1. Uso de Tables e Views (Modos)
Antes de darmos prosseguimento ao processo de criação do nosso arquivo, devemos alertar sobre a importância de
criarmos modos específicos de trabalho para inclusão e visualização de informações na ferramenta, de modo que a
mesma seja otimizada na função de atender nossas necessidades.
O MS Project é um processador de informações, um banco de dados que deve ser alimentado com informações de
alto valor para que seus resultados também sejam de alto valor. Estes resultados podem ser apresentados de
diferentes formas, utilizando-se diferentes VIEWS, possíveis de serem acessadas na aba view, ícone Other Views,
opção More Views. Chamaremos as views de modos.
Em More Views, é possível verificar todos os modos

disponíveis para este arquivo. Entendendo que ao
longo do ciclo de vida de um projeto a equipe de
planejamento necessita de diferentes formas de
analisar as informações contidas no arquivo, a
ferramenta já está pré-configurada com alguns
modos quando chega ao usuário.
Entendemos que os modos pré-configurados são

importantes a título de exemplo, mas reafirmamos
a necessidade de expansão deste acervo e de cada
usuário criar seus modos de acordo com suas
necessidades específicas.
Cada modo é formado pela composição de 5 elementos

principais:
SCREEN
Forma na qual as informações serão apresentadas. Na
versão 2013 da ferramenta existem 16 formas diferentes
entre screens de atividade e de recurso.
A screen mais conhecida é a Gantt Chart, em que as

informações são apresentadas na forma de tabela à
esquerda, e utilizando-se barras à direita.
TABLE
Seleção de quais dados serão apresentados no modo. Os campos devem ser escolhidos a partir de uma lista de
características das Atividades ou dos Recursos.
GROUP
É possível agrupar os elementos do projeto, sejam eles marcos, atividades, produtos ou recursos; segundo critérios
específicos criados pelo usuário. Pode-se, por exemplo, agrupar as atividades pelos responsáveis, pela execução,
por recursos por centro de custo, etc.
FILTER
Podemos filtrar as informações apresentadas no modo segundo critérios específicos, de forma a atender às nossas
necessidades. Como exemplo, podemos citar a criação de um filtro que somente permita a apresentação dos marcos
do projeto. Neste exemplo, o filtro bloqueia a exibição das linhas referentes às atividades e aos produtos.
É uma função muito útil da ferramenta, que utilizaremos diversas vezes ao longo do livro, para atender nossas
necessidades.
SORT
Caracteriza a ordem na qual as linhas serão apresentadas. Podemos encontrar as opções referentes a sua
configuração na Aba View.
Voltaremos a esta funcionalidade da

ferramenta em momento adequado do
nosso livro, quando seu uso atende às
melhores práticas de gestão.
Característica importante dos modos é a de armazenarem as configurações dos elementos que os caracterizam.
Assim, ao selecionarmos uma combinação de screen, table, group, filter e sort, podemos resgatar o modo da forma
como o configuramos no futuro, mesmo após selecionar outro modo, ao encerrar o aplicativo MS Project ou desligar
a máquina.
Criação de um novo modo: Step 01 - WBS
Apresentaremos agora o processo de criação de um modo próprio para elaboração da EAP.

Primeiro, temos a criação da tabela que atenda às nossas necessidades, e somente às nossas necessidades. Um
erro comum consiste na elaboração de Estruturas Analíticas do Projeto utilizando tabelas que apresentam campos
desnecessários, poluindo visualmente o ambiente de trabalho e divergindo a atenção dos envolvidos nesta atividade.
Criação da tabela
Para iniciar, vamos selecionar a aba View, depois em Tables. Na lista apresentada, podemos ver algumas tabelas já
disponibilizadas pela ferramenta. Como nenhuma delas atende a nossa necessidade, vamos selecionar a opção More
Tables...
Uma pequena janela é apresentada, mostrando todas as tabelas disponíveis no arquivo.
Atente para a opção de marcar, “Task” ou “Resource”. A lista de tabelas apresentadas será referente à seleção
realizada. É comum os recém chegados à ferramenta fazerem confusão com os dois tipos de tabela. Seguindo a
metodologia proposta, apresentaremos as tabelas
de recurso em momento oportuno do livro, mas a
distinção deve ficar clara desde já. Tabelas tipo Task
guardam informações sobre tarefas (e produtos, e
marcos), como seu nome e duração, enquanto que
tabelas tipo Resource armazenam informações
referentes aos recursos, como seus nomes, valor
cobrado por hora de serviço ou quantidades
máximas disponíveis. Existem campos de mesmo
nome para tabelas Tasks e Resource, mas são
definitivamente conjuntos de dados diferentes.
Na janela More Tables, podemos criar uma tabela

nova, editar uma tabela existente ou copiar uma
tabela existente para criar uma nova. Podemos
ainda abrir o Organizer, que é detalhado no anexo
C.
Vamos criar uma tabela nova para desenvolvimento da EAP do nosso projeto, então vamos selecionar a opção New...
Nos é apresentada a tela Table Definition, que analisamos abaixo:
1. Nome da tabela
Recomendamos que o usuário nomeie a tabela da mesma forma como nomeará o modo no qual será
aplicada, para facilitar a associação.
Recomendamos ainda que cada modo tenha sua própria tabela, mesmo que cópia de uma outra, para que a
edição de uma tabela durante o trabalho não afete outras. Nomeamos nossa tabela como Step 01 – WBS.
2. Show in menu
Quando marcada, a tabela fica destacada na lista de tabelas anteriores à opção more tables, facilitando-nos o
seu acesso.
3. Field Name
Seleção dos campos a serem apresentados na tabela. A ordem de escolha dos campos é tal que o primeiro será
o elemento mais à esquerda, o segundo estará à direita deste, e assim sucessivamente.
Vamos escolher os campos ID, Indicators, WBS e Name para a tabela a ser utilizada no nosso primeiro modo,
como mostrado na imagem anterior.
ID – Número da linha contado de forma crescente, de cima para baixo.
Indicators – Indicadores gráficos na forma de ícones utilizados pela ferramenta para informar
características desta linha do projeto.
WBS – Código utilizado para identificar os elementos da EAP e possível de ser customizado na
ferramenta.
Name – Nome do elemento representado pelas linhas do projeto.
4. Configurações visuais
Configurações de espessura da coluna, alinhamento e disposição do texto, e definição de título para os campos.
Como utilizamos o software em inglês, é interessante criarmos títulos para elementos cuja identificação possa
ser dificultada para aqueles que não dominam o idioma.
Um título é um nome dado ao campo para uma dada tabela; é o nome apresentado na cabeçalho. Exemplo:
Utilizando o mesmo campo em outra tabela, ele pode ter outro título, ou não ter título, caso em que é mostrado
com seu nome padrão.
5. Date format
É possível escolher o formato pelo qual os campos tipo data (date) apresentarão informações em cada tabela
criada. Esta configuração sobrepõe a configuração geral, efetuada em FILE>Options>General.
6. Row height
Definição da altura das linhas.
7. Outras configurações
Lock first column

Quando marcada, torna a edição da primeira coluna indisponível. Recomendamos deixar marcada, pois
além do seu uso direto, de não permitir edição dos elementos da primeira linha, torna disponível um atalho
para a janela tables, ao se clicar com o botão direito na intercessão da primeira linha com a linha de
cabeçalhos.
Auto-adjust header row Heights

Caso marcada, ajusta automaticamente a altura da linha de cabeçalho para ser a menor possível, e ainda
acomodar o texto das células. Recomendamos deixar marcada.
Show ‘Add New Column’ interface

Recomendamos que seja deixada desmarcada, para não utilizar espaço desnecessário na visualização da
tabela.
Terminando de criar a tabela, clicamos em OK, para fechar a janela salvando nossas configurações.
Na janela More Tables, o botão Apply altera o modo atual para usar a tabela selecionada. Dessa forma, não
clicaremos nesta opção, já que ainda estamos por criar nosso modo customizado.
Criação do modo
Criada a tabela, vamos configurar agora o modo que a utilizará. Ainda na aba View, selecionamos a opção Other
Views e em seguida More Views...
A tela More Views é apresentada, e podemos perceber que guarda muita semelhança com a tela More Tables. Não
existe na tela More Views opção de selecionar os elementos
tipo Tasks ou Resources, sendo apresentados todos os modos
ao mesmo tempo, em ordem alfabética.
Vamos selecionar a opção New.., para criação de um modo

novo.
Somos perguntados se desejamos criar um modo simples ou

composto (Single ou Combination)
Os modos compostos serão tratados nos capítulos seguintes. Para criação da EAP, desejamos a criação de um modo
simples, e essa é portanto a nossa escolha.
Selecionando a opção Single view e clicando em OK, somos levados para a tela View Definition, na qual devemos
compor nosso modo escolhendo o seu nome, Screen, Table, Group e Filter.
▪ Selecionamos o nome idêntico ao da tabela utilizada, conforme já citado, para facilitar a referência;
▪ Escolhemos a screen task sheet, na qual é exibida somente a tabela construída, sem nenhum apoio visual,
que nesse momento não colaboraria com o nosso trabalho;
▪ Selecionamos a tabela criada para este modo;
▪ Não usamos grupos ou filtros, e portanto deixamos as opções No Group e All Tasks marcadas,
respectivamente.
A opção Highlight filter será apresentada ao tratarmos dos filtros da ferramenta, e recomendamos que permaneça
desmarcada por enquanto. Recomendamos, também, deixar a opção Show in menu marcada para facilitar o acesso
a essa view no futuro. Clicando em OK criamos o modo conforme configurado.
Posteriormente, é possível editar as características do modo, alterando seu nome, sua tabela,
incluindo ou alterando grupos e filtros; mas, uma vez criado, não é possível alterar sua screen.
Caso tivéssemos errado na escolha da screen, deveríamos deletar o modo pelo organizer (Anexo
B) e criar outro.
Na tela More Views, podemos selecionar o modo criado e clicar em Apply para torná-lo ativo no programa. Como
curiosidade, após efetuar alguma alteração na lista de modos do programa, o botão Cancel, ao lado do botão Apply,
se transforma em Close.
2.2.1.2. Definição da EAP
Criado o ambiente de trabalho otimizado para definição da EAP, vamos iniciar o processo de criação da estrutura em
si.
Seleção do modo
O primeiro passo é a seleção do modo Step 01 – WBS, caso ele já não esteja selecionado. Para ativação de um
modo, temos algumas opções.
1. Pela aba View
Na aba View, os modos disponíveis para seleção estão organizados segundo dois critérios. Primeiramente, existe a
divisão de modos do tipo Task (esquerda) e modos do tipo resource (direita). Em seguida, os modos estão agrupados
pela screen utilizada.
Dessa forma, temos um ícone para listar os modos tipo Gantt Chart, Tipo Task Usage, e assim por diante. Segundo
um critério da ferramenta, algumas screens não possuem ícone próprio, e estão dentro do conjunto outros modos
(Other Views), sendo este o caso dos views tipo Task Sheet, que utilizamos para criar o views Step 01 – WBS.
Todos os ícones de agrupamento de views apresentam as mesmas opções, para cuja apresentação utilizamos as
opções de Other Views (Task):
Custom – lista dos modos criados pelo usuário;
Built-in – lista dos modos padrão, aqueles já configurados pela ferramenta. Esta
lista permanece inalterada mesmo que o usuário edite os modos.
Reset to Default – caso o modo selecionado seja um modo built-in, é possível

restaurá-lo à sua configuração inicial (“de fábrica”) por esta opção.
Save View... – É possível criar uma cópia do modo atual com esta opção, tal
como a função ‘salvar como’ do software.
More Views – Abre a tela More Views, já apresentada.
Podemos então selecionar o nosso modo Step 01 – WBS indo em Other Views e clicando no seu nome, dentro do
conjunto custom.
➔ Somente serão apresentados nesta lista os modos cuja opção Show in menu estiver marcada.
2. Em More Views
Como dito acima, qualquer um dos ícones que agrupam os modos apresenta como última opção o botão More Views...
, onde nos é apresentada a lista de todos os modos disponíveis para este projeto.
Podemos então selecionar o modo Step 01 – WBS e clicar em Apply.
3. Pelo atalho da barra à

esquerda
Clicando com o botão direito do mouse na

área mais à esquerda da área de trabalho,
representada por uma barra branca (ou
cinza, dependendo das configurações do
usuário), onde é possível ler o nome do
modo ativo no sistema, recebemos uma
lista de todos os modos que possuem a
opção Show in menu marcada.
Os modos estão divididos entre tipo Task e

tipo Resource por uma linha horizontal, e
no final da lista encontramos a opção More
Views... .
Podemos encontrar nosso modo Step 01 –

WBS listado entre as opções exibidas.
Independente da forma escolhida, selecionamos o modo de trabalho criado para inserirmos os dados da EAP.
Inserção de dados
Na seção 2.1, apresentamos os conceitos e melhores práticas para criação da EAP. Após o estudo deste material e
preparação do ambiente de trabalho específico, vamos entrar com os dados na ferramenta, lembrando que a
qualidade dos seus resultados será diretamente proporcional à qualidade das informações inseridas.
Podemos inserir o nome dos produtos que compõem a EAP direta ou indiretamente. Na forma indireta, a informação
é preparada em outros softwares e posteriormente importada ou simplesmente colada (ctrl + V) no MS Project 2013.
Daremos ênfase à criação da

EAP na própria ferramenta, mas
destacamos o software WBS
Chart Pro2. Quando utilizado, a
atividade de preparar a
estruturação do projeto e incluir
e retirar pacotes de trabalho e
produtos se torna mais amigável
e mais fácil. Esse aplicativo,
desenvolvido pela
www.criticaltools.com, é
fornecido como versão de
avaliação e permite a montagem
da estrutura de trabalho de
forma simples e eficaz.
Outra ferramenta muito utilizada

para geração de conteúdo que
posteriormente é transportado
para o MS Project é o MS Excel.
Isso se deve à maior
disponibilidade de acesso e
conhecimento do gerenciador de planilhas, já que se trata de aplicativo padrão nos pacotes Office. O conteúdo das
células de Excel é facilmente importado com os comandos copiar/colar. Mais sobre a interação do MS Excel com o
MS Project no anexo E.
Para inserir os elementos da EAP no nosso modo Step 01 – WBS, basta-nos escrever
seus nomes no campo name. Cada linha representa um elemento da EAP: produto,
pacote de trabalho ou pacote de planejamento.
Ao lado vemos o resultado preliminar da listagem dos elementos da EAP para o nosso
"projeto exemplo", que nos acompanhará ao longo do curso.
Sendo necessário incluir um elemento entre os já criados, devemos inserir uma

linha em branco. Para isso, podemos:
➔ Clicar no ícone Task, na aba Task (grupo insert);
➔ Clicar com o botão direito na linha inferior no ponto em que deseja incluir a nova, e
acessar a opção Insert Task;
➔ Pressionar a tecla Insert do teclado.
2
Esse software, distribuído na forma de demonstração da empresa Critial Tools, www.criticaltools.com é muito útil para a construção da WBS
de um projeto, pois permite mais facilmente a visualização do conceito de quebra do trabalho.
Para modificar a posição de um elemento da EAP, alterando a posição de uma linha inteira da tabela, basta-nos
selecionar toda a linha (somente possível através dos elementos da primeira coluna, caso a tabela esteja com a opção
lock first column marcada.) e em seguida arrastá-la para o local desejado. Note que o ponteiro do mouse é modificado
nos dois momentos. Na seleção da linha, assume o formato de uma seta que aponta para a direita, e, na
movimentação de setas, que apontam para as quatro direções.
Aproveitamos este momento para verificar que a estrutura das tabelas podem ser modificadas diretamente no
ambiente de trabalho da ferramenta. Podemos mudar as colunas (campos da tabela) de posição, alterar sua largura,
incluir e remover colunas da tabela.
Para mudar as colunas de posição, realizamos procedimento análogo à alteração da posição das linhas da tabela,
selecionando uma única coluna por inteiro, em seu cabeçalho, e depois arrastando-a para o local desejado;
Para incluir novas colunas (campos), basta-nos clicar com o botão direito do mouse no cabeçalho da coluna à direita
do local onde desejamos incluir uma nova, e selecionar a opção Insert Column;
Para remover ou esconder uma coluna, podemos clicar com o botão direito do mouse no seu cabeçalho e selecionar
a opção Hide Column, ou simplesmente selecionar a coluna e pressionar a tecla Del (Delete) do teclado.
Por se tratar de um banco de dados, não estamos de fato deletando o campo ou suas informações,
apenas ocultando sua apresentação.
Todas as alterações realizadas em tabelas, na área de trabalho, são salvas e armazenadas como seus parâmetros,
da mesma forma como o seriam caso as alterações fossem realizadas através da janela Table Definition.
Estruturação da EAP
Seguindo os procedimentos de trabalhos que contemplam as melhores práticas, neste momento devemos organizar
a nossa EAP, para que, de fato, se torne uma estrutura. Apresentamos abaixo três maneiras de indentar os elementos
da EAP, ou seja, alterar o nível dos elementos da EAP de forma lógica para representar as subdivisões do escopo do
projeto.
1. Botões Indent Task
Encontrados na aba Task, podem ser utilizados para levar os

elementos para a direita ou esquerda, conforme o botão escolhido,
formando assim a estrutura desejada.
Estes botões podem também ser acessados clicando-se com o botão direito do mouse em qualquer célula da linha
que se deseje alterar a posição na estrutura.
2. Seleção do mouse
Posicionando-se o mouse no espaço imediatamente anterior ao texto da coluna name, o curso se altera para setas
que apontam para a direita e esquerda. É possível alterar a posição da linha na estrutura arrastando-a a partir deste
ponto, com o mouse.
3. Atalho ALT + SHIFT + ( ➔ ou  )

Por fim, podemos realizar a indentação de maneira muito prática através deste atalho. Para isso basta-nos selecionar
o conjunto de elementos cuja posição na estrutura desejamos mover, e pressionar as teclas ALT + SHIFT + DIREITA
ou ESQUERDA (setas direcionais), conforme a alteração desejada. As teclas devem ser pressionadas nessa ordem,
e liberadas somente após a última ter sido pressionada.
Recomendamos a utilização deste atalho simples, que torna o processo de transferência da EAP para a ferramenta
ou o desenvolvimento da Estrutura mais ágil e produtivo.
4. Campo Outline level

A indentação pode ser realizada pelo campo Outline Level, inserindo o número equivalente à posição na estrutura de
cada elemento da EAP. As imagens abaixo elucidarão o uso do campo:
Somente recomendamos esta utilização em casos específicos, não sendo de ordinário a mais produtiva pra trabalho.
O resultado da indentação dos elementos anteriormente listados para a EAP do nosso "projeto exemplo" está abaixo.
É importante comentarmos duas características de visualização da Estrutura.
Primeiramente, identificamos triângulos do lado esquerdo dos elementos que representam os produtos do nosso
projeto.
Esses triângulos podem ser clicados para

exibir ou suprimir o conjunto de elementos
que estão subordinados ao produto.
Repare, na imagem ao lado, que a

posição e a cor do triângulo se alteram de
acordo com o estado (expandido ou
suprimido).
Outra útil funcionalidade que colabora com a visualização da Estrutura é a

opção Outline, encontrada na aba view.
Nesta opção encontramos a possibilidade de suprimir ou exibir

simultaneamente um conjunto de elementos (que tenham sido selecionados
antes de pressionarmos estas opções), ou escolher um nível específico
para que a estrutura seja exibida até este.
Tudo apresentado até aqui pode ser executado no nosso modo Step 01 –
WBS, criado especificamente para o desenvolvimento da Estrutura
Analítica do Projeto. Nos próximos itens, continuaremos o processo de
desenvolvimento do nosso projeto modelo, apresentando novas funções da
ferramenta para desenvolvimento dos modos que serão utilizados para
documentar a nossa EAP.
2.2.2. Documentação da EAP

2.2.2.1. Uso de Custom Fields
O próximo modo que criaremos terá o objetivo de documentar a EAP do nosso projeto. Para isso
usaremos campos padrão da ferramenta, como fizemos até o momento; e para melhor adaptar o
modelo do projeto às nossas necessidades, faremos uso dos campos customizáveis (Custom Fields).
Os campos customizáveis dão liberdade ao usuário de inserir no programa os mais diversos tipos de
informação. Seus principais usos, além da documentação, é ser parâmetro para a criação de grupos e
filtros do projeto. Podemos citar como características gerais dos campos personalizados:
▪ Existem 9 tipos, de acordo com a natureza do valor armazenado em suas células;
▪ Existem em número limitado;
▪ Podem ser renomeados;
▪ Seus valores podem ser calculados por fórmulas;
▪ Podem apresentar indicadores gráficos baseado em regras pré-definidas, no lugar do seu valor em
caracteres.
Existem por exemplo 30 campos do tipo Text. Cada um deles pode ser renomeado para a melhor identificação do
conteúdo que armazena. Em um dado projeto, poderíamos tomar o campo Text1, renomear para “Cidade” e inserir
em cada célula desta coluna referente às atividades do projeto a informação da cidade onde é executada.
O apresentado acima refere-se a custom fields da

categoria task, mas existem nos mesmos tipos
características e quantidades para uso em tabelas do
tipo resource. É importante o usuário atentar para este
fato, sendo comum o engano de supor que se tratam
dos mesmos campos, o text1 task e o text1 resource,
pois possuem o mesmo nome padrão, quando na
verdade são dois campos distintos.
Podemos acessar a tela de nome Custom Fields, onde

realizamos todas as configurações pertinentes, de duas
maneiras.
1. Na aba project, botão Custom Fields;
2. Clicando com o botão direito no cabeçalho de

qualquer coluna, e escolhendo a opção
Custom Fields.
Na tela apresentada, podemos ver as configurações dos

aspectos gerais citados acima, mas nesse momento
vamos nos ater à preparação dos campos para uso em
nossa necessidade atual: a documentação da EAP.
Prepararemos os campos do tipo texto para que possam receber valores dos níveis organizacionais a que os
elementos da nossa EAP estão subordinados. Como apresentado na seção 2.1, este uso se faz importante para os
processos de comunicação, gerenciamento das partes interessadas (stakeholders), controle e documentação geral
do projeto.
Para acessar os campos do tipo texto, na tela custom fields, selecionamos em type a opção text. Existem 30 tipos de
campos customizáveis do tipo texto para serem usados nas tabelas tipo task, e faremos uso de três desses campos
para representar os três primeiros níveis da nossa OBS (Organizational breakdow structure).
Selecionamos os três últimos campos disponíveis (text28, text29 e text30) como forma de protegermos nossas
informações. Com a experiência, percebemos que usuários desatentos que utilizam os campos livres antes de
verificar se já possuem informações armazenadas fazem uso dos primeiros elementos.
Faremos agora a renomeação dos campos, que pode

ser realizada:
1. Selecionando o campo e clicando no botão
Rename...
2. Selecionando o campo e pressionando a tecla
F2 do teclado.
3. Dando um duplo clique no campo.
Na primeira opção, uma pequena janela é apresentada,

na qual podemos inserir o novo nome do campo; na
segunda e terceira opções editamos o nome do campo diretamente na tela Custom Fields.
Diferente dos outros campos da ferramenta, aos quais podemos dar títulos em nossas tabelas para atender alguma
necessidade de identificação, os campos customizáveis podem também ser renomeados, passando o novo nome a
ser exibido em qualquer tabela na qual é inserido (a menos que receba título). Podem ainda ser procurados na lista
de pesquisa de campos, tanto pelo seu novo nome, quanto pelo nome padrão.
Renomear os custom fields que estejam sendo utilizados, assim como manter registro e documentação atualizada, é
extremamente recomendado para que o arquivo do projeto possa ser utilizado por mais de um usuário, de forma clara
e sem o risco de perda de informação.
2.2.2.2. Configuração do Ambiente para Documentação da EAP
Criaremos neste momento um modo para trabalharmos a documentação da nossa EAP. A criação de ambientes de
trabalho específicos para cada atividade faz parte da proposta de procedimento de elaboração do arquivo de projeto
na ferramenta MS Project. Por esse motivo, apresentaremos diversos modos para cada etapa da vida do projeto, que,
quando preparados antecipadamente, são utilizados como ativos das organizações para aumento da produtividade
da equipe de planejamento e controle.
Step 02 - Documentação da EAP
Utilizando o procedimento de criação de uma nova tabela do tipo Task, na aba view, selecionamos a opção tables e
em seguida more tables. Clicando em New, nos é apresentada a tela table definition, onde selecionamos os campos
ID, indicators, WBS, name, notes, contact (com títulos conforme imagem abaixo), Nível ORG 1(Text28), Nível ORG 2
( Text29 ), Nível ORG 3 ( Text30 ). Nomeamos esta tabela como Step 02 - Documentação da EAP.
De forma semelhante ao realizado para o Step 01 - WBS, criamos o modo Step 02 - Documentação da EAP.
Selecionamos a aba view / Other Views / more views / New... / Single view. Definimos o modo como a imagem abaixo:
Aplicando o modo Step 02 - Documentação da EAP como ativo, podemos iniciar o processo de documentação da
EAP.
2.2.2.3. Codificação da EAP (WBS Code)
Ao realizarmos a indentação dos elementos da EAP, podemos observar que o campo WBS, que representa o código
da EAP, se atualiza para exibir a relação de " pais e filhos " entre os elementos, e a posição em que estão listados no
nosso programa.
Este código é importante como primeira documentação da EAP, sendo consideradas melhores práticas o seu registro
formal para uso em relatórios e outros documentos, precedendo o nome dos elementos da EAP, para garantia de
entendimento único entre os envolvidos no projeto.
A forma padrão desde campo é a apresentação de números separados por pontos.

Podemos, no entanto, customizar esta regra para atender nossas necessidades
específicas.
Na aba Project, encontramos o ícone WBS, que apresenta as opções Definir Código
(Define Code...) e Renumerar (Renumber).
Na opção Definir Código, encontramos a tela WBS

Code Definition, reproduzida ao lado, onde existe a
possibilidade de customizar o código da EAP, criando
prefixo para os elementos e definindo o padrão da
sequência.
Quanto às opções Generate WBS code for new task e

Verify uniqueness of new WBS codes, recomendamos
que ambas fiquem marcadas.
A primeira faz com que novos elementos do projeto

(produtos, atividades e marcos) recebam automaticamente o seu código da EAP.
A segunda garante que os códigos da EAP sejam únicos, importante para a documentação do projeto, conforme já
comentado.
2.2.2.4. Dicionário da EAP (Notes)
Deve incluir as descrições de cada subproduto, de cada pacote de trabalho e outras informações do planejamento,
como prazos, orçamento e a responsabilidade organizacional. Na EAP, pecar por omissão ou por zelo excessivo traz
consequências desagradáveis para o projeto, mas documentar o escopo de forma eficiente e detalhado reduz em
muito o custo das alterações, sendo esse custo significativamente menor se identificado e corrigido nas etapas de
planejamento, em contraste aos realizados na etapa de execução do plano do projeto. Essa informação pode ser
armazenada dentro de um dos campos da tabela Task: o campo “Notes”, que na nossa tabela recebeu o nome de
“Dicionário da EAP”.
A importância do dicionário da EAP na documentação do projeto foi apresentada na seção 2.1. Reforçamos aqui a
real necessidade de investimento de tempo nesta etapa para reduzir os riscos do empreendimento.
O texto pode ser digitado diretamente nas células da coluna Notes, e as informações ficam disponíveis na mesma
tela do item da EAP. Nesse caso só será possível introduzir dados tipo texto, limitado ao não uso de múltiplas linhas,
conforme mostrado no comum erro abaixo:
Dessa forma, recomendamos que o dicionário da EAP seja inserido através da aba Notes da tela Task Information,
possível de ser acessada através das opções a seguir:
1. Um duplo clique na linha correspondente ao

produto “entregável” ou pacote de trabalho
abre uma tela específica para inclusão de
dados nos campos do registro da tabela Task.
Esse formulário tem o objetivo de agrupar parte
desses inúmeros campos referentes ao
planejamento e controle por classe. Na guia de
“NOTES” é conveniente observar que o campo
está preparado para receber informações do
tipo RTF – Rich Text Format, onde é possível
colocar não apenas textos, mas também
objetos como “arquivos”, fotos, sons etc. Nesse
local podemos incluir o texto dos documentos
referenciados, seu arquivo completo, suas
referências para localização entre outras
informações. Quando se fecha essa tela, as informações que aparecem na planilha de dados se restringem
apenas à parte de texto;
2. Através da barra de ferramentas no

ícone que representa um “post it”
amarelo;
3. Na linha correspondente ao produto “entregável” ou pacote de trabalho, em

que pressionamos simultaneamente “Shift+F2” e localizamos a aba “Notes”;
4. Com o uso do botão direito do mouse sobre a linha.
Note que na coluna indicators, um ícone de bloco de notas amarelo indica as linhas que receberam informação
nos seus campos Notes. Passando o mouse sobre esses ícones, é possível ler parte do conteúdo.
Atenção: O uso desse espaço para a inclusão de informações descritivas do trabalho é muito
útil e conveniente, porém vamos observar que o arquivo passa a ficar maior e muitas vezes
compromete o desempenho do sistema.
2.2.2.5. Vínculo com documentação externa (Hyperlink)
Continuando com a documentação da nossa EAP, vimos na introdução teórica que existem diversos
documentos cuja criação é necessária para o planejamento do projeto. Incluir todos estes documentos no
campo Notes da ferramenta tornará o arquivo demasiado grande, podendo comprometer o desempenho do
mesmo. É, no entanto, necessário que esses documentos sejam referenciados e vinculados de alguma
forma aos arquivos de planejamento, e, para isso, faremos uso da função hyperlink.
Recomendamos que ao menos o documento Registro das Especificações ou a Declaração do Escopo do

Projeto sejam vinculados ao projeto desta maneira. Para selecionar o alvo do hyperlink, basta-nos clicar
com o botão direito do mouse no elemento da EAP mais conveniente e selecionar a última opção
apresentada, Hyperlink, como mostrado na imagem anterior.
Esse procedimento pode ser realizado também selecionando a linha e pressionando as teclas Ctrl + K
O uso de hyperlink apresenta ainda como benefício o fato de tornar possível o vínculo com páginas da
internet, documentos e arquivos armazenados ou outra máquina acessados através de rede local. Por
serem dois arquivos separados, o do projeto e o vinculado, qualquer alteração ou atualização no arquivo
vinculado fica imediatamente disponível no projeto.
 Responsável (Contact)
O campo contact, renomeado para Responsável durante a criação da tabela, pode receber entradas do tipo texto. É
um campo padrão da ferramenta, que utilizaremos para representar os responsáveis pela execução e entrega dos
resultados previstos para os elementos da nossa EAP.
Novamente, lembramos da importância de documentarmos os usos específicos que fazemos dos campos e
funcionalidades da ferramenta em documento específico do projeto, que deve ser disponibilizado aos envolvidos que
tenham contato com o arquivo.
 Nível Organizacional
Em nosso "projeto exemplo", que trata da reforma de uma residência, definimos que o patrocinador-cliente contratou
o escritório Akmeo, de arquitetura e design de interiores, para criação do projeto e consultoria ao longo das obras, e
que este escritório é responsável pelas subcontratações.
A classificação realizada para responsável e níveis organizacionais do nosso "projeto exemplo" pode ser vista na
imagem abaixo.
2.2.2.6. Uso de Groups
Para encerrar nossa proposta inicial de documentação

da EAP, criaremos neste momento um modo que
utilizará grupo (Group) para organizar os elementos da
nossa EAP conforme a classificação ORG realizada.
Para isso, se faz necessário que apresentemos esta
importante funcionalidade da ferramenta.
Group
É possível reorganizar os elementos da EAP do nosso projeto

segundo critérios configurados através dessa função da
ferramenta. Fazemos isso para atender às mais diversas
necessidades dos envolvidos no projeto, necessitados que são
de informações precisas e de resposta ágil.
Estamos interessados no momento em organizar os elementos

da nossa EAP conforme o nível organizacional criado através
dos campos Text28 a 30. Poderemos assim verificar
rapidamente todos os produtos sob responsabilidade de cada
divisão organizacional.
Para iniciar o processo, devemos ir à aba View, e no conjunto

Data, selecionar a lista suspensa Group by.
Existem grupos pré-desenvolvidos pela Microsoft, e o usuário é incentivado a testá-los posteriormente para
entendimento das suas funções, no entanto recomendamos que crie seus próprios grupos e os aplique aos
seus modos para maior domínio do procedimento e criação de soluções específicas às suas necessidades.
Dando continuidade, selecionamos a opção More Groups... que se mostra muito semelhante à opção More Tables...
já apresentada.
Tomando o cuidado de ter selecionado a opção Task, criaremos um novo grupo clicando no botão New... e somos
recepcionados pela tela abaixo:
1 – Inserir o nome do Grupo. Recomendamos que seja o mesmo nome do modo no qual será inserido. No nosso
caso, Step 03 – WBS – ORG
2 – Marcação para aparecer no menu, como na imagem ao lado.

Recomendamos permanecer marcado.
3 – Local para inserirmos os elementos usados para criação do grupo. No

nosso caso, os Campos Text28, Text29 e Text30 (podemos selecioná-los
também pelo seu nome renomeado).
4 – Configuração visual de cada elemento usado para criação do grupo.

Recomendamos a utilização de uma escala de cor na qual os elementos
superiores no grupo possuam tom relativamente mais forte.
5 – Opção de mostrar elementos do tipo summary. Por definição, o MS Project exibe nos grupos somente as linhas
que entende como sendo atividades (para o MS Project qualquer linha que não tenha subníveis é considerada Não-
summary). Recomendamos que o usuário experimente ambos os estados desta marcação, para optar qual melhor
atende as suas necessidades.
6 – Opção de manter hierarquia. Recomendamos permanecer desmarcada para não dificultar a visualização dos
elementos.
O resultado final do nosso grupo pode ser visto na imagem abaixo:

Step 03 – WBS – ORG
Finalizando este capítulo, criaremos o Step 03 – WBS – ORG, no qual apresentaremos os elementos da EAP recém
criada, organizados por nível organizacional.
Desejamos criar a tabela Step 03 – WBS

– ORG com os mesmos elementos da
tabela Step 01. Para que não tenhamos
todo o trabalho novamente, usaremos a
opção Copy na tela More Tables,
mostrada abaixo.
Assim, teremos somente que renomear

a tabela e conferir os elementos
selecionados.
Poderíamos utilizar a opção de Copiar a

tabela mesmo que fôssemos usar
somente alguns de seus elementos, de
forma a agilizar o processo de criação de
tabelas.
Criamos agora o modo Step 03 – WBS -ORG selecionando a tabela de mesmo nome e o grupo de mesmo nome.
Novamente recomendamos que a opção Show in menu permaneça selecionada.
O resultado final do Step 03 pode ser visto abaixo. Desse modo, podemos imediatamente reconhecer quais pacotes
de trabalho do nosso projeto estão sob responsabilidade de cada departamento e setor da empresa.
Reparem que a configuração visual somente é apresentada para os elementos a partir da coluna Name e à sua direita.
Assim, caso seja necessário, é possível mudar a ordem das colunas para que todas recebam a configuração visual
de distinção entre as camadas do grupo.
O uso de grupo se dá não somente para organizar os elementos da EAP, e posteriormente atividades e recursos,
mas também para totalizar informações segundo seus critérios de agrupamento. Aproveitando este modo, como
exemplo do uso de grupos para totalizar custos entre seus elementos, temos a imagem abaixo. Nela, criamos valores
simbólicos para os elementos da nossa EAP e um modo com agrupamento por nível organizacional; e pusemos na
tabela o campo Total Cost.
Figura 1: Exemplo de uso de grupo para totalizar custo
Podemos aqui, além de verificar quais pacotes de trabalho estão sob responsabilidade de cada departamento e setor,
saber também de que ordem de grandeza são os recursos sob responsabilidade de cada uma dessas divisões
organizacionais.
3. Capítulo 03: Gerenciamento do Tempo
3.1. Conceitos de Gerenciamento do Tempo

Pode-se dizer muitas coisas dessa área de conhecimento ou do tema administrativo do gerenciamento de projetos,
mas com certeza a afirmação de que o Gerenciamento de Tempo do Projeto constitui, junto ao Gerenciamento do
Escopo e o Gerenciamento do Custo, o alicerce básico e inicial de um planejamento eficaz é algo bem pertinente. Até
o momento da definição do escopo das tratativas com os envolvidos do projeto, no início de vida do próprio projeto,
entendemos que as habilidades são de sucesso na negociação, e tratativas de entendimentos comuns, únicos e de
mesma intenção. Aqui, neste momento, se diferenciam as propostas, os planos de ação pela capacidade do gerente
de administrar seus recursos ou envolvidos mais próximos. Os especialistas vão definir o “como” serão produzidos
os diversos pacotes de trabalho que foram “acertados ou comprometidos”, em tempo de redação e definições. Temos
claro que, basicamente, podemos estender e subsidiar alguns dos trabalhos a serem apresentados, mas pelo menos
esses apresentados pelo guia de conhecimentos do PMI são essenciais. Temos uma frente de pelo menos 6 trabalhos
no planejamento: Planejar o gerenciamento dos prazos – processo que descreve como a equipe irá adquirir e
documentar a administração dos prazos do projeto e suas mudanças; Definir as Atividades – processo de identificar
quais atividades devem ser realizadas para produzir os diversos Resultados Parciais do projeto; Sequenciar as
Atividades - processo de identificar e documentar as relações de dependência entre as atividades; Estimar os
Recursos da Atividade – processo que avalia quais os tipos e as quantidades de recursos a serem utilizados para a
realização das atividades do projeto; Estimar a Duração das Atividades – processo de determinar a quantidade de
períodos de trabalho que serão necessários para a implementação de cada atividade; e Desenvolver o Cronograma
– processo que utiliza as saídas dos processos anteriores e a necessidade de recursos para determinar o prazo do
projeto. Como processo a ser estudado ainda na etapa de controle do projeto, temos: Controlar o Cronograma –
processo utilizado para medir periodicamente o progresso e detectar as mudanças no cronograma do projeto.
Durante o transcorrer das ideias propostas nesse livro e da metodologia utilizada para apresentar o gerenciamento
de projeto, é interessante notar que o último processo do planejamento de tempo, Desenvolver o Cronograma, não
se encerra na etapa de planejamento de tempo; ela será realimentada pelo planejamento de recursos humanos,
custos, riscos, comunicação, pela revisão de qualidade do projeto e outros.
O plano de gerenciamento do cronograma identifica uma metodologia de programação e uso de ferramentas,

define o formato e estabelece critérios para o desenvolvimento e controle do cronograma do projeto. Uma
metodologia de planejamento define as regras e abordagens para o processo de agendamento. Algumas
das metodologias mais usadas e conhecidas incluem método do caminho crítico (CPM) e o método da
corrente crítica (CCM). Devemos entender aqui que o CPM, já mencionado, deve levar em conta também as
restrições, quando elas existirem, para o seu perfeito entendimento. Isso significa que imposições como
calendários, com seus feriados, datas impostas por contratos ou limitações de recursos, devem ser
considerados mesmo nos processos mais tradicionais com o CPM – método do caminho crítico. Essa
ferramenta, dentro dos seus limites e propósitos, se situa bem no modelo CPM mencionado e aventura-se
no apoio ao RCPM (Resource Critical Path Method).
3.1.1. Planejar o Gerenciamento dos Prazos

Esse processo é aquele que estabelece as políticas, procedimentos e documentação para o planejamento,
desenvolvimento, gestão, execução e controle dos prazos do projeto. A principal vantagem deste processo é que ele
garante que a gestão, o cronograma e suas ferramentas e técnicas associadas sejam documentados. As entradas,
ferramentas e técnicas, e saídas deste processo serão descritas e apresentadas a seguir.
Entradas do Processo
1. Termo de Abertura.
2 - Fatores ambientais da empresa.
3 – Plano de gerenciamento do projeto.
4 - Ativos dos processos organizacionais.

1 - Opinião especializada - A avaliação especializada, guiada por informações históricas, fornece informações
valiosas sobre o ambiente e informações de projetos similares anteriores. O julgamento de especialistas
também pode sugerir como e se se deve combinar métodos, e como reconciliar as diferenças entre eles.
2 - Técnicas Analíticas - O Plano de Gestão dos prazos pode envolver a escolha de opções estratégicas para
estimar e agendar os prazos parciais e totais do projeto, tais como: metodologia de trabalho, ferramentas de
trabalhos e técnicas, abordagens das estimativas, formatos e software de gerenciamento de projeto. A gestão
do cronograma pode também apresentar propostas e diretrizes para aceleração da produção no cronograma
do projeto, tais como a realização de atividades em paralelo ou compressão por métodos pré-estabelecidos.
Essas decisões, da mesma forma que em outras áreas de conhecimento, afetam os riscos do projeto. As
políticas e procedimentos organizacionais que podem influenciar as técnicas de agendamento devem ser
levados em conta também.
3 – Reuniões - As equipes de projeto podem realizar reuniões de planejamento para desenvolver o plano de
gerenciamento do cronograma. Os participantes dessas reuniões incluem o gerente de projeto, o patrocinador
do projeto, membros selecionados da equipe do projeto e outros conforme necessário.
Saídas do Processo
1 - Plano de Gerenciamento do Cronograma - Esse documento é um dos componentes do plano de

gerenciamento do projeto que estabelece os critérios e as atividades para desenvolver, monitorar e controlar
o cronograma. O cronograma pode ser formal ou informal, muito detalhado ou bastante amplo, com base nas
necessidades do projeto.
Um plano de gerenciamento do cronograma pode estabelecer o seguinte:
• Modelo de desenvolvimento de cronograma de projeto - A metodologia de programação e a
ferramenta a ser utilizada no desenvolvimento do modelo de programação de projeto;
• Nível de precisão – Os critérios para aderência das estimativas de duração das atividades a valores
pré-definidos, com base no escopo das atividades e na magnitude do projeto, podendo incluir valores
para contingências;
• Unidades de medida – A unidade usada em medições (volume produzido, horas de trabalho, dias de
pessoal, ou semanas; definida para cada um dos recursos;
• Limites de controle – Limites de variação para o desempenho do cronograma durante o seu
monitoramento, sendo especificados para indicar uma quantidade pré-definida, de modo a garantir
alguma ação a ser tomada. São tipicamente expressos como desvios percentuais em relação ao
plano de linha de base;
• Regras de medição de desempenho – As regras de aplicação do “Earned Value Management” (Valor
Agregado) e regras de medição de desempenho. Por exemplo, o plano de gerenciamento do
cronograma pode especificar:
o Pontos de WBS em que a gestão do progresso e cronograma serão medidos;
o Técnicas de medição de valor agregado (por exemplo, linhas de base, fórmula fixa, por cento
completo, etc.) para serem empregadas (para informações mais específicas, consulte a
Prática Standard para Earned Value Management),
o Programação de medições de desempenho, como variação do cronograma (SV) e
cronograma índice de desempenho (SPI), usado para avaliar a magnitude da variação com
a programação original linha de base.
• Formato dos Relatórios - Os formatos e frequência para os relatórios de cronogramas.
• Descrições dos processos - Procedimento de uso e aplicação desses documentos.
3.1.2. Definir as Atividades

A definição das atividades envolve identificar e documentar o trabalho planejado para atingir o objetivo do projeto. A
principal fonte para identificar as atividades é o escopo, portanto, a EAP (Estrutura Analítica do Projeto). Nesse
processo é importante a participação do time de planejamento, gerentes funcionais e outros especialistas. A
experiência tem mostrado que a definição das atividades só se torna eficaz quando trazemos para dentro do time de
planejamento não apenas os profissionais que estarão detalhando os produtos ou serviços parciais que devem ser
entregues para a composição do empreendimento, mas também aqueles profissionais que de fato estarão executando
as atividades no seu nível técnico e administrativo-gerencial. É comum verificarmos que muitas das atividades
elencadas na etapa de planejamento não são executadas pelas “equipes de campo” ou “times de trabalho”,
simplesmente porque elas não refletem o estilo ou “expertise” dos profissionais que as geraram. Aqueles que definem
as atividades para efeito de composição de estrutura de trabalho ou para efeito de composição de custos e
orçamentação nem sempre possuem o domínio da "arte". Quando se leva em conta que as atividades definidas no
planejamento serão utilizadas para acompanhamento e controle de desempenho de prazo e custo, deve-se também
considerar o peso que a atenção nessa etapa tem para o sucesso do planejamento.
1 – Plano de Gerenciamento do Cronograma
2 - Fatores Ambientais da Empresa
3 - Ativos de Processos Organizacionais
4 - Linha de Base do escopo

1. Decomposição - Significa subdividir os pacotes de trabalho do projeto em componentes menores – as ações
de produção, e que de fato irão produzir o trabalho, aqui chamados de atividades. Essas atividades são as ações
que, no seu menor nível, produzirão o trabalho necessário para a produção dos pacotes. Essa técnica é aplicada
apenas aos pacotes de trabalho. Quando a definição do escopo não permite chegar aos níveis mais baixos é
necessário então lançar mão de alternativas.
2. Modelos - Quando as características do projeto a ser desenvolvido na fase de planejamento são muito
semelhantes a outras da organização, é possível utilizar os dados históricos e aproveitar parte dos modelos
existentes. O modelo deve ser íntegro o suficiente para não trazer vícios ocultos, características particulares de
outros projetos e conflito com a melhor técnica existente. Dessa forma, os modelos serão mais que úteis no
ganho do tempo de planejamento; estarão contribuindo para a formação dos especialistas que trabalham no
planejamento e serão reavaliados a cada uso pela organização. A utilização de softwares de gerenciamento de
projetos muitas vezes facilita o arquivamento desses modelos e “receitas” ou “templates”, mas esse trabalho
deve ser acompanhado sempre do registro dos atributos das atividades, que no fim passam a compor as
características do modelo.
3. Planejamento em Ondas Sucessivas - O planejamento em regime de ondas sucessivas pressupõe que a
equipe de trabalho não tenha de imediato todas as informações e detalhes do projeto para a sua modelagem
final de planejamento. Nesse caso, somente as partes mais próximas à data de realização estão detalhadas o
suficiente para chegar ao nível de pacotes de trabalhos e consequentemente ao nível de detalhamento de
atividades. Nesse caso, as atividades podem ser modeladas através de componentes de planejamento.
4. Opinião especializada - Essa técnica pode ser considerada a mais eficaz e, talvez até a mais custosa. Ela
reúne aquele ou aqueles que de fato sabem como deve ser feito o trabalho para a realização dos pacotes e
produtos detalhados. Se na definição dos pacotes e produtos do projeto podemos ter a participação apenas da
equipe de planejamento do projeto e seus vendedores, nesta técnica, a experiência vivida pelos participantes e
executores traz visões muito mais interessantes. Essas experiências, aliadas ao conhecimento das
especificidades do projeto, subsidiam a análise de risco. Essa técnica pode e deve ser utilizada em conjunto com
outros processos, em particular os processos do gerenciamento de risco, de forma a otimizar o tempo e o custo
despendido nesta fase e reduzir as realimentações e correções muito comuns durante a fase de planejamento.
5. Componente de Planejamento. Quando o

nível de conhecimento dos detalhes de um
projeto não é suficiente para o detalhamento
dos seus pacotes e produtos, inviabilizando
assim o detalhamento das atividades por
qualquer outro meio, agenda-se esse
trabalho dentro do planejamento futuro.
Elementos, aqui chamados de “componentes
de planejamento”, são alocados como
atividades e agendados no cronograma final
para serem escrutinados o mais breve
possível. É importante lembrar que a etapa
de identificação das atividades precede o
detalhamento de recursos e custos alocados
para a composição geral dos recursos do
projeto. Nesse caso, essa técnica não
permite esse nível de detalhamento, ficando
os recursos e custos sendo estimados
também por técnicas específicas, como estimativas análogas e estimativas paramétricas. As melhores práticas
utilizadas tomam o elemento “Conta de Controle” e o colocam dentro da EAP acima dos pacotes de trabalho, e
abaixo do produto principal. Uma vez que os pacotes de trabalho ainda não existem, pela falta de definições
detalhadas, o elemento passa a conter os “Pacotes de planejamento” que, como o nome diz, é o responsável
por guardar sob o centro de custo “Conta de Controle” todo o trabalho dirigido ao esforço e o trabalho conhecido
que não possui atividades ainda detalhadas. Na figura ao lado, em cinza, o projeto; em azul, os produtos
principais do projeto; em azul claro, os pacotes de trabalho decompostos pelo conhecimento do projeto; em
verde, as atividades elencadas para a produção desses pacotes; na cor castor, as “contas de controle”; e, em
amarelo, os pacotes de planejamento.
6 - Engenharia Simultânea - Essa técnica é baseada numa VIP – Value Improved Practice, chamada “Análise
da Capacidade de Construção”, e é muito usada na área das engenharias e EPC - Engineering Procurement
Construction. Normalmente, envolve a mobilização de técnicas especificas de construção na fase de engenharia
do projeto, para auxiliar os especialistas na decisão de escolha de materiais, técnicas de construção e arranjos
de leiautes. O objetivo desta técnica, como a de todas as VIPs, é reduzir custos e aumentar a funcionalidade das
instalações do projeto.
Saídas do processo
1. Lista de atividades. São as atividades programadas e necessárias para a realização do projeto. Assim como
os elementos da EAP, elas devem receber um identificador único para a perfeita compreensão do trabalho a
ser realizado. Se após esse processo de definição da lista de atividades, outros processos de planejamento
forem realizados, é muito provável que seja necessária uma nova interação com a lista gerada, para, ampliá-
la, consolidá-la ou até mesmo reduzi-la. A interpretação dessa identificação não deve confundir um princípio
básico: as atividades não fazem parte da definição de EAP – Estrutura Analítica do Projeto, aqui praticada. É
recomendável que a lista de atividades inclua uma descrição sucinta de cada atividade para garantir que os
membros da equipe do projeto entendam claramente como o trabalho deverá ser realizado, seguida de uma
documentação complementar para perfeito entendimento e compreensão. Na lista de atividades, é essencial

encontrarmos os marcos do projeto. As atividades dentro da estrutura do projeto recebem a codificação
utilizada para a montagem da EAP, ou código da EAP. É muito importante que as atividades sejam
referenciadas por um VERBO no infinitivo.
2. Atributo das Atividades. Para cada atividade pode ser designado um conjunto de atributos, ou seja, de
características. Esses atributos vêm a contribuir para o melhor entendimento daqueles que participam do
trabalho e daqueles que registram esses modelos para uso futuro. Muitas vezes, esses atributos podem ser
apresentados em forma de planilha, facilitando o seu entendimento aos participantes do projeto. As melhores
práticas indicam os seguintes atributos listados abaixo:
Identificador Um sistema qualquer que venha a identificar de forma mais fácil a

atividade dentro do projeto.
Código Um código, semelhante ao código EAP, ou código de conta, para
definir de forma técnica a atividade dentro do projeto.
Volumes Unidades de produção a serem produzidas a partir de insumos
apresentados na entrada do processo (atividade).
Unidade de Medida Unidade de medida identificadora desse volume a ser produzida
(m2, m3, kg).
Descrição Um conjunto de palavras que, normalmente, tenha um profundo
sentido de ação, que consiga descrever o trabalho a ser realizado.
Predecessoras As atividades ou seu código que sejam predecessoras.
Normalmente, são aquelas que determinam o seu início.
Relacionamentos lógicos A forma como a atividade se relaciona com as suas
predecessoras.
Antecipações e atrasos O número de períodos de trabalho que trazem à atividade
predecessora ou sucessora avanços ou retardos de início.
Recursos necessários Todos os recursos necessários para a realização das tarefas
dessa atividade.
Datas impostas Datas que possam ser atribuídas para início ou término da
atividade e que sejam restritivas à liberdade de deslocamento
dentro do planejamento
Restrições e Premissas Condições que foram impostas no início do projeto, ou
considerações tomadas por conta dos stakeholders do
empreendimento.
Responsável pela realização Nome do responsável pela execução da atividade.
Nível da ORG associado Identificação do nível da organização do projeto que é
responsável pela execução da atividade.
Forma da Alocação de Dentre os tipos existentes, a forma como o esforço é alocado; se
Trabalho “nível de esforço”, “esforço distinto” ou “esforço distribuído”.
Duração Estimada Valor em período de trabalho que deve ser consumido para
atender à realização das tarefas necessárias para os recursos
definidos e alocados.
Calendários Os dias em que haverá a possibilidade de realização de trabalho
para a atividade, em respeito aos padrões da empresa, da cultura
local, dos feriados nacionais e regionais.
3 - Lista de marcos. Conforme já comentado, essa lista complementa a lista de atividades e apresenta todas
as referências necessárias para o controle e acompanhamento da execução das atividades e entrega dos
produtos. Esses marcos muitas vezes denotam o início ou o término de uma fase ou etapa, o início e o término
de um produto ou pacote de trabalho, assentamento de etapas de atividades concluídas e, por fim,

compromissos contratuais. Eles são utilizados, principalmente, para o controle de desempenho do projeto. É
muito importante que os marcos sejam referenciados por um VERBO no tempo Particípio Passado, sempre
que possível.
Marco Obrigatório Aquelas indicações que, por força de garantia de qualidade do projeto,
referência contratual, definição de conclusão de fase de projeto ou outra
condição relevante, devem ser representadas.
Marco Opcional Aquelas indicações que, por conveniência da equipe do projeto, devem
ficar explicitadas para o controle e o monitoramento de equipes e
fornecedores internos.
4. Atualizações do Plano de Projeto de Gestão - Como resultado do processo “definir as atividades”, alterações
e acertos no escopo ou nos requisitos podem ser descobertos, e seus impactos detectados sobre alguns dos
elementos do plano de gerenciamento de projetos. Atualizações para o plano do gerenciamento do projeto
podem incluir mudanças em outras linhas de base, como escopo, custos, risco, comunicações e outros.
3.1.3. Sequenciar as Atividades

O processo de sequenciamento das atividades envolve identificar e documentar as relações de dependência
entre as atividades do projeto, possibilitando mais tarde a elaboração de um cronograma dinâmico, realista e
viável. Muitas vezes, a diferença entre equipes de planejamento é medida na capacidade de elaborar a melhor
solução sequência e exequível para um dado projeto e suas características. Da mesma forma que a etapa de
identificação das atividades, essa etapa tem de ser realizada por uma equipe que possua o conhecimento técnico
reconhecido na elaboração do produto ou serviço a ser entregue. Muitas vezes, por falta de tempo ou recursos
especializados, os gerentes lançam mão de profissionais que definem o sequenciamento sem ter o conhecimento
das condições, premissas e restrições que envolvem aquele determinado produto ou serviço. Isso é comum
quando são “delegadas” às equipes de orçamentação a realização dessas análises sem o fornecimento das
condições específicas que regem o “contrato de serviços” ou as necessidades “específicas do negócio”. As
consequências de sequenciamento inadequado só são conhecidas durante a execução, quando a etapa de
planejamento inicial já passou e qualquer acerto é mais custoso que desejado. O sequenciamento deve ser feito
com o auxílio de um computador, utilizando software de gerência de projeto, ou com técnicas manuais. As
técnicas manuais são, geralmente, mais efetivas em projetos menores e em etapas iniciais de projetos maiores,
quando existem poucos detalhes disponíveis. As técnicas manuais e automatizadas podem, também, ser
utilizadas em conjunto. A maioria, senão todos os de maior uso comercial, utiliza o Método do Diagrama de
Precedência – PDM (Predecessor Diagram Method), que é um método de construção de diagrama de rede que
se utiliza de retângulos ou caixas para representar as atividades, e setas entre essas figuras para representar as
suas dependências. Esta técnica também é conhecida como “atividade no nó” (AON - Activity-on-node), sendo
o método mais utilizado para a representação gráfica e em softwares dos diagramas de rede. Teve a sua origem
nos idos tempos dos projetos militares do DoD e evoluiu dentro desses moldes até os dias de hoje.
1 – Plano de Gerenciamento dos Prazos
2 - Declaração do Escopo do Projeto
3 - Lista de Atividades
4 - Atributos da Atividade
5 - Lista de Marcos
6 - Ativos de processos organizacionais
1 - Método do Diagrama de Precedência – PDM - Este é um método de construção de diagrama de rede que
utiliza retângulos ou caixas para representar as atividades. O Método do Diagrama de Precedência possui quatro
classificações:
 Dependências obrigatórias. São aquelas inerentes à natureza ou condições técnicas e

específicas do trabalho que está sendo feito. Frequentemente, envolvem limitações físicas e
organizacionais. As dependências obrigatórias são também chamadas de lógica rígida (hard logic).
É muito comum tornar uma necessidade de trabalho, ou limitação de recurso, um fator de
classificação tendenciosa ao “obrigatório”, numa relação entre atividades. Dessa forma, a equipe
de planejamento deve se abstrair dos limites e tradições e atentar para a exequibilidade do trabalho.
A seguir, e havendo fatores restritivos, rever o sequenciamento de modo a ajustar as atividades
simultâneas ou sequenciais à realidade do projeto.
 Dependências arbitrárias. São aquelas definidas pela equipe do projeto. Esse tipo de
dependência deve ser usado com cuidado (e bem documentado como premissa), já que pode
limitar, posteriormente, as opções do cronograma. As dependências arbitrárias são usualmente
definidas com base no conhecimento de melhores práticas dentro de uma área de aplicação
particular, ou algum aspecto particular do projeto, em que uma sequência específica é desejada.
As dependências arbitrárias podem ser chamadas também de lógica preferida (soft logic).
Normalmente, são dadas pelos técnicos na sua experiência profissional, pelo conhecimento das
limitações de suas equipes e dos limites de aceitação dos clientes. Nesse ponto, pode-se dizer que
é onde os fornecedores se diferenciam nas suas propostas técnicas de realização de serviços.
 Dependências externas. São aquelas que envolvem um relacionamento com atividades de fora
do projeto. Essas dependências são definidas pela experiência dos profissionais envolvidos, das
condições contratuais, governamentais ou órgãos de controle de serviços de uma região. As
dependências externas podem ser verificadas em atividades que estão fora da cadeia produtiva,
ou na mão de termos e condições contratuais ou pela legislação. Essas dependências, uma vez
estabelecidas, ajudam a identificar o momento de início ou de término dos envolvidos externos às
equipes do projeto. A modelagem dessas dependências, feita de forma adequada, é muito útil para
o gerenciamento que vise evitar conflitos e fugir de negociações desnecessárias.
 Dependências de Critérios Particulares. São as dependências que não têm cunho técnico
construtivo, ou da cadeia de valor dos trabalhos a serem realizados no produto ou pacote de
trabalho. Os critérios específicos de um projeto podem ser levantados para apoiar as decisões de
criação de tais dependências. No caso de projetos que envolvam áreas de risco à vida e ao
ambiente, ou no caso de projetos que envolvam compromissos políticos e sociais, é possível
encontrar essas formas específicas de dependências. Os especialistas dessas áreas devem ser
consultados para a validação dessas programações.
Independentemente de sua classificação, podemos definir aqui a forma das dependências ou das relações
entre as atividades no processo de produção; qual atividade determina qual atividade vai ser executada, por
conseguinte, e a forma de comando. Nos exemplos a seguir, as atividades, representadas pelos retângulos
na cor verde, são aquelas que definem a precedência, e são mandatórias; as na cor amarela, são aquelas
consequentes da ação de sua predecessora.
Término para Início (finish-to-start):

O início do trabalho da sucessora depende do término da
predecessora. Esse é o relacionamento lógico mais usado nos
diagramas de rede PDM. Ele define que a atividade seguinte só deve
ser iniciada após a conclusão da anterior. Seja essa sequencia
oriunda de uma dependência obrigatória ou arbitrada, é importante
lembrar que sua escolha está sempre definida pela condição de
“preexistência” obrigatória de uma atividade em relação à outra. O
uso de artifícios, como o adiantamento ou retardos, deve ser
monitorado para garantir que nas duas condições, a premissa inicial seja mantida, ou seja, a segunda só
pode existir se a primeira estiver “praticamente” ou completamente concluída. Adiantamentos entre
atividades desse tipo, "Término para Início", não costumam exceder a 20% de intercessão, sob pena de
descaracterizar o tipo de ligação. Isso será abordado em técnicas de compactação e redução de prazo
adiante.
Término para término (finish-to-finish):

O término do trabalho da sucessora depende do término da
predecessora. Nesse tipo de relacionamento, as datas de término das
atividades são idênticas e a data de término da atividade sucessora
depende da atividade antecessora. É uma ligação de pouca
expressividade quando comparada à anterior. Normalmente, elas
representam as atividades de criação e montagem de um produto e
serviço, que são acompanhadas por atividades com características de
“processos” de acompanhamento e análise. Na alocação de custo, essas atividades de “processos” são
reconhecidas pelo “nível de esforço” ou “esforço distribuído”, e por possuir duração e empenhos fixos. Dessa
forma, elas são levadas pelos atrasos e adiantamentos da antecessora. A tarefa sucessora não é passível de
atraso. Se na montagem do sequenciamento for detectado que essa atividade pode atrasar o projeto,
provavelmente seu tipo de ligação não é o recomendado para ela.
Início para Início (start-to-start):

O início do trabalho da sucessora depende do início da predecessora.
Nesse tipo de relacionamento, as datas de início das atividades são
idênticas. Há mais sentido em falar nesse tipo de relacionamento quando
estamos elaborando as dependências arbitrárias e escolhidas pelos
profissionais, no intuito de otimizar e acelerar o projeto. Elas definem o
uso simultâneo de recursos nas técnicas de redução de tempo de
cronograma que serão abordadas adiante. Diferentemente da ligação
anterior, a tarefa sucessora não é obrigatoriamente caracterizada por “processos” de algum tipo. É importante
registrar que o início da primeira restringe e define o início da segunda. Atrasos e adiantamentos entre atividades
desse tipo, "Começar para começar", não devem exceder a 20%, sob pena de descaracterizar o tipo de ligação.
Esse tipo de prática deve ser monitorado de forma a redefinir as ligações entre as atividades, ou quebrá-las em
outras menores e administráveis.
Início para Término (start-to-finish):

O término do trabalho da sucessora depende do início da predecessora.
Esse tipo de relacionamento é o mais conturbado de todos. Sua aplicação
se restringe a atividades externas à cadeia de valores da produção de um
produto ou serviço. As atividades específicas para a entrega de um
produto ou serviço, conforme já visto, possuem características de
dependências obrigatórias e escolhidas (arbitradas) pela equipe de planejamento técnica, normalmente do tipo
terminar para começar. É verificado algumas vezes que atividades suplementares ao processo de “fabricação”
de um produto são necessárias e importantes para atendimentos contratuais e das condições de negócio.
Consideremos como parte essencial da cadeia de valor tudo aquilo que diretamente é necessário para a
realização de um produto, e como parte suplementar as atividades que garantem a entrega e aceitação do
produto. Dessa maneira atividades de cumprimento de cláusulas contratuais, de apoio ao gerenciamento e
atendimento a exigências a órgão e instituições do governo e sociedade, passam a ser passiveis desse tipo de
ligação. No caso da instalação elétrica de uma fábrica, parte entregável de um produto maior - a fábrica, temos
como atividade suplementar e obrigação contratual à instalação elétrica a “elaboração de um manual de
operação” que deverá ser aprovado pelo cliente. Lembramos que, para o
funcionamento físico desta instalação, o “manual de operação” é
dispensável; porém, para a sua entrega ao cliente, não. Essa atividade
será ligada sequencialmente à conclusão física das instalações elétricas
numa ligação começar para terminar, objetivando a conseguir a data de
início dos trabalhos da equipe suplementar de elaboração desse manual
operativo, com duração e recursos previamente estimados, como
consequência dos trabalhos principais das instalações. Os atrasos ou
adiantamentos sinalizarão novos início e fim da atividade suplementar em
questão, como consequência da sua condição de suplemento de esforço para a entrega do produto. Se para a
elaboração de uma “atividade específica” dentro da cadeia maior de valores de um produto for necessária uma
“reunião para reavaliação de riscos local” do gerente com sua equipe, essa atividade de reunião deverá estar
condicionada numa ligação começar para terminar à “atividade específica”. Isso garante que qualquer atraso
ou adiantamento imposto à atividade principal, detentora de real valor para conclusão do produto ou serviço, será
repassado ao início e fim da atividade de reunião, dando condições de programar equipe e análise de novos
cenários da ocasião. Da mesma forma, as licenças de início e aceite de órgãos ambientais, estaduais e
municipais agregam valor, mas não são essenciais para a execução física das atividades que comporão o
produto ou serviço a ser entregue. Esse tipo de relacionamento são mais facilmente modelados com essa ligação.
Hammocks – Quando existe uma atividade que, por princípio,

acompanha o desenvolvimento de outras, que tenha característica
administrativa ou que represente o tempo despedido por atividades ou
sequência limitada, ancoramos seu início e término de forma simultânea
e como “dependentes”, dando ao esquema uma aparência de rede de
índio – ou seja hammock,presa em dois pontos e sem duração definida
pelo seu próprio trabalho, e sim pelo trabalho de outras. As atividades em
verde definem um trabalho a ser supervisionado pela atividade em cor
amarela. Uma dependência Início-Início (1) da primeira atividade da sequência verde é acompanhada por uma
dependência Término-Término (2) da segunda atividade da sequência verde. A atividade Hammock, ou de
resumo, é aquela caracterizada como atividade ligada à administração ou processos de gerenciamento cobrindo
um grupo de mais de uma atividade do projeto.
2 - Modelos de Rede do Cronograma - Modelos de Redes, também chamadas de sub-redes, e padronizados,

podem ser utilizados dentro de um projeto levando-se em conta duas condições básicas: a partir do
desenvolvimento da sub-rede pela equipe do projeto para aplicação dentro do próprio projeto, por ser atribuído
a fases ou etapas repetitivas e de mesma característica construtiva; ou por ter sido a sub-rede desenvolvida para
um projeto muito semelhante e de mesmas características restritivas que, por meio de testes e resultados, se
mostrou eficaz e confiável. As duas situações trazem um risco ao projeto. A primeira se refere ao entendimento
da condição “atividades de mesmo sequenciamento”, repetitivas dentro do projeto. É importante que as restrições
sejam analisadas para não incorrer no erro de superestimar a capacidade do modelo. A segunda se refere à
análise das características dos projetos utilizados. Muitas vezes, as restrições físicas são diferentes e colocam
a equipe de planejamento em má situação, gerando retrabalhos e perda de recursos. Nesse último caso, a
análise dos atributos das atividades é relevante e essencial. É importante lembrar que o modelo de rede não
carrega em si a duração das atividades; o modelo é construtivo, de representação da cadeia de trabalho, sendo
necessária sua adaptação de durações mesmo que para o uso repetitivo dentro de um mesmo projeto.
3 - Determinação da Dependência - Existem classificações básicas para definir a relação de dependência entre
as atividades, como já apresentado anteriormente.
4 - Aplicação de Antecipações e Atrasos - Na modelagem do
sequenciamento do projeto, em particular nas dependências
arbitrárias, o uso de antecipações e atrasos entre atividades é positivo.
As quatro relações de procedência entre duas atividades
relacionamento apresentadas podem exigir a aplicação desses
recursos. Uma atividade que inicia após o término de sua predecessora
pode ter necessariamente a obrigação de uma espera ou retardo de
algumas unidades de tempo. Por questões construtivas ou contratuais,
essa espera deve ser modelada e representada para efeito de
planejamento.
O uso de artifícios como o adiantamento ou retardos deve ser monitorado para garantir que haja uma coerência
na modelagem adotada. Adiantamentos para as atividades que sucedem em ligações do tipo Término para
início não costumam exceder a 20% de intercessão, sob pena de descaracterizar o tipo de ligação. Já atrasos
e adiantamentos entre atividades do tipo Início para Início não devem exceder a 20%, sob pena de também
descaracterizar o tipo de ligação. Esse tipo de prática deve ser monitorado de forma a redefinir as ligações entre
as atividades, ou quebrá-las em outras menores e administráveis. As únicas exceções conhecidas e praticas
estão no nível de “pacotes de planejamento”, em que, por analogia e projetos similares, verificou-se nos níveis
mais superiores da EAP uma ocorrência real. Chamam ao retardo de LAG e à antecipação de LEAD de vezes.
Os Retardos podem ser modelados para representar uma relação de comando retardado de tempo ou de volume
produzido. A atividade sucessora terá o seu comando atrasado ou adiantado em função desse modelo. Os
retardos e antecipações existem na prática, é necessário existirem nas ferramentas e não devem ser
transformados em atividades para modelagem. As atividades ocupam tempo, porém produzem algo e consomem
recursos do projeto. Os “Lags” são apenas esperas por conta de definição de processos.
LAG - Na figura
ao lado, como
exemplo de
uma Pintura
em um imóvel,
há a previsão
de duas
demãos de tinta
nas paredes,
com a
recuperação do posicionamento dos quadros artísticos e adereços nas paredes pós-pintura. A produção prevê
que teremos uma atividade de preparação; duas atividades de pintura; uma atividade de retoque e, ao final, uma
atividade de recuperação de posicionamentos. As melhores práticas de pintura preveem que entre cada uma das
demãos de tinta, se espere pelo menos 4 horas para uma nova aplicação, em função da secagem da demão
anterior; idem para os retoques e recomposição de mobiliário. Assim, o retardo de início das ações em sua
sequência será obrigatório e sempre com o valor de 4 horas. O resultado gráfico no tempo poderia ser o
apresentado na figura. Os indicadores “L1”, “L2” e “L3” são os espaços de tempo forçosos de não trabalho e sem
consumo de recursos, programação dependente de passagem de tempo. Como o retardo obedece a regras de
tempo, pode-se estender o modelo com a atribuição de um calendário ao LAG, (no nosso caso, as atividades
acontecem em horário
comercial de 8 horas
ao dia útil); já a espera
de secagem (LAG)
pode ser modelada e
calculada como horas
corridas (24h todos os
dias).
Saídas do processo
1 - Diagrama de Rede do Cronograma do Projeto - Essa saída é a esperada deste processo. Nela é encontrada
de forma gráfica a lista e a sequência planejada e agendada das atividades necessárias para a realização do
projeto. É muito importante ressaltar que em qualquer que seja o diagrama de rede a ser utilizado, ele deve ter
a capacidade de apresentar todas as ligações necessárias para a execução dos produtos e serviços parciais
e totais, garantindo que toda a atividade tenha SEMPRE uma entidade predecessora e SEMPRE uma entidade
SUCESSORA. As únicas exceções são o início e o término do diagrama.
Os diagramas de rede do projeto frequentemente são chamados de Diagrama PERT (Program Evaluation and
Review Technique). Devemos lembrar que o PERT foi originalmente introduzido pela Marinha dos EUA em
1957, quando se desenvolvia o míssil balístico intercontinental Polaris. O método PERT foi empregado para a
simulação do trabalho necessário para a conclusão desse projeto, através da criação de um diagrama de
precedência e redes lógicas de sequência de eventos dependentes e se utiliza do diagrama de predecessores
para atingir seus objetivos. É muito importante ressaltar que, em qualquer que seja o diagrama de rede a ser
utilizado, ele tenha a capacidade de apresentar todas as ligações necessárias para a execução dos produtos
e serviços parciais e totais, garantindo que toda a atividade tenha SEMPRE uma entidade predecessora e
SEMPRE uma entidade sucessora. As únicas exceções são o INÍCIO e o FIM do diagrama. A figura a seguir
mostra o resultado do sequenciamento das atividades definindo e formando uma rede de produção.
Alguns cuidados devem ser tomados por conta da verificação final de uma rede. Dentre eles, chamamos a
atenção do Leapfrog - atividades que mantêm relação de dependência redundante ou desnecessária.
Dependendo do tipo de sequenciamento entre três ou mais atividades, podemos verificar que em alguns casos
é possível estabelecer desnecessariamente dependências no aplicativo. Tomemos o caso do exemplo anterior,
dando o foco às atividades de ID Number 20 a 25. Se ID 22 precede 24 e ID 24 precede D 25, então,
excetuando-se uma característica extremamente particular de retardos ou recursos dedicados, temos uma
redundância como o citado.
Sobre os marcos e os diversos caminhos de produção, ou ainda por conta do ciclo de vida do projeto, abrimos
aqui um parêntese filosófico e apontamos como chave para decisão um elemento de apoio ao planejamento
tático operacional, e não estratégico no sentido mais utilizado pelos “gerentes de projeto da atualidade”.
Durante a condução de um projeto temos obrigações a cumprir, entregas a realizar e não cabe ao comandante
a decisão de corte, postergação ou abandono de etapas, fases ou partes. Cabe sim a sua execução. O uso de
chaves de decisão aqui pode ilustrar o caso dos “kil points” – pontos de decisão de ir ou não ir dentro de um
empreendimento ou projeto. Os “kil points” muito discutidos nos processos de análise de decisão do negócio,
do ciclo de vida do projeto, ou ainda de refino de resultados do negócio, aqui dão lugar a opções de produção.
A figura ao lado apresenta esse tema da seguinte maneira; temos que produzir uma entrega e, dependendo
das condições do “durante” as atividades de produção previstas, pode-se seguir dois caminhos distintos:
caminho UM – continuar, ou caminho DOIS – não continuar. Lembrando que durante a execução do plano de
projeto, temos que levar em conta o ambiente e as condições sobre as quais não temos domínio, como o clima,
ambiente social, valores de mercado, ações de correção mais austeras do que apenas o aumento de
contingente e aplicação de equipamentos mecanizados, essencial para gestores de maior maturidade
profissional. Se o projeto para, então a equipe deve decidir o que fazer: esperar, cancelar ou refazer.
2 - Atualizações dos Documentos do projeto – já comentado.
3.1.4. Estimar a Duração das Atividades
O processo de estimativa da duração das atividades tem por objetivo definir a duração mais provável para que a
atividade seja cumprida, produzindo o trabalho necessário com os recursos necessários e alocados para esse
fim. A estimativa da duração será mais precisa e confiável quanto mais precisa e confiáveis forem as suas
entradas nesse processo e a experiência da equipe nessa função. Cabe ao gerente do projeto liderar e definir
as diretrizes de trabalho, mas é a equipe especialista, além das informações históricas e da quantidade e
qualidade dos recursos alocados, que darão a palavra final. É comum que essa estimativa de duração seja
progressivamente elaborada e refinada ao longo da fase do planejamento, quando todas as informações vêm
contribuir para a precisão dos resultados, incluindo a análise dos riscos do projeto. A duração é sempre dada em
número de períodos de trabalho necessários para a sua execução. Temos dois casos clássicos para chegar à
definição da estimativa da duração: quando o trabalho a ser executado é consequência da “opinião
especializada” técnica e quando a estimativa é “paramétrica”, como veremos a seguir. Como a satisfação dos
“stakeholders” está diretamente ligada às expectativas, a melhor estimativa é aquela que reúne os dados e
premissas necessários à segurança do cumprimento de prazos. É preciso ter em mente que a equipe do projeto
deve evitar a todo custo iniciar um projeto estabelecendo como meta uma duração estimada infundada. Esse
processo pode e deve ser solidificado com o uso de técnicas de análise de riscos do projeto, escolha do método
de modelagem do cronograma, CPM (Critical Path Method), RCPM (Resource Critical Path Method) ou CCPM
(Critical Chain Path Method); e a disponibilidade de recursos numa relação custo/benefício.
As entradas listadas a seguir, já identificadas e conhecidas, são consideradas fundamentais para os trabalhos
desenvolvidos neste processo: Plano de gerenciamento dos prazos; Lista de Atividades; Atributos da atividade;
Recursos Necessários para a atividade; Calendário de recurso; Declaração do escopo do projeto; Estrutura
analítica dos Recursos; Fatores ambientais da empresa; além de Ativos e processos organizacionais. Vale
detalhar aqui que os Registro dos Riscos identificados consiste na consideração também dos riscos e
oportunidades durante a estimativa de duração das atividades, sendo que esses têm uma significante influência
na duração; e a Estimativa de Custos das Atividades apoia a quantificação de homens-hora para os recursos
alocados, levando o cálculo da duração por consequência.
1 - Opinião Especializada - As durações, geralmente, são difíceis de estimar por causa do número de fatores que
podem influenciá-las (nível dos recursos, produtividade dos recursos). A opinião especializada baseada em
informações históricas deve ser usada sempre. Se tal conhecimento especializado não está disponível, as
estimativas serão mais imprecisas e consequentemente mais arriscadas. Nesse ponto a experiência dos
profissionais e o histórico das organizações contam. Nos dois casos, encontra-se o valor do registro das
informações histórica dos acontecimentos: sucessos e fracassos. A opinião especializada se mostra consoante
com o gerenciamento do conhecimento dos projetos. Ela permite não só o desenvolvimento de sistemas de
informação como também consolida as suas bases para o uso futuro. Quanto mais experiência o profissional
possuir no caso em estudo, ou quanto mais informação for incluída na base de trabalho do sistema de
informações, mais preciso será o resultado da estimativa de duração.
2 - Estimativas Análogas – Essa técnica utiliza uma solução comparativa para a estimativa das durações.
Consistindo basicamente em detectar atividades de mesmas características, de mesmo padrão de alocação de
recursos, de mesmo grau de dificuldades e muitas vezes até de mesmas condições físicas. Através dessa
semelhança, os analistas tomam ou criam padrões que são extrapolados para o caso em estudo. É uma técnica
que requer um sentimento muito grande de confiança nas condições de contorno que tangem as atividades e
que introduzem um grau a mais de risco ao projeto. Normalmente é utilizada para os “pacotes de planejamento”
ou para atividades nas quais existem poucos ou nenhum detalhamento de tarefas a serem executadas. A
expertise dos envolvidos, assim como os dados históricos de projetos semelhantes, se faz muito mais
significativos então.
3 - Estimativa Paramétrica – Essa técnica é amplamente utilizada pelos projetos que já detêm, pelas suas
características, processos de produção repetitivos e conhecidos. Esses processos, pela sua repetição, permitem
a definição de quantidades e tempos bem precisos e dão uma segurança muito grande àqueles que desses
parâmetros se utilizam. O conhecimento pode vir da organização ou de boletins, periódicos, literatura
especializada ou de simulações a partir de modelos e protótipos especificamente realizados para esse fim. A
estimativa paramétrica é muito útil quando estamos trabalhando com equipes padronizadas de produção ou com
tarefas conhecidas. O quociente de volume escalar a ser produzido pela atividade, pelo valor de esforço
conhecido para produção de uma unidade, traz com grande precisão o número de períodos de trabalho
necessários para a sua realização. É conveniente sempre analisar as condições de aplicação para validar o
modelo paramétrico; e a análise de riscos do projeto é muito conveniente, assim como a avaliação de
desempenho e produtividade necessários e disponíveis das equipes envolvidas e o padrão de qualidade
desejado.
4 - Estimativa de três pontos – Essa técnica está atrelada ao princípio definido pela distribuição adotada na
análise PERT – Program Evaluation and Review Technique, que usa uma estimativa de duração por média
ponderada para calcular as durações das atividades. A técnica PERT foi desenvolvida na década de 50 do século
passado para atender a um programa militar das forças armadas americanas e partia do pressuposto de ser
possível definir historicamente as durações mais prováveis, durações como cenários otimistas e cenários
pessimistas para aumentar a precisão e contingenciar possíveis riscos. Essa técnica de promover três pontos
para definição de um valor mais provável não é tão utilizada como no passado, devido a alguns fatores:
 O poder de processamento matemático dos computadores portáteis aumentou de forma considerável,

tornando esse recurso disponível para todos;
 Os modelos de cálculo estatísticos se difundiram e se aprimoraram de tal modo que o nível de precisão
se mostrou mais eficaz para considerações e análises mais precisas;
 O modelo apresentado baseava-se numa curva de distribuição estatística que restringia a modelagem
e comprometia os resultados finais em projetos mais complexos.
Mesmo assim, vale lembrar que três pontos representam mais informação que apenas um e, por isso, mais
considerações podem ser feitas sobre a mesma atividade.
Esses três pontos na técnica apresentada não devem ser confundidos com os três pontos definidos pela filosofia
do gerenciamento de projetos, pela corrente crítica das
atividades. Nesse método de elaboração de planejamento, a
filosofia desloca a atenção da atividade para os recursos.
5 - Curvas de aprendizado – Essa técnica é uma consequência do aprendizado repetitivo e complementar das
três técnicas anteriores. Ela é, normalmente, mais empregada nas modelagens paramétricas e permitem reduzir
o lastro ou o tempo de reserva para valores mais baixos, porém nunca nulos. Isso é explicado pela observação
da repetição de grupos semelhantes de atividades ou de produção de elementos ou pacotes muito parecidos,
dentro de um mesmo projeto ou programa de trabalho. Uma vez que na modelagem paramétrica é possível
utilizar o conhecimento das tarefas repetitivas e conhecidas, na repetição de pacotes de trabalho é possível
manter um monitoramento do nível de aprendizado das equipes alocadas, e dos equipamentos ou máquinas
utilizados, explorando ou refinando os índices de produtividade e desempenho. É previsto que essa técnica seja
conseguida pelos históricos registrados na base de informações da organização.
6 - Entre outras.
Saídas do processo
A saída principal desse trabalho é o registro formal das estimativas de duração da atividade. As melhores práticas
orientam a se acompanhar as durações estimadas das atividades com uma referência de segurança para sua
realização. Isso normalmente é conseguido através de análises de risco ou de dados históricos de projetos em
condições semelhantes.
3.1.5. Desenvolvimento Preliminar do Cronograma

É esperado que o processo de desenvolvimento do cronograma ajude a determinar as datas no calendário de início
e fim para as atividades do projeto, considerando todas as condições estabelecidas no projeto,seja por conta das
suas restrições ou premissas, seja por conta de suas limitações de recursos (restrições) ou por considerações de
datas impostas (contratuais), ou ainda de critérios de operação e construção (restrições de critério). Significa definir
como e quando as atividades necessárias para a realização e entrega dos produtos e serviços serão executadas. O
processo de desenvolvimento do cronograma continua, também, durante a execução, parte integrante do ciclo de
vida do gerenciamento do projeto, que aqui chamaremos de replanejamento. Nesse capítulo será abordada a versão
preliminar do cronograma, respeitando basicamente os padrões mínimos de sua montagem.
3.2. Uso da Ferramenta - Tempo

3.2.1. Definição das Atividades e Marcos

Apesar de na prática os processos de definição das atividades e documentação das atividades se sobreporem, os
apresentaremos de forma separada, visando à facilitação do aprendizado dos recursos da ferramenta e sua
organização em tópicos para otimizar a pesquisa de leitores que estejam utilizando o material para consultar um tema
específico.
Usando da metodologia por nós defendida, vamos criar um modo para trabalhar a definição e a posterior
documentação das atividades e marcos do nosso projeto de reforma da casa feliz, e, por isso, o primeiro item do
nosso capítulo 3 está destinado à apresentação deste modo.
3.2.1.1. Modos Compostos (Combination view)
Até o momento, quando nos defrontamos com a tela “Define New View”, apresentada ao criarmos cada novo modo
do nosso projeto, orientamos a selecionar a opção single
view. Trataremos neste momento das características da
segunda opção.
Para simplificação de nossa linguagem e referência,

trataremos os single views pelo nome de modos simples, e
os combination views pelo nome de modos compostos.
Os modos compostos reúnem dois modos previamente desenvolvidos, apresentados na mesma tela, mesmo que
esses modos possuam screens diferentes, dando ao usuário maior liberdade para geração de um ambiente de
trabalho que atenda suas necessidades. Esses modos são divididos por uma barra horizontal que o usuário pode
mover verticalmente para mostrar mais de um, ou do outro, conforme sua necessidade de visualizar o conteúdo.
Ao selecionarmos a opção Combination view mostrada acima, é exibida a seguinte tela:
Atente para a definição do Primary view e Details Pane. Os dois modos apresentados não
terão o mesmo comportamento, e o entendimento dessa configuração é fundamental
para o entendimento dos modos compostos.
Name: Nome do modo, inserido e utilizado da mesma forma que os modos simples.
Primary View: O modo inserido nesta opção terá comportamento similar aos modos simples, e tudo
que vimos até o momento se aplica 100% a este modo. Para simplificar, chamaremos
este de modo superior, devido a sua posição no modo composto.
Details Pane: O modo inserido nesta opção terá limitada capacidade de apresentação de informações,
sendo subordinado à seleção dos elementos que o usuário realizar no modo superior.
Por exemplo, caso o usuário tenha selecionado a linha de ID 6 no modo superior, o modo
inferior apresenta as informações, respeitando sua screen, do elemento contido na linha
de ID 6. De modo análogo ao primary view, chamaremos estes de modos inferiores.
Quase todas as screens podem ser utilizadas em modos a serem aplicados na parte
inferior de um modo composto, no entanto, não se comportam da mesma forma quando
utilizadas desta maneira. As exceções são: Calendar e Team Planner, que não podem
ser utilizados em modos compostos, e a Timeline, que se caracteriza como uma
aplicação especial de modo composto que será tratada em momento futuro do livro.
Show in menu: Marcação para determinar se esse modo será exibido no menu. Funciona da mesma
forma que a marcação dos modos simples.
Step 04 – WBS + Atividades
Utilizaremos um modo composto para definir e documentar as atividades e marcos do nosso projeto, que chamaremos
de Step 04 – WBS + Atividades. Na parte superior, faremos uso de modo com a screen Gantt Chart, e na parte inferior,
usaremos modo com screen Task Name Form, ambos apresentados neste capítulo.
Step 04 – WBS + Atividades - sup
Como vimos acima, antes de criarmos o modo composto, precisamos ter os modos que o comporão já completamente
definidos. Desta forma, vamos começar criando o modo Step 04 – WBS + Atividades - sup, em que sup faz referência
a sua posição superior.
Apresentamos abaixo a tabela deste modo, desenvolvida segundo o processo de criação de tabelas já apresentado,
e cada campo não previamente apresentado sumarizado em seguida.
Unique ID
Campo que apresenta um código único, jamais passível de repetição ou duplicata, para cada elemento tipo task do
projeto. Este código é referente à ordem de criação do elemento e pode ser utilizado para acompanhamento e resgate
do trabalho de desenvolvimento do arquivo de planejamento e controle.
Text27 (Código da Atividade)
Campo livre tipo texto, conforme apresentado na seção 2.2.2.1. Aqui o uso proposto é a possibilidade de definição de
códigos de referência para os elementos da EAP + Atividades não passíveis de limitação, passíveis de receber prefixo
e sufixo variáveis conforme o elemento, para, por exemplo, atender à metodologia de codificação de qualquer
envolvido no projeto.
Predecessors (Predecessores)
Campo que apresenta em forma de códigos, separados por ponto e vírgula, a lista de atividades e marcos que são
predecessores do elemento. É possível utilizar este campo para sequenciar as atividades e marcos do projeto,
conforme será apresentado na seção 3.2.2.
Flag16 (Pacote de Trabalho)
Custom Field, que apresenta em cada célula da sua coluna dois possíveis valores: “Yes” ou “No”. Aqui utilizaremos
esse recurso para marcar os elementos que representam pacotes de trabalho. Dessa forma, o usuário deverá
selecionar “Yes” manualmente nas devidas células.
Sucessors (Sucessores)
Campo que apresenta em forma de códigos, separados por ponto e vírgula, a lista de atividades e marcos que são
sucessores do elemento. É possível utilizar este campo para sequenciar as atividades e marcos do projeto, conforme
será apresentado na seção 3.2.2.
Milestone (Marcos)
Apresenta tal como um campo livre tipo flag duas possibilidade de conteúdo, "Yes" ou "No", para indicação dos
elementos que representam os marcos (milestones) do projeto. Suas células podem ser editadas pelo usuário para
transformar um elemento em marco, ou vice versa.
Summary (Produtos)
Semelhante ao campo milestones, mostra os elementos classificados como produto pela ferramenta. Lembremos que
o MS Project reconhece como produtos os elementos que possuam outros a ele subordinados, através da indentação.
Diferente dos campos tipo flag e do campo milestone, o usuário não é capaz de alterar os seus valores diretamente,
apenas através da indentação. Este campo é especialmente útil para criação de filtros e reconhecimento de produtos
quando a configuração visual da ferramenta foi modificada a partir da padrão.
Criada a tabela, podemos criar o modo Step 04 – WBS + Atividades - sup, já que o mesmo não possuirá grupo ou
filtro. Criamos o modo seguindo o processo de criação de modos, tomando o cuidado de selecionar a screen correta,
neste caso Gantt Chart. Como este será um modo a ser aplicado em modo composto, recomendamos que não seja
listado no menu e, para isso, deixamos desmarcada a opção show in menu3.
Step 04 – WBS + Atividades - inf
O modo a ser inserido na seção inferior do nosso modo composto Step 04 – WBS + Atividades terá a screen Task
Name Form. Algumas screens da ferramenta (esta, uma delas) não permitem que os modos criados utilizando-as
possuam tabelas, grupos ou filtros, devido a sua própria natureza.
3
É possível que a ferramenta torne esta opção ativa após a aplicação deste modo, mesmo que o usuário a
desabilite.
A screen Task Name Form não apresenta informações em formato de tabela, conforme vimos até o momento,
apresentando-as em campos de formulário pré-definidos, em que visualizamos dados de somente um elemento da
EAP + Atividades (produtos, atividades ou marcos) por vez. Esta característica faz com que o uso ótimo dos modos
criados a partir desta screen seja feito nas seções inferiores dos modos compostos.
Podemos criar o nosso modo Step 04 – WBS +

Atividades - inf através do processo de criação de
modos. No entanto, selecionando a screen Task Name
Form, veremos que as opções de seleção de tabelas e
grupos ficarão inacessíveis. Não aplicaremos filtro a
este modo. Novamente, não marcaremos o modo para
exibição no menu, deixando desmarcada a opção
show in menu.
Recomendamos que, posteriormente, o usuário

experimente também as screens Task Form e Task
Details Form, que possuem formatação semelhante à
Task Name Form.
A criação do modo Step 04 - EAP + Atividades pode agora ser concluída. Criaremos o modo composto selecionando
o nome proposto, os modos Step 04 - EAP + Atividades - sup e Step 04 - EAP + Atividades - inf já criados e marcando
a opção Show in menu, para que o mesmo esteja disponível facilmente nos atalhos de seleção de modos.
Nosso modo Step 04 - EAP + Atividades foi concebido propositalmente mais denso para que possamos mostrar
possibilidades da ferramenta. Ao longo do livro, criaremos outros modos compostos que irão sempre facilitar a
visualização da informação e o trabalho da equipe de planejamento e controle, mas cabe ao usuário definir o modo
ótimo de trabalho baseado nas suas necessidades e recursos disponíveis (é difícil manejar um modo composto em
telas inferiores a 13’’, por exemplo).
Neste momento, vamos aplicar nosso modo recém-construído para realizar a definição das atividades e marcos do
projeto. Ao clicarmos em Apply, devemos encontrar a imagem reproduzida abaixo:
O modo inferior, devido a sua screen Task Name Form, pode apresentar
diferentes formulários. Neste momento, estamos interessados na opção
Notes, que usaremos para inserir o dicionário das atividades e marcos que
criaremos. Para alterar o tipo de formulário apresentado, basta-nos clicar
com o botão direito do mouse em qualquer área cinza do formulário, e na
caixa apresentada selecionar a opção Notes.
O procedimento de definição das atividades do projeto no MS Project 2013 guarda grande semelhança com o
procedimento de definição dos produtos da EAP. No entanto, as primeiras, por serem os elementos que representam
o esforço necessário para viabilizar a entrega dos pacotes de trabalho, apresentarão diversas novas possibilidades
de configuração e necessidade de documentação.
Para inserir atividades dentro dos nossos pacotes de trabalho, primeiramente precisaremos inserir novas linhas, o
que podemos fazer das formas já apresentadas. Dentre elas, a mais simples é pressionar o botão insert do teclado
após selecionar o elemento imediatamente inferior ao local onde deseja inserir a nova linha.
Para respeitar as melhores práticas de trabalho, devemos tomar o cuidado de, conforme apresentado na seção 3.1,
iniciarmos o nome das nossas atividades com verbos no infinitivo. Conforme vamos inserindo linhas e definindo as
atividades, devemos utilizar os campos de codificação das atividades e a área inferior do nosso modo para inserir as
informações pertinentes. Antes de tratarmos deste conteúdo, vamos apresentar como inserir os marcos do projeto na
ferramenta, já que estes também fazem uso de códigos e dicionários.
3.2.1.2. Marcos (milestones) 
Para o MS Project, marcos (milestones) são elementos tipo Task que possuem valor “Yes” no campo de nome
Milestone. Devemos ter em mente esta definição fria e desprovida de carga teórica para utilizar a ferramenta na
modelagem de projetos, sem infringir conceitos de gerenciamento de projetos, apresentados na seção 3.1 deste
capítulo, juntamente com as boas práticas de uso dos marcos nos projetos.
Existem diversas formas de se criar um marco no arquivo de MS Project:
• Selecionar a opção Milestone no grupo Insert da aba Task
Esta opção cria uma nova linha imediatamente acima da atualmente selecionada, já configurada para
representar um marco, com opção
• Definir duração 0 (zero) para um elemento;
Ao definirmos duração nula para uma atividade, a ferramenta automaticamente a define como marco,
respeitando os conceitos de gerenciamento de projetos
• Marcar Yes na coluna milestone
Caso o campo Milestone esteja visível, poderemos realizar a marcação dos elementos que desejamos
transformar em marcos com a opção “Yes”, e “No” para aqueles que não representam marcos.
• Marcar a opção Mark as a milestone na aba Advanced da tela Task Information
Na tela Task Information, na parte inferior da guia Advanced, encontramos a caixa de seleção Mark as a
milestone, que, se marcada, configura o elemento para representar um marco.
Todos estes métodos deveriam ser equivalentes e garantir que o elemento tenha duração nula e campo
milestone marcado como Yes, no entanto, os dois últimos não garantem que o marco terá duração nula,
podendo ser aplicados em atividades com duração e recursos alocados, o que se mostra uma
inconsistência da ferramenta.
Atenção: O MS Project 2013 permite que atividades com duração diferente de zero sejam definidas
como marco. Para verificar este fato, simplesmente crie uma atividade, defina sua duração e
posteriormente marque-a como marco (na coluna milestone ou no task information). O mesmo
comportamento se verifica com produtos, que podem ser definidos como marcos.
Lembramos que as boas práticas de trabalho ditam que os marcos tenham nomes terminados com verbos no
particípio, para representar ações concluídas, por exemplo:
Produto aceito;
Fase A encerrada;
ou iniciados com substantivos tal como:
Início da Intervenção Civil;

Término do Projeto;
3.2.1.3. Códigos das atividades e marcos
Tratamos no item 2.2.2.3. sobre a codificação dos elementos da EAP através do recurso WBS Code. O mesmo pode
ser utilizado para codificação das atividades e marcos do projeto. Apresentamos, no entanto, outras duas maneiras
de definir este importante passo da documentação do projeto.
Como visto na tabela do nosso modo Step 04 – EAP + Atividades – Sup, incluímos os campos Unique ID e Text27,
renomeado para Código da Atividade. O campo Unique ID tem o seu preenchimento automático.
Podemos no campo Text27 definir o código para cada elemento da EAP + Atividade com total liberdade. Infelizmente,
perdemos o automatismo do preenchimento sequencial dos campos WBS e Unique ID, mas viabilizamos inserir na
ferramenta qualquer código capaz de ser reproduzido com elementos alfanuméricos.
Como exemplo, definimos que na Akmeo, empresa responsável pelo projeto Reforma da Casa Feliz, existe padrão
de codificação em que cada prefixo é definido pelo produto no qual o elemento está inserido.
3.2.1.4. Dicionário da EAP + Atividades
Para inclusão do dicionário das atividades na ferramenta, utilizamos novamente o campos Notes, já apresentado no
item 2.2.2.4, ao tratarmos do dicionário da EAP. Nosso modo composto apresenta no entanto a facilidade de
incluirmos as devidas informações com facilidade após a criação de cada atividade.
Sem desejar repetir todo o conteúdo já apresentado na parte teórica do nosso capítulo, nos limitamos a reforçar a
importância da documentação do dicionário das atividades, destacando-se a descrição, objetivo, premissas e
restrições e critérios de aceitação. O dicionário dos marcos também deve ser inserido na ferramenta para
entendimento único entre os envolvidos do que cada um deles representa, como e quando serão considerados
concluídos e por que pessoa ou setor envolvido no projeto.
Após listar as atividades, inserir seus códigos e seus dicionários, podemos continuar utilizando o Step 04 para analisar
nosso trabalho. Caso se perceba a necessidade de mais espaço para visualização, basta-nos um duplo clique na
barra horizontal que separa os modos (superior e inferior) para que o modo inferior seja ocultado (clicar e arrastar a
barra até ocultar o modo inferior também funciona). Esta operação não altera a estrutura do modo, que, caso
novamente aplicado, ainda se mostra um modo composto.
Reproduzimos abaixo uma tabela com a estrutura do cronograma após definição das atividades e marcos do nossos
projeto modelo, destacando a Fase 01.
EAP + Atividades Elementos do Cronograma
Reforma da Casa Feliz Projeto

Início do Projeto Marco
Gestão do Projeto Produto
Fase 01 - Anteprojeto Produto
Anteprojeto Subproduto
Realizar medição Atividade
Layout Pacote de Trabalho

Criar Planta baixa Atividade
Criar Vistas Atividade
Criar Cortes Atividade
Imprimir Layout Atividade
Indicação de Materiais Pacote de Trabalho
Pesquisar materiais Atividade
Criar pasta de amostra Atividade
Imprimir Pasta de amostra Atividade
Perspectivas Pacote de Trabalho
Fazer perspectivas Atividade
Imprimir perspectivas Atividade
Atividades de produção concluídas Marco
Aprovação Pacote de Trabalho
Todas as impressões realizadas Marco
Conduzir reunião de apresentação Atividade
Realizar ajustes no anteprojeto Atividade
Anteprojeto aprovado Marco
Fase 02 - Projeto Produto
Fase 03 - Execução de Obras Produto
Término do Projeto Marco
3.2.1.5. Sequenciamento
A criação de dependências entre as atividades e marcos do projeto, criadas a partir do seu sequenciamento, tem
importante papel na maioria das metodologias de gerenciamento de projetos. O MS Project 2013 dá suporte a quatro
tipos de sequenciamento, representados pelas siglas SS, FS, FF e SF, que representam Início-para-Início, Término-
para-Início, Término-para-Término e Início-para-Término, respectivamente.
Como em todas as operações realizadas nesta ferramenta, é extremamente importante que tenhamos
domínio dos conceitos de gerenciamento de projetos para que possamos modelar o projeto em que
estamos trabalhando. O sequenciamento equivocado de atividades ou o não sequenciamento de todas
as atividades do projeto, deixando a rede aberta, traz consequências severas para o resultado final.
Além do sequenciamento das atividades, temos ainda a possibilidade de criarmos retardos e antecipações utilizando
o recurso lag, ampliando nossas possibilidades de modelagem para o cronograma do projeto. Existem diversas formas
de executar o sequenciamento das atividades e marcos, que apresentamos abaixo:
CTRL + F2
A forma de sequenciamento mais comumente encontrada nas

modelagens de projetos é a Término-para-Início, e isto se reflete na
facilidade que temos para gerar esta relação entre atividades Para simplificação,
modeladas na ferramenta. escreveremos
Temos como forma mais simples de sequenciamento de atividades a utilização do
sequenciamento de
ícone em formato de corrente, reproduzido no canto superior direito desta página, que atividades nesta
se encontra na aba Task, grupo Schedule. Selecionando duas atividades e em apresentação, mas deve-
seguida pressionando este ícone, criaremos uma relação de Término-para-Início se ter em mente que
entre estas atividades.
atividade e marcos
Importante notar que a atividade predecessora será aquela primeiramente devem ser sequenciados
selecionada. Caso mais de duas atividades sejam selecionadas, criar-se-á efeito de forma que a rede
escada, ou seja, serão criadas diversas relações de Término-para-início na sequência esteja fechada: Todas
da seleção das atividades.
atividades e marcos
Caso se deseje criar diversos sucessores para uma mesma atividade predecessora, possuem predecessor,
a operação deve ser repetida para cada vínculo, ou deve-se utilizar as outras técnicas fora o marco de início do
descritas a seguir. projeto e todas as
atividades e marcos
possuem predecessor,
fora o marco de término
do projeto.
O atalho para este ícone é o Ctrl + F2, e não é possível utilizar o recurso de lag com
esta operação.
A seleção de elementos, realizada com o mouse, deve ser auxiliada com os botões Shift e Ctrl do teclado, o
primeiro para seleção de elementos adjacentes, e o segundo para seleção de elementos não adjacentes.
Colunas predecessor e sucessor
Inserimos na nossa tabela Step 4 – EAP + Atividades os campos Predecessores e Sucessores. Além de informar a
relação de precedência entre as atividades e marcos do cronograma, estes campos podem ser utilizados para criar
estas relações em todas as suas variantes, bastando-nos conhecer o padrão utilizado pelo MS Project. Para melhor
compreender, vamos analisar a imagem abaixo:
No campo predecessores da linha de ID 4 podemos perceber toda a possibilidade da coluna Predecessors: 2FS + 1
day, na qual 2 é o ID da atividade predecessora, FS é o tipo de relação - neste caso Finish-to-Start ou Término-para-
Início, e + 1 day é um retardo de 1 dia (sempre segundo o calendário da predecessora). Desta forma, a atividade 4
terá início programado para um dia após o término programado da atividade 2. A unidade de tempo do Lag deve ser
definida de acordo com os padrões da ferramenta. Pode ainda ser definida de forma percentual em relação à duração
da predecessora.
Analisando agora o campo predecessor da atividade 5, podemos notar que, quando o recurso de lag não é utilizado,
a ferramenta omite esta informação do campo, não sendo necessária, por exemplo, a definição de 3FF + 0 day; e
quando a relação é do tipo término-para-Início e não existe uso do recurso lag, podemos incluir somente o ID da
predecessora, como visto no campo das atividades 1, 2 e 6.
Por fim, quando existe mais de uma atividade predecessora, os códigos do campo Predecessors são separados por
“ ; “ (ponto e vírgula), como visto na atividade 6, que possui a atividade 3 e atividade 2 como predecessoras no regime
Término-para Início. O início programado da atividade 6 se dará após o término das atividades 3 e 2.
Todo o exposto neste item é aplicado ao campo sucessor, que apresenta os sucessores das atividades.
Aba Predecessor em Task information
A tela Task Information, já

apresentada, possui aba
de nome Predecessors, na
qual podemos visualizar e
configurar os
predecessores da
atividade.
Podemos definir novos

predecessores inserindo o
seu ID na coluna
correspondente, ou
selecionando seu nome
nas células da coluna Task
Name.
Logo ao lado, em Type,

podemos selecionar e alterar o tipo de relação entre as atividades, dentro dos 4 modeláveis no MS Project (SS, FS,
FF, SF) e em Lag vemos a possibilidade de inserir retardos e antecipações.
Diagrama de Gantt e Diagrama de Rede
O lado direito do diagrama de Gantt, Screen que estamos utilizando para definir nossas atividades, será mais
amplamente discutido no item 3.2.4 deste capítulo, no entanto, cabe adiantar a possibilidade de realizarmos e
editarmos o sequenciamento das atividades através da sua representação gráfica neste útil diagrama.
Atenção: Não recomendamos o sequenciamento das atividades através deste método devido à
possibilidade de alteração de outros parâmetros do cronograma. A seção gráfica do diagrama de Gantt é
capaz de criar restrições, alterar a duração das atividades e atualizar andamento de projeto (% Complete),
por isso somente deve ser utilizada por quem domina a ferramenta e compreende o funcionamento destes
recursos
Para criar novos vínculos, deve-se clicar no meio da barra que representa a atividade predecessora e arrastar o
ponteiro do mouse (com botão esquerdo pressionado) na direção da atividade sucessora (o ponteiro deve se
transformar em uma corrente e uma linha cinza aparecer entre a atividade predecessora e este ponteiro), liberando o
botão do mouse quando seu ponteiro estiver sobre a atividade sucessora. A relação criada será do tipo Término-para-
Início.
Para alterar qualquer vínculo entre atividades, basta dar

duplo clique na seta que representa esta relação no gráfico
de Gantt, e a seguinte tela ao lado será apresentada,
mostrando as possibilidade já apresentadas.
Recurso muito semelhante é encontrado nos modos tipo Diagrama de Rede (Network Diagram), apresentados
também no item 3.2.4 deste capítulo, sendo o processo de criação e edição dos vínculos exatamente igual. Entretanto,
nestes modos, devemos tomar o cuidado adicional para não criar novas atividades, o que ocorre quando utilizamos
o processo descrito acima para criar dependências e liberar o ponteiro do mouse fora das caixas que representam as
atividades e marcos.
Lags – Retardos e Antecipações
Fazendo um breve resumo do recurso de lag para criação de retardos e antecipações, vimos que podemos criá-lo
diretamente nas colunas Predecessores e Sucessores, na aba predecessor do Task Information e editando links no
diagrama de Gantt e diagrama de Rede, e ainda:
▪ Usa o calendário da predecessora;
▪ Para criação de antecipações, devemos inserir valores negativos: - 1 day, -2 h;
▪ As unidades de tempo devem respeitar os padrões da ferramenta;
▪ Podemos criar lag percentual + 20%, -15%, sendo o valor referente à predecessora
▪ Quando não utilizado, é omitido da coluna predecessores e sucessores.
Step 05 – WBS + Atividades - Relacionamento
Vamos neste momento desenvolver um modo composto como alternativa para visualização do trabalho de
sequenciamento das atividades e marcos enquanto o mesmo é realizado, sendo ainda útil para apresentação do
sequenciamento das atividades para a equipe de planejamento e controle do projeto e envolvidos mais próximos, que
desejem receber informações mais precisas do desenvolvimento do arquivo de modelagem do projeto.
No modo superior teremos uma cópia do

modo Step 04 – EAP + Atividades – Sup e
criaremos o modo inferior utilizando a
screen Relationship Diagram, que será
apresentada.
Step 05 – WBS + Atividades –

Relacionamento - Sup
Para criação do nosso modo superior,

criamos uma cópia da tabela Step 04 –
EAP + Atividades - Sup, nomeando-a Step
05 – EAP + Atividades – Relacionamento
– Sup.
Não desenvolvemos grupos ou filtros para este modo, portanto o criamos conforme visto ao lado.
Step 05 – WBS + Atividades –
Relacionamento - Inf
Esta screen permite a visualização de todos

os predecessores e todos os sucessores de
uma única atividade ou marco, selecionada
no modo superior, de forma simples,
podendo inclusive discernir o tipo do vínculo
e se existem retardos e antecipações em
cada relação.
Seu uso mais eficiente se dá como modo
inferior de um modo composto, tal qual
estamos realizando.
O resultado da construção do modo Step 05 – EAP + Atividades – Relacionamento é apresentado abaixo. Importante
notar mais uma vez que o modo inferior apresentará informações conforme a seleção realizada no modo superior e
conforme a relação dos modos compostos.
Findo o sequenciamento de todas as atividades e marcos, passaremos para o processo de documentação destes
elementos definidos, no entanto recomendamos que o trabalho realizado seja conferido para garantia de rede fechada
e não sequenciamento de produtos4.
Lembramos, novamente, que estes processos foram segmentados para melhor apresentá-los e para facilidade de
consulta ao livro, que normalmente se sobrepõem, sendo a forma específica de trabalho responsabilidade da equipe
de planejamento.
3.2.2. Atributos das Atividades e Marcos
Vimos no item anterior do nosso capítulo 3 a definição de atividades e marcos e o início de suas documentações.
Continuaremos neste item com a documentação das atividades definindo seus parâmetros e configurações para que
seja possível a criação do cronograma do projeto, mesmo que de forma preliminar, já que não contemplaremos no
capítulo 3 o uso e restrições de recursos ou de custos, temas dos capítulos 4 e 5 respectivamente.
4
O MS Project 2013 possui proteção para o não sequenciamento de elementos tipo summary. Mesmo com
este recurso, recomendamos a verificação.
Os quatro parâmetros aqui apresentados, após devidamente configurados, juntamente do trabalho já desenvolvido
até o momento nos permitirão definir as datas de início e
término previstos para cada atividade do nosso projeto. Para
nos ajudar com este trabalho, criaremos o modo Step 06 –
Atributos das Atividades, descrito abaixo.
Step 06 – Atributos das Atividades
Nosso próximo modo será simples (não será um modo

composto) e trará screen tipo Gantt Chart, nenhum grupo e
nenhum filtro. Apresentamos abaixo sua tabela, definida a
partir do processo de criação de tabelas, e em seguida
informações dos campos inéditos.
Type (Tipo da Tarefa)
Exibe e permite a alteração do tipo da atividade, classificação relativa ao elemento que a ferramenta mantém fixo na
fórmula W=D*R (Trabalho = Duração * Recurso), conforme visto na seção teórica. No capítulo 1 configuramos a
ferramenta, para que, por padrão, as atividades criadas nela apresentassem o tipo duração fixa, sendo esta a nossa
recomendação durante a etapa de planejamento do projeto.
A tabela a seguir resume o comportamento dos componentes desta relação (W = D*R), quando um dos termos é
modificado, em relação ao tipo da atividade.
Se você alterar o(a)

Em atividades tipo
unidades duração trabalho
duração é trabalho é duração é

Unidades fixas
recalculada recalculado recalculada
duração é unidades são duração é

Trabalho fixo
recalculada recalculadas recalculada
trabalho é trabalho é unidades são

Duração fixa
recalculado recalculado recalculadas
Dentro do comportamento das relações entre os termos desta equação, podemos ter uma variação no Trabalho
(work), caso a atividade esteja configurada como Effort Driven (Dirigida ao Esforço). Effort Driven é um campo da
ferramenta que apresenta valores de Yes e No. Se uma atividade possui valor Yes, novos recursos adicionados à
atividade, após o primeiro, não aumentam o valor do campo work. Isto não se aplica ao aumento ou redução da
quantidade de unidades do primeiro recurso alocado, mas sim a novos recursos alocados. Recomendamos que esta
opção esteja desabilitada (valor No) para todas as atividades, portanto não a incluímos na nossa tabela de trabalho
no modo Step 06 – Atributos das Atividades
Number19 (volume) e Text26 (unidade)
Vimos na seção 3.1 que podemos realizar estimativa da duração das atividades de forma indireta, através da análise
do volume de trabalho por ela representado e estimativa de produtividade dos recursos alocados. Esta opção não é
nativa da ferramenta, e para viabilizá-la devemos utilizar campos livres com fórmulas, ou outros aplicativos, o que
será discutido em momento futuro.
Propomos esta documentação mesmo que se saiba que outro será o método utilizado para estimativa de duração
das atividades, já que colabora de forma geral com a documentação das atividades para garantia de entendimento
único entre os envolvidos do projeto e, dependendo da natureza do mesmo, se mostra como importante ferramenta
para a definição das métricas de controle.
Duration
Apresenta a duração da atividade a ser inserida após a definição da técnica de estimativa a ser utilizada. Deve-se
respeitar os padrões de unidades e abreviação da ferramenta, como os exemplos abaixo:
20 min 20 minutos 3 wk 3 semanas

4 hrs 4 horas 1 mon 1 mês
2 days 2 dias
A unidade padrão da ferramenta, usada em fórmulas, é o minuto, e, dessa forma, caso incluamos duração em unidade
superior, a duração real será definida de acordo com as configurações em FILE, Options e Schedule, realizadas no
capítulo 1. Portanto, na duração estamos informando a quantidade de minutos necessários para a execução da
atividade; o agendamento e as datas de início e término são definidos pela duração, mas também por muitas outras
variantes.
Expandiremos a apresentação deste campo no item 3.2.2.1 a seguir.
Work e Resource Names
Inserimos estes campos na nossa tabela para uso posterior ao longo da etapa de planejamento, já que serão
apresentados no próximo capítulo, Gerenciamento dos Recursos. O campo Work apresenta o valor da multiplicação
da duração pela quantidade de recursos alocados, e o campo Resource Names apresenta uma lista dos recursos
alocados e suas quantidades.
Start e Finish
Datas de início e término da atividade, respectivamente. Apesar de existir a possibilidade, não devemos inserir os
valores da data de início e término que desejamos para cada atividade, e sim deixar que a ferramenta as calcule com
base na data de início do projeto, duração das atividades, calendário utilizado, sequenciamentos realizados e
restrições inseridas de forma consciente.
Caso incluamos manualmente valores nestes campos, estaremos criando restrições no cronograma que, não
compreendidos, podem gerar a falsa impressão de atendimento às premissas do projeto, gerando grandes prejuízos.
Constraint Type e Constraint Date
Temos no MS Project a possibilidade de restringir a possibilidade de agendamento das atividades e marcos do

cronograma como ferramenta de modelagem de nossos projetos. O campo Constraint Type informa e permite a
alteração do tipo de restrição atualmente utilizada em cada atividade e marco; e no campo Constraint Date
encontramos a data de referência para este recurso.
Trataremos dos campos Constraint Type e Constraint Dateno no item 3.2.2.4, em que apresentaremos todas as
possibilidades de restrição, recomendações de uso e recomendações de restrições, que devem ser sempre evitadas.
Deadline
Quando existe neste campo informação de uma data, esta define o prazo de término para a atividade, marco ou
produto, sem restringir o agendamento destes elementos no cronograma. Caso este prazo seja infringido, um ícone
vermelho de alerta será exibido no campo Indicators. Completaremos a apresentação deste campo no item 3.2.2.3.
Task Calendar
Mostra o calendário aplicado à atividade. Caso o valor none esteja selecionado, a atividade estará utilizando o
calendário padrão do projeto, definido na opção Project Information, da aba Project.
A definição correta dos calendários utilizados no projeto é etapa importantíssima na modelagem do projeto na
ferramenta MS Project, capaz de influenciar todo o cronograma. Expandiremos a apresentação deste campo no item
3.2.2.2, cujo conteúdo será aproveitado quando definirmos os calendários dos recursos disponíveis no projeto.
Linked Fields
Apresenta valores Yes ou No, dependendo se o elemento possui ou não vínculos dinâmicos. Uma aplicação do uso
de vínculos dinâmicos é apresentada no item 3.2.3.1 para criação de atividades tipo hammock.
3.2.2.1. Calendários
Com o recurso de customização de calendários, possuímos grande liberdade para modelagens de padrões fixos de
agendamento para as atividades. Problemas como atividades que só podem ser agendadas às quartas-feiras entre
8:00 e 13:00, em certos meses do ano, ou no período noturno, e inclusão de feriados, por exemplo, podem ser
solucionados com o uso deste recurso.
Recomendamos cuidado extra daqueles que estão iniciando seus estudos da ferramenta para com a definição de
calendários e como eles interagem com o agendamento das atividades. Os calendários definem as janelas de
possibilidade de agendamento para as atividades, que deverão encaixar suas durações nessas janelas. Assim, se
temos um atividade de duração definida como 1,5 days (12 horas, segundo nossas configurações
em FILE, Options, Schedule), em um calendário padrão, em que temos 8 horas disponíveis de
trabalho ao dia, e se esta atividade tem início agendado para a primeira hora (ex.: 8:00) do dia 1
do cronograma, terá término previsto para 12:00h do dia 2 do cronograma.
Se por outro lado, o calendário desta atividade somente permitisse que fosse agendada entre as
8:00 e 12:00 (4h por dia), ela teria início às 8:00 do dia 1 e término previsto para 12:00 do dia 3,
mas no campo duração ainda veríamos 1,5 days.
Para acessar os calendários,

devemos clicar no ícone
Change Working Time,
disponível na aba Project, e a
tela de mesmo nome será
exibida. Nela seremos capazes
de visualizar e modificar os
calendários existentes, e criar
novos calendários para nosso
projeto.
1– Seleção do calendário
apresentado
2– Visualização do resultado da
configuração do calendário
3– Lista de exceções do
calendário
4– Semanas de trabalho
5– Criar novo calendário
6– Atalho para FILE, Options,

Schedule
7– Botão OK, deve ser pressionado para aplicação de qualquer alteração feita nesta janela
Para apresentação dos itens desta tela, criaremos um

calendário para uso em nosso projeto modelo. Iniciamos
pressionando o botão Criar novo calendário. Temos a
possibilidade de copiar um calendário existente, herdando
suas configurações de semana de trabalho e exceções, mas
não o desejamos neste momento, motivo pelo qual
selecionamos a outra opção Create new base calendar.
Existem dois parâmetros a serem configurados para os calendários do projeto: as semanas de trabalho e as exceções.
As semanas de trabalho (Work Weeks) definem os períodos padrão de trabalho, para cada dia da semana, definindo
a hora exata de início e término desses períodos. Para customização da nossa semana de trabalho, devemos clicar
no botão Details para recebermos a tela abaixo.
Podemos perceber do lado esquerdo a lista de

dias da semana, a serem selecionados para
configuração dos períodos de trabalho, sendo
possível a seleção simultânea de mais de um dia
para agilizar a tarefa.
Após selecionar os dias a serem configurados, na

direita, temos três opções:
• Use Project default times for these days.

(Usar períodos padrões do Project)
Nesta opção, sábado e domingo não possuem períodos de trabalho, e de segunda a sexta-feira temos
trabalho entre 8:00 e 12:00 e novamente entre 13:00 e 17:00, completando 8 horas de trabalho ao dia. Esta
opção deixa desabilitada a caixa de definição de períodos de trabalho, no entanto podemos visualizar em
cinza claro os padrões da ferramenta.
• Set days to nonworking time.

(Configurar dias para não-trabalho)
Torna o dia selecionado em dias de não-trabalho, desabilitando a caixa de definição de períodos de trabalho
e configurando esses dias com 0 horas de trabalho.
• Set day(s) to these specific working times:

(Configurar períodos específicos para esse(s) dia(s):)
Aqui temos a possibilidade de usar a caixa de definição de períodos de trabalho para personalizar o nosso
calendário. Devemos criar o início e término de cada período com precisão de minutos, conforme a imagem
acima.
No nosso exemplo decidimos por manter o calendário com a semana padrão, com exceção das segundas-
feiras, que foram editadas para permitirem trabalho entre 13:00 e 17:00 (4 horas), representando que o
período matinal das segundas não está disponível para as atividades às quais esse calendário for vinculado.
O trabalho desenvolvido com os calendários do MS Project deve ser registrado e documentado

para fácil comunicação entre os envolvidos do projeto.
É possível a criação de semanas de trabalho adicionais para uso no mesmo calendário, sendo cada semana atribuída
a um período bem definido, conforme visto no exemplo abaixo. O procedimento de definição de cada semana é
exatamente igual ao já apresentado.
Na falta de um período definido, por exemplo, após dezembro de 2013, a semana [Default] será utilizada.
As semanas de trabalho nos dão grande flexibilidade para a definição dos padrões de trabalho e não-trabalho dos
calendários, mas comumente temos que criar exceções nestes padrões, por exemplo com a ocorrência de feriados.
Alterando a exibição para a aba Exceptions, podemos alterar a configuração dos períodos de trabalho para dias
específicos do nosso calendário, inclusive definindo recorrência. Para exemplificar, vamos criar três exceções:
Carnaval
Ignorando a semana de trabalho definida para nosso calendário, definimos os dias 11 e 12 (segunda e terça-feira) de
fevereiro de 2013 como dias de não-trabalho, respeitando a manifestação cultural brasileira mais esperada do ano, o
carnaval.
Pré-Carnaval
Seguindo uma premissa organizacional, definimos o dia 8 de fevereiro de 2013 (sexta-feira) como um período de
trabalho com início às 8:00 e término às 12:00, removendo o período da tarde. Fazemos isso com um duplo clique na
recorrência recém-criada, ou clicando no botão Details e alterando a configuração da exceção.
Natal
Todo dia 25 de dezembro é feriado, de forma que além de procedermos como no caso do carnaval, tornando a data
dia de não-trabalho, definimos recorrência anual para esta exceção.
O uso de exceções pode ser uma alternativa ao uso de diversas semanas de trabalho, com o benefício da
possibilidade de definição de padrões de recorrência anuais. Por exemplo, em projetos de construção de hidrelétricas,
certas atividades somente podem ocorrer nos períodos de cheia dos rios, enquanto outras somente nos períodos em
que a vazão é mínima. Esses períodos são conhecidos e pode-se considerar constantes ao longo dos anos. Se
definíssemos diversas semanas de trabalho, teríamos de fazê-lo para cada ano do projeto, enquanto a exceção
criada com recorrência anual seria apenas uma.
Temos acima novamente

exemplificada a necessidade de
entender o arquivo de MS Project
como o modelo computacional do
projeto, escapando dos rótulos e
padrões já definidos para atender
às necessidades dos envolvidos, e
reafirmando a necessidade de
documentação das premissas de
planejamento e modelagem.
Com a junção de diversos

calendários, semanas de trabalho
e exceções, as possibilidades de
agendamento de atividades para
atendimento ao nosso projeto
modelado são grandemente
beneficiadas.
Devemos lembrar que a configuração de calendários não altera o valor padrão de horas para um dia, semana ou mês,
configurado em FILE, Options, Schedule, e ainda de clicar no botão OK após as alterações realizadas em nosso
calendário para que as mesmas sejam salvas no sistema.
Após a criação dos calendários adequados às necessidades do projeto, recomendamos que um calendário base,
aquele que será utilizado na maioria das atividades, seja aplicado como calendário padrão do projeto. Para isso nos
direcionamos para a aba Project, ícone Project Information, opção Calendar e selecionamos o calendário que atende
o papel de calendário padrão.
Para toda atividade que um calendário específico não for definido, o calendário padrão será o utilizado, e para
definição de calendários específicos para as atividades do nosso projeto, inserimos a coluna Task Calendar na tabela
do modo Step 06 – Atributos das Atividades
3.2.2.2. Deadlines
Inserimos na tabela Step 06 – Atributos das Atividades, o campo Deadline, renomeado para Data
Limite. Como o nome sugere, usamos este campo para definir datas para as atividades a serem
utilizadas como pontos de referência dos quais não devem ultrapassar.
Para inserir a data de referência do deadline, podemos usar diretamente o campo (coluna deadline)
!
ou usarmos a aba advanced da tela Task Information, apresentada na seção 2.2.2.4. Dicionário da EAP (Notes).
O benefício do uso de deadlines está no fato de, caso a data de término, de fato, ultrapasse a definição do deadline,
por quaisquer motivos, este não impede nem restringe o reagendamento da atividade de qualquer maneira. Temos
como consequência da quebra do deadline o aparecimento de um indicador de atenção no formato de um losango
vermelho com ponto de exclamação no campo Indicators. Este indicador sempre significa que uma deadline não está
sendo cumprida, cabendo ao usuário analisar a situação.
A ferramenta permite que criemos deadlines para qualquer elemento tipo task, seja ele atividade, marco ou produto,
cabendo ao usuário decidir o melhor uso para suas necessidades. Recomendamos que, por padrão, deadlines sejam
inseridas somente em atividades e marcos, objetos mais fáceis de trabalhar em momentos de atualização do
cronograma com possíveis modificações e reordenação da EAP. As premissas usadas para definição de deadlines
devem ser documentadas no dicionário das atividades.
3.2.2.3. Restrições
Encerramos este conjunto de atributos apresentando as restrições de cronograma, nome que demos para o campo
constraint type, que atribuímos à cada atividade e marco do nosso projeto.
Existem ao todo 8 tipos de restrições na ferramenta MS Project, e cada atividade e marco necessariamente estão
associados a uma restrição. De forma semelhante ao recurso de deadline, podemos modificar a restrição das nossas
atividades no campo Constraint Type e Constraint Date, ou pela tela Task Information (aba advanced).
O uso de restrições sem o devido entendimento do impacto causado no cronograma traz sempre consequências
desagradáveis, devendo alguns dos tipos de restrição serem sempre evitados, e outros usados com parcimônia.
Dividimos seus tipos de acordo com o grau de flexibilidade imposto ao elemento do cronograma para apresentação
das restrições.
Restrições flexíveis
As Soon As Possible (Mais cedo possível);

As Late As Possible (Mais tarde possível).
Segundo nossas configurações na tela Project Information, realizadas no capítulo 1, nosso projeto está sendo
agendado segundo sua data de início. Esta configuração define a restrição padrão das atividades definidas
em nosso arquivo, no caso as soon as possible (ASAP).
Atividades ASAP são criadas de forma que seu início coincida com a data de início do projeto (data mais cedo).
Com o trabalho de sequenciamento, uso de calendários, estimativa de duração e outras etapas do
planejamento, ficamos conhecendo a data de término do projeto. Este é o tipo de planejamento (Schedule
from Project Start Date) e restrição (ASAP) recomendados para a grande maioria das modelagens.
Por outro lado, caso optamos por planejar segundo a data de término do projeto, definimo-la, e todas as
atividades criadas no arquivo serão agendadas o mais tarde possível (as late as possible, ou ALAP). Todas
terão término igual à data de término do projeto e, novamente de acordo com o trabalho de planejamento
desenvolvido, conheceremos o cronograma e a data de início das atividades e do projeto como um todo. Este
planejamento atende somente a casos e necessidades específicas.
O tipo de agendamento define a restrição padrão das atividades, no entanto somos capazes de editar e definir
a restrição de cada uma delas, para atender nossas necessidades.
Essas restrições são consideradas flexíveis por não restringirem a data de início ou de término das atividades,
mas apenas orientar o fluxo de agendamento das mesmas.
Restrições Semiflexíveis
Start No Later Than (Não Iniciar Depois De)

Finish No Later Than (Não Terminar Depois De)
Estas restrições impedem que o início (Start No

Earlier Than) ou o término (Finish no earlier Than)
ocorram após a data de referência, definida no
campo Constraint Date. Caso, por motivo qualquer,
a atividade naturalmente cumpra esta restrição, uma mensagem de erro surgirá na tela informando o conflito
de agendamento (um exemplo é mostrado ao lado).
Temos como grande problema deste tipo de restrição a criação de incoerências na modelagem do nosso
projeto. Verifiquem o exemplo abaixo, no qual existe restrição na atividade Exemplo2 do tipo Não Terminar
Depois de :
Podemos ver que as restrições ignoram o sequenciamento das atividades, com o início da atividade Exemplo2
programado para antes do término da atividade Exemplo1, o que infringe o vínculo de término-para-início.
Mais que isso, caso o motivo para o conflito tenha sido o atraso da atividade Exemplo1, todo o caminho de
atividades sucessoras a Exemplo2 não terá suas datas reagendadas para representar este atraso.
Complicando a situação, existe a possibilidade de, na tela mostrada anteriormente, marcarmos a opção ‘Don’t
tell me about this again” (Não me fale sobre isso novamente) e o MS Project não mostrará novamente este
tipo de aviso, caso no qual o conflito ocorreria de forma a dificultar nossa percepção do problema.
Por esses motivos, recomendamos o uso destes tipos de restrição somente em casos em que se mostrem
como única opção para a modelagem do projeto, quando recomendamos que em todos os modos exista uma
identificação clara dos elementos que usam este recurso, como, por exemplo, alteração da cor de fundo de
suas células para vermelho claro.
Restrições de tipo diferente de ASAP e ALAP, quando usadas nas atividades e marcos, adicionam seu ícone
no campo indicators. Caso ocorra algum conflito, este ícone muda para alarmar o usuário.
Finish No Earlier Than (Não Terminar Antes De)

Start No Earlier Than (Não Iniciar Antes De)
É semelhante ao caso anterior, mas impede que o início ou término das atividades ocorram antes da data de
referência, atrasando-os, de fato, para atender à restrição, caso naturalmente ocorressem antes desta data,
mas não impedindo que possuam data posterior, caso o cronograma evolua para este cenário.
O ponto principal é o não impedimento de atraso da atividade modelada. O uso destas restrições é
aconselhável para colaboração à modelagem do projeto, sempre que se mostrar necessário, e lembramos que
a devida documentação deve ser realizada.
Restrições inflexíveis
Must Finish On (Deve terminar em)

Must Start On (Deve iniciar em)
Os dois últimos tipos de restrição definem a data na qual a atividade deve iniciar ou terminar, e nenhuma outra
força no cronograma será capaz de alterar isso. Pelos mesmos motivos dos casos Start No Later Than e Finish
No Later Than, intensificados pela maior força da restrição, não aconselhamos o uso destes tipos de restrição
em nenhum tipo de modelagem de projeto.
Se é grande a prioridade para atendimento de uma data específica, devemos trabalhar os elementos do
cronograma para que isto ocorra, compreendendo o modelo desenvolvido e as forças que atuam a favor e
contra o cumprimento desta data. Somente travar a modelagem computacional não é garantia de atendimento
desta data.
Caso o trabalho desenvolvido seja um planejamento preliminar de alto nível, caso no qual muitos usuários
sentem-se tentados a utilizar as restrições, temos no recurso de atividades manualmente agendadas, descrito
no item a seguir, uma solução mais simples e mais facilmente ajustável e revertida para a forma padrão de
agendamento.
Resumindo nossas recomendações de uso das restrições por cores autoexplicativas, temos:
As Soon As Possible (Mais cedo possível)

As Late As Possible (Mais tarde possível)
Finish No Earlier Than (Não Terminar Antes De)
Start No Earlier Than (Não Iniciar Antes De)
Start No Later Than (Não Iniciar Depois De)
Finish No Later Than (Não Terminar Depois De)
Must Finish On (Deve terminar em)
Must Start On (Deve iniciar em)
3.2.3. Definição e documentação de atividades especiais

Decidimos por segregar estes três tipos de atividade por apresentarem comportamento e configurações diferentes
das demais, seja por se tratarem de recursos específicos da ferramenta, ou usos diferenciados de elementos
previamente apresentados para possibilitar modelagens não permitidas normalmente pelo MS Project.
Atividades ativas e inativas (campo active) serão apresentadas somente no capítulo 8, Gerenciamento do Risco.
3.2.3.1. Atividades Manualmente Agendadas
A partir de sua versão 2010, o MS Project apresenta duas possibilidades de agendamento

para as atividades do projeto, agendamento manual e agendamento automático. No nosso
capítulo 1 configuramos a ferramenta para que novas atividades fossem criadas com
agendamento automático, e todo o trabalho desenvolvido até este momento, e no restante
do livro, utilizará este tipo de atividades. Trataremos aqui das propriedades das atividades
manualmente agendadas.
Numa primeira análise, tarefas manualmente agendadas têm seu início e término definidos pelo usuário, não fazendo
a ferramenta qualquer interferência destes valores, ou seja, essas atividades não são impactadas por seu
sequenciamento5, seus calendários, nivelamento de recursos, restrições, ou qualquer outra função de agendamento
de atividades do MS Project. Em teoria, a equipe de planejamento ao usar este recurso tem controle absoluto sobre
as atividades do projeto, podendo definir seus inícios e términos conforme sua vontade.
Atividades manualmente agendadas não precisam ter seus valores de início, término e duração definidos segundo os
padrões normais da ferramenta, sendo possível a inclusão de
textos. Dessa forma, poderíamos criar uma atividade com
início “semana que vem”, duração “de 3 a 5 dias”, etc. Caso
dois desses valores sejam inseridos dentro do padrão de data
e duração da ferramenta, a atividade será capaz de se
agendar no cronograma.
Por padrão, a configuração visual do gráfico de Gantt diferencia as atividades manuais das automáticas, e dentre as
atividades manuais também existe diferença dependendo da forma como seus valores de início, término e duração
foram inseridos. O campo utilizado para diferenciar atividades manuais de limites conhecidos, daquelas criadas com
início, término ou duração fora do padrão reconhecido pelo MS Project se chama Placeholder.
Pelas suas características, somente recomendamos que o agendamento manual seja utilizado em arquivos que
representam versões preliminares do cronograma, de baixo nível de detalhes, criadas para facilitar a comunicação
entre os envolvidos no projeto, provavelmente por responsáveis pela administração do empreendimento. Outro
possível uso pode ser gerar imagens para ilustrar apresentações.
A ferramenta foi concebida para nos ajudar na modelagem de um cronograma que se atualize com base nos diversos
parâmetros que configuramos, já que não conseguimos (ou nos tomaria muito tempo) manter o mesmo nível de
controle com papel e caneta. Este recurso reduz o MS Project a uma ferramenta de anotações, e em nenhum
momento seu uso se justifica dentro do arquivo do cronograma do projeto.
3.2.3.2. Atividades Hammock
Poderíamos traduzir Hammock como rede de pendurar, como as utilizadas pelos povos indígenas para dormir ou nas
nossas casas de veraneio para cochilar. Essa tradução nos dá uma boa ideia das características desse tipo de
atividade, que possui duração variável devido às suas datas de início e término estarem amarradas e condicionadas
à datas de outras atividades ou marcos do projeto.
As atividades tipo Hammock não são nativas da ferramenta, e o procedimento que apresentaremos a seguir foi
desenvolvido para contornar essa as limitações do software. Faremos uso de links dinâmicos entre datas de início e
término do projeto para o agendamento desta atividade cuja modelagem atende perfeitamente às atividades de
gerenciamento, supervisão, coleta de resíduos, dentre outras que devem permanecer ativas enquanto suas atividades
relacionadas também o estiverem.
O procedimento é bem simples. Copiaremos (Copy) o conteúdo da célula início do elemento de referência do início
da atividade Hammock o colaremos (Paste) na célula início da atividade hammock de forma dinâmica, assim caso o
valor da célula de origem se altera, esta alteração se dará também na célula início da atividade de supervisão.
5
Ao serem sequenciadas pela primeira vez, as atividades manuais respeitam este link, mas caso o mesmo seja
atualizado, não acompanham a atualização do cronograma. Para desabilitar inclusive esta atualização, vá em
FILE, Options, Schedule e desmarque Update manually scheduled tasks when editing links.
Fazendo o mesmo para a célula de término, teremos uma atividade de duração elástica, definida pelos valores de
dois outros pontos do projeto.
Vamos apresentar os passos e construir a atividade de Controle e Supervisão do nosso "projeto exemplo".
1. Passe o tipo da atividade para Fixed Units.
Como estamos criando uma atividade de duração elástica, não podemos manter seu tipo como duração fixa. Dessa
forma alteamos o tipo no campo Type, ou em Task Information, aba advanced.
2. Copie o conteúdo da célula que representa início.
Desejamos no nosso exemplo que a atividade hammock esteja ativa durante todo o
projeto, e desta forma usaremos os marcos de início e término do projeto para sua
criação. Copiamos (Ctrl + C) então o conteúdo da célula início do marco Início do
Projeto.
3. Cole na célula início da Hammock
Para colar, não utilizamos o atalho Ctrl + V. Após selecionar a célula de destino, vamos clicar na opção colar especial,
encontrada no ícone Paste, na aba Task. Na tela apresentada, selecionamos a opção Paste Link:, e em seguida Text
Data.
Feito isso, clicamos no botão

OK, e poderemos perceber que
um pequeno triângulo cinza
aparecerá no canto inferior
direito da célula destino. Ainda,
um duplo clique nesta célula faz
com que a célula de origem seja
selecionada.
4. Repetir os passos 2 e 3
para a data de término.
No nosso exemplo, copiamos a

data de término do marco de
término do projeto e colamos de
forma dinâmica na data de
término da nossa atividade
hammock.
5. Rever os atributos da
atividade Hammock
De forma geral, atividades

hammock não devem ser sequenciadas e possuir restrição diferente de ASAP. Entendendo a mecânica de
agendamento desta atividade, o usuário pode utilizar calendários, recursos e outros elementos do cronograma
normalmente.
Devido à percepção de instabilidade do software, não recomendamos que sejam criadas mais de 10 vínculos
dinâmicos no mesmo arquivo, ou seja, mais de 5 atividades hammock. Sendo necessário, alterar a atualização dos
vínculos de automático para manual pode trazer mais confiabilidade ao sistema, mas cabe ao usuário perceber como
sua máquina e o programa estão reagindo.
Para visualizar todos os vínculos dinâmicos do arquivo, e poder passar a atualização para manual, vamos editar a
barra de ferramentas de acesso rápido (Quick Access Toolbar) para incluir a opção Edit Links.
Conforme descrito anteriormente, clicamos na seta que marca o término desta barra e escolhemos a opção More
Commands...
Na tela que nos é apresentada, selecionamos primeiramente a opção todos os comandos (All Commands) e a seguir
localizamos a opção Edit Links, clicando então em Add para adicionar à nossa barra de ferramentas.
Clicando no ícone Edit Links, a ferramenta nos apresenta sua tela Links, onde podemos configurar os vínculos
dinâmicos criados com este arquivo.
A criação de atividades tipo hammock exemplificam a utilização de vínculos dinâmicos, no entanto podemos utilizar
este recurso em diversos outros campos da ferramenta, inclusive com fonte ou origem externa ao arquivo, com uma
célula do excel por exemplo. Todos esses vínculos aparecerão na tela Edit Links, e elementos da EAP + Atividades
que possuam links dinâmicos terão valor Yes no campo Linked Fields, último da nossa tabela Step 06 – Atributos das
Atividades.
Arquivos que apresentam Links dinâmicos apresentam, sempre que são abertos, uma mensagem nos perguntando
se desejamos manter esses links. Clicando em Yes, manteremos os vínculos e atualizaremos os valores segundo
estes vínculos. Clicando em no, manteremos os valores como estavam da última vez que foram atualizados.
3.2.3.3. Atividades Recorrentes
Durante a modelagem das atividades do nosso projeto, podemos nos deparar

com algumas que devem ser criadas em intervalos regulares, seguindo
padrão conhecido de recorrência. Existe na ferramenta um recurso para
facilitar esta modelagem, de forma a reduzir o esforço do usuário, sendo este
recurso conhecido como Recurring Task (Atividades recorrentes).
Encontramos o ícone para inclusão de atividades recorrentes na aba Task,

grupo Insert. A imagem abaixo ilustra o rumo final. Ao selecionar a opção
Recurring Task, nos é mostrada a tela apresentada a seguir.
1 – Nome
Aqui definimos o nome padrão para as atividades criadas através deste recurso. Após a criação das
atividades os seus nomes serão seguidos de números crescentes. É possível editar o nome das atividades
individualmente após a sua criação, de forma a atender alguma necessidade específica. Atente, no
entanto, que sempre que houver uma atualização das atividades recorrentes (nunca automáticas, sempre
realizadas pelo usuário) que as forcem a serem reagendadas, os nomes serão convertidos ao valor padrão.
2 – Duração
Selecionamos aqui a duração padrão das atividades criadas. Da mesma forma que os seus nomes, as
durações podem ser editadas individualmente, mas deve-se ter em mente a possibilidade de conversão
para o valor padrão.
3 – Padrão de recorrência
O MS Project 2013 fornece liberdade para definirmos uma grande gama de padrões de recorrência.
Primeiramente, devemos selecionar a base, que pode ser diária, semanal, mensal ou anual, e, em
seguida, configuramos a frequência com base nesta base.
Ex. 1: de 3 em 3 dias úteis segundo calendário estipulado, ou calendário padrão

Ex. 2: Todo dia 15 de cada mês
4 - Extensão da recorrência
Devemos especificar a partir de quando as atividades desse conjunto de recorrências devem ser criadas,
e, para isso, basta informar a data de início da recorrência no campo Start. Para determinar a extensão
da recorrência, podemos definir a quantidade de ocorrências, ou definir uma data limite.
Importante notar que não é possível criar vínculo dinâmico com a data de término da extensão da
recorrência, e, portanto, sempre que por qualquer motivo necessitarmos de mais ou menos atividades,
deveremos editar os parâmetros do conjunto de atividades recorrentes para que atendam à nova
realidade.
5 - Calendário
Por fim, podemos selecionar o calendário a ser aplicado às atividades criadas pela recorrência. Caso
nenhum seja selecionado, as atividades usarão o calendário padrão do projeto.
Caso alguma atividade seja agendada para dia de não trabalho (nonworking time), a seguinte mensagem será exibida:
Neste exemplo, uma de cinco das atividades criadas teve esse conflito de agendamento e o programa nos pergunta
se desejamos agendá-la para o espaço disponível mais próximo. Clicando em sim, o programa fará o reagendamento;
clicando em não, o programa não criará a ocorrência conflitante, e teremos uma atividade a menos; clicando em
cancelar, a operação é cancelada e podemos rever os nossos critérios de definição das atividades recorrentes para
encontrar outra solução.
O elemento que sumariza as atividades recorrentes, apesar de não possuir automaticamente as configurações visuais
de um produto, é reconhecido como tal pela ferramenta, sendo de fato um pacote de trabalho e, portanto, é necessário
que configuremos o valor do seu campo Flag16 (Pacote de Trabalho) para Yes.
Quanto à configuração visual deste elemento no Gráfico de Gantt, podemos aprimorar sua configuração, o que
trataremos no item 3.2.4.5 Formatação do Gantt Chart.
3.2.4. Análise do cronograma preliminar do projeto
Nesta seção discutiremos formas de facilitar a visualização do cronograma que começa a ser desenhado pela equipe
de planejamento,tanto para facilitar seu trabalho de desenvolvimento como para colaborar com a criação de
ferramentas de comunicação entre os envolvidos do projeto.
Trataremos de configurações visuais das tabelas, compreenderemos como funcionam as barras dos gráficos de
Gantt, e como visualizar o caminho crítico do nosso projeto, salvaremos e analisaremos a linha de base do projeto, e
apresentaremos a Screen Network Diagram, usada para montar modos tipo diagrama de rede.
3.2.4.1. Formatação Visual Pelo Text Styles
Em todos os modos que apresentam tabelas, podemos modificar a aparência das células
alterando-lhes a cor do plano de fundo e características da fonte utilizada, bastando para isso
marcarmos com o mouse a região a ser modificada e em seguida escolher a nova aparência,
selecionando do grupo Font, da Aba Task, as opções desejadas. Esse tipo de configuração
pontual de elementos é encontrado em toda a família de aplicativos Office da Microsoft.
A ferramenta MS Project apresenta uma alternativa para a configuração visual das células de forma automática na
opção Text Styles, encontrada nas Contextual Tab Sets dos modos que apresentam tabelas.
Nesta opção podemos definir padrões para cada elemento da nossa EAP + Atividades, que serão aplicados em
todas as células do nosso modo,
inclusive em novos elementos. Para
exemplificar o uso deste recurso,
vamos selecionar o modo Step 04 –
EAP + Atividades. Como este é um
modo que apresenta tabela (Screen
Gantt Chart), na aba Format (Gantt
Chart Tools), encontramos a opção
Text Styles.
Clicando no seu ícone, encontramos a

tela apresentada ao lado. Na seleção
de “Item to Change:”, escolhemos para
que conjunto de elementos desejamos
criar um padrão de configuração.
Lembramos que esse será o padrão
aplicado em todos os elementos atuais
do modo, e nos novos a serem criados.
Ainda é possível realizar
configurações visuais pontuais, que
sempre sobrepõem as configurações
padrão.
No nosso exemplo de aplicação no modo Step 04 – EAP + Atividades, recomendamos a realização da seguinte
configuração do Text Styles, seja de atividades não críticas (Noncritical tasks), seja de atividades críticas (Critical
Tasks) na cor azul marinho, e marcos (Milestone Tasks) em itálico e cor diferente das demais atividades. A não
diferenciação entre as atividades críticas e não críticas tem dois motivos: o primeiro é que no modo Step 04 ainda
não definimos a duração das atividades e, portanto, não existe ainda um caminho crítico no cronograma; o segundo
é evitar a poluição visual em um modo que já é composto e apresenta as barras do diagrama de Gantt.
Toda e qualquer configuração visual fica armazenada no modo.
Mesmo que dois modos utilizem a mesma tabela 6, qualquer configuração visual não é compartilhada,
devendo ser repetida caso deva ser encontrada em mais de um modo. Nesses casos, sugerimos que
novos modos sejam criados como cópia do primeiro, para herdar seus elementos visuais (especialmente
útil nas configurações visuais dos modos tipo gráfico de Gantt, descritos abaixo)
Toda modificação visual será salva no modo, por isso deve-se tomar cuidado com marcações, anotações
ou qualquer tipo de modificação que não se deseje permanentemente no modo. Apesar de ser possível
desfazer as alterações visuais, por vezes, ao se misturar formatações pontuais com as realizadas pelo
Text Styles, pode-se perder o controle das alterações, o que pode gerar dúvidas principalmente se o
arquivo for utilizado por mais de um membro da equipe de planejamento e controle.
6
Não recomendamos que mais de um modo utilize a mesma tabela.
3.2.4.2. Uso de Filters
Apresentamos neste momento o último elemento básico da construção de modos na ferramenta MS Project 2013. A
principal função dos filtros é selecionar quais elementos do conjunto EAP + Atividades desejamos que sejam
apresentados em um dado modo do nosso projeto, sendo ocultada a visualização dos demais.
Para exemplificação deste recurso, criaremos um filtro que mostre somente as atividades do nosso projeto, excluindo-
se os marcos e produtos. Não criaremos um modo para aplicação deste filtro, e sim o usaremos conforme nossa
necessidade de análise, qualquer que seja o modo ativo.
Para criação de um novo filtro, nos encaminhamos para a aba View, e

selecionamos a opção New Filter. A janela Filter Definition será exibida, na qual
deveremos realizar os ajustes conforme as necessidades que tivermos em
mãos.
Abaixo, a referida tela é reproduzida, preenchida para criação do nosso filtro proposto, que apresentamos em seguida.
1 Name: Selecionamos o nome do filtro. No caso da criação de um filtro para uso em modo específico,
recomendamos que receba o mesmo nome deste. No nosso caso, criamos um nome significativo, para fácil
identificação posterior do uso proposto do modo.
2 Show in menu: Marcação para o filtro ser exibido ou não no menu de filtros; marcação semelhante aos modos e
tabelas, já apresentados.
3 Field Name: Aqui entramos na construção da lógica usada pelo filtro. O primeiro passo é a seleção do campo a
ser utilizado no teste de valor. No nosso caso, iniciamos selecionando o campo milestone e summary.
4 Test: Local no qual selecionamos o tipo de teste a ser usado em cada campo. Podemos selecionar uma entre 11
opções; entre elas igual, maior, menor, maior ou igual, contém entre outras. Selecionamos para ambos os campos a
opção equals (igual).
5 Value(s): Valor a ser usado nos testes. No nosso caso, desejamos que sejam apresentados os elementos que não
representam produtos e não representam marcos. Dessa forma, selecionamos o valor ‘No’ para o teste.
6 And/Or: Relação entre os testes. Podemos selecionar a opção ‘ou’ e a opção ‘e’. No nosso exemplo, desejamos
que ambos os testes sejam respeitados, e, dessa forma, selecionamos a opção ‘and’.
7 Show related summary rows: Caso marcada, esta opção faz com que o filtro exiba os produtos dos elementos
contemplados pelo filtro. A deixamos desmarcada, uma vez que nossa intenção é justamente não exibir produtos.
Criado o filtro, devemos salvá-lo e estaremos prontos para aplicá-lo em qualquer modo
previamente ou posteriormente construído. Para isso, basta-nos ir à aba View, Filter e selecionar
o nosso filtro na seção Custom.
Ao aplicarmos um filtro em modo já construído, estamos alterando a estrutura deste modo, inserindo este filtro
permanentemente. O mesmo se dá com a alteração de sua tabela. Devemos, portanto, lembrar de retornar o modo
ao seu estado original após a análise a que nos propomos.
A partir da versão 2010 da ferramenta, foi adicionada a função de Highlight para os filtros. Com este uso, o filtro não
oculta os elementos que não respeitarem seus testes lógicos, mas sim destaca aqueles que o fizerem. Assim,
podemos criar formas lógicas e dinâmicas de realçar elementos dos nossos modos. Um uso desta função será
mostrado no item a seguir ao tratarmos do caminho crítico do projeto.
O mesmo desenvolvimento pode ser usado para filtro dos recursos a serem apresentados em dado modo, como
veremos no capítulo 04. No anexo D, temos um compêndio do uso de filtros no MS Project onde apresentamos todas
as funções deste recurso.
3.2.4.3. Caminho Crítico
Já vimos no item 3.1, Conceitos de Gerenciamento do Tempo, a definição de caminho crítico do projeto, mas, para
analisar como o MS Project trabalha com este conceito, devemos lembrar que se trata do maior caminho de atividades
ao longo do projeto, aquele que qualquer atraso em suas atividades gera um atraso no projeto.
A imagem abaixo representa um projeto simples, de 10 dias, com 4 atividades.
Repare que nenhuma das atividades vermelhas pode atrasar sem que o projeto como um todo atrase, ou ainda, que
caso se consiga uma compressão na duração destas atividades, o projeto certamente será beneficiado. Essa é a
essência da análise do caminho crítico do projeto, no entanto devemos compreender de que maneira o MS Project
define este caminho para podermos analisá-lo da maneira adequada.
Temos na ferramenta dois campos cujo apresentação é essencial para este tema: O Free Slack e o Total Slack, que
aqui trataremos como Folga Livre e Folga Total, respectivamente.
Folga Livre
Apresenta, de acordo com o cronograma, um valor em dias para o quanto a atividade poderia atrasar antes que este
atraso impacte nas suas atividades sucessoras. As atividades 2 e 4 da imagem abaixo possuem folga livre maior que
zero. No caso da atividade 2, ela pode terminar até um dia após a programação atual sem que isso impacte na
atividade que lhe sucede e, no caso da atividade 4, esse valor é igual a dois dias.
Para facilitar, incluímos o valor da folga livre das atividades à esquerda das mesmas.
Folga Total
Apresenta, de acordo com o cronograma, um valor em dias para o quanto a atividade poderia atrasar antes que este
atraso impactasse na data de término do projeto.
As atividades 1,3 e 5 da imagem abaixo possuem folga total maior que zero. No caso da atividade 1, podemos ver
que ela pode ter seu término agendado para o dia 8 de fevereiro sem impactar no término do projeto, ou seja, 5 dias
de folga total; o mesmo valendo para a atividade 5, mas com valor igual a 1,5 dias, ou 12 horas de acordo com o
padrão configurado na ferramenta em que 1 dia = 8 horas de trabalho.
Para facilitar, incluímos o valor da folga total das atividades à esquerda das mesmas.
Com a atividade 3 vemos que as atividades predecessoras acumulam o período de folga total das suas sucessoras,
assim, não podemos somar os valores e acreditar que a atividade 3 poderia ser postergada em 2,5 dias e a atividade
5 em 1,5 dias, já que estes 1,5 dias já estão somados ao valor 2,5.
Importante!
O uso de calendários, deadlines e restrições pode impactar no valor dos campos free slack e total slack,
alterando dessa forma a análise do caminho crítico do projeto. Exemplificamos ambas as situações na imagem
abaixo:
Podemos ver do lado esquerdo das barras do gráfico de Gantt o valor do campo total slack. A atividade 1
mostra valor igual a um dia, mesmo que existam 5 dias de trabalho disponíveis entre sua data de término
atualmente agendada e o término do projeto, e isso devido ao uso do recurso deadline, como pode ser visto
na representação de uma seta na cor verde, posicionada um dia após o término agendado da atividade.
Observando a atividade 4, vemos o valor do seu campo total slack como 2 dias. Esta atividade recebeu
calendário em que os períodos de trabalho se dão aos finais de semana, 8 horas no sábado e 8 horas no
domingo. Assim, o período disponível após o seu término compreendido entre os finais de semana não é
somado no campo total slack, respeitando o uso do calendário.
Devemos cuidar também para que atividades hammock não interfiram no caminho crítico do projeto. É possível
que links dinâmicos realizados na ferramenta se percam e a duração destas atividades deixem de se atualizar
automaticamente.
Step 07 – Análise do Caminho Crítico
Compreendidos os campos de folga, vamos

criar um modo para analisar o caminho
crítico do nosso projeto. Será um modo
simples, na screen Gantt Chart, com as
seguintes configurações:
A tabela desenvolvida pode ser vista na

imagem a seguir
Dos campos utilizados, apresentamos abaixo os inéditos:
Late Start (Início mais tarde) e Late Finish (Término mais cedo)
Vimos que algumas atividades podem ter seu início – e consequentemente término – adiados em certos períodos,
sem que isso afete o término do projeto, sendo este período o valor do campo Total Slack (Folga Total).
Os campos Late Start e Late Finish mostram então os maiores valores das datas de início e término, respectivamente,
possíveis de serem agendadas para a atividade, sem adiar a atual data de término do projeto.
Early Start (Início mais cedo) e Early Finish (Término mais tarde)
De forma semelhante aos campos descritos acima, existem situações nas quais podemos agendar as atividades mais
cedo que o agendamento atual do projeto. Como configuramos a ferramenta para usar agendamento a partir da data
de início do projeto, e assim todas as nossas atividades são criadas ASAP (mais cedo possível), estes campos
apresentarão na maior parte das atividades os mesmos valores dos campos Start e Finish.
Critical
Campo que, semelhante aos tipos flag, mostra valores Yes ou No para mostrar as atividades que são consideradas
críticas ou não pela ferramenta. Lembramos que, por padrão, o MS Project considera críticas as atividades que
possuem valor 0 (zero) no campo Total Slack.
Podemos no entanto ajustar em FILE, Options, Advanced a quantidade de dias mínimos para uma atividade ser
considerada crítica. Caso seu valor de total slack seja menor ou igual a esta definição, ela será crítica.
Esta configuração se mostra útil em projetos cujas atividades possuem valores de duração em semanas ou meses,
ou caso seja definido período de atualização dos dados de controle igualmente dilatados.
Para concluir nosso sétimo modo, criaremos um filtro tipo Highlight mostrado abaixo, com o mesmo nome do modo,
para realçar as atividades críticas do nosso projeto.
Aqui, inserimos o teste “Summary equals No” para garantir que somente as atividades sejam realçadas, já que os
produtos também recebem valor para o campo Critical. Importante notar que após alterações do cronograma, caso o
caminho crítico seja alterado, será necessário realizar o modo, ou ao menos o filtro, para que a atualização do realce
ocorra.
Finalmente, para apoio visual, configuramos em Text Styles a cor de fundo do filtro tipo Highlight para vermelho, como
na imagem abaixo:
3.2.4.4. Linha de Base 1: Tempo (Baseline1)
O término da definição e documentação das atividades e marcos do projeto é momento importante, que deve ser
registrado para posterior análise de seus valores frente às atualizações do cronograma realizadas no decorrer do
processo de planejamento e, depois, na execução deste.
Temos no recurso de linha da base a possibilidade de registrarmos diversos valores dos elementos EAP + Atividades
do nosso projetos e armazenar em campos criados pelo MS Project, destinados a esta
finalidade. Dentre os valores de campos tipo Task (Atividade), podemos citar os que
ficarão armazenados em: Baseline Cost, Baseline Duration, Baseline Finish, Baseline
Start e Baseline Work.
Para salvar a linha de base, nos direcionamos à aba Project e

encontramos o ícone Set Baseline. Clicando na opção Set
Baseline... , nos será apresentada a tela de mesmo nome,
reproduzida abaixo.
Como esta é a primeira vez que salvamos linha de base em

nosso projeto, basta-nos deixar a tela como mostrado ao lado
e clicar no botão OK. Caso uma linha de base anterior estivesse
já armazenada, nos seria perguntado se desejamos sobrepor
estas informações pela nova linha de base.
Além do conjunto de campos padrão de salvamento e uso de

linha de base, existem ainda 10 conjuntos de linhas de base
auxiliares. Cada um desses conjuntos contém todos os campos
de armazenamento de informações de linha de base do MS
Project. Os nomes desses campos apresentam um número identificador para que saibamos de que conjunto ele faz
parte (ex.: Baseline1 Start e Baseline1 Work, Baseline5 Duration e Baseline5 Finish).
Como salvaremos diversas linhas de base ao longo do projeto, para confrontar as informações e verificar a evolução
das mesmas, copiaremos as informações da linha de base padrão (Baseline) para o conjunto Baseline1 através da
opção “Set interin plan”.
Após salvar a linha de base, voltamos à tela Set Baseline, e copiamos as informações da forma mostrada abaixo.
Feito isso, teremos os dados atuais de planejamento do projeto registrados na Baseline1 mantidos arquivados, e
poderemos salvar novas linhas de base para trabalho na ferramenta sem risco de perder estas informações.
Arquivaremos novas linhas de base nos conjuntos Baseline2 e Baseline3 para registrar o estado do projeto após a
inserção das informações e restrições de recursos e custos, respectivamente.
3.2.4.5. Formatação do Gantt Chart
Temos na formatação visual dos modos tipo gráfico de Gantt uma forma simples e eficiente de análise do cronograma
do projeto e de comunicação com os envolvidos do projeto, já que se apresenta como uma das formas mais difundidas
de visualização dos dados de um projeto nesta ferramenta. Em suas últimas versões, o MS Project acrescentou
configurações automáticas que facilitam o uso desta screen. Estes serão apresentado primeiramente, e em seguida
passaremos à análise mais geral da configuração deste modo, para que seja possível sua customização fora dos
parâmetros pré-estabelecidos.
Sempre que temos um modo que use a screen Gantt Chart, veremos a guia GANTT CHART
TOOL disponível no final da ribbon. Nesta guia temos a aba FORMAT, na qual poderemos
fazer toda a configuração mostrada nesta seção.
 Show/Hide
Iniciaremos tratando do grupo Show/Hide, que, como o nome indica, apresenta

a opção de mostrar ou ocultar as opções nele contidas.
Outline Number
Caso marcada, apresenta à esquerda de cada texto do campo Name o número correspondente ao seu nível
de indentação. No nosso projeto, a deixamos desmarcada, pois estamos usando o campo WBS para este fim.
Project Summary Task

Exibe a linha 0 (zero) do projeto, representando o projeto. As características deste elemento serão tratadas no
Capítulo 05: Gerenciamento do Custo.
Summary Tasks
Apresenta os produtos do projeto, ou seja, as linhas cujo campo Summary apresenta valor Yes. Caso
desmarcada, estes elementos serão ocultos, restando as atividades, marcos e pacotes de planejamento do
nosso projeto.
Este grupo não é exclusivo dos modos Gantt Chart, e pode ser encontrado em todos as abas Format de modos
que utilizam tabelas.
 Timescale
Temos na configuração da escala do tempo do gráfico de Gantt um passo importante na facilitação da leitura
de suas informações. Escalas muito dilatadas trazem maiores
detalhes e maior definição para o conteúdo, mas impedem a
análise simultânea de muitos elementos, já que os mesmos
não serão comportados na tela.
Para configuração do Timescale, clicamos com o botão direito

do mouse na sua área, e selecionamos a opção Timescale...
.
Podemos usar de 1 até 3 níveis de escala, representados na

ferramenta pelo nome de tier. No nosso exemplo,
selecionamos a opção de usar dois níveis selecionando Two
tiers, nos quais serão exibidos o nível do meio e o inferior
(middle e botton). Assim, as configurações a seguir se darão
nas guias correspondentes a estes níveis.
Na aba Middle Tier, mostrada na imagem acima, vemos as possibilidades de configuração do timescale. No
nosso exemplo, usamos a unidade semana (Weeks), apresentando todas as semanas (count: 1). Caso
desejássemos apresentar semana sim, semana não, usaríamos valor 2 para o elemento count.
Deve-se tomar o cuidado de usar unidades proporcionalmente menores para os tiers inferiores. Em nosso
exemplo, escolhemos a unidade dias (menor que semanas) para a escala inferior, novamente com contagem
unitária (count: 1). Em Label, selecionamos a forma como desejamos que a unidade da escala seja
apresentada e, em Align, o alinhamento
correspondente.
A qualquer momento podemos visualizar o
resultado das nossas configurações na parte
inferior da tela Timescale, chamada de Preview.
Na aba Non-working time, temos a possibilidade

de configuração visual dos períodos de tempo de
não trabalho no calendário base do projeto,
aquele selecionado nas configurações em Project
Information.
A timeline não é exclusividade dos modos que utilizam o diagrama de Gantt, também sendo encontrada nos
modos de screen task usage e resource usage, que seguem exatamente o mesmo procedimento para sua
configuração.
 Bar Styles
Analisando o grupo Bar Styles, iniciamos a apresentação da configuração das barras do gráfico de Gantt.
Como já pudemos observar, nos modos criados anteriormente, as barras representam atividades, produtos e
marcos ao longo do tempo.
Em geral, representam a duração destes elementos no cronograma do projeto. Por exemplo, as barras que
representam as atividades começam a ser desenhadas na da de início e têm seu término na data de término
da atividade, ficando assim o comprimento da barra relacionada à duração da atividade.
Entre as opções de alteração das barras do gráfico de Gantt pré-configuradas pela ferramenta, vemos:
Critical Task
Caso marcada, esta opção faz com que as barras das atividades que possuam valor ‘Yes’ no campo Critical
apresentem cor vermelha, indicando que fazem parte do caminho crítico do projeto.
Slack
Apresenta uma barra fina e escura, que representa a duração do campo Free Slack. Essa barra se inicia no
término das atividades e produtos, e possui comprimento relativo ao valor do campo Free Slack.
Late Tasks
Faz com que as barras de atividades consideradas atrasadas pela
ferramenta fiquem em cor escura. Sobre este recurso, trataremos no
Capítulo 07: Monitoramento e Controle.
Task Path
Este novo recurso da ferramenta, também conhecido como rastrear
caminho da tarefa, apresenta a possibilidade de marcar em cores as
barras de todas as atividades predecessoras e sucessoras da atividade
selecionada pelo usuário, possível ainda diferenciar as predecessoras e
sucessoras que imediatamente influenciam ou são influenciadas pela
atividade selecionada, usando a opção Driving Predecessors e Driven
Successors, respectivamente.
Baseline
Apresenta na forma de barra cinza na parte inferior para as atividades, e linha inferior do mesmo tom para os
produtos, a linha de base selecionada pelo usuário.
Slippage
Exibe uma linha inferior na cor preta para apresentar a variação da data de início da atividade armazenada na
linha de base para o início da atividade atualmente programado no campo Start.
As configurações mostradas acima nos são dadas prontas pela ferramenta. Poderemos simulá-las
manualmente, e ainda criar diversas outras configurações visuais para nossas barras do gráfico de Gantt,
após compreender os meios pelos quais o MS Project define estes elementos gráficos.
 Personalização das barras do Diagrama de Gantt

Clicando com o botão direito do mouse no nosso gráfico de Gantt, podemos
selecionar a opção Bar Styles, que nos faculta a visão da tela de mesmo
nome, onde poderemos ver toda a configuração visual dos elementos do
diagrama de Gantt.
Tudo o que vemos representado como barras, ícones e linhas neste

diagrama (Gantt), está descrito nesta área, de modo que caso deletamos
todos as linhas desta tabela de definições, todos estes elementos
desaparecerão do modo ativo.
Como forma de aprendizado, propomos que os usuários ainda não acostumados com o tema façam este
exercício de deletar todas as barras pré-configuradas pela ferramenta e criar as suas próprias definições, como
as propostas na imagem abaixo. Não há motivo para preocupação na realização desta operação, uma vez
que as configurações destas barras são propriedades dos modos. Novos modos criados com a screen Gantt
Chart terão as barras padrão da ferramenta.
Vamos apresentar os elementos desta tela:
1 Name: Devemos nomear cada elemento gráfico criado. Recomendamos que o nome seja significativo, para
fácil identificação de seu propósito.
2 Appearance: Para definição da aparência do elemento, devemos usar a aba Bars, encontrada na parte
inferior desta tela. Lá, devemos definir a forma (shape), padrão (pattern) e cor (color) para o corpo da barra,
além dos pontos de início e término. Caso estejamos interessados em definir ícones, como nos casos dos
marcos e do deadline, podemos definir apenas a forma do ponto de início (Start).
3 Show For .. Tasks: Neste importante item, devemos selecionar para quais tipos de elementos do projeto,
como produtos, atividades e marcos, esta barra será apresentada. Dessa forma, as barras azuis são
apresentadas somente para as atividades e os losangos somente para os marcos, por exemplo.
Dentre as mais de 50 possibilidades, devemos selecionar o requisito a ser cumprido para apresentação da
barra. Utilizando mais de um, deve-se separá-los por ponto e vírgula.
Os valores mais comuns são:

Normal: Elementos que não representam produtos. Podemos entender como atividades e marcos
do projeto;
Summary: Produtos, elementos com valor Yes no campo Summary;
Critical: Elementos críticos. Produtos, atividades ou marcos;
Noncritical: Elementos não críticos. Produtos, atividades ou marcos;
Milestone: Elemento com valor Yes no campo Milestone.
4 Row: é possível criar mais de uma linha para construção de diversas barras concorrentes no gráfico de
gantt, até um limite de 4 unidades. Não recomendamos seu uso, uma vez que o mesmo ficaria visualmente
poluído, dificultando o acesso à informação.
5 From: Definição do ponto no qual a barra começará a ser desenhada. Devemos lembrar que os diversos
campos possíveis de serem selecionados sempre representam datas, que ficarão representadas de acordo
com a Timeline configurada. No caso de marcos (milestones), devemos inserir Task Finish (término da
atividade)
6 To: De forma semelhante ao item anterior, configuramos aqui o ponto de término da barra.
Ainda nesta tela, podemos configurar textos para serem apresentados próximos às barras. Para cada elemento
criado na aba Text, podemos escolher campos para serem exibidos antes (esquerda), acima, abaixo, depois
(direita) e dentro do mesmo.
Após a definição do padrão de

criação das barras do diagrama
de gantt, podemos fazer
alterações pontuais. Dando um
duplo clique na barra a ser
alterada, nos é apresentada a
tela Format Bar, onde podemos
fazer os ajustes, de forma
semelhante ao já apresentado.
Recomendamos que as
atividades tipo hammock
tenham cores diferenciadas,
principalmente se possuem
trabalho do início ao término do projeto, para assim não serem confundidas com o caminho crítico do projeto.
No exemplo mostrado ao lado, selecionamos a cor verde para a nossa atividade hammock de controle e
supervisão do projeto.
 Format
Nosso último grupo de recursos apresenta os recursos finais de apoio à

visualização do conteúdo do diagrama de Gantt. Já tendo apresentado o uso da
formatação pelo recurso Text Styles, no item 3.2.4.1, vamos trabalhar as outras
duas possibilidades:
Gridlines
Aqui, vemos a possibilidade de configuração visual das linhas verticais e horizontais, lembrando que estas são
propriedades armazenadas no modo, existindo a possibilidade de se realizar configurações diferentes nos
diversos modos a serem criados na
ferramenta.
Recomendamos que ao menos duas

alterações sejam realizadas: em
current date selecionar uma linha na
cor verde, e em Status date uma
linha na cor laranja.
A configuração dos valores destas

datas se dá na tela Project
Information, e trataremos da data ‘Status Date’ no capítulo 07 do nosso livro.
Layout
Finalmente, em layout, podemos configurar a forma como

as setas de precedência são apresentadas no diagrama de
Gantt, assim como o formato das datas e a altura das
barras.
Always roll up Gantt bars leva os elementos gráficos de

nível mais inferior para serem representados sobre o
elemento gráfico de sumarização. Recomendamos que
fique desmarcado e, caso necessário, seja selecionado o
roll up específico de cada atividade na tela Task Information,
guia General.
O “Round bars to whole days” faz com que a

representação gráfica dos elementos seja apresentada
preenchendo os espaços da unidade de tempo visível. Se
não, fica fracionado em função das “horas” definidas no
agendamento. Essa opção deve ficar marcada.
Show bar splits, caso marcado, exibe os splits das atividades. Em FILE, Options, Schedule, desmarcamos a
opção Split in-progress tasks, mas ainda é possível a criação de splits de forma manual. Recomendamos que
fique marcado para identificação dos splits, caso algo ocorra fora do esperado.
Caso Show drawings esteja marcado, desenhos criados por esse recurso da ferramenta serão exibidos.
3.2.4.6. Diagrama de Rede
Com a apresentação dos modos que utilizam a screen Network Diagram (Diagrama de Rede), finalizaremos o
conjunto de ferramentas e recursos facilitadores da visualização e análise do cronograma preliminar do projeto. Aqui,
encontraremos especial utilidade para verificação, entendimento e comunicação do sequenciamento das atividades
e marcos do projeto, e visualização qualitativa do caminho crítico.
A exemplo dos modos tipo diagrama de Gantt, que são aqueles que utilizam a screen Gantt Chart, chamaremos de
modos tipo diagrama de rede aqueles que utilizarem a screen Network Diagram.
Step 08 - Diagrama de Rede - PDM
Criaremos neste momento o modo Step 08 - Diagrama

de Rede – PDM, modo simples a ser criado como cópia
do modo Network Diagram, para que aproveitemos as
configurações visuais pré-configuradas.
Ao utilizar a screen Network Diagram, percebemos que

nos é vetado o acesso à seleção de tabelas, uma vez
que, como veremos adiante, este modo não as utiliza.
No entanto, ainda podemos selecionar grupos e filtros,
dando-nos liberdade para personalização do nosso
modo.
Neste momento, estamos interessados em ver toda a

sequência lógica do sequenciamento das atividades e
marcos do nosso projeto. Com este simples, mas importante objetivo, não obteremos vantagens em aplicar grupos
ou filtros, portanto não os aplicamos. Ao longo do livro, teremos necessidade de aplicar estes recursos a modos tipo
diagrama de rede.
Finda a criação do modo, podemos aplicá-lo para iniciar nossos estudos de seu uso.
Primeiramente, percebemos que os elementos da nossa EAP + Atividades foram

desenhados com formas geométricas diferentes para representar produtos, atividades
ou marcos; que setas mostram a relação de precedência entre estes elementos; e que
possuem cores diferentes para mostrar quais fazem parte do caminho crítico do
projeto.
Quanto às formas, veremos que existem 10 possibilidades de configuração para cada

elemento mostrado no diagrama, conforme mostrado na imagem ao lado. Apesar
dessa riqueza em possibilidades, desaconselhamos a alteração do padrão já estabelecido, uma vez que se apresenta
difundido no mercado e cumpre com eficiência sua proposta.
Assim, temos:
ATIVIDADES PRODUTOS MARCOS

Quanto às cores, por padrão, todos estes três elementos mostram-se vermelhos ou azuis, ao fazerem parte do
caminho crítico ou não, respectivamente. O produto que sumariza todo o projeto apresenta-se em tom azul
diferenciado.
O conteúdo das caixas são passíveis de customização. Nas imagens acima, reproduzimos os ‘templates’ aplicados
às atividades por padrão. O uso deste modo, sem qualquer alteração, já nos faculta a análise do caminho crítico,
verificação e checagem do sequenciamento das atividades e marcos do projeto.
Faremos, no entanto, ajustes para que ele melhor sirva aos nosso interesses de
análise de precedência, e para apresentar as possibilidades de ajustes criadas
pela Microsoft.
Os modos tipo diagrama de rede apresentam a

Tool Tab correspondente, e na aba FORMAT
encontramos os caminhos para a personalização
do nosso trabalho.
Todas estas opções, que apresentamos abaixo, podem ser encontradas também
ao clicarmos com o botão direito na área livre do nosso modo, como visto ao lado.
Trataremos primeiramente do layout do modo. Clicando no ícone correspondente, nos é apresentada a tela de mesmo
nome.
Para as nossas necessidades, no modo Step 08 - Diagrama de Rede – PDM, devemos ressaltar 3 opções:
Show summary tasks: Desmarcaremos esta caixa de seleção, para mostrar em nosso modo somente a rede
lógica de relação entre atividades e marcos, ocultando os produtos, uma vez que não são passíveis de
sequenciamento.
Arrangement: Manteremos a opção “Top Down From Left”, para melhor visualização das informações, segundo
o padrão ocidental de leitura.
Link Style: Mantendo a opção Show arrows, devemos testar as opções Rectilinear e Straight para perceber qual
nos faculta melhor visualização das relações. Na opção Rectilinear, as setas são sempre verticais e horizontais,
e, na opção Straight, elas percorrem o menor caminho entre as caixas cujo link estão
representando.
Para o conteúdo de nossas caixas, definiremos nossas próprias opções. Para isso, devemos ir até a
opção Box Styles, no ribbon ou com o botão direito do mouse. Na tela apresentada, encontraremos o
ícone More Templates... , alvo de nosso desejo no momento.
Clicando em More Templates... , veremos a tela Data

Templates, onde encontramos todos os modelos
possíveis de serem aplicados a cada tipo de caixas do
modo diagrama de rede. Criaremos 2 novos modelos, um
para as atividades, tanto críticas quanto não críticas, e
outro para os marcos.
Note que estamos definindo o conteúdo das caixas, e não
a sua configuração visual (cor e forma).
Clicando em New, iniciamos com a definição do modelo

para as atividades. Na tela Data Template Definition,
primeiramente clicaremos em Cell Layout, e na pequena
tela de mesmo nome, aumentaremos o número de linhas
e colunas do modelo para 4, conforme mostrado abaixo.
Em seguida, selecionamos os campos que farão parte do

nosso modelo, dispondo-os na posição desejada. O
resultado da nosso proposta de construção do modelo
pode ser encontrado abaixo, e temos como resumo:
Campo Rótulo (Label)

WBS WBS:
Name -
Contact Resp:
Outline code10 ORG:
Type -
Para aplicar rótulos, basta-nos marcar a opção Show label in cell, e, em seguida, inserir o texto a ser exibido à frente
do conteúdo do campo.
Terminada a configuração, clicamos em OK e partimos, de forma análoga, para a configuração do modelo a ser usado
pelos marcos.
Usamos os campos WBS, Name e Finish, pondo rótulo apenas no primeiro. No campo Name, selecionamos a opção
“2 lines” para o item “Limit cell text to:”, de forma a dar maior relevância ao nome do marco.
Novamente terminada a criação do

modelo, voltemos à tela Data Template,
onde podemos pressionar o botão Close.
Devemos, neste momento, aplicar os

nossos modelos aos elementos que os
utilizarão. Para atividades críticas
(Critical) e não críticas (Noncritical),
selecionamos “Modelo – Atividades” na
opção Data template, destacada na
imagem ao lado.
Podemos fazer esta configuração isoladamente, ou selecionar ambos os itens e configurar o template
simultaneamente.
Para exemplificar, vemos ao lado a seleção dos itens dos marcos críticos e não críticos e aplicação do “Modelo –
Marcos” em ambos, simultaneamente.
Manteremos as formas e cores pré-

configuradas pela ferramenta, temos
por fim definido o nosso modo Step
08 - Diagrama de Rede – PDM para
apoio da análise do nosso projeto, e
do resultado do planejamento
realizado até o momento, com
destaque para o sequenciamento das
atividades e marcos.
Leapfrog
Os modos tipo diagrama de rede nos facultam boa possibilidade de encontrar anomalias no sequenciamento das
atividades, como os leapfrogs.
Chamamos de Leapfrog atividades que mantêm relação de dependência redundante ou desnecessária. Dependendo
do tipo de sequenciamento entre três ou mais atividades, podemos verificar que em alguns casos é possível
estabelecer dependências no aplicativo desnecessariamente. Vejamos abaixo a imagem para exemplo.
Neste exemplo o link entre as atividades “B” e “E” é desnecessário, uma vez que as atividades “C” e “D” sempre terão
duração maior que 0 (zero) e, portanto, os seus vínculos de precedência para a atividade “E” sempre terão maior
relevância. De fato, o vínculo entre as atividades “B” e “E” jamais será utilizado para militar o início da segunda e,
portanto, é desnecessário e deve ser excluído, conforme a imagem abaixo:
Deletado o vínculo desnecessário, temos uma cadeia isenta de leapfrogs. Notemos que, apesar da atividade “C” ter
duração planejada maior que a atividade “D”, o vínculo de precedência entre as atividades “D” e “E” não é
desnecessário.
No atual estágio do planejamento, este vínculo não será utilizado, uma vez que a atividade “C” limitará o início da sua
sucessora “E”. Primeiramente, devemos manter a rede fechada, e a atividade “D” deve possuir sucessora, prevista
segundo os critérios de definição de precedência já apresentados, para que saibamos as folgas desta atividade,
detectemos o caminho crítico corretamente e ainda para uso deste vínculo por ocasião do atraso da conclusão da
atividade “D” durante a fase de execução do projeto.
Step 09 - Diagrama de Rede - Visão ORG
Criaremos, no nosso último modo do capítulo 3 para apresentação, outras opções dos modos tipo diagrama de rede.
Neste momento, utilizaremos o modo Step 09 - Diagrama de Rede - Visão ORG para visualizar de modo simples a
relação entre as atividades sob responsabilidade dos diferentes níveis organizacionais do nosso projeto.
Iniciaremos a construção do modo definindo o grupo que utilize o campo Outline Code10, e possua nome igual ao do
modo. Em seguida, podemos criar o modo que será simples, com screen Network Diagram, usando o grupo recém-
criado e sem filtros. Lembremos de marcar a opção Show in menu.
Terminada a definição, podemos aplicar o modo. Para facilitar a visualização, selecionamos a opção
Collapse Boxes, encontrada no grupo Display da aba Format, ou nas opções apresentadas ao
clicarmos com o botão direito do mouse na área livre do nosso modo. Outra alternativa é a seleção
da caixa Hide all fields except ID, encontrada no canto inferior direito da tela Layout.
Novamente, o usuário deverá testar sua preferência de estilo de links para decidir pelo “retilíneo” e pelo “direto”.
Somamos agora a decisão de aplicar ou não a opção Show link labels que, caso marcada, mostra o tipo do
relacionamento entre as atividades e marcos.
A seguir, mostramos o resultado da configuração do estilo de link conforme mostrado acima.
Terminamos esta seção deixando três dicas:
▪ É possível criar, editar ou deletar links neste modo. Para criar, devemos
proceder de maneira semelhante ao modo Gantt Chart, arrastando a
seleção com o botão esquerdo do mouse da predecessora para a
sucessora. Para editar, ou excluir, realizamos um duplo clique no link,
exibindo a tela Task Dependency.
▪ Podemos selecionar diversas caixas simultaneamente. Para isso, clicamos com o botão esquerdo e arrastamos
a seleção para englobar as caixas que desejamos selecionar.
▪ Devemos tomar cuidado para não criar novas atividades. Se criarmos uma caixa de seleção que não englobe
nenhum elemento, ou definirmos um link que não possua destino, uma atividade será criada. Não recomendamos
esse procedimento.
4. Capítulo 04: Gerenciamento dos Recursos
4.1. Conceitos de Gerenciamento dos Recursos

Recurso é tudo aquilo que é necessário para a produção das ações que garantirão na sua conclusão as entregas
do projeto. Assim, pode-se dizer que o primeiro nível a ser definido é o que será entregue, o segundo nível as
ações promotoras das entregas e o terceiro nível o que ou quem será empregado para promover essas ações
dentro da proposta original planejada. O código da EAP, que já foi estendido até as atividades para identificação
de pertinência, agora é estendido aos recursos diversos para garantir esse entendimento maior. Graças aos
tipos recursos que essa ferramenta nos dá, é possível entrar na conceituação dos tipos e classificações dos
recursos do projeto, entendendo de imediato os recursos: non-renewable e renewable. Os recursos do tipo
“insumos” são utilizados no processo de produção dos pacotes nas atividades e não estarão disponíveis após a
sua conclusão, isto é, trata-se de um uso sem retorno para reuso. Já os recursos aqui classificados como
renewable podem ter sua reutilização em outros momentos, de forma simplista, Recursos Humanos (renewable)
e Materiais (non-renewable). Os recursos financeiros, essenciais para apoio à realização das atividades do
projeto, não devem aqui ser encarados como atributos dos recursos anteriores apenas, como acontece na
maioria das modelagens, mas como elementos que de fato contribuem para a sua realização. É o caso dos
recursos financeiros que vêm contribuir para custeio e promoção de licenciamentos, taxas, obrigações legais e
insumos de apoio à aquisição de materiais ou recursos reutilizáveis de pequena monta. Não devemos esquecer
que esse recurso financeiro é essencial quando se trabalha com compromissos de pagamento de serviços
contratados, em projetos de grande porte.
4.1.1. Estimar os Recursos da Atividade
O processo da estimativa de recursos da atividade se refere ao trabalho necessário para determinar quais
os recursos (profissionais, equipamentos, materiais, financeiros) que devem ser utilizados na atividade,
para que ela contribua de forma adequada para a realização do pacote de trabalho do projeto, com a sua
classificação e grupamento adequados e modelagem de custos pertinente. Fica claro, então, pelo exposto,
que nesta etapa estamos mapeando os custos do projeto.
A Estimativa de Recursos Reutilizáveis

A estimativa dos recursos reutilizáveis, ou equipe e equipamentos do projeto, é um trabalho que deve ser
feito também com a participação da equipe de planejadores do projeto ou a partir de um banco de dados,
previamente construído e maturado dentro da organização. A codificação é muito importante e deve ser
considerada nesse momento. Os recursos podem ser cadastrados livremente nas suas tabelas e, a partir
daí, serem agrupados dentro de centros de controle e de grupos.
A Estimativa de Recursos Não Reutilizáveis

A estimativa dos recursos não reutilizáveis, ou insumos do projeto, de mesma forma que o anterior, é um
trabalho que pode e deve ser feito também com a participação da equipe de planejadores do projeto. A codificação
é muito importante e deve ser considerada nesse momento. Os recursos podem ser cadastrados livremente nas suas
tabelas e, a partir daí, serem agrupados dentro de centros de controle e de grupos.
A Estimativa de Recursos Financeiros

Por diversas vezes, precisamos alocar recursos financeiros apenas por conta da necessidade de
supervisão de contratos ou de um gerenciamento mais superficial ou preliminar. Os recursos podem ser
cadastrados livremente na tabela de elementos de custeio e, a partir daí, serem agrupados dentro de
centros de controle. Os recursos ditos aqui “financeiros” são comumente definidos como “rubricas de
lançamento”, isso é, sempre representados por valor moeda, mas definidos pela sua classe contábil:
“Salários”; “Caixa Pequena”; “Impostos Estaduais”; “Impostos Federais”, “Reservas de Contingência”;
“Serviços Contratados”; “Despesas Financeiras”; “Gastos gerais”; “Pró-labores”; “Serviços de Consultoria”;
“Taxas Públicas”; entre outras.
As entradas a seguir, já identificadas nos outros Processos de Gerenciamento de um Projeto, são
consideradas fundamentais e principais para os trabalhos desenvolvidos neste processo.
1 – Plano de Gerenciamento dos Prazos
2 - Fatores ambientais da empresa
3 - Ativos dos processos organizacionais
4 - Lista de atividades
5 - Atributos da Atividade
6 - Calendário dos Recursos e sua disponibilidade. Entenda-se como a relação dos recursos disponíveis e
seus calendários para serem considerados no planejamento e na alocação dentro das atividades. Uma
listagem de todos os recursos da empresa, normalmente chamada de “pool” ou conjunto, apresenta à equipe
de planejamento um quadro genérico de alternativas e perfis para utilização no projeto. Esse conjunto de
recursos também inclui os equipamentos e materiais.
7 - Registro dos Riscos
8 - Estimativa dos custos das atividades
1 - Opinião especializada - Essa técnica reúne aquele ou aqueles que, de fato, têm o conhecimento de como
deve ser feito o trabalho e, desse modo, conhece os recursos necessários para sua correta execução.
2 - Análise de alternativas – Essa técnica pressupõe a possibilidade de haver mais de uma opção para a
realização da atividade e, com isso, avaliar o tipo de recursos a serem alocados. As alternativas incluem a
escolha de “comprar” ou “fazer”, levando à dispensa de um ou outro recurso próprio por mão de obra ou
equipamento contratado.
3 - Dados publicados para auxílio e estimativas – Para a composição de custo na forma paramétrica, é
possível lançar mão de publicações especializadas que apresentam a produtividade de equipes, máquinas
e processos novos para a realização das mesmas atividades com diferentes resultados. Essa técnica é muito
aplicada nas áreas de engenharia e de desenvolvimento de softwares. O histórico da organização também
ajuda a criar esse banco de dados e o ciclo permanente de melhoria contínua permite às empresas refinar
os resultados, melhorando as estimativas de recursos. Essa técnica, quando associada aos processos de
gerenciamento de recursos humanos do projeto, facilita muito as interações entre os responsáveis das
equipes de planejamento – execução – RH. Dependendo do projeto e das diretrizes da organização, até a
equipe de contratação e aquisição é beneficiada.
4 - Software de gerenciamento de projetos – Uma vez que, para grandes projetos, muitas atividades são
necessárias, a quantidade de recursos a serem alocados também é significativa e proporcional a essas
grandezas. Os softwares permitem não só agilizar as alocações como também determinar o nível de uso de
todos os recursos e sua locação. Alguns chegam a permitir o controle de um conjunto de recursos geral
disponibilizando-o para todos os projetos, mantendo o controle do conjunto e verificando a alocação de forma
conjugada. Essa técnica, quando associada aos processos de gerenciamento de recursos humanos do
projeto e de custeio, facilita muito as interações entre os seus responsáveis, reduzindo o trabalho de acertos
de quantidades e estimativas.
5 - Estimativa “bottom-up” - quando os recursos a serem alocados na atividade são dificultados pela falta
de seu detalhamento, muitas vezes é necessário quebrar essa atividade em tarefas ou atividades menores,
estimar seus recursos materiais e humanos e depois totalizar o conjunto sumarizando os montantes na
atividade maior. Não é o caso das atividades do nível “pacote de planejamento”. Essas, pela sua
característica de “pouco conhecimento”, não leva à quebra em atividades menores. Talvez a técnica mais
indicada seja a “Dados publicados para auxílio e estimativas”
6 - Criação de Pool de recursos - quando a empresa ou organização possui um grau de maturidade maior
em projetos, ela passa a atuar com o seu quadro de recursos de forma integrada e voltada para a otimização
e melhores práticas no seu gerenciamento. A criação de um conjunto centralizado e integrado de recursos
de uma organização, respeitando os critérios de relevância de sua classificação, traz para as técnicas
anteriormente apresentadas um fator de alavancagem. O recurso necessário a um projeto pode ser
identificado na organização sem a necessidade de negociações trabalhosas nos níveis funcionais onde os
recursos estão alocados funcionalmente. Uma vez que os recursos sejam visualizados na empresa, dentro
de sua estrutura organizacional – ORG, centro de custos, fica facilitado o seu mapeamento e disponibilidade
para a organização. Dessa forma, a criação de um conjunto – ou “pool” de recursos se mostra como uma
boa ferramenta para apoio à estimativa de recursos da atividade. Os softwares de gerenciamento de projetos
estão bem a par desses benefícios e a maioria deles já incorpora essa opção. Nesse “pool” podem também
ser cadastrados atributos como custos, dados profissionais e atribuições específicas de responsabilidades.
Saídas do processo
1. Recursos necessários para a atividade – Essa é a saída lógica esperada para esse processo, porém com
o foco de totalização no nível das atividades de produção do pacote de trabalho. Esse resultado mostra para
a equipe de planejamento todos os recursos desejados para a realização dos trabalhos. Mais tarde, no
decorrer do planejamento, os recursos poderão sofrer alterações em alocação ou disponibilidade por
diversos fatores, mas nesse processo é fundamental que as técnicas sejam aplicadas de forma eficaz para
o melhor dimensionamento de esforços. Dependendo da técnica utilizada, é possível ao final, além da lista
de recursos, obter também o perfil básico, os índices de produtividade necessários e o grau de qualificação
para o desempenho e uso dos recursos no projeto em análise. Os recursos compartilhados ou críticos podem
ser especialmente difíceis de alocar, visto que sua disponibilidade pode ser altamente variável. Como
exemplo da afirmativa anterior, pode tomar o caso de um engenheiro altamente especializado poder estar
alocado em diversos projetos simultaneamente, sendo necessário negociar sua disponibilidade. Uma
ferramenta interessante na definição dos recursos do projeto é a ORG - OBS (Organizational Breakdown
Structure). A ORG é similar ao organograma da empresa, porém inclui apenas as organizações que irão
participar do projeto.
2 - Estrutura Analítica dos recursos - À semelhança da EAP e ORG, a EAR – Estrutura Analítica de Recursos
(ou RBS) apresenta os recursos através de uma classificação estruturada. Essa estruturação pode ser por
categoria ou tipo, sempre atendendo às características da organização ou dos interesses de controle do
projeto. Muitas vezes, essa classificação se adéqua às estruturas de custeio ou de apropriação de custo.
Outras vezes, nos casos de alocação de recursos exclusivamente humanos às estruturas organizacionais.
O mais importante é que, uma vez que todos os recursos estão alocados e se apresentam como necessários,
essa classificação ajuda as partes interessadas a ver esses componentes dentro de uma forma mais
conveniente e eficiente.
3. Lista de Atributos dos Recursos - A cada recurso existente, pode ser designado um conjunto de atributos,
ou seja, de características. Esses atributos vêm a contribuir para o melhor entendimento, tanto daqueles que
participam do trabalho como daqueles que registram essas informações para uso futuro. Muitas vezes esses
atributos podem ser apresentados em forma de planilha facilitando o seu entendimento para os participantes
do projeto. As melhores práticas indicam os seguintes atributos listados abaixo:
Identificador Um sistema qualquer que venha a identificar de forma mais fácil o recurso dentro
de um “pool” ou dentro do projeto.
Código Um código, que represente a estrutura analítica de recurso dentro de um “pool” ou

dentro do projeto.
Nome Um conjunto de palavras, normalmente o nome do recurso, sua função ou

localização que identifique o recurso.
Nível da ORG associado Identificação do nível da organização ou do projeto no qual está funcionalmente
alocado.
Valores de custo Os valores tradicionais de custeio: por hora, mês ou semana, pelo uso, por
pagamento de honorários, por valores estimados em caso de contratação.
Produtividade - Habilidade Nível de produtividade médio do recurso comparado a um padrão pré-estabelecido

de referência. No caso de recursos humanos, a experiência e competência do
indivíduo irão influenciar a produtividade. Outros fatores culturais, geográficos e
motivadores devem ser considerados na análise de produção e desempenho.
Chamamos de habilidades aquilo que na prática é chamado de produtividade
individual. No caso de equipamentos, a falta de informação da sua qualidade ou
eficiência, a sua procedência, constituição ou capacidade operativa são fatores que
pesam na produtividade. O tempo de depreciação de equipamentos e máquinas,
assim como a obsolescência, são outros fatores.
Tipo de Recurso Forma utilizada pela organização para a sua classificação, tipo ou classe, fabricante
ou função.
Premissas Considerações afetas as decisões e escolhas feitas para a alocação nas atividades
e seus atributos.

4.1.2. Alocar os Recursos nas Atividades
Esse processo, incluído aqui para melhor entendimento, pode ser considerado como parte integrante do
anterior por muitas publicações, mas se evidencia aqui como uma atividade que deve ser encarada com
cautela e por conta de experiência comprovada. A atribuição de quantidades de recursos às tarefas ou
atividades é algo que deve levar em conta três fatores: efetividade, quantidade e produtividade. Nessa
ferramenta, de forma direta, não é possível registrar e modelar a produtividade do recuso, mas a
quantidade e efetividade, sim.
A Quantidade define quantas unidades serão utilizadas de forma simultânea no trabalho da ação dos
recursos, sendo que, por vezes, é muito conveniente colocar dois profissionais simultâneos e períodos
parciais de tempo (efetividade) ao invés de um apenas, em tempo integral. Outra vezes, não é por questão
de conveniência, e sim de imposição ou restrição, que há essa limitação de “efetividade”.
A efetividade define o quanto de tempo do profissional é alocado na ação produtiva, levando como certeza
a entender a carga (workload) de trabalho atribuída ao profissional.
É importante lembrar que, para recursos humanos e equipamentos de apoio, essas três características
podem ser consideradas, para materiais e recursos financeiros apenas a quantidade é relevante.
4.2. Uso da Ferramenta - Recursos

A partir deste capítulo, estudaremos o uso de recursos na ferramenta MS Project 2013. Para que essa empreitada
seja bem sucedida, os conceitos anteriormente apresentados devem estar bem embasados, uma vez que o
gerenciamento dos recursos faz uso de diversos conceitos e utilidades pelos quais já passamos.
Outra dica importante é: fique atendo à diferença entre os itens tipo task (tarefa) e resource (recurso). É comum que
aqueles que iniciam seus estudos de gerenciamento de projetos com MS Project se confundam com as diferenças
das tabelas e modos tipo task e tipo resource, mais ainda com os campos personalizados, que, apesar de possuírem
o mesmo nome, são de fato endereços diferentes para armazenamento de informações.
4.2.1. Definição dos Recursos
Iniciaremos este capítulo tratando da definição dos recursos dentro da ferramenta, etapa inicial da modelagem do
recurso idealizado pelo gerenciamento do projeto, dentro dos padrões do MS Project. Nesta seção, apresentamos a
possibilidade de definição de recursos locais - recursos próprios - e de definição de recursos em “pool de recursos”,
em que os mesmos podem ser compartilhados entre vários projetos criados em arquivo diferente. Teremos ainda a
apresentação dos tipos de recursos suportados pela ferramenta e seus diferentes usos.
4.2.1.1. Recursos Locais x Pool de Recursos
Recursos Locais
Nesta opção de trabalho, os recursos são definidos e suas informações ficam armazenadas dentro do próprio projeto,
fazendo com que o arquivo do projeto sozinho contemple todas as informações necessárias para o trabalho de
planejamento e controle. Não existe neste caso a gestão unificada dos recursos da organização, trazendo como
consequência a perda do processo de otimização de recursos entre projetos e a repetição de funções. A figura do
gerente de recursos desaparece como apoio, pois fica praticamente impossível dar apoio aos projetos no dia a dia
das medições e ações corretivas.
Como esta opção é mais simples, e está inteiramente contida no uso de Pool de Recursos, utilizaremos a segunda,
que será apresentada a seguir, para o trabalho do gerenciamento dos recursos do "projeto exemplo" do nosso livro.
Pool de Recursos
É possível utilizar o MSProject 2013 como um gerenciador de recursos do projeto: um conjunto de recursos único que
passa a ser a fonte para todos os projetos. A utilização do Pool de Recursos torna viável o gerenciamento dos recursos
a nível organizacional, visando à otimização do mesmo
segundo as premissas e restrições pertinentes. Em
organizações que já atingiram maturidade em gerenciamento
de projetos, esse é um papel do PMO.
Como ilustração, a imagem ao lado mostra um Pool de

Recursos que possui quatro recursos diferentes. Destes, o
Recurso 1 e o Recurso 2 são utilizados no Projeto 1, e o Projeto
2 utiliza o Recurso 2 e o Recurso 4. Notemos assim que os
recursos podem ser utilizados em mais de um projeto
simultaneamente, um único projeto, ou estarem definidos e não
serem aproveitados, como no caso do Recurso 3.
Para utilização do Pool de Recursos, devemos estar atentos a três momentos importantes, que comumente são
motivos de dúvidas: a criação do arquivo, sua vinculação com os arquivos de projeto e o simples ato de abrir um
arquivo Pool de Recursos.
➔ Criar
Ao contrário do que se poderia esperar, a criação de um arquivo para que funcione como reservatório dos
recursos segue o mesmo procedimento de criação e preparação de um arquivo de MS Project para receber
as informações de um projeto, o que discutimos no capítulo 1 do nosso livro. Lembramos que é importante
verificarmos se as configurações iniciais da ferramenta foram realizadas.
Veremos abaixo que o fator determinante para que um arquivo seja considerado Pool de Recursos é a forma
como o vinculamos com outros arquivos de MS Project. Dessa forma, o arquivo usado como Pool pode conter
produtos, atividades, marcos, calendários e todos os elementos que discutimos até o momento no nosso livro,
no entanto, não aconselhamos que isso seja feito, fora no caso de elementos de gestão dos recursos da
organização. Sobre esse assunto, trataremos no capítulo 10: Gerenciamento de Múltiplos Projetos.
➔ Vincular
Uma vez criado e preparado, o arquivo deve ser transformado em Pool de Recursos
pela sua vinculação a um ou mais projetos. Fazemos isso de modo simples, abrindo
simultaneamente o(s) arquivos do(s) projeto(s) e do Pool, e no arquivo do (de cada)
projeto localizar na Aba Resource a opção Resource Pool, para em seguida
selecionar a opção Share Resources... . Importante repetir que esse procedimento
deve ser realizado no arquivo de cada projeto, e não no arquivo do Pool.
A tela apresentada possui mesmo nome, e está reproduzida abaixo. Nesta,

marcamos a opção “Use resources(requires at least one open resource pool)
From:”, e na caixa de seleção, escolhemos o arquivo destinado a ser o Pool.
Somente os arquivos que estejam abertos na máquina serão

exibidos para seleção como Pool, motivo pelo qual
informamos a necessidade de se abrir o arquivo a se tornar
Pool junto do arquivo do projeto.
Para a opção “On conflict with calendar or resource

information”, recomendamos a opção “Pool takes
precedence” para favorecimento do Pool de Recursos, que
usaremos como fonte de informações para os projetos.
Terminando a vinculação com cada projeto,

recomendamos que se vá ao arquivo do Pool e se
selecione a mesma opção “Share Resources”. Na tela a
ser apresentada será possível analisar todos os projetos
que se encontram ligados a este Pool. No exemplo
reproduzido ao lado, temos três projetos ligados ao
arquivo que está funcionando como Pool de Recursos.
Caso a equipe de projeto tenha como

procedimento de trabalho a realização de
cópias de arquivo do projeto, para
arquivamento ou análise posterior, é
importante que somente a última versão de
trabalho esteja ligada ao Pool, de modo que
este não veja as diferentes versões como
projetos diferentes, levando à alocação de
recursos que não serão utilizados e possível
superalocação dos mesmos.
Quando um projeto perde a ligação com o

Pool de Recursos original, uma cópia desses dados é incorporada ao arquivo do projeto tornando-o possível
de prosseguir com os trabalhos de planejamento e controle, mas eliminando as vantagens de se trabalhar
no modo anterior.
➔ Abrir
Por fim, devemos informar que após o

vínculo, os arquivos do projeto e do Pool
se comportarão de forma diferente no
momento que forem abertos, quando
mensagens serão exibidas ao usuário,
que deverá selecionar diferentes opções.
Nos arquivos de projeto, será exibida a

tela “Open Resource Pool Information”,
que informa o uso de recursos contidos em outro arquivo, e pergunta se o usuário deseja abrir o arquivo onde
estes recursos estão armazenados - o nosso Pool.
Esta mensagem será exibida somente se

o Pool de Recursos já não estiver aberto
na máquina.
Já nos arquivos que estiverem servindo de

Pool de Recursos, no momento que forem
abertos, será apresentada a tela “Open
Resource Pool”, que informa esta
condição e pede que o usuário escolha
uma entre três possíveis opções para se
abrir o arquivo.
1) Abrir pool de recursos como somente leitura, permitindo que outros trabalhem em projetos conectados
ao pool.
2) Abrir pool de recursos como leitura-gravação, para que você possa realizar alterações nas informações
dos recursos (como valores financeiros, etc.), mas isso impedirá que outros atualizem o pool com novas
informações.
3) Abrir o pool de recursos junto de todos os projetos a ele ligados, como leitura e gravação, em novo
arquivo tipo master. Você pode acessar esse novo arquivo master a partir da aba View, comando Switch
Window.
Atenção: Durante a alocação e planejamento de recursos do projeto, muitas vezes somos obrigados a completar o
“banco de dados” da organização com os recursos “especialmente” contratados ou adquiridos para um
projeto. Eles passam a fazer parte do arquivo de “conjunto de recursos”. A sua disponibilidade e quantidade
devem ser registradas nos campos apropriados, de forma a não induzir aos outros projetos o pensamento
de que esses recursos poderiam estar disponíveis como patrimônio da organização.
Tendo apresentado este conteúdo, criamos nosso arquivo de pool de recursos, vinculamos ao arquivo do nosso
"projeto exemplo" e abrimos nosso arquivo de pool na segunda opção, como leitura e gravação.
4.2.1.2. Modo para definição e documentação dos recursos
Para definição dos recursos do nosso projeto, criaremos um modo no nosso recém-criado arquivo Pool de Recursos7.
Este modo também será utilizado para os procedimentos de documentação dos recursos, apresentados no decorrer
deste capítulo.
Step 10 – Definição e documentação dos recursos
Criaremos um modo composto, semelhante ao

desenvolvido para a documentação das atividades do
projeto, no capítulo 3; ou seja, na parte superior teremos
uma tabela para definição e documentação de
informações nos campos da ferramenta, e na parte
inferior um espaço para inserirmos e visualizarmos o
dicionário dos recursos.
Iniciando pela parte superior, devemos criar a tabela a

ser utilizada. Devemos seguir o procedimento de
criação de tabelas já apresentado, lembrando que neste
momento estamos criando uma tabela do tipo recurso,
e, por isso, devemos selecionar a opção Resource na
parte superior da tela More Tables, antes de clicar no
botão New... .
7
Os passos descritos em seguida podem ser replicados mesmo que se use recursos locais.
As tabelas do tipo recurso (resource) diferem das tabelas do tipo atividade (task) no conjunto de campos possíveis de
serem selecionados para as integrar.
Devemos escolher o tipo de tabela correta para o modo que estamos construindo. No caso em tela, desejamos inserir
informações dos recursos que farão parte do nosso Pool, e, para isso, as tabelas do tipo resource nos possibilitarão
inserir campos para completarmos com: nome do recurso, tipo do recurso (material, mão de obra), valor da hora dos
recursos humanos, entre outros. Alguns campos possuem nomes parecidos, ou idênticos a campos das tabelas tipo
atividade, no entanto, devemos sempre ter em mente que tratam-se de campos diferentes.
Criaremos a tabela Step 9 – Definição e documentação dos recursos com os campos descritos abaixo.
Os campos ID, indicators e Name se comportam de forma semelhante aos seus equivalentes do tipo atividade, mas
como dito anteriormente, tratam-se de outros campos, do tipo recurso.
Type
Aqui selecionamos o tipo do recurso, tal qual interpretado pela ferramenta. São três os possíveis tipos: Work (mão de
obra), Material (material consumível) e Cost (recursos financeiros). Selecionar o tipo correto é etapa muito importante
da definição dos recursos, e esse tópico será tratado no item 4.2.1.3 a seguir.
Material Label
Caso o tipo do recurso selecionado seja material, podemos definir um rótulo para este material, que será exibido junto
à quantidade deste recurso no momento da alocação e na representação do consumo deste recurso. Como exemplos,
poderíamos criar o recurso tijolo com o rótulo “unidade”, e o recurso solvente com rótulo “lata de 5l”.
Max Units
Somente para recursos do tipo Work, podemos definir a quantidade máxima disponível para utilização simultânea no
projeto, ou conjunto de projetos no caso de definição em pool de recursos. Caso façamos a locação de um recurso
com uma quantidade superior à quantidade máxima disponível, o MS Project nos alertará que este está superalocado.
Standart Rate
Devemos inserir aqui o valor financeiro padrão relacionado ao recurso. No caso de recursos tipo work, trata-se de um
valor por unidade de tempo, sendo a unidade padrão “hora”. Dessa forma, inserindo o valor de R$ 15/h para o recurso
“Ajudante”, quando 1 unidade deste recurso estiver alocado à atividade de duração igual a 4 horas, este trabalho terá
um custo de 15 x 4 = R$60,00.
Caso o recurso seja do tipo material, o valor inserido neste campo representa, por padrão, seu custo de aquisição,
que independe da duração da atividade.
Overtime Cost
Recursos do tipo work podem realizar trabalho caracterizado como hora extra. Para esse tipo de trabalho, devemos
inserir o valor cobrado por unidade de tempo, que novamente tem como padrão R$/h.
Cost Per Use

Podemos inserir um valor financeiro a ser cobrado sempre que o recurso for alocado a uma atividade. Este campo
deve ser utilizado se o valor for invariável, independente das características da atividade.
Accrue At
Neste campo temos a possibilidade de escolher a forma de distribuição do custo do recurso ao longo da duração das
atividades nas quais está alocado. Esta escolha pode ser feita para qualquer tipo de recurso (work, material ou cost)
e define se a concentração do custo se dará no início da atividade, no seu término ou se será distribuída ao longo da
sua duração para os valores Start, Finish e Prorated, respectivamente.
Para exemplificar, criamos um novo arquivo em que definimos três recursos tipo work e uma atividade. Cada um dos
recursos recebeu um valor para o campo Accrue At e todos foram alocados na mesma atividade. Também definimos
o mesmo valor padrão (R$/h).
Repare a imagem abaixo, que exibe parte de um modo tipo Resource Usagem, que apresentaremos no decorrer
deste capítulo. Nesta imagem podemos ver que todos os recursos possuem o mesmo valor para o campo Work nesta
alocação, e a mesma distribuição de trabalho. O custo, no entanto, se concentra no início, no final ou é dividido ao
longo da alocação, conforme a escolha realizada no campo Accrue At.
Base Calendar
Definimos aqui o calendário base a ser utilizado pelo recurso. Diferente do campo de seleção do calendário das
atividades, não existe o valor “none”, usado para herdar o calendário padrão do projeto. No caso dos recursos o
calendário padrão do projeto será exibido por padrão no campo Base Calendar, e desejando-se selecionar outro,
basta alterar este valor. Mais informações no item 1.1.2.1 deste capítulo.
Os campos Group, Code e Email Address são campos padrão da ferramenta, que aceitam informações tal qual um
campo customizável do tipo text, que usamos para aprimorar a documentação dos recursos. Cabe ao usuário definir
a forma como serão utilizados, e lembramos que se faz importante a documentação do uso específico dos campos
da ferramenta para garantia da qualidade da comunicação com os envolvidos no projeto.
O modo superior do nosso modo composto não utiliza

grupos ou filtros, dessa forma, tendo pronta sua tabela,
podemos já terminar sua criação. Como visto na janela
ao lado, ele utiliza a screen Resource Sheet.
Para nosso modo inferior, vamos utilizar o

Resource Name Form, modo padrão da ferramenta
que utiliza a screen de mesmo nome.
Criamos o modo composto como visto na imagem
ao lado.
Terminada a criação do modo, devemos selecioná-lo como ativo e iniciar a definição dos recursos conforme as
necessidades do projeto. Pra isso, preenchemos no mínimo os campos name e type, inseridos na nossa tabela. O
preenchimento dos demais campos, incluindo o dicionário dos recursos, é simples e será tratado no item 4.1.2
Documentação Básica.
4.2.1.3. Tipos de Recurso
A escolha do tipo de recurso, dentre os três suportados pela ferramenta, depende unicamente da utilização visada
pela equipe de planejamento, de forma análoga à parametrização das restrições de cronograma do projeto, que pode
ocorrer de diversas formas, inclusive para se atingir o mesmo objetivo.
Os três tipos de recurso disponíveis na ferramenta possuem seu uso padrão, fortemente ligados aos títulos que
receberam, mas podem ser utilizados de diferentes formas, para melhor atender às necessidades dos envolvidos.
Para que o melhor uso da ferramenta seja alcançado, faz-se necessário que seja compreendida a mecânica específica
relacionada ao uso de cada um destes três tipos de recursos, conhecimento que será alcançado ao se completar a
leitura deste capítulo. Apresentamos abaixo informações que ajudarão na compreensão das diferenças entre os tipos
de recursos, e exemplos de seus usos.
Recurso tipo Work

Tipo mais comumente utilizado pelos usuários desta ferramenta, o tipo work geralmente representa um
profissional, ou grupo de profissionais, disponíveis para utilização no projeto. É o único tipo que pode receber
calendário, quantidade máxima, que fica superalocado e pode ser nivelado automaticamente. Não representa, por
padrão, um recurso consumível, ou seja, uma vez sendo utilizado numa atividade, volta a ficar disponível para
utilização em outras. Por essas características, é o recurso com mais funções de parametrização de
disponibilidade.
Exemplos de utilização:
▪ Pessoa única: Engenheiro Ricardo da Silva
Nesse caso, o recurso representa uma pessoa, bem definida. Sua quantidade máxima obviamente
deve ficar menor ou igual a 1 (ou 100%). O calendário, valor cobrado e todas as configurações, são
relativas a esta pessoa específica.
▪ Grupo de trabalhadores: Eletricistas
É geralmente utilizado para representar um grupo de trabalhadores com a mesma habilidade, em que
quase sempre temos mais de uma unidade disponível. Em projetos de construção, por exemplo,
podemos ter 2 pedreiros, 4 ajudantes, 1 eletricista, representados como 3 recursos na ferramenta:
pedreiros, ajudantes e eletricistas.
▪ Equipe de trabalho: Departamento de marketing
Podemos utilizar este recurso para representar um grupo heterogêneo de profissionais, com diferentes
habilidades e funções, mas que se completam a fim de cumprir um objeto maior. Geralmente esse uso
se dá em projetos de alto nível (pouco detalhados), ou a nível de portfólio, mas pode ser utilizado para
simplificar projetos grandes ou complexos, ao definir por exemplo, uma equipe de solda, equipe de
manutenção; e configurando este recurso para ter as horas de trabalho disponíveis correspondentes a
esses profissionais.
Esta utilização recebe apoio do modo Team Planner, que apresentaremos na seção 4.2.3.3.
▪ Equipamento de quantidade limitada: Guindastes
Para fazer uso da limitação de utilização simultânea dos recursos tipo work, para uma dada quantidade
máxima disponível, podemos utilizá-lo para representar não pessoas, e sim materiais ou equipamentos
de quantidade ou disponibilidade limitada. Podemos ter um número limitado de guindastes.
Como sempre, lembramos da importância de se documentar as decisões e premissas adotadas na elaboração do

arquivo de planejamento e controle do projeto, para apoio à comunicação com os envolvidos, e consequentemente
diversas outras áreas.
Recurso tipo Material

Recursos tipo material normalmente representam aqueles que são consumidos ao longo do projeto. Por não
receberam limitação de quantidades máximas, caberá à equipe o controle e otimização da aquisição x consumo
destes recursos. Entendendo as diferenças entre os recursos do tipo material e work; resta-nos pouco a
acrescentar.
Exemplos de utilização:
▪ Materiais consumíveis: Litros de gasolina
O uso do campo material label facilita a documentação e leitura da quantidade de recursos, quando
usados desta maneira. Podemos verificar a utilização totalizada por pacotes de trabalho, produtos e
grupos.
▪ Equipamentos reutilizáveis: Microcomputador
Podemos utilizar recursos do tipo material para que seja possível estimar a quantidade de utilização
máxima simultânea de um certo equipamento que esteja à disposição no projeto. Nesse exemplo, em
que citamos a utilização de microcomputadores, o recurso deve ser criado sem custo de utilização ou
aquisição, e a análise será verificar a quantidade totalizada de utilização deste recurso, para, por
exemplo, reservar estes equipamentos, garantindo que estejam disponíveis nas quantidades mínimas
necessárias.
▪ Despesa ao longo do tempo: aluguel de grupo gerador
Se ao alocarmos o recurso material, no campo unidades, inserimos um valor ao longo do tempo,

podemos simular este exemplo.
Na imagem acima vemos o aluguel do grupo gerador sendo cobrado mensalmente. Isso significa que
o valor Standart Rate do recurso será cobrado proporcionalmente à duração da atividade.
Recurso tipo Cost

Este se mostra o tipo de recurso mais simples, em que não existem funcionalidades ou opções adicionais a serem
exploradas além do seu uso simples e básico, que é a representação de uso de recursos financeiros que não
sejam representados pelos tipos de recursos descritos anteriormente. Destaca-se o fato do mesmo recurso possuir
valores diferentes a cada alocação realizada.
Exemplos de utilização: Custo de transporte e viagens, taxas e impostos, custo de impressão.

4.2.2. Documentação Básica
Veremos nesta seção como iniciar a documentação dos recursos definidos na ferramenta MS Project, passando pela
familiarização com a tela Resource Information, gerenciando os calendários dos recursos, configurando e visualizando
o organograma e detalhando o dicionário dos recursos.
A atividade de documentação deve ser constantemente alvo da atenção da equipe de projeto, que deve definir sua
metodologia de trabalho. Apresentamos aqui formas de suporte à documentação dos recursos dados pela ferramenta,
que podem (e recomendamos) ser utilizados antes dos recursos serem alocados nas atividades.
4.2.2.1. A tela Resource Information
Assim como temos a tela Task Information para visualizarmos e configurarmos características das
atividades, marcos e produtos do nosso projeto, temos a tela Resource information, que possui
função análoga, beneficiando o gerenciamento dos recursos do projeto. O uso desta tela, cujas guias
apresentaremos abaixo, se faz importante para o acesso a configurações impossíveis de serem
inseridas no nosso modo de definição e documentação de recursos, e por aumentar nossa agilidade e produtividade
na inclusão e edição de informações pontuais ao longo da vida do projeto, uma vez que pode ser acessada
rapidamente através de ícone da aba Resources ou com um duplo clique na linha que representa o produto.
Guia General
Nessa tela a orelha ou aba

apresenta alguns dos campos já
conhecidos na tabela do modo de
definição e documentação dos
recursos e o espaço para o
“Resource Availability”.
Os campos mais importantes são o

“resource name” ou nome dos
recursos, e o “Type” ou tipo
(recurso humano, material ou
custo). O “Group” ou grupo permite
a montagem de visões particulares
e complementares à ORG –
Estrutura Analítica da Organização, o código
ou “code” permite a segregação do centro de
custo do profissional envolvido para
entrosamento e complemento da EAC –
Estrutura Analítica de Custo do projeto, por
exemplo.
O e-mail é muito conveniente para o controle

das atividades e sua execução, como veremos
mais adiante nesse trabalho.
O “Resource Availability” define os períodos disponíveis para trabalho daquele recurso. Isso é útil para que
o sistema possa avaliar o impacto de pequenos atrasos dentro de um projeto. O campo Max Units, que
inserimos na nossa tabela, permite a inclusão da quantidade máxima dos recursos tipo mão de obra (work).
Se ajustado, o “Resource Availability” permite que seja informado ao aplicativo quantidades máximas
diferentes para períodos diferentes. No ajuste ao lado, temos uma unidade disponível até a data de
03/04/2013; 3 unidades até de 03/05/2013; nenhuma até 31/07/2013; 10 até 07/08/2013; e a partir de
08/08/2013 teremos novamente 1 unidade.
O resultado desse ajuste apoia de forma precisa as simulações e análises de alocação de recursos e
reagendamento de atividades, por conta da disponibilidade ou indisponibilidade de recursos. Mais adiante
apresentaremos o modo do “Resource Graph”, no qual esse ajuste poderá ser mais bem apreciado ao longo
do tempo.
Guia “Cost”
Os recursos possuem nessa

ferramenta três valores de custo
base para registro e posterior
uso, em cinco alternativas
diferentes e para até 25 intervalos
de tempo para custeios
possíveis. Isso permite que sejam
previstos aumentos de custo em
decorrência de épocas diferentes
de sua utilização (25 intervalos de
tempos para custeio).
O custo padrão ou “Standard
rate” é aquele utilizado pelo
sistema para cálculo de horas
normais. O custo extra ou “overtime rate” é aquele utilizado pelo sistema quando detecta que o recurso foi
utilizado fora de seu horário normal; o custo pela utilização ou “per use Cost” é aquele que o sistema toma
toda vez que o recurso é utilizado numa atividade independente do tempo de sua utilização.
Esse recurso é bem flexível e permite que os valores sejam introduzidos de forma absoluta ou de modo
relativo ao anterior na expressão de seu percentual.
A forma como o custo será rateado ou “cost

accrual” pode ser ajustado nessa orelha.
Podemos ter o custo alocado no início ou
durante, e rateado no término da atividade.
Guia “Notes”
Essa Guia tem as funções idênticas àquela encontrada na tela de propriedade das atividades. Ficam, então,
dispensados os comentários.
Guia “Custom Fields”
Essa Guia tem as funções idênticas àquela encontrada na tela de propriedade das atividades. Uma vez que
estamos na maioria das vezes
trabalhando com recursos
humanos, é adequado registrar
nesses campos dados pessoais
ou corporativos. Os dados
pessoais como telefone, registros
de identidade e habilidades
específicas podem ser
parametrizados, permitindo que o
operador responsável pela
administração dessas informações
tenha condições de elaborar
visões e grupos que venham a
auxiliar o mapeamento das
competências de seu corpo
profissional. No caso de tratar-se
de materiais, o nome dos
fornecedores, sua forma de
contato e outras informações, como “último preço”, podem ser úteis de alguma forma para as equipes de
compra.
Ao longo deste capítulo utilizaremos campos personalizados, que poderão ser visualizados nesta tela.
4.2.2.2. Calendário dos Recursos
Para parametrização adequada dos nossos projetos na ferramenta MS Project, o uso de calendários se faz quase
sempre como imperativo a partir do momento que necessitamos de períodos de trabalho diferentes do padrão da
ferramenta. Já vimos, anteriormente, como criar e utilizar calendários nas nossas atividades, e a partir de agora vamos
verificar como utilizamos os calendários nos recursos tipo work, lembrando que este é o único tipo capaz de receber
calendário.
A lógica para determinação do agendamento das atividades cujos recursos alocados possuem calendários diferentes
dos seus é encontrar o conjunto intercessão entre os calendários dos recursos e o calendário da atividade. Por
exemplo, se um recurso alocado possua calendário em que
segundas-feiras não são dias de trabalho, e o calendário da
atividade diz que sextas feiras não são dias de trabalho, o
conjunto intercessão mostra que esta atividade será
agendada de forma que haja trabalho de terça a quinta, como ilustrado na imagem ao lado.
Caso não haja período de trabalho em comum entre os calendários da atividade e dos recursos, o MS Project
apresentará uma mensagem de erro semelhante à reproduzida abaixo, na qual é possível identificar o ID e nome da
atividade, nome do projeto e nome do recurso envolvidos no problema.
Clicando em OK, a ferramenta dá preferência ao calendário da atividade, ignorando o calendário do

recurso, enquanto espera que o usuário resolva o conflito. Um ícone no modelo reproduzido ao lado
aparece no campo indicators enquanto o conflito perdurar.
Enquanto o campo para escolha do calendário personalizado das atividades se chama Task Calendar, nas tabelas
de recurso temos o campo Base Calendar. No entanto, o comportamento destes campos não é idêntico, uma vez que
os recursos tipo work possuem calendários base (base calendars) e calendários específicos. Sempre que criamos um
recurso tipo work, automaticamente é criado um calendário, com mesmo nome, para customização da disponibilidade
deste recurso no projeto. Estes calendários, que chamamos de específicos, podem ser acessados da mesma forma
que os calendários para as atividades: Aba
Project, opção Change Working Time. Para
configuração do calendário de um recurso,
devemos selecionar seu calendário base, que
será o ponto de partida, e podemos personalizar
este calendário base através da edição do calendário específico do
recurso. Calendários específicos somente são utilizados pelos
recursos aos quais pertencem, não podendo ser aplicados à
atividades ou outros recursos.
Na imagem à direita vemos parte da tela Change Working Time para

o calendário de um recurso que possui o calendário Standart como base, mas que teve sua semana de trabalho
configurada para que somente seja possível o agendamento de trabalho às terças-feiras.
Novamente faremos uso de um novo arquivo para exemplificar as opções de uso de calendários de recurso, e suas
peculiaridades. Criamos quatro atividades, a princípio iguais, do tipo Fixed Duration, de duração igual a 2 dias. Cada
atividade recebeu um recurso, conforme pode ser visto na imagem a seguir, através do texto no diagrama de Gantt,
ou no campo Resource Names.
 Para a atividade 1, que recebeu o recurso A, nada acontece com a duração, ou data de término, uma vez que o
calendário utilizado pela atividade é o mesmo do recurso: o calendário padrão do MS Project (Standart).
 Alteramos o calendário da atividade 2 para o calendário Task – somente Terça, em que o único dia de trabalho
se dá na terça-feira. Não foi alterado em nada o calendário do recurso 2. Reparemos que a duração da atividade
continua com valor de dois dias, mesmo que o término da atividade seja diferente da atividade 1. Este
comportamento está de acordo com o que vimos anteriormente, e o entendemos como o correto.
 Na atividade 3, mantemos o calendário padrão para a atividade e alteramos o calendário base do recurso, sem
alterar o calendário específico do recurso, e definimos o calendário Res – Somente Terça, no qual também
somente existe trabalho neste dia da semana. Assim que aplicamos o calendário ao recurso, recebemos a
mensagem de erro reproduzida a seguir.
Apesar de não concordar com a mensagem, para manter a alocação necessitamos clicar em OK, e, fazendo isso,
a duração da atividade 3 é alterada. Isso ocorre devido às premissas de configuração das atividades Fixed
Duration desta ferramenta. Isto não ocorre para atividades Fixed Units ou fixed Work.
 É o mesmo o caso da atividade 4, com a única diferença de utilizar o calendário base Standart e ter o seu
calendário específico alterado para que sua semana de trabalho somente contemple atividades às terças-feiras.
Em nenhum dos casos o trabalho possui valor diferente de 16h, o valor correto.
Não concordamos com o valor apresentado para a duração da atividade 3 e 4, que pode gerar problemas de
comunicação e entendimento do agendamento da atividade e dos recursos, e erros de agendamento pela ferramenta.
Abaixo, temos exemplificado um dos erros possíveis de serem gerados por este problema:
Nesta imagem temos um arquivo simples, com somente uma atividade e dois recursos (RES-A e RES-B). A princípio,
tínhamos 4 dias de duração e nenhuma configuração de calendário. A seguir, alteramos o calendário específico do
RES-A para que sua semana de trabalho somente permitisse agendamento de atividades às segundas e terças-
feiras.
Teoricamente, a ferramenta encontraria os momentos de intercessão nos calendários dos recursos e da atividade,
para somente agendar trabalho nesta intercessão, no entanto, isso somente foi realizado para o RES-A, com o
aumento da duração da atividade. Como o RES-B não possuía restrição no seu calendário, seu trabalho foi agendado
nos quatro primeiros dias de trabalho da atividade. Vemos, assim, que os recursos estão agendados para trabalho
não simultâneo, o que pode comprometer a própria realização da atividade, agendamento das atividades sucessoras,
análise de superalocação, entre outras. Este agendamento não síncrono de recursos também pode acontecer em
atividades Fixed Units e Fixed Work. O usuário é recomendado a tomar cuidado e inspecionar o resultado do
agendamento de atividades que possuam mais de um recurso tipo Work alocado.
4.2.2.3. Geração do Organograma
Outro passo importante na documentação dos recursos consiste em permitir que os recursos cadastrados sejam
classificados dentro de uma estrutura organizacional, ou dentro de uma estrutura de habilidades. Essas estruturas
auxiliam o gerente de projetos e o gerente de recursos a analisar as substituições e negociações necessárias nos
momentos de superalocação dos recursos.
No nosso arquivo pool de recursos, vamos editar a tabela do modo Step 10 – Definição e documentação dos Recursos
para incluir três novos campos: Organograma, Habilidades e Can Level. Os dois primeiros serão campos
personalizáveis do tipo Outline Code, que serão apresentados a seguir, o último é campo da ferramenta que nos
permite escolher se o recurso é passível de nivelamento automático ou não. Após a edição da tabela, preencheremos
os dados dos campos inseridos e criaremos um modo para visualização do organograma.
Iniciamos então pela criação dos campos personalizáveis. Através da aba project, ícone Custom Fields,
podemos acessar a tela de mesmo nome. Navegando na opção Type, devemos selecionar o tipo Outline
code. Nela, vamos escolher o Outline Code 9 para ser nosso campo Organograma e o Outline Code 10
para ser o campo Habilidades; então, renomeamos os campos desta forma. Sempre importante lembrar
que estes campos são do tipo Resource, diferentes dos campos personalizáveis do tipo Task, e que as
alterações realizadas no arquivo do Pool serão refletidas nos campos de recurso do nosso projeto.
Após renomearmos os campos, precisamos editar os Lookups para atender às necessidades do nosso organograma.
Abaixo, exemplificamos o resultado da construção das estruturas.
Nos dois campos, recomendamos que as Data entry options sejam realizadas conforme a imagem abaixo, para
garantir que itens adicionais não sejam inseridos automaticamente, e somente permitir que os últimos níveis das
estruturas sejam selecionados.
Após a criação dos campos, editamos a tabela Step 9 e preenchemos os campos com as devidas informações. Em
seguida, no nosso arquivo do projeto, vamos criar o modo Step 11A – Organograma – ORG e o modo Step 11B –
Organograma - Habilidades. Nesta etapa do nosso livro, não se faz necessário repassarmos os passos para criação
de tabelas, grupos e modos, uma vez que já as reproduzimos em diversos momentos anteriores. Dessa forma, basta-
nos exibir as imagens reproduzidas abaixo para o entendimento das configurações realizadas.
4.2.2.4. Dicionário dos Recursos
Podemos acessar o dicionário dos recursos através da guia Notes do Resource Information, conforme mostrado
no item 4.1.2.1, utilizando a parte inferior do nosso modo composto Step 9 ou modo análogo, ou ainda pelo ícone
Notes, encontrado na aba Resource e reproduzido ao lado.
Cabe informar que este dicionário, além de ser diferente do dicionário das atividades, também é diferente do
dicionário das alocações, que será tratado no item 1.1.4.2. Por isso, o campo Notes dos recursos deve ser preenchido
com informações específicas dos recursos, não relacionadas com atividades ou projetos.
Além da descrição, premissas e restrições gerais, link para currículo, entre outras informações pessoais, podemos
citar como importante documentação os critérios para definição dos custos, critérios para escolha da tabela de custo,
anotações sobre premissas e restrições de calendário; especificação de cuidados de transporte para materiais, ou
restrições de tipo de pagamento para recursos tipo cost. Como veremos no capítulo 09, Gerenciamento da
Comunicação, devemos usar a função Print Preview para exportar o dicionário dos recursos.
Terminando este item do nosso capítulo 4, o leitor deve estar apto a preencher toda a tabela do modo Step 10 de
maneira consciente, tendo criado e documentado os recursos do seu projeto. No próximo item aprenderemos como
alocar os recursos nas atividades, que é a razão pela qual modelamos os recursos nesta ferramenta.
4.2.3. Alocação dos Recursos

Após definidos os recursos na ferramenta, sejam eles no próprio arquivo do projeto ou no pool de recursos, se faz
necessário que informemos à ferramenta quais recursos serão utilizados em cada uma das atividades do projeto,
assim como os detalhes desta utilização.
Cabe lembrar que a divisão do trabalho apresentado neste capítulo visa à apresentação do tema de forma didática e
para facilitar consultas posteriores ao conteúdo aqui apresentado. No procedimento de trabalho a ser utilizado pela
equipe de planejamento, as etapas de definição, alocação e documentação dos recursos devem ser atacadas
alternadamente, conforme apresentado no processo no início do capítulo.
Para iniciar o trabalho de alocação, criaremos o modo de apoio Step 12 –

Alocação dos Recursos.
No arquivo do projeto, criamos uma nova tabela do tipo Task, com os

elementos reproduzidos na imagem a seguir, todos já apresentados em
momento anterior do nosso livro, com exceção do campo Resource Names,
do qual trataremos nas próximas páginas. Em seguida, podemos já criar o
modo, uma vez que se trata de modo simples, sem grupos ou filtros.
Após a criação do modo, devemos aplicá-lo e

nos preparar para o ato da alocação dos
recursos, cujas diferentes aproximações serão
apresentadas a seguir.
4.2.3.1. Formas de alocação dos recursos
Diversas vezes nesta ferramenta encontramos formas diferentes para atingirmos um resultado, o que também ocorre
para alocação de recursos. Utilizando o modo recém-criado, passaremos pelas possíveis formas de relacionar os
recursos às atividades. Recomendamos a leitura de toda esta seção do livro, mesmo que o leitor já tenha elegido sua
forma preferida de alocar recursos às atividades. A screen Team planner, por sua forma peculiar, será tratada no item
4.1.3.4.
Ícone Assign Resources
Pode ser acessado através da marcação da atividade desejada e do

acesso pelo ícone de “Assign Resources” na ”Ribbon” Resources
grupo Assignments. Ou através da marcação da atividade desejada
e ALT+F10. Esse ícone aciona o aparecimento de uma tela de apoio
conforme reproduzida a seguir. Essa tela apresenta todos os recursos
disponíveis para esse projeto, quer seja originado pelo pool, quer seja
usando os recursos do próprio projeto.
Para alocação, basta-nos selecionar o

recurso desejado e em seguida
selecionar a opção Assign. No caso de
recursos tipo work ou material, devemos
realizar, logo depois, a definição da
quantidade de recursos alocados, e o
campo custo refletirá o resultado das
nossas configurações anteriores de
custo dos recursos.
Reparemos a possibilidade da alocação

de unidades menores que 1 (um). Se
utilizada para recurso tipo work, significa
que estará proporcionalmente dedicada à atividade, podendo portanto ser alocada em outras, desde que a
quantidade máxima não seja ultrapassada. No caso da imagem anterior, o Design de Interior foi alocado em
0,25 unidades ( ou 25% ). Dessa forma, a princípio, cada dia (8h de duração) terá dedicação de 2h destinada
a essas atividades.
No caso de recurso do tipo material com

alocação menor que 1, interpretamos como
consumo menor que o definido no dicionário do
recurso, e em especial no Material Label (ou rótulo). Exemplificamos ao lado.
A tela Assign Resources é dotada

de filtros que têm o objetivo de
facilitar o trabalho quando o banco
de recursos é muito extenso. É
possível a aplicação dos filtros que
estão disponíveis para o sistema ou
o uso de filtros personalizados, criados pelo usuário da mesma forma como criamos filtros para uso nos
modos. Lembramos que para usar filtros nesse sentido, os mesmos devem ser criados do tipo resource.
A opção do “available to work” permite que a apresentação dos recursos na lista sejam condicionados ao
“saldo” de horas disponíveis no período.
Conforme estamos apresentando, a inclusão dos recursos é simples e trabalhada atividade a atividade, ou
em grupos selecionados de atividades. Esse recurso é útil quando desejamos atribuir mais rapidamente
recursos comuns a mais de uma atividade. O uso dos botões “Assign”; “Remove”; “Replace”; “Close” é
intuitivo e dispensa maiores explicações. O detalhe ou diferença reside na alocação dos recursos tipo cost.
Lembremos que, diferentemente dos outros dois tipos, não realizamos configuração de valor financeiro para
os recursos do tipo cost no momento da sua definição ou documentação básica. Isso ocorre devido à
possibilidade de variação deste valor cada vez que o recurso é alocado, conforme exemplificamos na
imagem a seguir.
Neste exemplo o mesmo recurso (custo de impressão) foi alocado às atividades “Imprimir Layout” e “Imprimir
Pasta de
amostra”,
recebendo
valor
diferente em
cada uma
destas,
conforme
constatamos
pelo campo Resource Names.
No nosso exemplo, definimos o valor financeiro na coluna Cost da tela Assign Resources.
Pela sua simplicidade, recomendamos que a alocação dos recursos seja realizada, por padrão, através da
tela Assign Resources. A seguir, apresentamos outras formas de alocação de recursos, que podem se tornar
a melhor escolha, dependendo da situação.
Outras formas de alocação dos recursos.
Task Information
Através da marcação da atividade desejada e
SHIFT+F2, utilizando a aba “Resources” da
janela de informações.
Através da seleção do nome do recurso ou
“Resource Name” é possível a introdução dos
recursos e sua quantidade na coluna unidades
ou “units”. Esta opção perde para a anterior em
não permitir aplicação de filtro, dificultar a
visualização da lista de recursos e não permitir
a seleção de nova atividade com a tela aberta.
Devemos aplicar as mudanças e abri-la novamente, tornando o procedimento menos produtivo.
Campo Resource Names

Através da inclusão do campo
“Resource Names” na tabela
de atividades e escolha dos
recursos através da caixa de
escolha que aparece na
seleção desse campo.
Esse modo é pouco

recomendado por conta da
possibilidade da inclusão de
recursos não constantes na
relação original (Resource Sheet), uma vez que o item correlato em FILE - Options – Advanced - General
– pode ERRONEAMENTE estar marcado como SIM. É necessário colocar ao lado de cada recurso
selecionado a sua quantidade entre colchetes. Recomendamos então que o uso deste campo se limite ao
suporte da visualização dos recursos já alocados, e uso em fórmulas e
filtros.
Podemos ainda locar os recursos através dos modos tipo Resource Usage e Task Usage, os quais nos permitem
configuração adicional do uso dos recursos ao longo do tempo. Estas importantes screens serão apresentadas na
seção seguinte.
Apresentadas as formas de alocação dos recursos, devemos passar por todas as atividades do nosso projeto e,
através das premissas e informações documentadas pela equipe de planejamento, alocar os recursos conforme
estimativa desenvolvida. É importante que todas as atividades recebam recursos, já que todas as atividades
representam realização de trabalho.
Uma forma simples de verificar se todas as atividades possuem recursos alocados (e verificar se alguma não passou
despercebida) é a utilização do seguinte filtro, que utilizamos no modo highlight:
Reparem que este filtro não ressalta alocações errôneas, ou a falta de um recurso quando existem outros já alocados.
Apenas marca as atividades que não possuem nenhum recurso alocado.
4.2.3.2. A tabela de alocação (assignment)
Até o momento, falamos sobre tabelas do tipo task e tabelas do tipo resource. No entanto, um terceiro tipo de tabela
é criado a partir da junção ordenada dos registros TASK e RESOURCE. Essa tabela só é acessada para trabalho por
meio dos modos que utilizam as screens TASK USAGE e RESOURCE USAGE, deixando muitas vezes os gestores
limitados a relatórios e simulações.
Apresentaremos aqui os modos criados a partir destas screens de forma geral, para que nas seções seguintes
possamos fazer uso de suas possibilidades, sem problemas. Para apoio desta apresentação inicial, teremos o
exemplo a seguir.
Imaginemos um projeto simples, de três atividades, em que existem dois recursos disponíveis, que são alocados
conforme a imagem ao lado. A seguir
Caso desejássemos fazer uma lista de alocações De forma semelhante, caso desejássemos fazer uma
realizadas nas atividades, teríamos algo assim: lista das alocações as quais os recursos estão
submetidos, teríamos algo assim:
Estas imagens são capturas de tela de modos que utilizam as screens Task Usage e Resource Usage,
respectivamente. Estes modos não apresentam formas de organizar ou filtrar informações, como são a utilização de
grupos e filtros, e sim uma forma de exibirmos as alocações relacionadas às atividades, ou aos recursos.
Devemos atentar ao fato dos elementos em itálico não representarem atividades ou recursos. No modo Task Usage,
por exemplo, vemos na primeira linha o elemento que representa a Atividade 01, tal qual seria representado em
qualquer modo do tipo Task, e ‘dentro’ dele os elementos Recurso A e Recurso B, que não representam recursos, e
sim alocações relacionadas à atividade 01. Elementos que representam alocações nos facilitam a visualização e
configuração do uso específico de um recurso, em uma dada atividade. Estas possibilidades de configuração serão
apresentadas nesta seção, e no decorrer deste capítulo.
Ao darmos um duplo clique no elemento que representa a alocação do recurso A na atividade 01, encontramos não
a tela Resource Information, e sim a tela Assignment Information. Exploraremos esta tela.
Na guia General, como o nome sugere, encontramos informações gerais desta alocação, ou seja, do uso do
Recurso A, na atividade 01.
Work e Units
Estas opções nos permitem definir a quantidade de horas de trabalho deste recurso nesta atividade,
assim como sua quantidade. Nesse momento vamos analisar algumas possibilidades de configuração,
para melhor entender estes campos.
Até o momento vimos que, utilizando o calendário padrão, um dia possui 8h de trabalho. Uma unidade
de recurso, alocado em uma atividade que dura um dia, terá alocação de 8h de trabalho, e caso a
alocação seja de 0,5 unidades, a ferramenta acrescentará 4h de trabalho ao campo work da atividade.
Exemplo:
No exemplo acima, em que as atividades são fixed duration, somente um recurso foi adicionado às
atividades, para que possamos identificar claramente a diferença dos valores do campo work, e
associar à quantidade de unidades alocadas, mas este padrão se mantém ao alocarmos mais de um
recurso à mesma atividade.
Com o uso da tabela assignment, na qual podemos editar informações das alocações, é possível editar
o nível de dedicação do recurso sem variar sua quantidade alocada, mas atenção, somente
recomendamos que esta linha de ação seja seguida caso não haja outra maneira de se obter o
resultado desejado. Mostramos abaixo a edição do exemplo anterior, em que agora editamos o campo
work da alocação (o campo work da atividade é alterado para responder à mudança do primeiro),
marcado em verde.
Reparem que, sem alterar a quantidade de recursos, foi possível alterar a quantidade de horas
trabalhadas. Apesar de existirem possibilidades de análise que mitigam os problemas desta prática,
como já citado, não a recomendamos. Listaremos abaixo os motivos mais simples:
Os valores não são imediatamente entendidos por aqueles que os visualizam, podendo gerar
falha de comunicação com os envolvidos;
Caso a organização possua gerenciamento unificado de recursos, o responsável encontrará

dificuldade em levantar a quantidade de recursos necessários à realização das atividades. Por
exemplo, para execução da atividade Y do exemplo acima, é necessária a contratação de 1,5
recursos para que esta seja realizada em 8h, e não 0,5.
Qualquer edição na duração da atividade faz com que o valor do campo work volva ao padrão,
calculado pela multiplicação da duração da atividade pela quantidade de recursos alocados, e,
com isso, perdemos qualquer configuração específica realizada;
Poderemos variar também o nível de dedicação dos recursos à mesma atividade, no tempo, conforme
veremos ainda nesta seção.
Work Contour
Através deste recurso, podemos configurar a distribuição de trabalho ao longo da atividade utilizando 8
curvas padrão, pré-configuradas na ferramenta. São elas:
1. Flat – a carga de trabalho total é dividida pelo período de trabalho em cargas

iguais, obtendo uma “curva” de distribuição plana. Característico de
trabalhos desenvolvidos por produção diária ou planejados.
2. Back Loaded e Front Loaded – a carga de trabalho segue uma distribuição

que tende à linearidade, somente não a atingindo devido aos incrementos
se darem espaçados ao longo do timescale, gerando degraus, mas de taxa
constante.
3. Double Peak– a carga de trabalho reflete dois períodos de carga. Um no

início e o outro ao término. Poder-se-ia tentar descrever essa característica
como atividades que se iniciam, sofrem uma perda de desempenho
programado e depois retomam no mesmo nível para sua conclusão.
4. Early Peak e Late Peak – a carga de trabalho obedece a uma distribuição

do tipo BETA, em que os parâmetros alfa e beta são ajustados para cada
caso. Característicos de pacotes de planejamento, nos quais as atividades
não são detalhadas a níveis suficientes, mas se tem um histórico de maiores
desempenhos no início (early peak) ou no seu término (late peak).
5. Bell – a carga de trabalho obedece a uma distribuição do tipo NORMAL, ou

seja, há pouco volume no início e no término da atividade com uma
concentração maior no meio. Característicos de pacotes de planejamento,
nos quais as atividades não são detalhadas a níveis suficientes para estimar com precisão os pedaços
menores.
6. Turtle – a carga de trabalho obedece a uma distribuição do tipo NORMAL,

porém achatada, mantendo um comportamento constante e plano no meio de
seu período de atuação. Característicos de pacotes de planejamento, nos
quais as atividades não são detalhadas a níveis suficientes, mas se tem um
histórico que atende a esse perfil de comportamento.
A imagem abaixo mostra uma atividade de 5 dias de duração, em que foram adicionados 8 recursos, em
quantidade unitária, cada um seguindo uma curva de alocação. À esquerda, vemos a tela details do modo
Task Usage, que será apresentada em breve.
Reparemos que o campo indicators exibe ícone que retrata a alteração da curva à padrão (flat), tendo cada
curva o seu ícone. Vemos também que a escolha da curva alterou o total de horas trabalhada, ficando o
valor máximo diário relacionado à quantidade de unidades alocadas.
Cost Rate Table
Vimos na seção 4.2.2.1 que os recursos tipo work possuem 5 opções de tabela de custos,
representadas pelas letras de A a E. A seleção de qual tabela de custos será utilizada se dá através
do campo Cost Rate Table.
A guia tracking, por tratar da etapa de controle do projeto, será apresentada no capítulo 7 do nosso livro, e
a guia Notes possui uma seção dedicada a ela ainda neste capítulo (4.2.4.2).
Start Date e Finish Date
Altera a data de início e término da alocação do recurso. Deve ser utilizado com cautela, pois pode alterar a
duração das atividades. Caso a edição seja necessária, aconselhamos que se opte pela utilização da curva
de alocação (work contour) que mais se aproxime da realidade a ser modelada, ou edição do campo work
das telas à direita (área details) nos modos usage.
Após apresentação do conceito dos elementos tipo alocação, e de iniciarmos nosso estudo das suas características
através da tela Assingment Information, continuaremos este estudo introduzindo as screens Task Usage e Resource
Usage, que, como dissemos, são a principal fonte de acesso às informações de alocação.
Neste momento, uma vez que não estamos produzindo modos de trabalho seguindo nossa metodologia de
gerenciamento de projetos através do MS Project, não criaremos novos Steps (modos customizados), e sim
utilizaremos aqueles já definidos pela ferramenta, para testes e descobertas.
Na seção de análise da alocação dos recursos, criaremos modos que atenderão nossas necessidades.
As Screens Task Usage e Resource Usage
Tal qual a screen Gantt Chart, esta também apresenta uma separação vertical da sua tela de trabalho, para, à direita,
exibir informações que são distribuídas ao longo do tempo, seguindo um padrão de timeline definido pelo usuário. Na
imagem abaixo reproduzimos as áreas de interesse desta screen.
1 Aba Task Usage Tools > Format

Assim como todas as screens da ferramenta, esta também exibe uma aba que lhe é específica (Tools Tab).
Aqui temos acesso à configurações tanto da área “tabela” do modo, quanto da sua área Details. Algumas
destas, por já termos visto outras screens que utilizam tabelas, já nos são conhecidas, como o caso daquelas
que estão nos grupos format, Columns e Show/Hide. Apresentaremos as demais.
Details
Este grupo mostra, segundo critérios dos desenvolvedores da ferramenta, algumas das opções de
informações possíveis de serem inseridas na área details, para acesso facilitado. Ainda, mostra a opção Add
Details, onde podemos encontrar as demais opções, assim como configurar-lhes a aparência quando exibidos.
Assignment
Possui dois botões, Information e Notes. Ambos somente são habilitamos quando selecionamos, na área de
tabela, um elemento tipo alocação. A opção Assignment nos mostra a tela Assignment Information, já
apresentada. A opção Notes nos leva à mesma tela, mas diretamente à aba notes, da qual falaremos no item
4.2.4.2.
2 Área Sheet
Esta seção se comporta de forma semelhante às tabelas que utilizamos nos modos que utilizam as screens
Task Sheet, somente não lhe sendo idêntico pela possibilidade de expansão das atividades em suas
alocações. Quando se fala em criação, visualização, configurações e formatação visual, estas tabelas são
idênticas às citadas.
3 Área Details
Aqui encontramos a possibilidade de escolher campos a serem detalhados, tendo suas informações
expandidas para visualização ao longo de um período de tempo. Assim, caso escolhamos o campo work para
ser apresentado, este mostrará não a totalização de todo o trabalho das atividades ou alocações, como no
caso da sua aplicação às tabelas, mas sim a quantidade de trabalho planejada para ser realizada no período
de tempo especificado no timeline. Na imagem acima, por exemplo, cada valor de trabalho diz respeito a uma
semana.
Não é necessário que nos limitemos a um único elemento. Podemos incluir vários para exibição simultânea,
no entanto, recomendamos que a quantidade não exceda 5, visando não prejudicar a visualização e
entendimento por parte dos envolvidos. Caso mais sejam necessários, melhor será dividi-los em outros modos.
A configuração do timescale se faz dispensável, uma vez que já foi apresentada no item XXXX do nosso livro,
quando tratamos da screen Gantt Chart.
Como citado na página anterior, podemos selecionar quais campos serão exibidos na
área de detalhes. Para isso, devemos atingir o ícone Add Details, encontrado da aba
Task Usage Tools > Format, ou clicar com o botão direito na área Details e selecionar a opção Detail Styles... .
Ambos os casos nos levarão até a tela de nome Detail Styles.

Na aba Usage Details, encontramos:
1 Available fields: Mostra os campos possíveis de serem exibidos
2 Show / Hide: Após seleção do campo que desejamos exibir, devemos clicar na opção
show. De forma análoga, para ocultar, selecionamos a opção Hide após
ter marcado um campo que apareça no conjunto Show these fields.
3 Show these fields: conjunto de campos que serão exibidos na área Details
4 Move: Opção de alterar a ordem de exibição dos campos que estão em show these
fields..
5 Field settings for … : Configurações da fonte, cor e padrão de background do

campo. Recomendamos que sejam escolhidas cores diferentes para fácil identificação
6 Show in menu: Se marcada, o elemento aparecerá no conjunto de acesso rápido que encontramos ao clicar com
o botão direito na área Details do modo Task Usage. Ao lado, o conjunto padrão, pré-marcado
para apresentação no ‘menu’.
Já na aba Usage Properties, encontramos

possibilidade de configuração visual adicional
da área Details.
Align details data configura o alinhamento do

texto.
Display details header column informa se o

cabeçalho dos campos inseridos para exibição
detalhada deve ser exibido ou não.
Repeat details header on all assignment

rows informa se a ferramenta deve, ou não,
repetir os cabeçalhos dos campos detalhados em todas as linhas de alocações.
Display short details header names informa se a ferramenta deve abreviar, ou não, os cabeçalhos de campos muito
longos. Por exemplo, Cumulative Work é abreviado para Cum. Work.
Recomendamos que o padrão proveniente da ferramenta seja inalterado.
Selecionamos os campos Work e Cumulative Work para serem exibidos, com as cores de fundo verde claro e azul
claro, respectivamente. Configuramos o timescale para exibição em dois níveis, o mais alto anual, e o mais baixo
mensal. O resultado resumido é mostrado abaixo.
Podemos utilizar um dos ícones encontrados no canto inferior direito da tela

do MS Project como atalho que nos leva até o modo Task Usage, modo
padrão da ferramenta que utiliza a screen de mesmo nome. Trata-se do
segundo ícone, quando começamos a contar a partir da esquerda.
O conteúdo apresentado acima usou o modo Task Usage, mas todos os conceitos e novidades que mostramos são
aplicados aos modos que utilizam a screen Resource Usage, devendo o usuário somente transpô-las para a ideia de
modo tipo recurso, expansível às suas alocações.
Ambas as screens permitem que seus modos recebam grupos, filtros e ordenação. Para exemplificar, mostramos
abaixo o modo Resource Usage, com suas informações agrupadas de acordo com o tipo de recurso.
Nos modos Resource Usage, as atividades e marcos que não receberam nenhum recurso, e por isso não possuem
alocações a ela relacionadas, são agrupadas dentro do conjunto Unassigned, sempre na primeira linha. Devido aos
marcos, seguindo as melhores práticas, não receberem recursos, por padrão, esse conjunto sempre existirá, mesmo
que realize todas as alocações necessárias aos projetos, nas atividades. Podemos utilizar filtros para remover os
marcos desse modo.
Aqui escolhemos visualizar o campo Cost, detalhando-o em timescale mensal. Começamos assim a identificar as
possibilidades de análise do planejamento de recursos e de custo do projeto, assunto do final deste capítulo e do
próximo.
Mais uma forma de alocar recursos
Após a apresentação dos modos tipo Usage, podemos comentar sobre a última forma de alocação dos recursos no
projeto, que é utilizando-se a área details desses modos para definir valores específicos e individualizados de trabalho
ao longo do tempo. Aproveitaremos para comentar sobre o trabalho em hora-
extra (overtime work).
Criemos um modo para realizarmos esta alocação, que deve se chamar Step 13
– Alocação Detalhada. Trata-se de um modo simples, que utiliza a screen
Resource Usage e um filtro para que não sejam exibidos os recursos tipo Cost.
Os campos que devem constar na sua tabela estão exibidos na imagem ao lado,
e as informações do filtro, abaixo.
Selecionamos para a área detalhada, os campos Work, Regular

Work e Overtime Work, com fundos em cores diferentes para facilitar
a leitura.
Digitando direto na planilha da direita, nas linhas correspondentes a atividades escolhidas, e nas colunas
correspondentes ao agendamento individualizado das horas de trabalho, é possível alocar recursos e incluir horas
extras para todos os recursos. Nos campos das linhas do aplicativo relativas à alocação, é possível incluir as
quantidades, período a período de cada recurso, atentando ao detalhe: trabalho = trabalho regular + trabalho extra.
É possível incluir dados apenas nos campos “work” e “regular work”. O valor da hora extra deve ser apresentado
na coluna da planilha da esquerda do modo em questão.
Para exemplificar, vejamos a alocação do recurso Design de Interior, na atividade Realizar ajustes no anteprojeto.
Nesta imagem vemos o elemento que representa a alocação.
Devido a uma restrição de calendário, neste projeto, às segundas-feiras, o expediente para atividades de produção
se inicia às 13:00h. Dessa forma, a duração da atividade não será de 5 dias (40/8h), como imaginaríamos antes de
sermos informados sobre esta restrição.
A ferramenta distribuiu o trabalho de 40h conforme vemos na imagem acima. Podemos, no entanto, alterar essa
distribuição, por exemplo, informando que no primeiro dia o profissional deverá se dedicar 8h, e no último dia 4h, sem
contudo alterar a quantidade total de trabalho desta alocação. Nosso recurso ficou superalocado, mas este é um
assunto ainda por vir.
Simulando agora o uso do trabalho em hora extra, precisamos inserir este valor na célula da coluna Overtime Work.
Cuidado, pois por padrão a ferramenta reduzirá a quantidade de trabalho regular, para que o valor do trabalho total
se mantenha inalterado. Devemos atentar também para a impossibilidade de edição do campo Overtime Work na
área Details, o que prejudica a documentação do projeto, uma vez que não podemos ser precisos em informar quando
esta hora extra foi realizada.
Importante também ficar atento ao fato de recursos exercendo trabalho em hora extra não ficarem superalocados.
Pelo exposto, recomendamos que o uso de trabalho em hora extra seja usado somente caso outra alternativa não
esteja disponível, e fazendo-o, que seja coberto por documentação e comunicação aos envolvidos.
4.2.3.3. Team Planner
Introduzido no MS Project 2010, esta screen permite que a alocação seja realizada com foco nos recursos que serão
utilizados e suas agendas de trabalho. A ideia se mostra interessante e promissora, o que somado aos recursos
gráficos da ferramenta e facilidades de acesso deixam o usuário com altas expectativas com relação a este recurso.
Podemos dividir as áreas dos modos criados com a screen Team Planner desta forma:
1 Aba Team Planner Tools > Format

Segundo a linha de todos os screens da ferramenta, encontramos também para o Team Planner sua guia
Tools Tab, onde possuímos algumas opções para uso dos seus modos, a maioria autoexplicativa.
Destacamos a opção Prevent Overallocation, que, como o nome informa, impede que os recursos recebam
carga de trabalho que os deixe superalocados. Na prática a ferramenta realiza um nivelamento automático
no momento da alocação, atrasando atividades através do campo Leveling delay, para que a superlocação
seja evitada.
2 Lista de recursos
Aqui encontramos a lista de recursos tipo work disponíveis para uso no nosso projeto. Reparemos que
nestes modos encontramos somente os recursos tipo work.
3 Unscheduled Tasks (Atividades não agendadas)

É possível alocar as atividades aos recursos, mas não agendá-las no cronograma do projeto. Para isso,
devemos arrastar as atividades para esta área do modo. Na prática, o recurso é alocado e a atividade é
transformada em Manually Scheduled. Recomendamos que esta prática, por padrão, seja evitada.
4 Atividades agendadas
Encontramos nesta seção, ao longo da timeline que representa seus agendamentos, as atividades que
foram alocadas aos recursos.
Para realizar esta alocação, podemos arrastar as atividades até as linhas dos recursos, no entanto, não
recomendamos esta prática, pois, caso haja movimento horizontal, a ferramenta entenderá que o usuário
deseja impor novas datas de início e término, definindo restrições de cronograma.
Caso não deseje criar estas restrições, recomendamos que faça as alocações clicando com o botão direito
do mouse nas barras que representam as atividades e se use a opção Reassign To.
Um ponto positivo desta área é a possibilidade de visualizar exceções nos calendários dos recursos
marcados como não trabalho, como áreas de cor diferente. Para isso, devemos configurar a aba Non-
working Time da tela Timescale, opção color.
5 Unassigned Tasks
Por fim, temos aqui as atividades ainda sem recursos a ela alocados. Para alocação de múltiplos recursos,
sem sair destes modos, o usuário deverá se dirigir até a janela Task Information (Opção Information... ao
clicar com o botão direito do mouse em uma atividade) e realizar a alocação na aba Resources.
Como o leitor pôde perceber, este modo não deve ser utilizado como forma padrão de alocação de recursos na
maioria dos projetos. Resumimos abaixo os problemas encontrados:
▪ A alocação de múltiplos recursos não é facilitada;
▪ Podemos, facilmente, criar restrições de cronograma indesejados ao movimentarmos as atividades

horizontalmente enquanto as arrastamos até os recursos;
▪ As alterações realizadas neste modo não estão contempladas pelo recurso desfazer (ctrl+z);
▪ Não é possível inserir campos (colunas), dificultando o acesso a informações dos recursos, como, por
exemplo, a quantidade máxima disponível
▪ O Team Planner não pode fazer parte de um modo composto, se o outro modo possuir timeline.
Assim, não identificamos nenhuma vantagem na utilização de modos criados a partir desta view. Caso o usuário
deseje experimentá-lo profissionalmente, recomendamos situações em que colherá os melhores resultados
 Como forma de facilitar a visualização de envolvidos que não tenham familiaridade com a ferramenta com o
processo de alocação de recursos ou determinação de responsabilidades. Somente em projetos de baixa
complexidade.
 Em planejamentos que sigam a metodologia Rolling Wave, ou em outras situações em que tenhamos
pacotes de planejamento, esta screen pode ser usada para determinação de responsáveis ou gestores
destes pacotes de planejamento. Novamente, somente em projetos de baixa complexidade, ou em baixo
nível de detalhamento.
Encerramos informando que o modo padrão da ferramenta de nome Team Planner é um dos relacionados aos ícones
encontrados no canto inferior direito da tela do aplicativo. Trata-se da opção do meio.
4.2.4. Documentação Pós alocação

4.2.4.1. Matriz de Responsabilidade (RAM)
Após a realização das alocações dos recursos, nosso trabalho de documentação continua na apresentação do mapa
de responsabilidades dos profissionais envolvidos, e pela utilização da estrutura dos recursos do aplicativo para
verificar o uso dos materiais e equipamentos no projeto. Esse mapa de uso dos materiais e equipamentos, por conta
da metodologia e do processo de trabalho adotado, permite estudar e planejar as compras e entregas no projeto.
Manter a equipe de trabalho informada de suas atividades, datas de entrega, cargas de esforço previsto, assim como
as responsabilidades em cada momento, melhora o entendimento de equipe e trabalho em grupo, e, dessa forma, o
comprometimento dos seus componentes para com o projeto.
Possuir o mapa de compras e as datas de entrega dos materiais e equipamentos utilizados dá ao gerente de projetos
ou gerente de recursos mais manobra de negociação de preços e logística de acesso e estocagem.
O recurso tipo custo, dentro dessa proposta, se mostra ao logo do tempo, classificado e apresentado apoiando ao
sistema financeiro da organização e dando aos seus gestores uma visão diferenciada de qualidade.
Vamos criar um modo de trabalho que permita a visualização dos recursos humanos alocados no projeto, sua agenda
de trabalho, responsabilidades e papéis, através da matriz de responsabilidade (MR), que é usada para ilustrar as
conexões entre um trabalho que precisa ser realizado e membros da equipe do projeto. Em projetos maiores, é
possível desenvolver as MRs em vários níveis. Um exemplo de uma planilha RACI, (Responsible, Accountable,
Consult, Inform) pode ser obtido através de modo que utilize a screen Resource Usage.
Step 14 – Matriz de Responsabilidade (RACI)
1 - Campos customizáveis
Neste modo simples, utilizaremos
quatro campos customizáveis do tipo
resource, flag, para receber a
classificação da nossa matriz de
responsabilidade. Nosso primeiro
passo será então renomear estes
campos conforme a imagem ao lado.
Como estamos utilizando recursos de
um Pool, a forma mais fácil de editar estes campos será fazê-lo no arquivo do pool de recursos.
2 - Tabela e filtro
Para a tabela, selecionamos somente campos já
apresentados, dispensando-se então explicações de
funcionamento. Para o filtro que utilizaremos, copiaremos
o criado para o modo Step 13, somente alterando-lhe o
nome para ficarmos de acordo com nossa metodologia de
trabalho.
3 – Definição do modo
Utilizaremos a screen Resource Usage por

estarmos interessados em classificar, e ver
classificações de recursos, para termos acesso
às informações de alocação. Podemos então criar
o modo, aplicando a tabela e o filtro já
desenvolvidos. Por padrão, não utilizaremos
grupos, mas estes podem ser inseridos no modo,
conforme necessidades encontradas durante o
trabalho de classificação da matriz de
responsabilidades.
4 – Informações detalhadas
Selecionamos somente o campo work para ser exibido na área Details deste modo, uma vez que não estamos, a
princípio, interessados na visualização de informações ao longo do tempo. Deixar apenas um campo nesta área
facilita a leitura e preenchimento da matriz de responsabilidade, por reduzir a altura das linhas da área de tabela.
Outros campos podem ser inseridos, conforme necessidades de trabalho e documentação encontradas durante o
trabalho.
5 – Preenchimento das informações
Construído o modo, partimos para o preenchimento dos dados de atribuição dos recursos humanos para cada
atividade, e a sua classificação de custeio.
Informações:
• A cada alocação de recursos em atividades é criado um registro específico e consequente das duas tabelas
ATIVIDADES e RECURSOS. Nessas tabelas existem campos específicos que podem ser preenchidos,
como: A tabela de custeio escolhida – “cost rate table”; anotações “notes” entre outras. Porém, não
existem modos para a visualização dessas informações. Nestas anotações podem ser escritas as
responsabilidades dos membros da equipe, que exigem descrições detalhadas que podem ser
especificadas em formatos orientados a texto. Essas descrições e formulários tornam-se modelos
excelentes para futuros projetos, especialmente quando as informações são atualizadas durante todo o
projeto atual pela aplicação de lições aprendidas.
• Na versão liberada do aplicativo, por ocasião desta publicação, os campos livres (COST, NUMBER, DATE,
START FINISH, DURATION) não estão sendo levados de um modo Task Usage para os modos Resource
Usage após o preenchimento nos modos que apresentam os registros da tabela de alocação
(Assignment).
Assim, se faz necessário documentar em que visualização o preenchimento desses campos foi realizado.
Por exemplo, nosso preenchimento da matriz dos envolvidos, que se deu nos campos Flag 1 a 4, foi
realizado na tabela assignment, alcançada a partir da tabela recurso. Aplicando o modo Task Usage,
veremos que os campos Flag 1 a 4 estarão em branco.
4.2.4.2. Mapa de Materiais
Criaremos agora um modo para visualizar e documentar a utilização de materiais e equipamentos ao longo do tempo,
recursos que foram definidos como sendo do tipo Material. Este tipo de informação, explicitada e registrada de forma
clara, deve ser divulgada aos envolvidos para aprovação, em especial aos responsáveis pelos processos de compra,
logística e armazenagem (almoxarifado), para que estes possam negociar melhores preços, otimizar a utilização dos
recursos, e preferencialmente devolver à equipe de planejamento informações para atualização do cronograma.
O processo de construção deste modo, que chamaremos de Step 15 – Mapa de Materiais, é muito parecido ao
de construção do Step 14, motivo pelo qual somente as imagens abaixo devem ser suficientes para seu entendimento
e replicação.
Tabela Filtro
Details Resumo
Renomear campos customizáveis e inserir títulos nos campos da ferramenta que melhor os definam faz parte das
melhores práticas de uso da ferramenta. Por isso, destacamos nesta tabela a importância de incluirmos o título
Quantidade para o campo work, uma vez que neste modo teremos somente recursos do tipo material.
Para utilização deste modo se faz importante que os rótulos dos recursos (unidade de medida) tenham sido
registrados no campo Material Label. Veremos assim que tanto a coluna Quantidade, quanto o campo Work na área
Details apresentará esta informação ao lado do valor numérico que representa a quantidade do recurso material que
as alocações estão utilizando. No caso da área Details, somos capazes de perceber esta utilização ao longo do tempo,
configurado a partir da timeline. Tanto a informação da quantidade total de recursos que serão utilizados no projeto
(coluna Quantidade), quanto o uso ao longo do tempo (Work na área Details) são insumos para o trabalho dos
responsáveis pelo gerenciamento dos recursos no projeto.
Reparemos que os recursos do tipo material também permitem o uso de múltiplas tabelas de custeio, e, assim como
para o caso dos recursos do tipo Work, se definidos valores diferentes de trabalho, seus critérios devem ser
documentados no dicionário dos recursos, e os critérios de escolha devem ser documentados no dicionário das
alocações.
No exemplo exibido abaixo, vemos que o recurso tinta, com unidade de medida em latas de 3,6 litros (galão), será
utilizado em dois conjuntos de atividades. Acabamentos e Intervenção civil não são atividades, e sim pacotes de
planejamento, uma vez que o nosso "projeto exemplo" de reforma da Casa Feliz possui gerenciamento dividido em
fases8, o que não inviabiliza a necessária estimativa de uso de recursos.
O nível mais baixo do timeline está definido com o período semanal. Podemos ver que, ao tod,o serão utilizadas 6
latas de tinta em um período de 4 semanas de projeto, o que nos permite escolher realizar a compra do total no início
do projeto, comprar quinzenalmente ou semanalmente, conforme decisão estratégica.
4.2.4.3. Dicionário da Alocação
Muitas vezes necessitamos documentar o relacionamento dos recursos com as diversas atividades, como o perfil de
trabalho, condições de atuação, previsão de produtividade, regras de trabalho e segurança do trabalho, de forma
clara. Nesse caso, podemos utilizar o campo NOTES da linha da alocação.
Esse recurso pode ser acessado pela inclusão da coluna de mesmo nome na tabela dos
modos que utilizam as screens Task Usage ou Resource Usage, ou pela opção Notes,
encontrada no grupo Assignment da Tools Tab desses modos.
Podemos, então, definir como dicionário das alocações o conjunto de informações (texto, imagens, arquivos) que
documentam as informações específicas e únicas dessas alocações. Não se trata do dicionário da atividade,
tampouco do dicionário do recurso, e sim de informações do relacionamento dessas duas entidades.
No exemplo abaixo temos o recurso Design de Interior ligado à atividade Criar Vistas. Aqui poderíamos inserir, por
exemplo, os critérios de definição da tabela de custeio escolhida, informações de acesso deste recurso ao local onde
a atividade será executada, ferramentas que este recurso
utilizará nesta alocação, critérios de aprovação do trabalho
deste recurso nesta alocação, detalhes do calendário não
modelados na ferramenta, entre outros.
8
Para mais informações, busque por Rolling Wave Schdulling Methodology como exemplo de gerenciamento
dividido em fases.
4.2.5. Análise do Cronograma pós alocação dos recursos
4.2.5.1. Análise dos Insumos do Projeto
A lista de todos os insumos abaixo das atividades que serão utilizados para a realização dos trabalhos necessários é
o nosso próximo trabalho. Essa apresentação é a que mais afeta o gerente de projetos e dá uma visão de conjunto
para a programação dos trabalhos e tomada das providencias necessárias. Isso é conseguido por conta dos
resultados da conclusão da alocação dos recursos.
Step 16 – Apresentar os Insumos do Projeto
Desenvolveremos este modo a partir da screen Task Usage e o

ajustaremos para receber uma tabela que apresente a lista de
campos necessários para a avaliação dos recursos e sua
utilização, tanto na sua composição de quantidades, como de
plano de uso ao longo do tempo. Na tela ao lado temos um
exemplo de sua configuração final.
Os campos escolhidos para essa tabela “Step 16 – Apresentar os

insumos do projeto” são esses apresentados ao lado, sendo importante
observar que o título da coluna NAME, que antes preservava apenas os
pacotes de trabalhos e as atividades, agora passa a conter também
alocações.
Os campos relativos à alocação terão sua cor alterada

para azul, de modo a destacá-los dentro da estrutura.
Essa prática, ainda que não obrigatória, destaca
esses elementos facilitando sua visualização.
Definimos o painel direito do modo (Details), com apenas o

campo WORK.
O resultado final permite que o gerente avalie os insumos de cada atividade, de modo a entender os lançamentos de
recursos, quantidades, perfis, critérios de qualidade e remuneração ou treinamentos.`
Na versão liberada por ocasião desta publicação, o campo WORK acumula a função de apresentar as quantidades
dos campos WORK e MATERIAL, simultaneamente, mas o recurso tipo COST não apresenta aí de forma direta
seus valores. Por isso somos forçados a apresentar a coluna COST.
4.2.5.2. Detecção de Superalocação
Como já citado neste capítulo, os recursos do tipo Work possuem informação de quantidade máxima disponível e,
ultrapassada esta disponibilidade de trabalho, ficam superalocados. Nesta seção, criaremos formas de detectar a
superalocação dos recursos, para que as mesmas possam ser resolvidas.
Antes de iniciarmos a construção de um modo que facilite o nossa trabalho, é interessante alertarmos que, apesar de
estarmos tratando da ultrapassagem ou não da quantidade máxima de recursos disponíveis (precisar de 4 eletricistas
quando temos somente 3 à disposição), a análise de superalocação se torna mais fácil se o analista se preocupar
também em analisar os valores de trabalho (work), além da quantidade de recurso.
Explicando, relembramos os resultados obtidos na seção 4.2.3.2, na qual fomos capazes de editar na tabela de
alocação a quantidade de trabalho dos recursos sem alterar a quantidade de unidades alocadas e, mesmo assim, a
ferramenta marcou como superalocados os recursos que tentavam fornecer mais trabalho que o possível. Devemos
então lembrar que, por padrão, a quantidade de trabalho diária que um recurso do tipo work pode fornecer será a sua
quantidade de unidades máximas, multiplicada pela quantidade de horas de trabalho do dia, segundo seu calendário.
Step 17 – Gerar o Histograma
O gerente de projetos depende muito da disponibilidade de recursos, muitas vezes compartilhados com outros
projetos ou com outras atividades da organização as quais pertencem estes recursos. O MS Project, apesar de suas
limitações, se mostra muito útil para apoio à detecção e análise de superalocações.
Devemos criar um modo composto que representará de forma gráfica (histograma) a utilização dos recursos. Para a
parte superior, teremos um modo utilizando a screen Resource Sheet, que seguirá as definições mostradas a seguir,
e terá o nome Step 17 – Histograma – Sup.
Para a tabela, de nome Step 17 – Histograma – Sup, temos os campos ao

lado.
Definimos também um grupo que deve ser criado como na imagem abaixo. Reparemos que, preferencialmente, o
mesmo deve ser ordenado de forma decrescente, de modo que os recursos do tipo custo sejam os últimos a serem
exibidos.
Não utilizaremos, no modo superior, o filtro para exibição apenas dos recursos do tipo work, pela possibilidade de
utilização deste modo para visualizar a utilização de uso dos materiais, também de forma gráfica.
Para o modo Step 17 – Histograma – Inf, utilizaremos uma nova screen, a Resource Graph. Nessa screen, que não
utiliza tabelas ou grupos, também não utilizaremos filtros. Assim como o modo superior, também não a
apresentaremos no menu. Abaixo, temos as imagens que sumarizam as configurações dos modos superior e inferior,
e do modo composto que as utiliza.
A screen Resource Graph permite que seus modos exibam diferentes tipos de informação de forma gráfica, como
trabalho, custo ou disponibilidade de trabalho. Algumas dessas opções, por motivos lógicos, estão restritas em
recursos do tipo material e tipo custo.
Para selecionar que informação desejamos estar desenhada na tela deste modo, clicamos com o botão direito do
mouse e vemos a lista de possibilidades. Temos:
Recursos tipo work Recursos tipo material Recursos tipo cost

Antes de prosseguir com a finalização do modo, vejamos cada uma destas opções:
Peak Units – mais utilizada para avaliar pelas linhas de disponibilidade (linha preta) a utilização do recurso
alocado, sua disponibilidade no momento, e eventualmente a quantidade excedente necessária no período.
Abaixo, vemos que temos uma unidade do recurso Design de Interior Disponível, mas foram alocadas 1,5
unidades. O valor que excede 1 é mostrado em vermelho para facilitar a identificação da superalocação.
Note que essa ferramenta apresenta o maior valor do período. Neste exemplo, a timeline está definida com dias
no nível mais baixo definido em dias. Note ainda que a escala vertical é ajustada automaticamente pela ferramenta
para uma faixa que contemple os valores de mínimo e máximo exibidos
Work – é utilizada para avaliar a quantidade de trabalho previsto no período, a sua disponibilidade no momento,
e, eventualmente, a quantidade em horas excedente necessária no período. Podemos ver que temos somente
uma unidade deste recurso, e, de acordo com seu calendário, temos 8 horas de trabalho por dia. Valores iguais
ou menores que 8 são mostrados nessa escala na cor azul, enquanto o excedente é mostrado em vermelho e
caracteriza superalocação.
Ao usar a opção Work, devemos tomar cuidado com a totalização do valor do trabalho na escala da timeline. O
MS Project mostrará a coluna vermelha de superalocação somente se o valor do trabalho superar o valor máximo
para o período. Vejamos abaixo um exemplo no qual temos um recurso que está superalocado, pois é requisitado
em mais que seu limite diário (8h), mas não mais que em seu limite semanal (40h).
• Timeline com escala em dias:
• Timeline com escala em semana:

Observamos aqui a importância da identificação por diversos meios, como o ícone exibido no indicators em modos
tipo task, e na marcação vermelha do recurso superalocado em modos do tipo resource.
Cumulative Work –utilizada para avaliar a quantidade de trabalho acumulado e previsto no período. Uma curva
de utilização prevista será apresentada se mudarmos o tipo de gráfico para linhas, e não barras.
Overalocated Work – utilizada para avaliar a quantidade de trabalho não disponível, porem necessário e previsto
no período. Melhor utilização para estudos pontuais de sobrecarga. Essa ferramenta apresenta o valor da soma
do período.
Escala % Work Alocated – Idem ao resultado da Escala Work, porém expresso em percentual. Essa ferramenta
apresenta o maior valor do período.
Remaining Availability – utilizada para avaliar a quantidade de trabalho disponível para uso no período, que se
faz igual ao total de horas de trabalho disponíveis, menos a quantidade de horas de trabalho alocadas.
Cost– utilizada para avaliar a quantidade de recursos financeiros despendidos pelo trabalho programado do
recurso selecionado no período.
Cumulative Cost – da mesma forma que a anterior, porém através da apresentação de valores acumulados. Uma
curva de utilização prevista será apresentada se mudarmos o tipo de gráfico para linhas e não barras.
Work Availability – diferente da Remaining Availability, pode ser considerada como o resultado previsto da
“folha de pagamento” para os recursos tipo work.
Unit Availability – utilizada para apresentar a quantidade de recursos (units) disponível para uso no período,
como se fosse a prontidão dos recursos por unidade. Neste caso, a ferramenta mostra a média do valor do período.
Ainda explorando as possibilidade de configuração deste modo, vamos analisar as possibilidades

das opções Gridlines e Bar styles, possíves de serem acessadas na Tools Tab do modo Resource
Graph, grupo format, ou entre os atalhos da lista visualizada ao se clicar com o botão direito do
mouse sobre a parte gráfica do modo.
Gridlines
Semelhante ao dispositivo já visto para o

diagrama de Gantt, porém com menos itens a
ajustar, nosso foco deve ficar nas datas de estado
do projeto (Status Date) e na data corrente
(Current Date). Recomendamos que as datas de
início e término do projeto (Project Start e Project
Finhish) apareçam de modo tracejado.
Bar Styles
Aqui se fazem os ajustes dos elementos gráficos disponíveis:
Estes são os elementos que devem

representar as grandezas
escolhidas, quer sejam de forma
individual ou para serem
comparadas com uma seleção.
Os valores numéricos no rodapé dos

elementos gráficos (1) ou a linha
preta de disponibilidade (2) são
ajustados pelas caixas de marcação.
A retirada dos valores numéricos da
base dos elementos aumenta o
número de elementos na visão por
contado seu redesenho. O “Bar
overlap” (3) ajuda a evitar que os
diagramas fiquem muito extensos
por ocasião do uso de muitas
informações simultâneas.
A forma de apresentação das

quantidades da grandeza escolhida é feita pela seleção dos elementos (4 a 7). Alguns detalhes interessantes
sobre o “Show as:”.
Os elementos podem ser Barras, Áreas coloridas, Degraus, linhas, ou linhas

em degraus. Vejam os resultados das alterações pelos exemplos diagramados
a seguir.
Step Line
Bar Step Line
Quando utilizamos a seleção de diversos recursos do mesmo tipo, podemos realizar uma comparação entre eles de
demanda, disponibilidade, uso e projeções. Para isso, devemos
selecionar no painel superior o grupo de referência e no painel
inferior selecionar os elementos gráficos e o recurso a ser
analisado.
O grupo de 5 recursos tipo work foi selecionado. O recurso

Pedreiro foi comparado. Para todos os elementos foi
selecionada a opção BAR para seus gráficos.
Melhores práticas para o uso do histograma.
Em conjunto com outros dispositivos de visualização de alocação de recursos nesta ferramenta, podemos dizer que
o histograma bem configurado permite ter uma visão adequada do uso dos recursos, sua superalocação e ociosidade
dentro de um ou mais projetos. A forma escolhida para apresentar neste trabalho o modo histograma combina todos
os recursos disponíveis nessa ferramenta com o objetivo de dar ao gerente de projetos ou de recursos da organização
meios para a tomada de decisão.
No painel superior, a lista de recursos com os indicativos imediatos de excessos; no painel inferior, uma combinação
de ajustes que pelo uso de elementos gráficos tipo STEP e tipo BAR atuem na disposição do planejamento de
utilização.
ATENÇÃO: Na ocasião de lançamento deste material, a ferramenta apresenta erro de sincronia de timeline,
quando utilizamos o modo composto, em que o modo primário ou superior usa a screen Task Usage ou Resource
Usage, e o modo inferior usa a screen Resource Graph. Nessa ocasião, as barras do Resource Graph ficam
defasadas, não correspondendo aos mesmos períodos dos modos superiores. Acreditamos que este será um erro
eliminado no futuro.
Foi possível verificar que o trabalho de detecção de superalocação não se limita à procura de recursos marcados em
vermelho pela ferramenta, uma vez que existe possibilidade de análise, comparação e estudo do trabalho dos
recursos humanos e emprego de recursos materiais. Fechamos esta seção destacando o
comando Next Overllocation (Próxima Superalocação), que leva modos com timeline até
a próxima superalocação do recurso selecionado. Este comando pode ser encontrado na aba Resource, grupo Level.
4.2.5.3. Solução de Superalocação
Agora devemos apresentar métodos de solução para o agendamento com restrições de recursos no projeto e, para
isso, passaremos por diversas possibilidades. Antes, como já estamos acostumados, criaremos um modo para
organizar nossa área de trabalho.
Step 18 – Solução de superalocação
Faremos um modo composto, cuja criação não requer a princípio maiores detalhes, uma vez que o processo já foi
apresentado anteriormente em mais de uma ocasião, ao longo do livro. As telas abaixo são suficientes para que a
replicação seja realizada. Importante notar que utilizamos um filtro já disponível na ferramenta por padrão.
Step 18 - Solução de superalocação – Sup Step 18 - Solução de superalocação – Inf

Continuando a configuração do modo Step 18, selecionamos para a tela Details do modo
superior os campos Work, Overallocation e Peak Units.
No modo inferior, selecionamos a ordenação a partir da data de início das atividades. Esta
opção é encontrada na aba View, grupo Data, enfim, no botão Sort, em que selecionamos
by Start date.
Finalizando, devemos ainda incluir um elemento gráfico no modo inferior, que utiliza a screen
Gantt Chart. Nos encaminhando até Bar Styles, conforme processo descrito no capítulo 3,
incluímos o elemento de nome Delay como uma linha inferior, exibida para todas as atividade
e marcos (Not Summary) ativos (Active) que não tenham sido agendados de forma manual (Not Placeholder). A
imagem abaixo resume esta descrição.
Esta barra será entendida no momento que utilizarmos o recurso de nivelamento automático de recursos, a seguir.
Abaixo, vemos o resultado da construção deste modo, aplicado ao nosso "projeto exemplo".
Solução 1: Aumento da quantidade de recursos
Esta se mostra como a solução mais simples e direta, na qual solucionamos a superalocação de um recurso cuja
necessidade planejada superou a disponibilidade, aumentando esta oferta. Recomendamos que esta linha de ação
seja escolhida somente se o acréscimo de investimento necessário para a maior quantidade de recursos não justifique
outras soluções mais sofisticadas.
Procurando em nosso "projeto exemplo", vemos, através do campo Peak, que no momento atual o número máximo
de ajudantes necessário é igual a 8 unidades, e que a quantidade máxima disponível (Max units) é inferior, igual a 4
unidades. Como solução, podemos igualar a oferta à necessidade.
Novamente informamos que essa solução é simplória e por si só não atende às melhores práticas de gerenciamento
de projetos, uma vez que não se preocupa em minimizar a ociosidade dos recursos, tampouco otimizar a sua
utilização.
Uma variação para esta solução é a especificação de quantidades máximas de recursos variantes ao longo do tempo,
através da tela Resource Information. Aqui ganhamos ao facilitarmos a diminuição da ociosidade dos recursos, no
entanto perdemos proporcionalmente em flexibilidade do cronograma.
Solução 2: Redução do trabalho simultâneo dos recursos
Do mesmo modo que aumentar a disponibilidade de recursos se mostra como uma opção simples para solução da
superalocação, a redução da carga de trabalho do recurso nas atividades do projeto, podem solucionar o estado de
superalocação. Novamente advertimos que esta aproximação, assim como a anterior, deve ser usada somente após
estudo criterioso do impacto das alterações o planejamento.
Dentro do escopo de redução da carga de trabalho simultânea, temos por vezes a oportunidade de aumentar a
duração das atividades, distribuindo o trabalho antes concentrado, ao longo do tempo. Muitas vezes a atividade que
torna o recurso superalocado é uma atividade dirigida ao esforço e sua classificação é do tipo “fixed work”, e não
“fixed units”. Isso significa que uma atividade que possui recursos integrais alocados com uma duração calculada
pode ser completada em um período de tempo maior se os recursos forem reduzidos.
O MSProject2013 não faz essa análise de forma automática, ficando a cargo do usuário a verificação e aplicação
deste conceito. Conforme já apresentado, é possível editar a quantidade de horas de trabalho dos recursos ao longo
do tempo a partir das tabelas de alocação disponíveis nos modos que usam as screens Resource Usage e Task
Usage. Esse ajuste fino é um aliado para resolução de superalocações.
Solução 3: Nivelamento automático dos recursos
Existem basicamente dois tipos de superalocação: superalocação de trabalho e superalocação de unidades. Na

superalocação de trabalho a quantidade máxima de recursos necessários para execução individual de cada atividade
não ultrapassa a quantidade máxima disponível. Assim, com o reagendamento de algumas das atividades nas quais
os recursos superalocados estão alocados, é possível resolver o problema ao retirarmos a simultaneidade no
planejamento de uso dos recursos. Na superalocação de unidades, uma ou mais atividades necessitam de uma
quantidade de recursos superior à quantidade máxima disponível.
O recurso de nivelamento automático consegue

solucionar somente superalocações de trabalho, uma vez
que é regido por um algoritmo que verifica a
disponibilidade dos recursos num dado momento e, por
conta de eventuais conflitos, reagenda a data de início das
atividades através do campo Leveling delay. Este campo
acrescenta um período de tempo entre a data de início mais cedo possível (Early Start) e a data de início planejado
(Start) para as atividades que foram alvo do recurso de nivelamento automático
Esse recurso deve ser utilizado quando não é possível

redistribuir as quantidades de horas de trabalho ao
longo do tempo e nas atividades. Os recursos de
classe como pedreiros, ajudantes, programadores e
auxiliares têm características que permitem essa
aplicação, mas recursos individualizados, ou por que
não dizer especializados, devem ser considerados
“únicos” para o trabalho, daí justificando a técnica do
reagendamento das atividades. A ferramenta dispõe
desse recurso e é chamado de “Level Resources”,
acessado pelo item de menu TOOLS-LEVEL
RESOURCES. É uma ajuda parametrizável dentro
dos limites matemáticos do algoritmo do software.
É importante ajustar os parâmetros para efetuar o

nivelamento, disponível na tela Resource Levelling,
acessada através da opção Leveling Options. Esses
parâmetros são particulares em cada tipo de projeto.
1 - Para evitar que a ferramenta tente nivelar automaticamente qualquer recurso que fique superalocado, gerando
um automatismo de difícil rastreamento pelo usuário, mantemos esta marcação na opção manual.
2 - Período de procura por disponibilidade de alocação. Quanto menor a escala, mais preciso será o agendamento,
porém mais tempo de processamento será necessário. Por exemplo, o ajuste pode ser mantido em “hora a hora”
em função da possibilidade de troca de atividade no mesmo dia entre os profissionais, e inexistência de atividades
com duração definida na escala de minutos.
3 - Esta opção deve permanecer marcada para garantir que antes de cada nova ação da ferramenta de nivelamento,
o resultado dos nivelamentos anteriores sejam apagados, não se sobrepondo aos novos.
4 - Nivelamento em todo o projeto ou em um período dele. Deve ser escolhido de acordo com as características de
cada projeto, porém um nivelamento em todo o projeto é recomendado para os casos gerais, pois os recursos
podem ser utilizados em todas as etapas e em todas as atividades.
5 - Decisão de priorização. Esse parâmetro é muito relevante, pois nele incluímos o conceito de prioridade de
trabalho. Um mesmo recurso concorrido entre mais de uma atividade deve ser alocado àquela atividade de maior
prioridade ou importância para o projeto.
• ID Only - a ordem de introdução das atividades do projeto é considerada como mais importante;
• Standard - O sistema observa a relação de precedências, folgas (a atividade que tem a maior folga é
adiada primeiro), prioridades e restrições . Esse é o padrão do sistema;
• Priority, Standard - O sistema verifica primeiro o valor ajustado para a prioridade e depois para as
relações de precedências, folgas, datas e restrições. É usado na maioria das vezes.
6 - Opções com caixa de marcação:

a. O nivelamento poderá ser feito apenas nas atividades que possuírem folga para isso. Esse ajuste
previne o adiamento do projeto e explora (otimiza) os recursos em primeira instância;
b. O nivelamento pode ajustar os recursos individualmente dentro das atividades. Nesse ajustes, as
equipes de profissionais ou recursos poderão ser ajustadas como recursos que não devem
necessariamente ser considerados como equipe de trabalho;
c. Nivelamento pode criar divisão na duração restante da atividade. O nivelamento pode ajustar os
recursos iniciando as atividades, interrompendo-as e depois as retomando mais tarde. Esse ajuste
deve ser cuidadosamente analisado, pois é equivalente a iniciar uma operação cirurgica na segunda
feira, interrompê-la, voltar e concluí-la na sexta-feira;
d. Nivelar recursos com o “tipo de reserva” marcado como “proposto”. Existem dois “tipos de reserva”,
como visto no campo Booking Type, sendo o proposed utilizado para recursos ainda não confirmados.
e. Nivelar atividades agendadas de forma manual;
É recomendado que todas as opções das caixas de marcação finais fiquem desmarcadas.
Observações sobre o nivelamento automático
Há ainda a opção de limpar o nivelamento ou voltar ao que era antes,

através do botão “clear leveling”, em que podemos ainda selecionar
somente um recurso ou todos. Isso significa que, se a solução
proposta não atender, é possível voltar atrás e restabelecer a ordem
original.
É possível ver quais atividades foram impactadas pelo nivelamento, e ainda em quanto foram impactadas,
pelo campo Leveling Delay, passível de ser aplicado nas tabelas tipo
Task.
O sistema nivela todos os recursos do projeto, porém a análise de

resultados deve ficar a cargo do gerente do projeto ou do controlador
do arquivo do MSProject. Esse recurso demanda muito esforço
computacional e muitas vezes, dependendo do número de atividades,
ele paralisa a máquina para o seu cálculo.
Quando e antes da utilização desse recurso de nivelamento

automático é importante que sejam re-definidas as atividades do tipo
“duração fixa”, mudando-as para o tipo “unidade fixa”. Desse modo
evitamos que, para o atendido às alocações automáticas de recursos,
aconteçam reajustes definitivos das durações por ocasião de testes,
permitindo que as durações originais se mantenham no momento em
que o nivelamento é desfeito, “clear leveling”.
Os recursos que forem marcados como “não niveláveis” ou o campo CAN LEVEL marcado como NO não
promoverão o reagendamento das atividades. De mesma forma, as atividades com o ajuste do campo
PROIRITY em 1000 não serão passíveis desse reagendamento;
Apesar de recursos do tipo material aparecerem na lista de opções para nivelamento individual de recursos,
estes não são passíveis de nivelamento automático nesta ferramenta.
No exemplo a seguir, apresentamos a solução da superalocação do recurso Pedreiros. Inicialmente, tínhamos o

cenário exibido na imagem abaixo, em que três atividades estavam agendadas simultaneamente, cada uma com 2
recursos alocados. Como a quantidade máxima disponível deste recurso é de 4 unidades, os recursos existentes não
eram capazes de suprir a demanda de trabalho. Podemos ver no campo Overallocation, na área Details, a quantidade
de horas de trabalho não atendidas pela situação atual.
Percebemos que, após o nivelamento, a ferramenta selecionou o pacote de planejamento piscina para ser adiado em
alguns dias, de modo a adequar o uso dos recursos à disponibilidade de trabalho à disposição no Pool de Recursos.
Vemos que essa ação isolada não acarreta alteração nos custos do projeto, uma vez que o total de horas de trabalho
se manteve inalterado. Para uma análise mais completa do impacto do nivelamento dos recursos nos custos do
projeto, devemos verificar outras atividades, recursos e calendários.
Editaremos agora o modo Step 18 inferior, de forma a inserir o campo Leveling Delay na sua tabela, e mais dois
elementos gráficos no seu diagrama de Gantt. O campo Leveling Delay mostra em edays (elapsed days) o nível de
retardo aplicado a uma determinada atividade. Esse campo Leveling Delay denuncia o número de dias corridos que
foi necessário somar ao sistema de predecessores-sucessores das ligações entre as atividades para acomodar os
recursos sem a superalocação.
Os elementos gráficos inseridos podem ser utilizados para analisar o impacto do nivelamento, uma vez que mostram
o estado das atividades antes da aplicação desta função da ferramenta. A definição usa os dados Preleveled Start e
Preleveled Finish, conforme visto na imagem abaixo.
Analisando os pacotes de planejamento aos quais o recurso Pedreiros está alocado, podemos ver que todos foram
impactados pelo uso do nivelamento dos recursos do projeto, mesmo que somente "piscina" tenha recebido valor no
Leveling Delay. Esse impacto foi devido ao reagendamento de atividades ou pacotes de planejamento predecessores.
Se incluirmos agora o campo Priority para definição das prioridades das atividades e pacotes de planejamento,
podemos interferir na escolha da atividade que será adiada pela ferramenta, ao utilizarmos o nivelamento automático.
Resolução de falsos conflitos
Classificamos como falsos conflitos aqueles conflitos de super-alocação de recursos que são apresentados pela
ferramenta e que não são atribuídos de fato ao planejamento, e sim pela má utilização do software ou falta de
procedimentos adequados de trabalho.
Às vezes, quando na etapa de desenvolvimento do planejamento por ação voluntária do operador, é gravada mais de
uma versão do mesmo arquivo de trabalho na forma de “backup” ou para registro do estado do cronograma, um
problema possível de ocorrer é o aparecimento de superalocações de recursos onde não havia, ou quando estes já
haviam sido solucionados.
Tome como exemplo o caso de um projeto que por conta de falta

de recursos disponíveis mereceu a atenção do operador na
utilização de um dos diversos modos de resolução de conflitos
apresentados anteriormente. Logo após essa operação
trabalhosa, ao verificar através de um Modo derivado do
Resource Usage que nenhum dos recursos apresentava mais a
cor vermelha, fechou o arquivo. Ao abrí-lo novamente por conta
de uma gravação de segurança, os mesmos recursos se
apresentaram novamente em sobrecarga.
Isso pode acontecer se o arquivo de número de maior versão,

uma mais atualizada, tiver sido gravado com o modo “salvar
como ...”: outro nome. Essa maneira de preservação de versões
faz com que o novo arquivo criado herde entre outras coisas a ligação com o arquivo do Pool de Recursos
originalmente definido.
Isso pode ser verificado e resolvido dentro do arquivo do Pool de Recursos, no “Ribbon” Resource grupo
Assignments Resource Pool, elemento SHARE RESOURCES, verificando que mais de um arquivo está ligado ao
Pool de uma certa forma indevida.
Solução: Marcar o arquivo não desejado e a seguir aplicar o comando “break link”. Isso fará com que o sistema
retorne ao normal. Uma alternativa é cancelar o vínculo a partir do arquivo do projeto, informando que este não mais
usa recursos do Pool.
A classificação de falta de procedimentos adequados de trabalho foi dada aqui porque muitas das vezes
verificamos erros de superalocação por falta de procedimentos adequados de alocação de recursos.
Como primeiro exemplo desse tipo de falta de procedimentos adequados de trabalho, temos o fato de uma forma de
alocação que permite praticarmos vícios que só vamos perceber ao nos depararmos com as ditas superalocações. A
alocação dos recursos pelo Ícone Assign Resources faz com que isso aconteça. A cada alocação realizada em uma
atividade dessa forma os recursos são atribuídos de modo uniforme e constante, sendo sempre na sua forma
completa período a período de trabalho. É o caso da alocação de uma unidade do recurso “cara” a uma atividade de
4 dias. Todos os quatro dias automaticamente recebem uma carga de trabalho de 8h, atribuída independentemente
da real necessidade desse trabalho. Isso já foi abordado anteriormente no preenchimento do “perfil de carga” ou
“work contour”, e nesse caso o modelo é o FLAT.
Analisando o modelo acima, temos no cenário proposto (destaque 1 acima) a distribuição FLAT, em vez de uma
distribuição consciente e necessária período a período.
Solução: Analisar o tipo de técnica disponível no aplicativo para cada caso.
Como segundo exemplo, temos a alocação dos recursos em atividades administrativas e de produção indistintamente,
fazendo com que nas atividades de administração – caracterizadas como HAMMOCKS, apareça no decorrer do
projeto um recurso SIMULTANEAMENTE ao seu uso eventual nas atividades de produção. O nivelamento automático
não será capaz de acertar isso. Sempre que o aplicativo acertar a produção e reagendar as atividades, a HAMMOCK
será ajustada de forma automática, criando nova super-alocação.
Solução: Criar para os tipos administrativos recursos separados para verificar o uso com campo CAN LEVEL sempre
ajustados para NO.
4.2.5.4. Agenda dos Recursos
Step 19 - Agenda dos Recursos
A seguir, devemos representar no calendário dos dias do mês a

programação e trabalho ou de recebimento de materiais de um ou mais
projetos.
Quando os projetos reúnem as características necessárias à promoção
de comprometimento e adesão das equipes, pode ser interessante
possuir um programa de informação de atividades dos recursos e,
dependendo dos casos, do recebimento de materiais e equipamentos
dos projetos. A isso chamamos aqui de agenda. No momento em que
algo ou um evento deve acontecer, essa prática pode ser muito útil para
a disseminação e comprometimento dos envolvidos das equipes e dos
fornecedores de materiais.
Criaremos um modo de trabalho que permita essa visualização da agenda dos recursos na forma de um calendário
tradicional para apoio aos recursos humanos e aos fornecedores de materiais.
Item 1 – Desenvolver um filtro que, possuindo o mesmo nome, traga uma seleção dado uma escolha pelo operador.
Uma vez que temos a possibilidade de encontrar mais de um recurso para uma mesma atividade, o filtro a ser
desenvolvido deve possuir um critério de seleção que identifique a existência do item entre outros.
O filtro desenvolvido deve também passar uma

interação com o operador para receber um
parâmetro de informação: o nome do recurso. Uma
vez que, pelos princípios adotados na alocação, não
teremos recursos alocados dentro de outro
elemento que não as atividades, deixamos
desmarcado o item “Show related summary rows”
. A passagem de parâmetros se dará pela inclusão
de uma frase entre as aspas e com um caractere de
interrogação ao final, ou seja: “Escolha o recurso”?.
As aspas se fazem necessárias.
Dessa forma, sempre que o modo for aplicado, deveremos selecionar

o recurso do qual desejamos ver o calendário.
Item 2 - Criar um modo apoiado no padrão screen “Calendar“ com o nome de Step 19 – Agenda dos Recursos.
Ajustar o modo “calendar” para atender os objetivos propostos. O modo padrão oferecido pela ferramenta possui
ajustes que não necessariamente serão utilizados para atendimento às boas práticas e ao demandado pelos gestores.
Os elementos gráficos do modo, como todos os modos gráficos do aplicativo, podem ser ajustados para permitir uma
melhor representação do desejado. A escala de tempo para impressão (1) pode ser definida inicialmente como
semana ou mês, mas a opção “custom” está
disponível para eventuais alterações.
O título da caixa (2), assim como a

identificação da data (3) e do fundo (4),
podem ser redefinidos, ou ainda do painel com calendários de apoio. Todos através da Tools Tab Format ou pelo
duplo clique nesses pontos.
O botão direito na área do calendário também apresenta um menu suspenso com as mesmas opções em atalho.
Os ajustes do “Timescale ...”.
Aba “Week Headings” – permite

definir ou redefinir as
informações que devem ser
mostradas nos identificadores
dos elementos de tempo. Título
da semana, título do mês e título
do dia são responsáveis pela
aparência do calendário, já a
semana apresentada com 5 ou 7
dias define a inclusão de
SÁBADOS e DOMINGOS. O
item “Display month pane”
permite apresentar as miniaturas
dos meses antecessor e
sucessor do mês corrente. O item “Display monthly titles ...” evidencia o período coberto pelo calendário exposto
em seus meses contemplados.
Aba “Date Boxes” – permite

definir ou redefinir as indicações
de datas nas caixas do
calendário. São permitidas 4
anotações, duas tarjas, uma na
parte superior (padrão) e outra
na parte inferior da caixa. Um
símbolo indicativo de que há
mais conteúdo do que aquele
atualmente mostrado no
diagrama pode ser incluído
(padrão) para orientar ao
operador que há mais atividades
na data que aquelas
apresentadas, conforme destaque na figura ao lado.
Aba “Date Shading” – permite

definir ou redefinir as
informações de dias não
trabalhados no calendário
apresentado. Da mesma forma
que realizado no diagrama de
Gantt, é possível estabelecer
qual calendário define os
elementos gráficos de dias não
trabalhados para a
apresentação. Um recurso
interessante é o “exception
shading”. Nele é possível definir
como as cores das hachuras se
comportarão para diversas situações, inclusive quando utilizamos o calendário dos recursos.
Os ajustes das Barras ou “Bar Styles”.
Através do item de menu “Bar Style...”, ou pelo clique com o botão direito na área de trabalho, acessamos os ajustes
das barras e, na tela abaixo, os elementos de ajustes. Para cada tipo de elemento do planejamento é possível ajustar
forma, preenchimento, cor e sombra. No caso dos textos que aparecem dentro dos elementos, contamos com a caixa
seletora de campos, tendo o ponto e vírgula como conectivo “e”, e a possibilidade de quebra automática na
apresentação.
Item 3
Definir os ajustes do Step 19 - Agenda dos Recursos
Definir para todos os elementos gráficos (1)

a forma dos elementos (2) como
preenchimento homogêneo, na cor cinza
prata, sem sombras, apresentando apenas
o campo NAME (3) e permitindo a quebra
automática (4). O resultado dessa forma
será um calendário limpo e simples,
montado para um dado recurso escolhido
previamente pelo filtro interativo. Em estilos
de texto, ajustar para que todos os nomes
possuam tamanho de fonte 10, regular
viabilizando assim a leitura.
Como “layout”, ajustar os elementos para serem ordenados a partir do seu número de identificação quando
apresentados no mesmo dia/data, conforme a figura ao lado.
Ajustar o “Print Setup” a partir do “Print Preview”, de modo a

permitir que a altura ajustada na tela para a semana seja
preservada – “week height as on screen”; em “Text Styles”
ajustar todos os textos para fonte tamanho 10; e outros ajustes
como a tela ao lado. O Item “Print Notes” deverá ser analisado
caso a caso.
4.2.5.5. Linha de Base 2: Recursos (Baseline 2)
Quando encerramos o capítulo 3, obtivemos o cronograma do projeto realizado somente com restrições de tempo,
resultado importante que foi documentado através do recurso de linha de base da ferramenta, como vimos na seção
3.2.4.4 do nosso livro. Como dito naquela ocasião, faremos procedimento semelhante ao longo da construção do
nosso cronograma para documentar os níveis de restrição para comparação posterior.
Assim sendo, voltamos à opção Set Baseline, encontrada na aba Project, seguindo para
a opção Set Baseline... , para chegar à tela de mesmo nome. Nela, devemos atualizar a
linha de base para o novo estado do cronograma e ainda armazenar este estado na opção
Baseline2, da mesma forma que salvamos o estado do cronograma com somente
restrição de tempo no Baseline1. Mais informações sobre este procedimento foram
fornecidas no item 3.2.4.4.
Uma alternativa é salvar diretamente em Baseline2, caso não

façamos uso das informações do cronograma para comparação
durante a etapa de planejamento.
Feito isso, já temos dados armazenados em Baseline1 (Tempo)

e Baseline2 (Recurso). No futuro, usaremos o espaço Baseline3
para registrar o cronograma com restrições financeiras, entre
outros.
5. Capítulo 05: Gerenciamento dos Custos
5.1. Conceitos de Gerenciamento dos Custos
O gerenciamento dos custos não pode se limitar apenas a verificar o que se gasta contra o que deveria ter sido gasto.
Essa visão limitada muitas vezes traz ao gerente a impressão do que estamos no controle da situação, quando, na
verdade, os acionistas, investidores e patrocinadores não estão sendo atendidos. O tempo do gasto, tão importante
quanto o gasto em si, define a dinâmica do fluxo de desembolso e a saúde financeira do projeto. Esse capítulo atribui
um estudo do fluxo econômico do projeto, e não do financeiro, mas é a base para entendimento e para subsídio do
que está por vir. Os investidores que comprometem o seu capital trabalham com expectativas de retorno do capital
investido que lhes assegurem uma taxa de rentabilidade atraente ou prêmio do capital investido ou ainda que reflita
um novo posicionamento estratégico de mercado do seu produto ou serviço, de tal forma que no futuro possa se
traduzir em números rentáveis ao capital investido. Projetando essa linha de necessidade a um contexto de
volatilidade nos grandes movimentos de capitais dentro do cenário globalizado, teremos dentro das Organizações
Empresariais Privadas ou Públicas o alinhamento em bases metodológicas e processuais que possam garantir que o
orçado esteja compatibilizado com os custos globais previstos e que sejam controlados e gerenciados dentro de
processos racionais de análise, apoiados por técnicas e ferramentas e facilitadores desse gerenciamento.
O gerenciamento dos custos do

projeto inclui os processos
envolvidos em planejamento,
estimativa, orçamentação e
controle dos custos, de modo que
seja possível terminar o projeto
dentro do orçamento aprovado.
Em muitas áreas de aplicação, o planejamento e análise da perspectiva do desempenho financeiro do produto do

projeto são feitos em ambiente exterior ao projeto. Em suma, o Gerenciamento dos Custos do Projeto também deve
incluir este trabalho. Quando tais previsões e análises são incluídas, necessariamente processos e técnicas adicionais
serão incluídas, tal como retorno do investimento, descontado o fluxo de caixa colocado e a análise do “payback” do
investimento.
5.1.1. Planejar os Custos do Projeto

Processo que estabelece as políticas, procedimentos de documentação para planejar, gerenciar, executar e
controlar os custos do projeto. O principal benefício deste processo é que ele assegura que os processos de
gestão de custo e as suas ferramentas e técnicas associadas estejam documentadas. O processo de
planejamento para estimativa dos custos do projeto deve considerar o plano de gerenciamento de riscos.
Esse plano de gerenciamento é o resultado do trabalho da equipe de análise de riscos e traz a identificação
dos possíveis riscos e ou oportunidades que podem provocar impactos negativos ou positivos, dependendo
do elemento e força que atua sobre o mesmo. Esses riscos positivos ou negativos em ambos os casos se
refletem em custos. Como regra geral, quando o projeto sofre um evento de risco negativo , isto vai significar
um aumento de custo e impacto no cronograma. Do mesmo modo, o plano de gerenciamento dos recursos
humanos pode ser relevante para entender os gastos com treinamento e premiações, previstos pelo termo
de abertura e relatado no plano de RH.
Várias entradas para apoio a esse processo são necessárias, mas todas já comentadas aqui, como o Termo
de Abertura do Projeto, Fatores ambientais da empresa, Ativos de processos organizacionais, e o Plano de
Gerenciamento do Projeto, que são de nosso conhecimento; mas um elemento fundamental é a EAP
(Estrutura Analítica de Projeto) ou WBS e Dicionário.
1 – Opinião Especializada – essa técnica é usada tomando como referência a expertise dos profissionais
que são especialistas, tanto na área do projeto (área técnica), como também na área econômica-financeira.
Nesse caso, a informação conseguida por esses especialistas normalmente permeia todas as técnicas
descritas a seguir, para obter o melhor valor de estimativa, mais acurado e preciso, assim como mais
confiável.
2 - Técnicas Analíticas – o desenvolvimento do plano de gerenciamento de custos pode envolver a escolha

de opções estratégicas para financiar o projeto, tais como: auto-financiamento, o financiamento com capital
próprio ou financiamento com dívida. O custo plano de gestão pode ter também detalhes para financiar os
recursos do projeto, tais como compras, aluguéis ou “leasing”. Estas decisões, assim como outras decisões
financeiras, podem afetar os riscos do projeto. Outras técnicas podem ser incluídas, como: tempo de retorno
do investimento (Payback), o valor do retorno sobre o investimento, a taxa interna de retorno, fluxo de caixa
descontado e valor presente líquido.
3 – Reuniões - já conhecidas de outros processos de trabalho, a reunião de equipes de projeto de

planejamento para desenvolver o plano de gerenciamento de custos é uma constante. Os participantes
dessas reuniões podem incluir o gerente de projeto, o patrocinador do projeto, membros da equipe de
projeto, alguém com a responsabilidade de planejamento de custos ou de execução e outros, conforme a
necessidade.
Saídas do processo
1 – Plano de Gerenciamento dos Custos – Esse plano é um dos componentes do plano de gerenciamento
do projeto e descreve como os custos do projeto serão planejados, estruturados, monitorados e controlados.
A gestão de custos possui processos e suas ferramentas associadas e técnicas são documentadas no plano
de gestão de custos. O nível de precisão deve ser explicitado nesse documento, assim como a unidade de
medida, normalmente em moeda ou hora básica de custo conhecido. As tolerâncias de desvios, assim como
possivelmente praticadas na gestão do tempo do projeto, estão associadas aos níveis de competência e
autonomia citados no Termo de Abertura do Projeto. As regras de medição, aqui com destaque no método
do valor agregado, e os valores projetados ao final passam também pelo formato dos relatórios.
5.1.2. Estimar os Custos

Esse processo envolve atribuir valores dos custos requeridos a implementação das atividades do projeto.
Para desenvolver uma estimativa dos custos da forma mais realista possível, deve-se elaborar uma análise
quantitativa dos resultados prováveis. Para melhor balizamento no processo de estimativa dos custos do
projeto, deve-se incluir, identificar e ponderar várias alternativas de custo. Estimar custos de atividade
envolve desenvolver uma aproximação dos custos dos recursos requeridos necessários para completar as
atividades do projeto. Numa análise histórica das melhores práticas registradas pelo PMI, verifica-se que
uma modificação ocorreu na edição do PMBOK 2004, na qual o processo de “estimativa dos recursos das
atividades do cronograma” passou do gerenciamento dos cursos para o desenvolvimento no capítulo 6 do
Gerenciamento de Tempo, entretanto, o desenvolvimento das estimativas de custos das atividades do
cronograma dos recursos necessários para completar o projeto são inerentes ao Gerenciamento de Custo.
Nota–se, perfeitamente, a necessidade de Integração, conforme apresentado anteriormente neste trabalho,
para o perfeito desenvolvimento do Gerenciamento do Projeto. As estimativas de custos são geralmente
expressas em unidades de alguma moeda (ou seja, dólares, euros, ienes, etc.), emboraalgumas unidades
de outras instâncias de medida, tais como horas de trabalho ou dia pessoal, são usadas para facilitar a
comparação, eliminando os efeitos da flutuação da moeda. As estimativas de custo devem ser refinadas
durante o curso do projeto para refletir os detalhes adicionais. A precisão de uma estimativa de projeto irá
aumentar à medida que o projeto progredir através do seu ciclo de vida. Estimativa de custos é um processo
interativo e vai de fase em fase. As fontes de informação de entrada são derivadas a partir das saídas dos
processos de outras áreas de conhecimento. Os custos são estimados para todos os recursos que serão
utilizados no projeto. A estimativa de custo é uma avaliação quantitativa dos custos prováveis dos recursos
necessários para completar as atividades.
Da mesma forma que o processo anterior às entradas, ou requisitos para a esse trabalho (processo), são
conhecidas: Plano de Gerenciamento de Custos; Plano de Recursos Humanos; Linha de Base do Escopo;
Cronograma do Projeto; Fatores ambientais da empresa; e os Ativos de processos organizacionais.
Deixamos aqui o registro de que a identifição e registro dos riscos é um “plus” no que diz respeito à precisão
e abrangência de estudo do que “estimar”, dadas as condições de incertezas do projeto.
1 – Opinião Especializada - Técnica usada tomando como referência a expertise dos profissionais que são
especialistas tanto na área do projeto (área técnica) como também na área econômica-financeira. Nesse
caso, a informação conseguida por esses especialistas normalmente permeia todas as técnicas descritas a
seguir, para obter o melhor valor de estimativa, mais acurado e preciso, assim como mais confiável.
2 - Estimativas análogas - Técnica usada tomando por base os custos reais de projetos anteriores e
semelhantes. Essa técnica é utilizada quando faltam informações detalhadas do projeto. Isso ocorre na fase
inicial. Deve-se levar em conta que, por serem menos dispendiosas, as estimativas por analogia são também
menos precisas. As estimativas análogas são uma forma de avaliação especializada.
3 - Valores de Custo de Recursos9 - Essa técnica é baseada no conhecimento de um indivíduo ou grupo de

indivíduos que estão envolvidos no processo de estimativa de custos dos recursos . Deve–se saber os
valores unitários dos recursos requeridos, tal como homem x hora, unidades métricas e volume dos materiais
envolvidos, para estimar cada recurso das atividades exigidas. Outra fonte são os bancos de dados que
fornecem informações necessárias para estimar os custos dos recursos. Pode-se buscar a cotação de custos
junto aos fornecedores como outra fonte de informações. Caso ainda não se saiba ou não se tenha essa
informação, o caminho será determinar os próprios valores. Deve ser usado como último recurso.
9 Incluída pelo Autor por conta das práticas de engenharia

4 - Estimativa de Custos Bottom - Up - Esta técnica envolve um nível de detalhamento maior e, por isso,
mais preciso. Entretanto, representa um tempo maior gasto no desenvolvimento desse trabalho. Consiste
em trabalhar nos níveis mais baixos das atividades dos pacotes de trabalho identificados (work package)
estimando o custo do trabalho individual e totalizando–os no pacote. Por entenderem que essa técnica pode
demandar muito tempo, conforme já colocado anteriormente, muitos gerentes de projeto usam técnicas
diversas para buscarem a precisão exigida.
6 - Software de Gerenciamento de Projetos - São ferramentas amplamente utilizadas no gerenciamento de

projetos, que utilizam simulações baseadas em cálculos estatísticos que auxiliam nas estimativas de custos.
Tais ferramentas podem simplificar o uso das técnicas descritas acima e, por esse meio, criar condições de
otimização no processo de estimativas dos custos do projeto.
7 - Contingenciamento de Atividades - Essa técnica é usada como instrumento de reservas dos custos
estimados. Na verdade, essas reservas representam custos contigenciados nas atividades identificadas com
algum risco potencial. Deve–se estar atento para não exagerar nessas reservas, criando um nível de carga
(valores) que não esteja bem nivelado .
8 - Custo de Qualidade - O custo de qualidade pode e deve ser usado para preparar a estimativa de custo
de atividade.
9 - Análise de proposta de fornecedor - Outros métodos de estimativa de custos incluem a análise de

proposta de fornecedor e uma análise de quanto o projeto deve custar. Em casos em que os projetos foram
obtidos através de processos competitivos, a equipe do projeto talvez precise realizar um trabalho adicional
de estimativa de custos para examinar o preço de entregas individuais e obter um custo que dê suporte ao
custo final total do projeto.
10 - Estimativa Paramétrica - A estimativa paramétrica utiliza uma relação estatística entre dados históricos
e outras variáveis para calcular um custo para a atividade por parâmetros. Esses parâmetros podem ser
expressos por duração, metro quadrado construído, volume retirado, horas apontadas ou outros como
regionalidade e tipo de contratação. Esta técnica pode produzir níveis mais elevados de precisão,
dependendo da sofisticação e dos dados utilizados no modelo. Estimativas de custos paramétricos podem
ser aplicadas a um projeto ou segmentos de um projeto, em conjunção com outros métodos.
11 - Análise das reservas – Em estimativas é comum e possível incluir reservas de recursos financeiros,
também denominadas provisões para contingências. Essas reservas para contingências são custos
estimados que devem ser usados a critério do gerente de projetos para lidar com eventos antecipados, mas
não garantidos. Esses eventos são “desconhecidos conhecidos” e fazem parte do escopo do projeto e das
linhas de base dos custos e provenientes das análises de riscos. Uma forma de gerenciar as reservas para
contingências dos custos é atribuí-las no nível de pacote de trabalho a uma atividade com duração nula, que
se estende do início ao fim da sub-rede do pacote de trabalho. Alternativamente, essa atividade do
cronograma pode ser uma atividade buffer, quando no método da cadeia crítica, e é intencionalmente
colocada diretamente no final do caminho de rede desse grupo de atividades do cronograma.
12 - Estimativa dos três pontos. - Da mesmo modo que apresentado para a estimativa de duração das
atividades, os custos podem ser planejados na mesma forma com um histórico e informações precisas. Esse
método deve ser usado por especialistas por conta das condições de aplicações estatísticas que estão
envolvidas e por conta de seu nível de precisão.
Saídas do processo
1 - Estimativas de custo das atividades - Esse processo tem por objetivo quantificar os custos dos recursos
requeridos para completar todas as atividades do projeto. Podem ser apresentados em resumo ou
detalhados. Os custos estimados devem incluir, mas não ficar limitados a, materiais, equipamentos, mão de
obra, tecnologia da informação, provisões e taxa de inflação. Outras estimativas de situações especiais
podem ser requeridas.
2 – Bases das Estimativas - A quantia e o nível de detalhes que suportarão o processo de estimativa dos
custos irá variar por área de aplicação. Apesar do nível de detalhe, a documentação de apoio ou suporte
deve fornecer um relatório claro, conciso, completo, sendo o mais profissional possível, indicando de que
modo a estimativa dos custos do projeto foi derivada. Os suportes do detalhamento às estimativas dos
custos do projeto deveriam incluir:
• Descrição de escopo da atividade de trabalho.
• Documentação do fundamento à estimativa e como isto foi desenvolvido.
• Documentação de quaisquer premissas feitas.
• Indicação da série de resultados e possíveis flutuações para mais ou para menos com os níveis
limítrofes dessa flutuação - podemos tratar isso como margem de segurança a mais ou menos.

5.1.3. Determinar o Orçamento

Um dos maiores problemas enfrentados pelo Gerente de Projeto e sua equipe é quando eles são
responsáveis por projetos em que as datas de entrega ou término não são realistas. Essa situação ocorre
com muita frequência e muitos gerentes são designados após a assinatura do contrato. É um erro, e não
uma característica da Organização. As melhores práticas mostram a importância de se ter o envolvimento
do Gerente de Projeto na elaboração da proposta comercial, isso muitas vezes não ocorre. A Organização
(empresa ou entidade) é invariavelmente impelida em muitas negociações com o cliente ou por
posicionamento no mercado a uma redução dos prazos de entrega do produto em detrimento de prazos
realistas. Entretanto, a equipe de projeto se compromete a entregar no prazo combinado e dentro do
orçamento. Isso só é possível cortando itens ou atividades de trabalho que seriam necessários. O reflexo
se dará após a entrega, quando relatórios mostrarão custos contínuos que não foram orçados como
manutenção e garantia.
O orçamento dos custos envolve agregar os custos estimados das atividades individuais ou pacotes de
trabalho (work package), de tal forma que seja possível estabelecer uma linha de base ou referência dos
custos totais ou custos globais. Como mencionado acima, os custos globais são representados pelo
somatório dos custos das atividades individuais. A estimativa da atividade ou pacote de trabalho (work
package) é feita depois da carta do projeto fornecer a aprovação do orçamento global, porém o nível principal
da WBS e as estimativas dos seus elementos devem ser feitas antes do orçamento detalhado e autorização
de início de trabalho.
Mais uma vez, as entradas ou requisitos para o desenvolvimento desse trabalho são conhecidas: Estimativas
de Custos das atividades; Declaração do escopo do projeto; Plano de gerenciamento dos Custos; Bases de
Estimativa; Calendários de recursos; Registro de Riscos; Acertos contratuais; e Ativos de processos
organizacionais. O cronograma do Projeto é essencial, uma vez que o orçamento é o desembolso (valor) na
razão do tempo.
1 – Opinião Especializada - Técnica usada tomando como referência a expertise dos profissionais que são
especialistas tanto na área do projeto (área técnica) como também na área econômico-financeira. Nesse
caso, a informação conseguida por esses especialistas normalmente permeia todas as técnicas descritas a
seguir para obter o melhor valor de estimativa, mais acurado e preciso, assim como mais confiável.
2- Agregação dos Custos - Consiste no somatório dos custos individuais identificados. A tarefa mais
complicada é definir as categorias que integram o orçamento.
3 - Gerenciamento de Reservas - Consiste em contigenciar reservas de valores para atividades não

planejadas e mudanças requeridas no escopo e custo do projeto . O gerente do projeto deve obter aprovação
antes da sua utilização. O gerenciamento de Reservas não integra a baseline de custo do projeto, mas é
incluído no orçamento geral do projeto. Essas reservas não fazem parte dos cálculos de valor agregado.
4 – Relações e Modelos Históricos (Paramétricos) - Essa técnica consiste em usar características do projeto
( parâmetros) em um modelo matemático para prever os custos totais do projeto. O custo e a precisão de
modelos paramétricos variam amplamente. Eles geram maior confiança quando: a informação histórica
utilizada para desenvolver o modelo é precisa; os parâmetros utilizados no modelo são prontamente
quantificáveis; o modelo é flexível, podendo ser utilizado em projetos maiores ou projetos pequenos.
5 - Racionalização ou compatibilização de financiamento e gastos -variações grandes no gasto periódico

dos fundos destinados para as operações organizacionais são indesejáveis. Portanto, o desembolso do
financiamento do projeto necessita ser ajustado de maneira equilibrada e regular para os gastos do projeto.
O produto final destas interações é uma linha básica de custo.
Saídas do processo
1 – Linha de Base de Custos - A linha base de custo

estabelece um indicador dos custos para o projeto e será
utilizada como parâmetro para medir e monitorar o
desempenho do custo global do projeto. Sua representação
e modelagem são desenvolvidas por um software de
gerenciamento de projetos e exibidas graficamente para
acompanhamento e monitoramento de desempenho dos
custos, conhecida como curva S.
Os projetos de maior nível de complexidade em sua maioria têm linhas básicas de custo múltiplas para medir
aspectos diferentes de desempenho de custo. Por exemplo, a administração solicitará que o gerente de
projeto avalie o desempenho dos custos internos separadamente dos custos externos (subcontratados e
materiais de construção).
2 - Necessidades de financiamento do projeto - A necessidade de financiamento ou aporte de recursos

financeiros é conseqüência da linha de base dos custos. Esse financiamento, em geral, ocorre em quantias
incrementais e periódicas, não contínuas. Em face desta característica, é percebida uma falta de sincronismo
entre os recursos financeiros alocados e a linha de base dos custos.

4 – Fluxo de Desembolso do Projeto 10 – O fluxo de desembolso

é o resultado direto da aplicação dos custos incrementais de
cada elemento da atividade ou dos valores a ela atribuídos de
forma direta. Muitas vezes os custos são aplicados ao nível dos
produtos na EAP, permitindo assim a composição básica dos
custos e a primeira aproximação do valor desse fluxo
comentado. É notório o fato de não se “gastar” ou comprometer
toda a verba do projeto no primeiro dia ou aplicá-la apenas no
seu último momento. daí o entendimento de “fluxo” de saída de
recursos financeiros no projeto. O fluxo de desembolso na verdade é a apresentação dos momentos e das
quantidades a serem despendidas no ciclo de vida do projeto, tendo como referência única a “moeda”
utilizada, ou moedas, se for o caso.
5 – Fluxo de Caixa do Projeto11 – O fluxo de caixa do projeto difere do item anterior por conta da consideração
do suporte aos gastos, isto é, do montante de recursos financeiros que será aplicado para o pagamento das
despesas do projeto, dentro do seu ciclo de vida. É o resultado direto da diferença entre o que “entra“ no
projeto e o que “sai” dele. De mesma forma incremental, dentro de momentos específicos, é possível verificar
o estado “positivo” ou “negativo” de fundos dentro do projeto. É essencial para o gestor o fato de não se
manter um saldo – diferença entre entrada e saída, negativo. O fluxo de caixa é a apresentação do estado
e saúde financeira do projeto, tendo como referência única a “moeda” utilizada, ou moedas, se for o caso.
5.1.4. Controlar os Custos

Quando entramos na fase de execução do projeto, será o momento de avaliarmos se o custo e o orçamento
planejados foram bem realísticos e calcados em bases sólidas. A relação dos custos planejados com os
custos reais e os valores agregados aos pacotes de trabalho previstos e em execução permitirão através de
indicadores de desempenho uma análise do andamento dos custos e do desempenho do cronograma. Esses
parâmetros serão tratados em um capítulo à parte em EVMS ( Earned Value Management System) - Sistema
de Gerenciamento de Valor Agregado . Portanto, deixemos esses parâmetros de avaliação para o capítulo
em questão, ficando como referência. E atenção, visto que o nível de maturidade de uma Organização pode
ser medido, segundo Kerzner, pela integração entre o EVM e a Gerência de Risco; e às melhores práticas
10
Incluído pelo autor por se tratar de prática comum e jargão constante nas construções.
11
Incluído pelo autor por se tratar de prática comum e jargão constante nas construções.
de projeto atestam essa afirmativa . Então, sendo assim, vamos abordar outros aspectos também muito
importantes nesse processo em um momento à frente e mais oportuno, de forma integrada.
5.2. Uso da Ferramenta - Custo

5.2.1. Estimativa dos Custos do Projeto
Durante a documentação dos recursos do nosso projeto, já iniciamos as ações necessárias à estimativa dos seus
custos, quando inserimos o valor praticado pelas horas de trabalho dos profissionais envolvidos e o custo de aquisição
dos materiais a serem utilizados no projeto, ou quando alocamos recursos tipo Cost, com seus respectivos valores
definidos por alocação. Trataremos nesta seção do fechamento da estimativa dos custos do projeto apresentando
modos de trabalho e campos desenvolvidos especificamente para este objetivo.
5.2.1.1. Estimativa Botton-Up
Através da estimativa Botton-Up, que já iniciamos, definimos os custos relacionados às atividades do projeto, e por
totalização encontramos os custos dos pacotes de trabalho, dos produtos e, finalmente, o custo do projeto.
Novamente, iniciamos preparando um novo modo de trabalho, que se adeque às nossas necessidades. Este será um
modo simples, de nome Step 20 – Estimativa dos Custos, que utiliza a screen Task Sheet, nenhum grupo ou filtro.
Sua tabela é apresentada abaixo.
Atenção: Chamamos a atenção para o título custo fixado em vez de custo fixo, na figura a seguir.
Adotamos essa nomenclatura para apresentar esse campo ao leitor, porém
DESACONSELHAMOS a sua utilização em planejamentos profissionais que atendam aos
princípios das boas práticas de custeio, já apresentadas.
Atenção: Os custos fixos reais devem ser reapresentados dentro da planilha de recursos de modo a
atender às melhores práticas de custeio.
Fixed Cost (Custo fixado) e Fixed Cost Accrual
Se utilizados sozinhos, representam um custo de valor fixo que pode ser distribuído uniformemente ao
longo da duração da atividade. Pode ser distribuído de três formas: ao início, ao término e ao longo. Isso
é conseguido pelo ajuste do campo FIXED COST ACCRUAL;
Atenção: Chamamos a atenção para o fato de que podem ser alocados VALORES no campo FIXED COST
para as linhas RESUMO, que aqui sempre representam os pacotes de trabalho ou de
planejamento. Essa prática é DESACONSELHADA pela nossa metodologia.
Cost (Custo Total)
Exclusivo para planejamento, representa o somatório de todos os custos alocados e informados nas
atividades, ou seja, todos os custos dos recursos somados ao custo definido pelo campo Fixed Cost.
Overtime Cost
Exclusivo para planejamento, representa o somatório de todos os custos alocados e informados nas
atividades a título de horas extras x valores de horas extras.
Baseline Cost
Criado no planejamento e utilizado para monitoramento e controle, é referenciado aqui para manter a
informação do “acordado” no início do planejamento.
Se faz importante que as configurações dos custos relacionados aos recursos tenham sido realizadas de forma
consciente, atendendo às necessidades reais do projeto. Podemos perceber que a preparação da ferramenta para
finalizar a estimativa dos custos é simples, estando a maior carga de complexidade e de trabalho nos processos
anteriores, de gerenciamento dos custos.
Fazendo um resumo, vimos que o custo de uma atividade pode ser obtido no campo Cost, na etapa de planejamento,
através da totalização dos custos ligados a:
Recursos WORK
= Cost Per Use + Standard Rate x Regular Work + Overtime Rate x Overtime Work
O custo por uso é cobrado de forma fixa, independente da duração da atividade e da quantidade de recursos
alocados a ela.
Lembramos que é possível termos 5 Standards Rates e Overtime Rates diferentes, definidos pelas letras A a
E na tela Resource Information, e selecionados pelo campo Cost Rate Table, em tabela de alocação. Ainda,
que a distribuição da carga de trabalho (Work Contour) impacta na distribuição do custo da atividade.
Recursos MATERIAL
= Cost Per Use + Standard Rate x Work
Devemos lembrar que o campo Work para recurso do tipo material significa “quantidade utilizada”.
Alertamos também para a observação da estimativa dos custos de aquisição dos recursos materiais ao longo
do cronograma. O valor definido em Standart Rate é cobrado no momento de utilização do recurso material,
ou seja, síncrono com a atividade na qual está alocado. Esta informação é especialmente útil quando esse
campo for utilizado para modelar os custos de aquisição do recurso, o que pode gerar diferenças de fluxo de
caixa planejado e real . Uma solução seria inserir os custos de aquisição de materiais em atividades
específicas de compra e custos relacionados ao uso, ou operação, nos campos Cost Per Use e Standart Rate.
Recursos COST
= Cost
Para recursos do tipo custo, devemos informar o valor praticado a cada alocação realizada.
FIXED COST
= Fixed Cost
Valor definido para cada atividade, conforme já apresentado.
Assim, temos certa flexibilidade para modelar os custos do projeto na ferramenta MS Project 2013, que aumenta
quando lembramos que existem 10 campos livres formatados para moeda e apresentam os valores com o símbolo
padrão escolhido que admitem fórmulas e podem ser úteis na montagem de propostas de preço de venda.
5.2.1.2. Estimativa Botton-Up com Recursos tipo Cost
Nesta seção mostramos que a estimativa de custos de cada atividade pode ser feita diretamente por meio da alocação
dos recursos financeiros (tipo cost) nas atividades, SEM passar pela montagem de equipes e uso de materiais e
equipamentos. Ainda, essa metodologia de apoio ao gerenciamento dos custos, quando realizada em modo que utilize
a screen task usage, permite acertar o valor financeiro período a período no planejamento, seguindo a escala da
timeline, de forma análoga à possibilidade de edição do trabalho dos recursos ao longo do tempo.
Observações:
Como já vimos, o recurso tipo Cost tem a função de incluir valores de custo na forma de moeda em
rubricas predeterminadas pelo cadastro de recursos. Se comporta diferentemente do recurso tipo Work,
que é contabilizado em forma de horas e totalizado nesse sentido, e diferentemente do recurso tipo
material, totalizado em função da unidade (material label) escolhida. O tipo Cost é totalizado em
unidade Moeda. Ele não é cadastrado em valor ou limites na ocasião de sua definição. Sua valoração
é direta e particular para cada alocação realizada.
Com um duplo clique na linha de recursos tipo

Cost, no exemplo abaixo “Verba 1”, é possível
verificar as peculiaridades da tela de cadastro
das informações do recurso, como a
impossibilidade de definição de períodos de
disponibilidade, impossibilidade de definição
e edição de calendários e desabilitação da
aba Cost. Essas funções deixam de fazer
sentido para os recursos tipo Cost.
De forma a exemplificar e detalhar esta forma de estimativa dos custos, criaremos uma cópia do arquivo de projeto-
exemplo, em que removeremos todos os recursos já alocados e passaremos todos os valores financeiros,
armazenados no campo Baseline Cost 12, para um único recurso tipo Cost.
Note que ao criarmos esta cópia duplicamos os vínculos dos recursos do nosso Pool de Recursos, e para não gerar
futuros conflitos e anomalias, quebraremos o vínculo do nosso novo arquivo com o Pool, já que este é um arquivo
12
Caso a linha de base tenha sido definida em momento anterior e não se deseje alterá-la, é possível utilizar um
campo personalizável do tipo Cost, como o Cost1, para armazenar os custos atuais das atividades do projeto.
criado somente para esta apresentação. A utilização de Pool ainda se justifica em projetos que utilizam a estimativa
de custos modeladas somente nos recursos tipo Cost pois:
1) O trabalho e o custo podem ser gerenciados de forma separada e, dessa forma, os recursos tipo Work
e Material poderiam ser utilizados para modelar e controlar somente a utilização dos recursos, enquanto
que todo o valor financeiro estaria em um ou mais recursos tipo Cost.
2) Se for criado um conjunto de recursos tipo Cost para cada conta ou um centro de custo dos projetos, é
possível totalizar e avaliar os custos de forma centralizada no Pool.
Nesse novo arquivo criaremos um modo simples, conforme mostrado nas imagens abaixo, para trabalharmos a nossa
estimativa de custo.
Step 20b – Estimativa dos Custos - Cost
Retirar todas as alocações anteriores
Retiramos todas as alocações existentes de recursos materiais, humanos ou financeiros, de forma a garantir
que todas as atividades estejam com ZERO de valor no campo Cost. Podemos atingir esse objetivo
rapidamente apagando todos os valores do campo Resource Names, já introduzido no nosso modo.
Inserir todos os custos no recurso Verba 1
Pode-se inserir todos os custos anteriormente estimados de forma manual, alocando o recurso Verba 1 em
cada atividade e configurando o valor devido, conforme já apresentado. No entanto, em qualquer projeto
profissional, esta será uma atividade repetitiva, cansativa e longa, propensa a erros.
Propomos duas soluções. Na primeira, editamos um campo customizável do tipo Text (no nosso caso, o
Text20) e inserimos a fórmula exibida abaixo, que diz que se o campo não for um marco de projeto, o valor
deste campo será a concatenação de fragmentos de texto que resultarão num valor possível de ser inserido
no campo Resource Names.
IIf( [Milestone] = Yes ; '' ; 'Verba 1 [R$' + Str( [Baseline Cost] ) + ']' )
Vamos decompor a fórmula de dentro para fora.
Str( [Baseline Cost] )

Este trexo transforma o valor do campo Baseline Cost, originalmente no formato numérico, para string
(texto), através da função Str(). Caso se utilize outro campo para armazenar o custo, ele deve ser
inserido no lugar de Baseline Cost.
'Verba 1 [R$' + Str( [Baseline Cost] ) + ']'

Usamos esta expressão para construir o texto possível de ser inserido no campo Resource Names
que, lembremos, para um recurso tipo cost está na forma “Nome do recurso [Custo]”. As aspas simples
são usadas para inserir strings e o sinal de soma para concatenar strings. Esta expressão deve ser
customizável conforme o nome do recurso utilizado. Caso se utilize mais recursos Cost, a fórmula
deverá ser ajustada para identificar essa opção.
IIf( [Milestone] = Yes ; vazio ; expressão )

Esta é uma função condicional simples, na qual testamos a possibilidade do elemento ser um marco
com a expressão [Milestone] = Yes. Se a expressão retornar verdadeiro, o valor do nosso campo Text
será nulo, pois inserimos duas aspas simples sem nenhum conteúdo (vazio). Se a expressão retornar
falso, usaremos a expressão de concatenação.
Podemos visualizar na imagem abaixo o resultado obtido, no qual somente as atividades do projeto possuem
valor para nosso campo Text20.
A segunda opção é similar, porém mais simples, pois sugerimos a utilização do MS Excel para concatenar as
mesmas informações. No gerenciador de planilhas eletrônicas da Microsoft, a fórmula a ser utilizada é
“=CONCATENAR(celula1, celula2, celula3)”.
A seguir, temos uma visualização do nosso modo completo.
Observações:
1) A composição de custo se estabelece normalmente e sempre focada no recurso COST, eliminando

assim a necessidade da coluna WORK;
2) O campo apresentado no painel da direita passa a ser o COST e não mais o WORK;
3) No caso da adoção desta linha de ação desde o início do planejamento do projeto, não será necessário
passar pela etapa de remoção das alocações indesejadas, e a forma de alocação do(s) recurso(s) tipo
Cost será guiada pelas metodologias de estimativa de custo selecionadas pela equipe;
4) Ressaltamos que esse resultado, em que a alocação de recursos se restringe apenas aos recursos tipo
Cost, como as técnicas por analogia e por tomada de preços no mercado, também leva a valores válidos
e precisos;
5) Esse procedimento pode ser utilizado conforme apresentado ou em parte, para repassar o arquivo de
planejamento para envolvidos no projeto, com as informações da composição de custos, mas
protegendo o sigilo de informações que não possam ser repassadas.
5.2.2. Inclusão da Dotação Orçamentária

Até o momento, incluímos na ferramenta a informação de horas de trabalho e recursos financeiros que serão
consumidos para a realização das atividades e, consequentemente, do projeto. Nesta seção, veremos como modelar
a entrada ou aporte de horas de trabalho e o aporte financeiro, ou seja, saberemos como inserir na ferramenta a
quantidade de horas e de recursos financeiros disponíveis ao longo do tempo, para que possamos confrontar com os
gastos que já estimamos.
Para que esse objetivo seja alcançado, recomendamos os seguintes passos:
1. Criar os recursos específicos do tipo Budget;

2. Classificar todos os recursos tipo Cost e Work no modo contábil e no plano de contas da organização;
3. Evidenciar a linha ZERO do projeto;
4. Definir um modo apropriado que contenha os campos Budget para lançamento dos valores orçamentários;
5. Alocar esses recursos classificados como Budget à linha sumária do projeto (linha Zero no ID), tipo Work ou
Cost;
6. Preencher os valores limites das Dotações Orçamentárias de Recursos(Work) e de Custos;
Na próxima seção, continuaremos nosso trabalho analisando o resultado desta inclusão.
1 – Criar recursos tipo Budget
Editaremos nossa tabela Step 10 – Estimativa e documentação dos Recursos para incluir dois novos campos:
Budget
Campo que permite a seleção dos valores Yes ou No para que definamos se o
recurso é ou não uma provisão. Como veremos, este tipo de recurso possui
diversas peculiaridades.
Outline Code 8 – “Classe de Custeio”

Campo customizável do tipo Outline Code, que utilizaremos para classificar os
recursos do projeto e que criamos conforme imagem ao lado.
Para prosseguir nosso "projeto exemplo", criaremos dois recursos tipo budget, um do tipo Work e outro do tipo
Cost.
Name Type Budget

Financiamento Cost Yes
Aporte de Horas Work Yes
Atenção: apesar da ferramenta permitir a criação de recursos tipo material, pertencentes à classificação
budget, tal configuração não é suportada, não existindo funcionalidade que a totalize. Caso esta operação seja
realizada, resultará em alocação desnecessária que pode causar confusão e falha de comunicação entre os
envolvidos.
2 – Classificar todos os recursos tipo Cost e Work no modo contábil e no plano de contas da organização
Com a classificação individual de cada um dos recursos do Pool de Recursos ou os recursos do projeto,
estaremos preparando a apresentação do planejamento detalhado dos recursos utilizados, nesse caso em
função da classe contábil.
3 – Evidenciar a linha ZERO do projeto
Todos os modos que utilizam screens do tipo Task Sheet, Task Usage ou
Gantt Chart possuem nas suas Tools Tab o grupo Show/Hide, no qual
pode ser encontrada a opção Project Summary task. Marcada, ela faz
com que a linha ZERO do projeto seja exibida.
4 – Definir um modo para lançamento dos valores orçamentários
Criaremos o modo Step 21 – Dotação Orçamentária, que traz tabela e filtros com as informações mostradas
abaixo. O filtro será aplicado como Highlight filter, para destacar a linha ZERO do projeto e as alocações de
recursos tipo budget.
Para trabalhar a alocação de recursos tipo budget,

necessitamos atuar na tabela de alocações. Por isso,
escolhemos a screen Task Usage para nosso modo Step
21 – Dotação Orçamentária. Ao lado temos a imagem que
resume a criação do modo.
Para definir os campos a serem apresentados no painel direito do modo através

do Detail Styles, escolhemos Cost, Budget Cost, Work, Budget Work.
Sugerimos que o período de avaliação e alocação nesse painel deve ter sua
escala de tempo ajustada para, no mínimo, visualização mensal.
Por fim, sugerimos que a cor relacionada ao destaque das células

contempladas pelo filtro seja um tom pastel suave.
5 – Alocar esses recursos Budget à linha sumária do projeto
Visando facilitar a alocação dos recursos que acabamos de criar, recomendamos que seja
utilizada a opção Assign Resources, da aba Resources, e que na tela de mesmo nome seja
aplicado o filtro Budget Resources.
Destacamos que recursos do tipo

budget somente podem ser alocados nas linhas ZERO dos projetos e, ainda, que as linhas ZERO somente
podem receber recursos do tipo budget.
6 – Preencher os valores limites das Dotações Orçamentárias
Com os recursos de dotação alocados na linha ZERO, podemos definir seus valores através do preenchimento
de suas células pertencentes às colunas Budget Work e Budget Cost, de acordo com o tipo do recurso.
Acima vemos o preenchimento realizado no nosso "projeto exemplo". O Custo total do "projeto exemplo" da
figura monta em R$ 40.797,50. Para verificar o valor do financiamento, recorremos aos documentos do projeto
em que este valor foi definido e acordado entre as partes, assim como formas de repasse. Para o nosso
exemplo, inserimos o valor de R$41.000,00, o que nos deixa dentro do orçamento; o aporte de Horas (que
aqui simboliza a quantidade de horas disponibilizadas da força organizacional para esse projeto), definimos
como 2250 hrs.
Além da garantia de que o aporte financeiro e de horas é superior ao custo total e ao total de horas de trabalho
estimadas, se faz também importante garantir a integridade orçamentária do projeto, analisando o fluxo de
caixa no período definido ao início do planejamento e documentado a partir do Termo de Abertura e demais
documentos.
Assim, encerramos a inclusão da dotação orçamentária no nosso projeto, através dos recursos tipo budget aplicados
à linha ZERO. Na próxima seção veremos como apresentar e analisar os resultados do gerenciamento do custo que
já possuímos.
5.2.3. Consolidação do Planejamento dos Custos

Nesta seção criaremos modos para apresentação dos resultados da definição e classificação dos custos do projeto.
Esses modos são exemplos desenvolvidos com o intuito de apresentar recursos já conhecidos da ferramenta como
forma de apoio ao gerenciamento dos custos. Apesar de não ser nossa intenção esgotar o tema, a partir desses
exemplos o leitor será capaz de desenvolver suas próprias aplicações, de acordo com as necessidades percebidas
nos seus projetos.
5.2.3.1. Agrupamento dos Custos
Para mostrar os benefícios de se agrupar os custos do projeto sob critérios específicos, criaremos um modo de
trabalho que permita a apresentação dos custos de cada atividade dentro da estrutura organizacional que apoia o
projeto.
Step 22- Agrupamento dos Custos – ORG
Devemos criar um modo específico a partir do screen Task

Sheet, cuja tabela é cópia da utilizada no modo Step 20 –
Estimativa dos custos,
O filtro deve ser criado de forma que elimine a visualização dos

marcos do projeto (Campo: Milestone, teste: equals, valor: No).
Com o objetivo de dar a visão de gastos por setor da

organização já cadastrada no projeto, criamos o grupo
utilizando o campo ORG (Outline Code 10)
Para que esse modo atinja seu objetivo, é importante que todas as atividades possuam classificação do nível
organizacional a que pertencem. Garantido este requisito, veremos que a totalização dos custos do projeto na linha
de nível organizacional 1, com o nome de Presidência no nosso exemplo, é igual à totalização dos custos do projeto
na linha sumária do projeto.
Sendo as atividades do projeto os elementos utilizados para a decomposição e estimativa dos custos, podemos
perceber que onde antes víamos a totalização nos produtos que as separavam, de acordo com o critério para
construção da EAP, agora temos essa totalização segundo um critério qualquer, a partir do uso dos grupos.
5.2.3.2. Apresentar a Dotação Orçamentária
A necessidade de financiamento ou provimento, total e periódica, é obtida através da linha de base dos custos. O
financiamento em geral ocorre em quantias incrementais não contínuas e, portanto, aparece como uma função
degrau. Neste momento criaremos um modo que permita a visualização dos recursos apresentados pela sua
classificação e distribuição ao longo do tempo na sua classe de custeio.
Step 23 – Apresentação da Dotação Orçamentária
Iniciamos pela definição da tabela tipo Resource, que contenha

os campos adequados e necessários para essa atividade,
todos já apresentados no nosso livro, e encontrados na imagem
abaixo.
Esse modo conta ainda com um grupo que primeiramente

separa os recursos budget, pondo-os na parte superior da tela,
e depois organiza os recursos conforme a classificação de
custeio, realizada no campo Outline Code 10. Temos também
um filtro criado para impedir a exibição de recursos que não
possuam esta classificação.
O modo, como pode ser visto na imagem ao lado, utiliza a screen Resource Usage.
Tabela Grupo
Filtro
Details
Para confrontarmos os valores da dotação com o valor estimado dos custos do projeto, inserimos na tela Details os
campos Cost e Budget Cost, configurando a escala de tempo para o período mensal, normalmente utilizado para
avaliações financeiras.
O resultado esperado para este modo pode ser visto na imagem a seguir. Nela podemos verificar a contribuição de
cada classificação de custeio no custo total do projeto, e sua participação no consumo dos recursos de dotação.
5.2.3.3. O Fluxo de Desembolso Financeiro
O orçamento é uma consequência direta do valor a ser despendido para a execução de um projeto ao longo do tempo.
Ele tem como entrada para sua composição as estimativas unitárias dos custos de cada “pacote de trabalho”, sua
decomposição analítica em função das atividades que compõem esses pacotes e a sequência de ocorrência ao longo
do tempo. É o conjunto de informações de desenvolvimento das atividades ao longo do tempo e os seus custos que
chamamos de Linha de Base ou “Baseline”.
Nessa ferramenta, ao definirmos a chamada “Baseline”, estamos definindo de forma conjunta a linha de base do
escopo (sua EAP), cronograma e a linha de base dos custos do projeto.
• A linha de base do cronograma é o sequenciamento referencial das atividades no tempo (Time-phased) que
será utilizado para medir e monitorar o desempenho físico do projeto. É desenvolvido através do
sequenciamento e estimativa de duração de cada atividade. Sua visualização gráfica é usualmente
apresentada na forma do “Diagrama de Gantt”.
• A linha de base do custo é o orçamento referencial (Time-phased) que será utilizado para medir e monitorar
o desempenho do custo do projeto. É desenvolvido através da totalização das estimativas de custo por
período. Sua visualização gráfica é usualmente apresentada na forma de uma curva semelhante a um “S”.
Finalizando nosso capítulo de gerenciamento dos custos, criaremos um modo de trabalho que permita a visualização
do fluxo de desembolso e dos gastos classificados ao longo do tempo do projeto.
Step 24 – Desembolso Financeiro
Devemos criar um modo de trabalho que permita a apresentação

dos valores dos custos de cada atividade dentro da perspectiva
de seus gastos na linha do tempo. Para isso selecionamos a
screen Task Usage.
Informações para construção do modo:
▪ A tabela contém os campos ID, Indicators, Name e Cost ;

▪ À direita, temos em Details os campos Baseline Cost –
Cost – BCWS – Cumulative Cost, exibidos em cores
contrastantes para facilitar a visualização.
▪ Timescale configurada para visualização semanal.
Informação: Após o devido armazenamento da linha de base, o campo Baseline Cost

apresenta o custo totalizado período a período, e é síncrono e igual ao campo Cost.
Ele totaliza todos os gastos existentes no período: gastos dos recursos e os valores
em custo fixado (Fixed Cost). A diferença entre eles está no fato de “reprogramações”
alterarem o campo COST, mas não o valor original do BASELINE COST.
Informação: O campo BCWS é um campo relacionado à análise do valor agregado,

tema que será visto adiante com mais detalhes, que nesse momento se faz presente
como o valor do trabalho do projeto expresso em valor MOEDA. Ele representa
também o valor do custo da linha de base do projeto. Ele só é apresentado / calculado
se a data de STATUS do projeto for ajustada para o término planejado do projeto. Essa
informação pode ser configurada pelo acesso à Aba PROJECT grupo Properties
elemento Project Information, em Data de Status.
Já é possível observar que seu valor difere do campo “custo acumulado” ou “cumulative cost” por
conta do software desconsiderar o recurso tipo “resource cost” no seu cálculo.
Desenvolver um gráfico com o fluxo econômico
Para dar continuidade ao nosso trabalho, deveremos utilizar um gerenciador de planilhas eletrônicas, uma vez que a
ferramenta MS Project não suporta, nativamente, a criação da “Curva S”. No nosso exemplo, usaremos o programa
MS Excel.
Copiaremos para o Excel os dados gerados pelo painel direito do modo Step 24 – Desembolso Financeiro, mas
especificamente as informações dos quatro campos pertencentes à linha sumária do projeto, que totaliza os custos
do mesmo, tomando o cuidado de verificar se a escala de tempo está fixada em semanal, e se os dados foram
selecionados para cópia durante todo o período do projeto.
O gráfico gerado sobre essas grandezas foi acondicionado da seguinte maneira: Baseline Cost e Cost em barras
verticais e o Cumulative Cost e BCWS, que são a soma acumulada período após período, na forma de duas linhas.
Para facilitar, utilizamos as mesmas cores do fundo aplicadas aos campos do Details. As barras representantes dos
campos “discretizados” período a período poderiam apoiar o financiador do projeto, enquanto o campo acumulado
mais interessante para o controle e desempenho, o andamento do projeto.
O campo BCWS no MSProject 2013 – Etapa de Planejamento

O campo BCWS – Budget of Work Scheduled comentado anteriormente representa o valor acumulado do trabalho
agendado ou programado original conforme a linha de base acumulada ou o campo CUMULATIVE COST. Para
apresentar um problema crucial nessa ferramenta, em particular nessa versão mais atual do aplicativo, evidenciamos
em duas cores no gráfico abaixo esses campos CUMULATIVE COST e BCWS simultaneamente com divergência no
seu cálculo. Ambos deveriam totalizar os mesmos valores e, nesse caso, isso não acontece. Há uma diferença por
conta do recurso tipo COST, que não é contemplado no cálculo nessa ferramenta.
Atenção: Na versão liberada por ocasião desta publicação o campo BCWS NÃO
representa o valor real do custo acumulado do projeto como a sua linha de
base, pois ele NÃO totaliza os recursos tipo COST.
Análise numérica desse problema:
Essa análise pode ser repetida para confirmação ou correção deste material, e começa pela verificação do
valor total associado aos recursos tipo Cost, o que pode ser facilitado pela utilização de modos tipo Resource
Usage para a divisão entre os recursos e pela comparação dos campos Cumulative Cost e BCWS (até a data
do Status Date) para o valor total.
Uma possível solução para representação de valores moeda nas atividades e, consequentemente, no projeto,
é a utilização do campo Fixed Cost, que é totalizado pelo campo BCWS.
Atenção: O campo BCWS NÃO representa o valor real do custo acumulado do projeto como a sua linha
de base, pois ele NÃO totaliza os recursos tipo COST. O campo BCWS NÃO deve ser utilizado se houver
referências de valores MOEDA.
5.2.3.4. Linha de Base 3: Custos (Baseline 3)
Seguindo nosso procedimento de documentação das etapas do planejamento do projeto, armazenaremos as

informações atualizadas do cronograma em uma das 10 linhas de base secundárias da ferramenta. A repetição deste
procedimento possibilitará a posterior verificação e o resgate do cronograma isento de restrições de custo ou recursos,
sem a necessidade de utilização dos arquivos das versões anteriores.
Assim sendo, novamente voltamos à opção Set Baseline, encontrada na aba Project,
seguindo para a opção Set Baseline..., para chegar à tela de mesmo nome. Nela,
devemos atualizar a linha de base para o novo estado do cronograma, e ainda armazenar
este estado na opção Baseline2, da mesma forma que salvamos o estado do cronograma
com somente restrição de tempo no Baseline1. Mais informações sobre este
procedimento foram fornecidas no item 3.2.4.4.
Uma alternativa é salvar diretamente em Baseline2,

caso não façamos uso das informações do
cronograma para comparação durante a etapa de
planejamento.
Feito isso, possuímos dados armazenados em

Baseline1 (Tempo), Baseline2 (Recurso) e
Baseline3 (Custo). É possível estender este
procedimento para outros momentos do
planejamento, como após a inclusão das atividades
de gerenciamento de riscos, em que bastará
proceder da forma apresentada e reapresentada.
6. Capítulo 06: Gerenciamento dos Riscos
6.1. Conceitos de Gerenciamento dos Riscos

Um grande avanço na maturidade de um planejamento e que aumenta a
solidez dos resultados do projeto é a prática do gerenciamento dos riscos do
projeto. Esse gerenciamento, normalmente iniciado quando a estrutura
analítica do projeto já está madura, permite identificar e classificar em ordem
de importância os riscos – ameaças e oportunidades ao projeto – e, a partir
daí, desenvolver uma estratégia de ação para a administração dessas
incertezas. Não se deve confundir a análise de riscos estratégicos ou do
negócio com a análise das incertezas que rodeiam as atividades de um projeto.
Na primeira fala-se até em cancelamento do projeto, na segunda deve-se
trabalhar para a garantia de sua realização.
O processo inicial é a definição das regras de trabalho, abrangência e

considerações que, por definição, deve estar de acordo com o termo de
abertura e ativos organizacionais. O próximo passo é a identificação e registro
sistemático dos riscos que afetam o projeto. Aqui estaremos focando mais nas
ameaças do que nas oportunidades que afetam os elementos da estrutura
EAP. É indispensável para essa identificação que todas as considerações e
informações sobre o projeto, a organização patrocinadora, o cliente e as
diretrizes de classificação, interpretação e técnicas estejam claras e
conhecidas. Essas incertezas mapeadas permitem que sejam iniciados o
próximo processo de planejamento dos riscos, a classificação e priorização desses de forma quantitativa ou
qualitativa. Da mesma forma que temos uma estrutura de trabalho para identificar os produtos ou entregas
do projeto, uma estrutura organizacional que apoia o entendimento da compartimentação dos recursos
dentro da organização, temos também a possibilidade de agrupar os riscos dentro de uma estrutura de
classificação sistemática chamada de EAR – estrutura analítica dos riscos.
Conceitos do RISCO
A palavra ou termo Risco, quando aplicada a projetos, perde seu efeito de cunho exclusivo e negativo e
ganha a oportunidade de representar os efeitos positivos que podem também trazer vantagens para o
empreendimento. Como o risco vem da nossa inabilidade de prever o futuro e indica o grau de incerteza de
um evento, atividade ou produção, sua análise e classificação deve ser dada inicialmente com base nas
informações existentes e, no decorrer, com o desempenho real das equipes, cenários e contorno do projeto.
Risco é comumente usado como um sinônimo para imprevisto, ameaça ou perigo, i.e., um evento
indesejável. A análise e tratamento dos Riscos de um projeto muitas vezes pode invadir um escopo já
definido, alterar o tempo estabelecido de atividades já programadas e alterar substancialmente o custo final
desse projeto. Se para garantir a transferência de um Risco existente no nosso escopo, temos que contratar
os serviços, estamos transformando as atividades que anteriormente seriam executadas pelas equipes
próprias em atividades feitas pelas empresas contratadas. Se para garantir que o tempo estimado para uma
Atividade – [Activitie] for necessário adicionar uma “reserva” para prevenir, ou garantir proteção contra
possíveis atrasos, estaremos mexendo na cadeia de atividades possivelmente no Caminho Crítico – [Critical
Path] do projeto. Qualquer que seja a opção acima, o custo associado será alterado de alguma forma,
mostrando assim que o Risco é um componente a ser considerado como significativo em qualquer
planejamento consciente.
6.1.1. Planejar o Gerenciamento de Riscos

Nesse processo se decide como abordar e planejar o GERENCIAMENTO DE RISCO DO PROJETO no
projeto. Como se decide, quem decide e por que decide. O processo de planejamento é simples e complexo
e deve vir como diretriz básica pelo patrocinador e outros stakeholders, deve vir pelo termo de abertura que
é elaborado pelo executivo maior e pelas regras da organização e do mercado ou do ambiente. Deve vir
claro e com as limitações e autonomias dadas ao gestor futuro no momento de nomeação, e atual na
responsabilidade de produzir o plano. As regras,
técnicas, ferramentas e equipes ficam iniciadas pelo
TAP – Termo de Abertura, e continuada na definição e
pelo gerente de projetos, produzida pela equipe de
planejamento, e finalmente mantida pela equipe de
monitoramento e controle. A saída desse processo não poderia deixar de ser o “plano de gerenciamento
de riscos do projeto”.
6.1.2. Identificação de Riscos

Esse processo visa identificar os riscos do projeto. Prevê o conhecimento de todas as áreas anteriores
discutidas nesse livro, e mais algumas relativas a aquisições e gestão de recursos humanos, mas, sem
dúvida, não deve se limitar a essas. O advento de áreas como
segurança do trabalho, meio ambiente, entre outras, permite às
equipes determinar os riscos prováveis do projeto e registrar as
características de cada um, seus alertas e eventos de anúncio. A
análise de premissas, uso de diagramas de causa e efeito, e até
mesmo listas de verificações, são técnicas poderosas. Podemos
dizer que a saída mais importante desse processo é a “lista dos
riscos identificados, ou registro dos riscos do projeto”. Não
apenas os riscos, mas também as possíveis resposta a eles.
6.1.3. Realizar a Análise Qualitativa de Riscos

A análise qualitativa dos riscos é a classificação e priorização desses
riscos. Aqui utiliza-se como referência uma matriz chamada de
“Matriz de Probabilidade x Impactos”. Nessa técnica, lista-se em
linhas horizontais os riscos identificados do projeto e em colunas
verticais específicas a probabilidade desse risco ocorrer e o nível de
impactos. Essas grandezas, que são atribuídas a essas colunas “P” e “I”, são previamente definidas nas
diretrizes do plano de gerenciamento de riscos do projeto e sua classificação segue critérios específicos
para dar maior validade ao processo de priorização. Uma terceira coluna, “grau de risco”, é acrescentada,
sendo seu valor o produto das colunas citadas entre si. A título de exemplo chamaremos aqui de “grau de
risco” o resultado alcançado pela multiplicação entre P (Probabilidade) e I (Impacto) dessa matriz de
“Probabilidade x Impactos”. Os elementos da análise qualitativa, aqui chamada de “grau de risco”,
representados agora pelos valores numéricos, servem para priorizar os riscos mais importantes e com isso
promover uma resposta, ou uma ação para contrabalançar essas ameaças/oportunidades. Uma suposta
lista de 100 itens, ou 100 riscos com os seus “graus de risco” associados, servirá para definir um conjunto
de itens mais importantes (ou de maiores de “grau de risco”). A cada um desses riscos13, uma ou mais
ações podem ser realizadas para reduzir, eliminar ou contingenciar seus efeitos. A classificação ou
13
Analisaremos aqui apenas os riscos negativos do projeto, para simplificar o entendimento.
categorização é essencial para que sejam priorizados e escolhidos os riscos para resposta e ação eficaz.
No desenho inicial de fluxo de ações desse capítulo apresentamos uma opção de partir para um plano de
resposta ou de partir para um estudo de quantidades e modelos. É importante ter em mente que a diretriz
do TAP ou da proposta da equipe de planejamento de riscos deve ser firme nessa rotina. A análise conjunta
dessas diversas ações mencionadas pode ser condicionada a um plano de ação concomitante ao projeto ou
um plano de ação contingencial ao projeto. Nesse livro teremos atividades entre as quatros opções e ação
aos riscos do projeto: Plano de ação concomitante ao projeto e Plano de ação contingencial ao projeto.
6.1.4. Realizar a Análise Quantitativa de Riscos

Nesse processo se modela, numera, quantifica
grandeza e insistência dos riscos levantados e
escolhidos pela classificação feita pela equipe, em
conjunto com os envolvidos. Por conta de especialistas
nas áreas analisadas, no processo de produção e
logística, e, em particular no ambiente de aplicação do projeto, certos e escolhidos riscos são analisados
agora com cunho numérico e modelado, com ferramentas especificas, dando mais respaldo a escolha, ação
e investimento da organização na sua “melhoria” ou “potencialização”.
6.1.5. Planejar a Resposta a Riscos

Nesse processo se
desenvolvem procedimentos e
técnicas para aumentar as
oportunidades e reduzir
ameaças de dentro do projeto,
estudando-se ou acatando as
ideias geradas no registro dos
riscos inicias, validadas pelos estudos qualitativo e quantitativo.
Estratégias para riscos

São consideradas nesse meio como estratégias de ação da equipe de planejamento: evitar/explorar,
transferir/compartilhar, mitigar/potencializar e aceitar.
• Evitar/explorar.
A prevenção dos riscos negativos é uma estratégia de resposta ao risco em que a equipe do projeto
atua para eliminar a ameaça ou proteger o projeto de seu impacto. Já a exploração dos riscos
positivos é uma estratégia de resposta ao risco em que a equipe do projeto atua para promover e
estudar as possibilidades de maior ganho. Eles geralmente envolvem mudanças no plano de
gerenciamento de projeto para agir nessas incertezas.
• Transferir/compartilhar.
A transferência de riscos negativos é uma estratégia de resposta ao risco em que a equipe do
projeto transfere o impacto de uma ameaça para uma terceira parte, juntamente com a propriedade
da resposta. Transferir o risco simplesmente a terceiros dá à outra parte a responsabilidade da sua
gestão, mas não o elimina. A transferência de um risco envolve quase sempre o aumento de custos
por conta do repasse de incertezas. Já o compartilhamento de um risco positivo envolve, na
extensão dessa oportunidade, um terceiro, mais capaz de capturá-la e beneficiar a todos com isso.
Contratos podem ser usados para transferir a responsabilidade pelos riscos especificados para
outro partido.
• Mitigar/potencializar.
Mitigação de risco negativo é uma estratégia de resposta ao risco em que a equipe do projeto atua
para reduzir a probabilidade de ocorrência e impacto de uma ameaça. Isso implica numa redução
da probabilidade e / ou impacto de um risco adverso estar dentro de limites aceitáveis. Já a
estratégia de potencializar os riscos positivos é usada no sentido inverso, para aumentar a
probabilidade e / ou impactos positivos de uma oportunidade. Identificar e maximizar os principais
impulsionadores destes riscos de impacto positivo pode aumentar a probabilidade de sua
ocorrência.
• Aceitar.
Aceitação do risco é uma estratégia de resposta, em que a equipe do projeto decide reconhecer o
risco e não tomar nenhuma ação, seja ele positivo ou negativo. Esta estratégia é adotada quando
não é possível ou o custo-benefício não é conveniente para enfrentar um risco específico de qualquer
outro modo. Esta estratégia indica que a equipe do projeto decidiu não mudar o plano de
gerenciamento do projeto para lidar com o risco, ou é incapaz de identificar qualquer outra estratégia
de resposta adequada. Esta estratégia pode ser passiva ou ativa. A passiva aceitação não requer
nenhuma ação, exceto documentar a estratégia, deixando a equipe do projeto para lidar com os riscos
que ocorrem, e rever periodicamente a ameaça para garantir que o projeto não se altere
significativamente. A estratégia mais comum - a aceitação ativa - é estabelecer uma reserva de
contingência, incluindo os valores de tempo, dinheiro ou recursos para lidar com os riscos.
Nesse livro teremos atividades entre as quatros opções e ação aos riscos do projeto: Plano de ação
concomitante ao projeto e Plano de ação contingencial ao projeto.
6.1.6. Controle de Riscos

Nesse processo se acompanham os riscos residuais, se identificam novos riscos executam-se os planos de
redução de risco e se avalia sua efetividade durante todo o ciclo de vida do projeto, cumprindo o contínuo
processo de qualidade - PCDA.
6.2. Uso da Ferramenta – Riscos

6.2.1. Inactive Tasks (Atividades inativas)
Encontrado a partir da versão 2010 da ferramenta, o recurso de atividades inativas será utilizado neste capítulo para
apoio aos planos de ação e gerenciamento do risco, motivo pelo qual será apresentado nesta seção.
Possui conceituação simples. Caso um elemento seja marcado como inativo, não mais será utilizado no cálculo dos
parâmetros do cronograma. Sua duração não impactará no prazo, suas alocações não serão consideradas para
cálculo de carga de trabalho dos recurso, seus custos não serão somados ao total do projeto e assim por diante.
Representado pelo campo Active, pode apresentar os valores Yes ou No, que determinam se os elementos da EAP
+ atividades são ativos ou inativos. Inserindo o Campo Active em qualquer modo do tipo Task, podemos confirmar
que até o momento trabalhamos somente com elementos ativos. Como forma de teste, recomendamos que uma ou
mais atividades do projeto sejam marcadas como inativas para que o resultado seja observado. Terminado o teste,
deve-se reverter essa marcação e o cronograma deve retornar integralmente ao seu estado anterior.
Vemos na imagem acima que a atividade 1 foi suprimida do cronograma quando marcada como inativa. Sua duração
não mais impactou no cronograma, seu custo total (R$6000,00) foi removido do custo do seu produto e do projeto e
o recurso nela alocado em paralelo com a atividade 4 teve sua carga de trabalho aliviada, não mais ficando
superalocado.
Além deste recurso da ferramenta poder ser utilizado através da inserção do campo do campo
Active, podemos alcançá-lo também a partir do ribbon, na aba TASK, grupo Schedule, como
mostrado na imagem abaixo.
Para melhor visualizarmos o status inativo das alocações, passamos o mesmo arquivo utilizado no exemplo desta
seção para o modo Resource Usage, e
obtivemos a imagem abaixo.
Aqui vemos que a alocação Atividade 1 está

inativa, em consequência do estado inativo da
atividade Atividade 1. Dessa forma, os valores
de Work (trabalho) não são totalizados para o
recurso Pessoal A.
Observação: É possível tornar um produto inativo. Se o fizermos, estaremos tornando todo o seu conteúdo
(atividades, marcos e outros produtos) inativo.
Observação: Existe o campo Active para recursos, mas sua utilização se dá no modo Enterprise, que escapa ao
escopo deste livro.
6.2.1.1. Atividades Inativas e o Sequenciamento
Um ponto importante a ser destacado é o comportamento das atividades sucessoras às atividades inativas. Saber
como as dependências criadas pelos links entre as atividades modificarão o cronograma do projeto, mesmo com o
uso do recurso Active, é de suma importância para qualquer usuário da ferramenta.
Este é um livro de MS Project 2013, mas uma vez que este comportamento é diferente nas duas únicas versões nas
quais é encontrado (2010 e 2013), achamos prudente apresentar estas diferenças.
No MS Project 2010
Como pode ser visto na imagem a seguir, as ligações dos predecessores que se mostram inativos são
completamente ignoradas pelos sucessores e, caso não haja outro impedimento, o agendamento da atividade
ou do marco se dará pela sua restrição básica, seja ela ‘o mais cedo possível’ ou ‘o mais tarde possível’.
Aqui, nos vemos obrigados a realizar ligações extras, até mesmo incorrendo em leapfrogs, para manter a
estrutura de sequência lógica do projeto, íntegra e fechada.
No MS Project 2013
Na versão atual da ferramenta, as ligações com predecessores inativos são, de alguma forma, relativizadas e
transferidas para o próximo predecessor ativo. A forma como o “novo” agendamento se dará depende do tipo
de vínculo.
 Caso seja FS (término para início) ou SS (início para início), o início da sucessora se dará a partir do
ponto de término do último predecessor ativo, encontrado na sua sequência lógica.
 Caso seja uma ligação do tipo FF (término para término) ou SF (início para término), o término da
sucessora se dará a partir do ponto de término do último predecessor ativo encontrado na sua sequência
lógica.
MS Project 2010 MS Project 2013
De forma a se garantir a integridade do cronograma, recomendamos que as ligações adicionais sejam criadas, para
que o arquivo se comporte de forma idêntica, independente da versão utilizada.
Observação: Caso se trabalhe em colaboração com outros envolvidos, que utilizem a versão 2010 do MS Project, e
fazendo uso do recurso Active, deve-se ter atenção redobrada, uma vez que as características do
agendamento serão mantidas segundo a última versão a ter feito alterações nos elementos em estudo.
6.2.2. Plano de Ação Concomitante ao Projeto
Sabendo-se que um projeto possa sofrer ameaças a um de seus processos de trabalho, na sua continuidade ou
integridade, por conta dos riscos elencados e analisados, devemos desenvolver uma metodologia de trabalho voltada
à redução ou eliminação destes riscos, de modo que o projeto tenha maior confiabilidade.
Nesta seção, veremos os benefícios da criação de um processo novo e adicional, um conjunto de atividades de apoio
à redução ou eliminação dessas ameaças documentadas, modelado dentro do pacote de trabalho que ele “protege”.
Essas novas atividades de apoio deverão conter prazos, recursos humanos, equipamentos, materiais ou financeiros,
conforme necessidades do planejamento, para fazerem parte do cronograma.
Para o exemplo que desenvolvemos a seguir, criamos um novo arquivo de projeto. Neste, destacamos a entrega
"fundações", item 1.3.4.2 da EAP, e suas três atividades, cujos nomes foram criados de forma genérica
propositalmente, para que o foco do leitor fique no conteúdo do exemplo.
Numa análise ilustrativa de ameaças à realização dessas atividades, dentro das condições e recursos alocados,
verificaram-se diversas ameaças à garantia dos prazos de execução que originalmente eram 20 dias, 40 dias e 30
dias de trabalho, segundo o calendário do projeto. Dentro da lista de ameaças, temos, por exemplo, as questões
atmosféricas e de acesso ao local, que podem inviabilizar o trabalho. Uma vez que essas ameaças foram identificadas
e classificadas como muito importante, “grau de risco” extremamente alto, foi tomada a decisão de incluir um conjunto
extra de ações que pretendem garantir que, caso ocorram, em nada afetem as condições das atividades originais ou
a suas durações previstas. Poderíamos pensar nestas atividades como a construção de estrutura de cobertura do
local, ampliação e melhoria do acesso para caminhões ou ampliação do estacionamento. Cada uma destas atividades
deve possuir seus prazos, recursos e custos.
Observação:
Criamos um filtro de destaque (highlight filter) simples para personalizar o formato de exibição das atividades
e marcos que fazem parte do nosso plano de ação concomitante, onde utilizamos o campo Flag1 para marcar
estes elementos.
Com o auxílio da opção Format Text Styles, configuramos os elementos selecionados pelo nosso filtro para
serem exibidos em itálico e na cor cinza escuro.
Sugerimos que seja criado um modo de trabalho específico para a criação e visualização dos elementos dos
planos de ação de risco, no entanto, uma vez que a ferramenta não apresenta campo especial para esta área
do conhecimento, e já tendo trabalhado o procedimento de criação de novos modos diversas vezes ao longo
do nosso livro, se faz desnecessária nossa sugestão explícita.
O plano de gerenciamento de riscos contém dentre vários elementos, o período de revisão de suas informações e
alertas, assim como a sua relevância ao sucesso do projeto. Isso significa que as ameaças que eram significativas
em um dado momento podem não mais ser relevantes, ou até ficarem inferiores às outras, ou seja, as ações de apoio
à garantia do equilíbrio do projeto podem não ser necessárias, ou os recursos limitados do projeto podem determinar
que outras, mais prioritárias, ocorram em detrimento destas.
Caso sem as ações de apoio às

ameaças.
Caso com as ações de apoio às

ameaças.
Atenção: O plano de apoio às ameaças ao projeto pode ou não ser suprimido em função de novas avaliações
qualitativas. Isso vai depender das diretrizes do plano de gerenciamento de riscos adotado.
6.2.3. Plano de Ação Contingencial ao Projeto
Novamente, sabendo-se que um projeto possa sofrer ameaças a um de seus processos de trabalho, na sua
continuidade ou integridade, por conta dos riscos elencados e analisados, devemos desenvolver um conjunto de
atividades de contingência, que serão acionadas caso necessário, ou seja, será desenvolvida uma pequena rede 14
independente que poderá ser acionada caso um alerta seja dado e com a antecedência devida.
Para viabilizar esta modelagem, faremos uso novamente do recurso Active. O conteúdo do plano de ação
contingencial nasce inativo. Deve ser criado dentro do pacote de trabalho que ele “protege” e deve ser montado como
“atividades adicionais”, contendo prazos, recursos humanos, equipamentos, materiais ou financeiros, se necessários.
Fazem agora parte de um planejamento alternativo.
Caso 1: Substituição da rede atual
Nesta situação a equipe de planejamento desenvolve uma ou mais versões alternativas de parte do
cronograma, normalmente de uma entrega (deliverable) que poderá substituir a versão inicialmente utilizada,
dependendo de condições previamente estabelecidas e documentadas.
As condições para o acionamento de uma rede alternativa podem ser riscos contidos nos produtos que a
compõem ou externo a estes. Por exemplo, poderíamos imaginar o acionamento de uma rede alternativa cujas
atividades contemplem recursos com maior produtividade e consequentemente mais dispendiosos, após o
controle do projeto ter evidenciado um atraso no cronograma. A imagem abaixo ilustra este exemplo.
14
Consideramos rede um conjunto de atividades e marcos sequenciados de forma lógica.
De modo a facilitar a construção das redes alternativas, recomendamos que sejam criados os marcos de início
e término do trecho possível de ser alterado. Dessa forma, o sequenciamento torna-se simples e reduzimos a
probabilidade de erro humano.
Sempre recomendamos a documentação do projeto e, no caso do gerenciamento dos riscos, não é diferente.
Em especial no caso de caminhos alternativos para o cronograma, registrar os critérios, prazos e
responsabilidade de escolha é essencial, assim como a comunicação desses registros aos envolvidos e
possíveis envolvidos.
Caso 2: Inclusão de rede adicional
Neste caso temos a criação de uma rede ou mesmo uma única atividade, inativa, que será acionada em
resposta à condições relacionadas aos riscos do projeto, no entanto sem substituir nenhuma outra rede ou
atividade.
Difere das atividades do plano, e são concomitante ao projeto, pois aquelas eram criadas ativas, pela
necessidade de redução de um risco registrado e documentado, enquanto que estas são criadas inativas e
são acionadas em reposta à ocorrência dos riscos.
Importante citar que os planos de gerenciamento dos riscos não alteram o escopo do projeto. A realização das
atividades concomitantes, a criação e o uso de redes alternativas e as atividades de contingência não devem modificar
o resultado final dos produtos.
Atenção: A modelagem dos planos de contingência e seu uso vão depender das diretrizes do plano de
gerenciamento de riscos adotado.
Atenção: O caminho crítico, definido pela metodologia CPM, sempre poderá mudar por conta da formação de
nova rede de predecessores.
6.2.4. Gerenciamento das Alterações do Escopo

Aproveitamos a semelhança com o tema deste capítulo para apresentar o apoio da ferramenta ao gerenciamento das
alterações do escopo do projeto. Aqui apresentaremos a modelagem da inclusão de produtos adicionais do projeto,
possível de ser realizada durante a etapa de planejamento, que podem ser facilmente transportados para a etapa de
execução.
Ainda utilizando o campo Active, sempre que houver uma entrega nova em fase de aprovação, essa poderá ser
modelada e programada dentro do planejamento já aprovado, em modo inativo. Esse recurso permite que a equipe
de planejamento verifique os impactos que podem acontecer dentro do projeto, seu plano de tempo, recursos e custos
aprovados, com a inclusão dessas “novas entregas”, criando-se cenários do projeto para apresentação aos
envolvidos, que detêm as responsabilidades de decisão e definição de caminhos.
Em nosso exemplo, criamos o pacote subestação como adicional ao projeto em fase de aprovação. Tornando inativo
o pacote de trabalho Subestação, temos a não participação desse no cálculo tanto de prazos, como de custos e
consumo de recursos humanos e materiais. Lembramos que tornar um produto ou pacote de trabalho inativo é tornar
todas as suas atividades e marcos também inativos.
Cronograma sem Subestação Cronograma com Subestação
No diagrama de Gantt é necessário utilizar os recursos da ferramenta para configurar os elementos gráficos, para
que possamos evidenciar os trechos do cronograma em aprovação, mesmo quando a opção Active estiver com valor
Yes, o que ocorre durante testes e emissão de relatórios.
Analisando o impacto da inclusão do pacote Subestação no projeto, vemos que o prazo foi impactado, mostrando que
este pacote caso aprovado fará parte do caminho crítico e fazendo necessária a comunicação aos envolvidos nas
atividades e produtos que poderão ser reagendados.
Tivemos também um acréscimo de R$ 86.400,00 ao custo do projeto, o que deverá ser levado em consideração para
análise orçamentária e financeira do projeto. Este acréscimo pode, por exemplo, determinar o adiamento e outros
produtos por limitações de recursos financeiros. Análise semelhante é feita para o uso de recursos, que podem ficar
superalocados, uma vez que foram dimensionados e aprovados para um projeto que não contemplava esta entrega.
Atenção: Somente a partir da aprovação formalizada dos novos pacotes de trabalho ou aditivo contratual assinado
é que os elementos em estudo “Varanda de trás” e “Varanda da Frente” passam a compor o conjunto
real e definitivo da EAP e plano de projeto. O caminho crítico, definido pela metodologia CPM, pode
mudar por conta da formação de novos elementos e sua rede particular de atividades, incluída na rede
existente. A linha de base deve ser atualizada então.
7. Capítulo 07: Desenvolvimento do Cronograma
7.1. Desenvolvimento Real do Cronograma

Pode parecer estranho que a essa altura desse trabalho voltemos a falar de desenvolvimento do cronograma e agora
sob a adjetivação “REAL”. Esse termo é usado aqui por conta das condições reais de agendamento de datas sob
condições reais de restrições e considerações de trabalho, limitações de recursos e, por que não enfatizar, verbas e
financiamentos.
Uma rápida recuperação de conceitos aqui é necessária antes de prosseguirmos com a ideia de “REAL”.
7.1.1. Técnicas e Ferramentas

Na análise de rede do cronograma - técnica que tem o objetivo de traçar graficamente as relações de sequencia
entre as atividades e de forma analítica iniciar a inclusão das durações e valores estimados de esforço para atingir os
resultados parciais de um projeto. Podemos escolher a seguir diretrizes especificas e distintas como: Método do
Caminho Crítico – CPM - Critical Path Method; Método do Caminho da Cadeia Crítica – CCM - Critical Chain Method;
Método RCP - Resource Critical Path Method; Métodos Gráficos como: PERT – Program Evaluation and Review
Technique; VERT – Venture Evaluation and Review Technique; GERT – Graphical Evaluation and Review Technique;
e por Nivelamento de Recursos – Resource Level; ou ainda a Análise do tipo “e se?”. Mais arrojada ainda é a análise
SPDM – Success Driven Project Management.
Não vamos aqui analisar todas essas, mas dar destaques a algumas que são bem reais e que são bem aplicáveis no
nosso dia a dia, e que a ferramenta se propõe a apoiar.
Método do caminho crítico
Esse método é uma evolução do

modelo PERT Cost dos anos 60s e tem
por objetivo o foco nas atividades que
compõem o cronograma. Ele calcula as
datas de início e término mais cedo das
atividades e a seguir as datas de início
e término mais tarde. Com as
amarrações dadas pelo
sequenciamento e amarrações, antecipações e atrasos planejados, combinados com as restrições,
é possível definir o nível de folga que cada atividade possui em relação a sua sucessora e em
relação aos caminhos de trabalhos do projeto. Essas folgas relacionadas foram batizadas de folga
livre e folga total respectivamente, e em momento algum do processo de cálculo são levados em
conta os recursos alocados. O resultado esperado desse método são as datas de início e término
do projeto, a definição dos caminhos de trabalho existentes e determinação do caminho mais longo,
aquele que determina a duração total do projeto. Deve ficar bem claro nesse método que a folga,
livre ou total, não implica na possibilidade de atraso na atividade. Implica que se, e somente se,
houver um problema na execução com a utilização dessas folgas, os marcos intermediários e finais
não serão afetados. Ao caminho mais longo e normalmente àquele que possui folga nula é dado o
nome do método: caminho crítico. O uso desse método transcendeu as décadas e é peculiar por
colocar toda a atenção no caminho de folga nula. As medidas corretivas dos desvios entre o previsto
e o real sempre invocam a aplicação de mais recursos ou de ações de execução simultânea ou
antecipada de atividades, aumento do custo ou o risco dos dois. Esse método, ainda que eficaz,
traz algumas peculiaridades como: o caminho crítico muda dependendo do status do projeto e seu
desempenho; assume que os recursos são de fácil aquisição ou infinitos, uma vez que não os leva
em consideração; mantém a equipe do projeto com o foco na atividade e promovendo ações
direcionadas a elas; permite a criação de indicadores de desempenho de tempo e custo de alta
eficácia. Isso nos mostra que tais considerações se colocam pouco próximas ao que se encontra
na maioria dos projetos, com salvas e raras exceções. A partir da década de 80 do século passado,
novas técnicas com outros interesses surgiram, dando uma nova dimensão ao planejamento
ortodoxo que atua sem restrições de recursos humanos, materiais e financeiros.
Compressão do cronograma
Essa técnica pode ser aplicada cumulativamente à anterior

e, por tradição, visa através de artifícios ligados aos
parâmetros diretamente ligados às atividades reduzir o seu
tempo de execução. Uma vez que a duração final de um
produto ou pacote de trabalho é resultado sequenciado do
somatório dos quociente entre o trabalho necessário e a
capacidade de produção dos recursos na unidade de
tempo, temos aumentado o número de recursos alocados
na equipe ou mudado o sequenciamento entre as
atividades; Os prazos de execução devem se alterar. As
principais consequências dessa técnica são: o aumento do
nível de supervisão das equipes, e riscos de imprevistos
nos relacionamentos, pelo aumento do efetivo e de tarefas
simultâneas; o aumento dos custos por conta de novas tarefas de controle e administração dentro
da mesma atividade; o risco de perda de produtividade por falta de sinergia ou de espaço adequado
para a realização da atividade; o aumento do risco de retrabalhos por conta da alteração no
sequenciamento original das atividades; o aumento do tempo das atividades por conta da alteração
no sequenciamento original das atividades causado por esperas ou indefinições; e a mudança
constante do caminho crítico do projeto e, consequentemente, o desperdício de esforços e análises
de abordagem, controle e ações preventivas. Nota: as técnicas de aumento de efetivo ou
produtividade chamamos de Compressão e as técnicas de alteração de sequenciamento linear
entre atividades, colocando-as em simultaneidade parcial, chamamos de Paralelismo.
Análise de cenário do tipo “e se?”
Essa técnica aborda os casos para o desenvolvimento do

cronograma a partir de uma rede de atividades que traga
dentro de seu fluxo uma condicionante do tipo “se”. No caso
de inícios ou términos que dependem de atividades
externas ou atividades em que a análise de riscos do projeto
tenha sido apontada como “de alto impacto”, é possível
encontrar nesses modelos de rede apoio para simulações estatísticas que venham a auxiliar a
dimensionar as já mencionadas atividades do tipo lastro ou tempo de reserva para a montagem do
cronograma. Muitas vezes uma indicação de greve ou de liberação de licença no meio de uma
cadeia produtiva pode alertar a equipe de planejamento da necessidade de considerar lastros de
tempo de contingência para garantir os prazos intermediários ou finais do projeto. Os pontos de

“se” são eliminados e a modelagem segue na forma tradicional para a aplicação dos métodos
analíticos de desenvolvimento do cronograma.
Nivelamento de recursos
Como foi comentado anteriormente, a técnica do CPM foca

as atividades e define como crítico o seu caminho mais
longo. É sabido hoje que apenas considerar e
contingenciar esse caminho critico não garante o sucesso
dos projetos. Numa sociedade cada vez mais competitiva,
os recursos humanos e materiais estão ficando cada vez
mais difíceis e muitas vezes as especialidades e requisitos
de habilidade não são encontradas em prateleiras. Dessa
maneira, é comum após a programação inicial das
atividades verificar falta de recursos ou superalocações
físicas em certos períodos. Através do uso de algoritmos
computacionais e pelo ajuste de prioridades, é possível
rever o diagrama de rede, agora com o foco nos recursos. Os recursos são alocados
preliminarmente nas atividades do caminho crítico e, depois, pela ordem de importância nas outras
atividades. Muitas vezes os recursos não são suficientes para atender essas diretrizes e o caminho
possível de execução muda, respeitando o sequenciamento e precedências, atrasos e
antecipações explicitadas e marcos de restrições.
Algumas considerações relevantes sobre esse método baseado em recursos – resource base
method: o caminho crítico muda e as folgas que se apresentam por conta dos princípios de datas
de início mais cedo e mais tarde não são reais; o prazo final do projeto aumenta; o nível de
ociosidade de alguns recursos pode aumentar para permitir o ajuste dos recursos críticos; a
programação de outros projetos que dependem desses recursos pode sofrer impactos
significativos; os marcos parciais e finais não podem ser alcançados SEM o aumento de recursos;
o nível de estresse dos recursos críticos pode aumentar, em função do trabalho excessivo ou da
mudança de horários; os softwares que não preparados para promover esse tipo de controle podem
perder sua funcionalidade. Talvez o principal problema seja a descaracterização do método CPM
e seus recursos de controle. Nesse caso, o cronograma resultante será considerado como
Cronograma restrito por recursos ou resource-constrained schedule, sendo que suas datas de início
e término serão agendadas e não calculadas.
Suavização de Recursos.
Técnica que ajusta as atividades de um cronograma de tal forma que as necessidades de recursos
do projeto não ultrapassem a um limite predefinido dado pelas folgas. Na “suavização”, em oposição
ao nivelamento de recursos, o caminho crítico do projeto não é alterado e a sua data de conclusão
não é adiada. Em outras palavras, a atividade só tem sua data de início e término alterada dentro
de seus limites de folga.
Método da Cadeia Crítica
O método da cadeia crítica, também chamado de

gerenciamento de projetos pela corrente crítica, é a técnica
de análise de rede de projeto que foca os recursos
alocados e sua disponibilidade em vez do foco nas
atividades, como o método CPM. O método consiste basicamente em atribuir as durações mais
agressivas às atividades que contêm os recursos alocados, levando em conta todas as

dependências e restrições, avanços e retardos previstos no projeto. A rede então é ajustada para
representar o sequenciamento de atividades em função da disponibilidade dos recursos existentes,
e define, assim, um caminho crítico com base nos recursos, daí o nome caminho crítico de recursos.
Uma vez definido esse caminho, são então adicionados lastros de tempo, também chamados de
amortecedores, que vão garantir a margem de reserva necessária para a execução do conjunto de
atividades contempladas. É interessante observar que sempre que há um caminho crítico de
recursos atrelados a um lastro de reserva, é possível identificar caminhos concorrentes de
atividades a esse caminho citado, formando verdadeiros alimentadores ou afluentes de trabalho em
que, por definição de modelagem, também se aplicam lastros de reserva. Dessa forma, o
planejamento muda seu paradigma e agrega mais seguranças intermediárias ao processo. Pontos
interessantes desse método: o caminho crítico de recursos nunca muda; os caminhos
alimentadores não mudam de sequência; os lastros de reserva de tempo passam a ser os
indicadores de desempenho; os controles tradicionais de avanço físico financeiro das atividades
perdem seu papel de monitores de desempenho.
Software de apoio ao agendamento de projetos
Com a popularização dos computadores a partir da década de 80 do século passado, fica quase
que impossível trabalhar sem eles. Embora a grande maioria dos softwares seja baseada no
modelo CPM apresentado anteriormente e poucos se aventurem a trabalhar com o CCPM, muito
esforço se tem feito para se entender as outras formas de agendamento e suas vantagens. Os
softwares, na sua maioria, conseguem calcular e apresentar todas as grandezas necessárias para
o acompanhamento e controle do projeto físico e financeiro. Eles podem efetuar simulações com a
alteração de datas de início, término, durações, estimativa de múltiplas durações de projeto com
diferentes grupos de premissas nas atividades. Muitas técnicas de simulação utilizam a Análise
Monte Carlo e Latin HyperCube, na qual uma distribuição de resultados prováveis é definida para
cada atividade e utilizada para calcular a distribuição dos resultados prováveis para o projeto inteiro.
Além disso, análises “what-if” podem ser feitas utilizando a rede de lógica para estimular a geração
de diferentes cenários. Os resultados das simulações “what-if” são usados para avaliar a viabilidade
do cronograma sob condições adversas, e preparar planos de resposta/contingência para enfrentar
ou mesmo resolver o impacto de situações inesperadas.
Aplicação de calendários
Os calendários são essenciais para o agendamento real das atividades do projeto. O calendário
das atividades, isto é, a regra de agendamento e liberação para a execução, assim como a agenda
de disponibilidade dos recursos, são elementos que tomaram um grande avanço com o uso das
ferramentas informatizadas, processando grandes quantidades de informações de forma rápida e
precisa, apresentando, em segundos, resultados que, no tempo do planejamento PERT-COST,
eram impraticáveis. A maioria dos softwares de gerenciamento de projetos possui esse recurso.
Quando o projeto é caracterizado por recursos genéricos alocados, a importância do calendário dos
recursos é menor; porém, quando o projeto conta com recursos humanos únicos ou máquinas
complexas, o ajuste do planejamento em função das disponibilidades passa a ser essencial.
Ajuste de antecipações e atrasos
Alguns sequenciamentos apresentam, por limitações físicas de construção ou procedimentos

legais, antecipações e atrasos nas dependências entre atividades. Dessa forma, o planejamento é
apresentado muito mais consistentemente. Às vezes, por questões de ajustes e reduções de
prazos, essa técnica é invocada trazendo bons resultados. Deve-se atentar para que as regras de
exequibilidade das atividades não sejam quebradas pelo excesso nos valores aplicados. Para o
método do planejamento em poucos detalhes, que apresenta os “pacotes de planejamento”, os
valores de antecipações e/ou atrasos podem ser maiores; porém, eles devem ser revisados e
validados assim que o “pacote de planejamento” vier a ser detalhado.
Dotações orçamentárias
As dotações orçamentárias ajudam a definir as restrições do ciclo anual de orçamento. Nesse caso,
o uso de aplicativos que permitam ajustar o agendamento atendendo a essa restrição é essencial
para a produção de cronogramas reais e em atendimento aos limites estabelecidos. São úteis em
projetos com o porte de aquisição grande, mas podem ser usados somente se o poder legislativo
define regras para fazê-las exequíveis. Em muitos projetos do governo, o produto principal é
adquirido do setor privado. Em alguns casos, é possível garantir a verba para estes contratos, se
forem assinados antes do término do ano fiscal. Esta dotação coloca os fundos do contrato em
uma conta ou centro de custo separado para serem usados somente para o contrato específico.
Os fundos permanecem disponíveis por um período de tempo definido pelas regras estabelecidas
pelo poder legislativo. É uma técnica muito útil para projetos plurianuais.
7.1.2. O que se espera nas saídas
Cronograma do projeto - O cronograma do projeto, consequência da sinergia de todas as entradas em métodos

pré-escolhidos para montagem, possui pelo menos uma data de início planejada e uma data de término planejada
para cada atividade ou “pacote de planejamento” do cronograma. Uma vez que o cronograma encerra os recursos
necessários do projeto, ele deverá ser confirmado assim que os “stakeholders” que detêm o comando de recursos
confirmarem a sua participação. A apresentação do cronograma original era na forma de planilhas de datas de início
e término de cada atividade necessária para a produção do trabalho, porém, desde os anos de 1930, muitas
organizações trabalharam uma visualização gráfica para melhor entendimento e controle. Daí termos:
 Diagrama de rede do projeto – diagrama lógico e

sequencial das atividades a serem realizadas com o foco
nas atividades e suas precedências e informações de
início e término;
 Diagrama de barras do projeto – diagrama lógico e

sequencial das atividades representadas por barras
horizontais que se sobrepõem numa escala de tempo
definida com representação dos dias de trabalho e dos avanços e retardos. Eventualmente,
pode ser acompanhado por indicadores de texto com os atributos das atividades e seus
recursos.
Essa forma pode ser trabalhada ainda para

representar somente os pacotes de
trabalho ou entregas parciais, e nesse
caso chamados de “cronograma
sumarizado”, denotando que devem
estar representados apenas os produtos ou pacotes principais de entrega;
 Diagrama de marcos do projeto - Estes

gráficos são semelhantes aos gráficos
de barras anteriores, mas identificam
somente os pontos mais interessantes
do agendamento como o início ou o
término agendado das principais atividades, entregas de pacotes de trabalho, fases de
conclusões, entre outros.
Linha de base do cronograma – A linha de base

do cronograma é o retrato instantâneo do
planejamento efetuado pela equipe, levando em
conta todas as considerações já apresentadas
anteriormente e estabelecendo o padrão para ser
perseguido pela equipe de execução e referência
para a equipe de controle. Nela se encerram o
conceito de datas de início e de término das
atividades e de entrega dos pacotes de
trabalho.Os atributos de cada um dos elementos a seguir pode sofrer alterações por conta deste processo e, nesse
caso, a sua atualização se fará necessária e registrada.
A título de ilustração, há o método da cadeia crítica, também chamado de gerenciamento de projetos pela corrente
crítica. Definida inicialmente por Eliyahu Goldratt, essa técnica de análise de rede de projeto foca os recursos alocados
e sua disponibilidade em vez das atividades, como o método CPM, e diferente do método RCP.
CCPM – Critical Chain Project Management - A Corrente Crítica no Gerenciamento de Projetos pode ser apresentada
através de 5 etapas: Identificação, Resgate, Preservação, Potencialização e Controle.
Identificação
A primeira etapa do Gerenciamento do RCP – Resource Critical Path, foca na identificação do
caminho crítico obtido através do CPM – Critical Path Method. Dessa forma, o caminho lógico e
construtivo do projeto mais longo é identificado, sendo então a maior restrição do projeto. Essa
restrição é dada pela sequência de atividades. A seguir, com a utilização dos métodos de
nivelamentos disponíveis, revisar o uso dos recursos de forma a identificar a utilização do mesmo
recurso único em atividades diferentes. Essa verificação foi demonstrada no item 1 do tópico
anterior. O nivelamento foi apresentado a seguir no seu item 3. Suas consequências são na maioria
das vezes o atraso do cronograma do projeto, conforme foi demonstrado. Um novo caminho crítico
é apresentado em função das novas datas e do novo sequenciamento.
Nessa etapa é importante identificar os recursos que são críticos ou que caracterizem uma restrição
ao desenvolvimento mais cedo do projeto.
Resgate
A segunda etapa tem o objetivo de resgatar as

durações reais de realização das atividades
envolvidas nos “caminhos críticos” existentes. De
acordo com Dr. Goldratt15, a realização ou execução
das atividades de um processo atende a uma curva
de distribuição que apresenta um alto rendimento
no início com um longo período para a sua
conclusão. Esse efeito é também conhecido como
a Lei de Parkinson: “O trabalho se expande para
atingir todo o tempo disponível para executá-lo,
muitas vezes excedendo-o”. No desenho ao lado pode ser observado que as atividades podem ser
modeladas com duas durações básicas. A duração mais “agressiva” e a duração mais “segura”.
Isso significa que se trabalharmos sempre contando com a duração mais segura, seguramente
estaremos atingindo essa marca, enquanto que, se trabalharmos com a duração mais agressiva,
estaremos sempre com chances de fornecer às equipes um lastro (buffer) de apoio para eventuais
atrasos. A teoria que baliza a análise PERT (Program Evaluation and Review Technique) previu a
utilização de três valores de duração para a realização das atividades, porém, por uma série de
razões, não foi bem sucedida. Modelagens por simulação do tipo Monte Carlo, também são
utilizadas para definir o melhor valor para a duração das atividades. A etapa em questão otimiza a
duração através de dois valores de duração. Agressiva e Confortável.
O resgate passa pela administração

dos valores das durações das
atividades a 50% e a 95% dos valores
fornecidos.
A teoria da “síndrome do estudante” é
conhecida como: os estudantes
fazem os dois terços do trabalho
solicitado, na primeira terça parte do
tempo, e levam as ultimas terças
partes para fazer o restante. Muitas vezes pedindo mais “uma semana extra” para ajudar.
Solicitado: trabalho X para ser realizado em três períodos de tempo

Executado 2/3 do trabalho X no primeiro período, e o 1/3 final nos dois períodos seguintes
Alternativa Executar o trabalho X em ½ do tempo com uma “margem” de segurança de ½ período de
CCPM tempo
A filosofia do CCPM é, nesse momento, promover o resgate das durações agressivas, mas
possíveis, e adicionar um lastro para compensar o “risco” de atraso. As melhores práticas chamam
isso de tempo de
contingência. Por
segurança,
poderíamos dizer que
esse valor fica entre os 50% agressivos e os 95% do confortável.
Preservação
A terceira etapa tem o objetivo de apresentar meios para evitar que os outros caminhos de
sequenciamento de atividades que estejam alimentando o caminho crítico de recursos não o
15
Dr Eliyahu Goldratt – foi o primeiro a descrever a teoria das restrições, no seu livro A Meta (The Goal) - 1994
ameacem até o final do projeto. O processo de mixagem dos caminhos de atividades que interferem
no caminho crítico de recursos até o final do projeto cria um meio de eliminar a flutuações. Pode-
se dizer que os produtos desse processo são esses “lastros” que foram comentados anteriormente,
que têm a função de proteger o caminho crítico de recursos. Na figura a seguir pode ser observado
em verde o caminho crítico de recursos, dentro da visão estruturada do projeto; em azul, os
caminhos paralelos, que, por conta de suas características de disponibilidade de recurso, devem
possuir um “lastro” de tempo para as “eventualidades”.
O caminho YBBBR é o caminho crítico de recursos (as letras são os recursos). No caso do recurso
O verifica-se a existência de uma barra de atividades “lastro” hachureada na sequência OBR,
enquanto que na sequência YBOP-----R, o “lastro” se apresenta apenas após a atividade de recurso
P.
Esses “lastros” também são chamados de CCFB – Critical Chain Feeding Buffers. Eles têm a função
de absorver os atrasos das atividades que estão “alimentando” o caminho crítico de recursos.
Potencialização
A quarta etapa tem o objetivo de potencializar os recursos de forma a sempre atuarem de modo a
estar numa corrida para passar o bastão e não apenas para cumprir um cronograma estabelecido.
O CCPM apregoa que as pesquisas têm demonstrado que as equipes são mais motivadas por
metas do que pelas listas de atividades. Isso é registrado nas pesquisas em que se verifica que
quando é esperado que seja cumprido um percentual de 50% de uma atividade, apenas 50% são
reportados, sem interesse de antecipação do seu término. Nos casos de antecipação de término
de atividades, as atividades sucessoras (melhor dizendo, seus recursos) não estão preparados
para iniciar antecipadamente suas tarefas, apelando sempre para as programações estabelecidas
no cronograma. O uso de recursos no modo multi tarefas, ou seja, trabalhar simultaneamente em
vários projetos em vez de acabar as atividades de um para então iniciar outro é uma prática pouco
recomendada pelo CCPM.
Controle
A última etapa explora a
existência dos “lastros” dentro
do cronograma, de forma a
permitir a criação de
indicadores de desempenho.
Esses indicadores permitem o
monitoramento e controle
dentro dos processos já
conhecidos do PMBOK 3ª
edição e agregam um valor
significativo à tomada de
ações corretivas e de
contingências. São também eficazes como alertas de riscos do projeto. Uma vez que as datas dos
CCFB – “lastros” de tempo para os recursos que alimentam e concorrem para o caminho crítico de
recursos – são movidas para frente ou para trás no cronograma, elas refletem o uso do tempo de
reserva alocado no planejamento.
Uma regra de controle pode ser criada dentro de critérios específicos de cada projeto ou
organização que permita a tomada de decisão a partir do uso do tempo reserva dos recursos, quer
seja de forma generalizada ou de forma particular recurso a recurso.
Se houver o uso de até 30% do tempo de reserva promovido pelo “lastro”, nenhuma ação pode ser
necessária; se o uso chegar à casa dos 60%, uma revisão no planejamento pode ser invocada; e,
por fim, se houver um uso de mais de 60% uma ação corretiva deve ser iniciada e acompanhada,
uma vez que estamos esgotando as reservas de contingência previstas. O uso de uma carta de
controle é adequado.
Conclusões
Nota-se que essa forma de administrar o caminho crítico do projeto chega a quebrar alguns
paradigmas. Um deles é que o caminho crítico (método CPM) pode mudar dentro de um projeto de
acordo com os atrasos promovidos pelas atividades que estejam fora do caminho crítico original.
No CCPM (que determina o caminho crítico de recursos) isso não acontece, visto que os caminhos
“alimentadores” estão municiados de reservas em forma de “lastros” que protegem com segurança
o caminho original. Um outro é o foco que o CCPM dá a produção e aos seus elos de valor,
enquanto o caminho crítico promovido pelo CPM foca na sequência obrigatória de menor folga no
tempo. Um último ponto é a consideração dos recursos como sendo finitos e escassos,
programando o trabalho em sua função (CCPM) em vez de considerá-los inicialmente infinitos,
priorizando a sequência produtiva (CPM).
Consequências do Planejamento por Recursos no Projeto

O planejamento por recursos tem sido cada vez mais aplicado aos projetos que envolvam grande
alocação de mão de obra, contrariando o conceito de que esse tipo de análise seria feito apenas
para projetos que utilizassem mão de obra especializada. Recursos especialistas e de requisitos e
contratações especiais deram lugar agora à mão de obra barata e de fácil aquisição. Talvez isso
se deva a dificuldade de contratação legal e a desmobilização de grande volume ao início e ao final
dos projetos; ou talvez isso se deva a constantes remanejamentos de recursos entre projetos,
visando minimizar as despesas com tributos sociais. Há outras correntes que atribuem esse novo
método ao cálculo de estimativas de trabalho que agora estão na unidade “hh” e não mais em dias
ou semanas. O fato é que com o mapeamento dos recursos críticos de um projeto através do auxílio
de ferramentas computacionais, está ficando cada dia mais interessante e adequado para o
planejamento e controle dos projetos.
7.1.3. A importância de rever o Cronograma

Desenvolver o cronograma não deve se limitar a produzir gráficos ou determinar as datas ilusórias sem a preocupação
da modelagem necessária e adequada, e cabe aqui a análise das “Restrições do Projeto”. As Restrições do projeto
são aqui alvo de discussão e comentários enriquecedores do planejamento. Nesse tópico em particular, o
planejamento dos prazos do projeto.
Questões RESTRITIVAS como DATAS:
“Deve iniciar após a” ou “Devem acabar antes de” são comuns no nosso dia a dia e devem ser
modeladas para dar maior entendimento ao proposto à execução. Outras classificações, como “O
mais cedo possível”, “O mais tarde possível”, “O início não deve ser antes de”, “Não terminar antes
de”, “Não terminar depois de”, “Não iniciar após”, “Deve começar e” ou ainda “Deve terminar em”.
Questões RESTRITIVAS como INTERVALOS:
Os calendários são elementos restritores e necessários ao planejamento do projeto. Definem

intervalos de permissão de trabalhos ou períodos úteis. Podem assumir a sua função para o projeto,
as atividades e para os recursos. Eles identificam os períodos nos quais os trabalhos serão
considerados e realizados, sendo essas informações encontradas nas premissas do projeto, nas
características operacionais da empresa executante, na legislação local ou ainda na cultura dos
envolvidos. Os calendários do projeto são atribuídos de imediato a todas as atividades e a todos os
recursos e por, consequência, de forma direta e determinante no planejamento de um projeto.
Algumas atividades podem ser regidas e apenas realizadas em determinadas condições e
momentos. Alguns dos recursos podem ser regidos por condições contratuais específicas e
especiais dentro do projeto. Enquanto alguns trabalhadores estão sendo regidos por horário
comercial, outros podem estar regidos por turnos. Alguns equipamentos (alocação por período)
podem estar à disposição todo o tempo do projeto, enquanto outros podem estar alocados apenas
parte de um período do ano, limitando assim o seu uso e comprometimento.
Questões RESTRITIVAS como RETARDOS E ANTECIPAÇÕES:
Os RETARDOS e as ANTECIPAÇÕES também são elementos restritores e necessários ao

planejamento do projeto. Alguns retardos são consequências de processos construtivos ou legais
e interferem na disponibilidade de início de outras atividades dentro da rede de precedência. Se
considerados, dão mais realidade ao planejamento e por questões de acertos, condições técnicas
ou jurídicas esses restritores podem ser trabalhados para otimização e melhoria de cenários.
Questões RESTRITIVAS como LIMITES DE RECURSOS:
Os Limites de Recursos também são elementos restritores e muitas vezes mudam de forma radical
o resultado da programação das atividades e do término do projeto dentro do calendário. Isso é um
outro mundo que não dá, de fato, um capítulo, mas um estudo profundo sobre o tema.
7.2. Uso da Ferramenta – Desenvolvimento do Cronograma
7.2.1. Revisão do Cronograma
A ordem de apresentação do conteúdo do nosso livro foi definida para que pudéssemos seguir de forma lógica e
procedural o ciclo de vido do projeto, segundo as melhores práticas adotadas pelo mercado. Entretanto, entendemos
que, para que a equipe de planejamento possa desenvolver um cronograma de qualidade e, consequentemente, que
a equipe de controle receba material adequado de trabalho, nenhuma das áreas de conhecimento representadas
pelos capítulos anteriores pode ser segmentada e pensada de forma isolada, fora do contexto geral do gerenciamento.
Na definição das atividades do projeto, por exemplo, devemos dominar o gerenciamento dos recursos, custos, risco,
controle, comunicação, etc., para que sejam criadas adequadamente suas atividades de planejamento e controle,
criando-se assim um cronograma que de fato contemple todas e somente as atividades necessárias para a entrega
do projeto.
Se um trabalho será executado no projeto, sendo ele de produção de resultados diretos ou indiretos, existem
responsáveis, executantes, uso de recursos, custo, e esse trabalho está de alguma forma relacionado com os demais
“trabalhos” do projeto, ou não seria parte deste.
Pode ser necessário, após estas análises, uma reorganização da EAP do projeto, com criação de novos pacotes de
trabalho, o que deve ser seguido de uma atualização dos registros do projeto e emissão desta atualização para
aprovação dos responsáveis.
Administração
A inclusão das atividades de planejamento, gerenciamento, administração e fins dentro de produto adequado
deve ser estudada pela equipe de projeto, de acordo com as diretrizes definidas e documentadas para criação
do arquivo de gerenciamento.
Certamente, o escopo de cada uma destas atividades deve estar definido de alguma forma, colaborando para
a definição de responsabilidade, estimativa de gastos e ações de controle; e entendemos que a ferramenta
Ms Project é o local adequado para esta definição, documentação e parametrização, de forma que os custos
relacionados às atividades que não são de produção sejam incluídos na estimativa geral de custos do projeto,
por exemplo.
Gerenciamento dos recursos
Quase sempre os recursos a serem utilizados no projeto não estão disponíveis desde o primeiro dia da fase
de execução, sendo necessárias atividades preliminares para preparação do ambiente de trabalho.
Os recursos humanos muitas vezes devem ser contratados e treinados no início do projeto em produto de
mobilização da equipe, o que consome tempo de recursos do projeto e, portanto, deve ser modelado no
cronograma. O mesmo para a desmobilização das equipes ao término do seu aproveitamento no projeto.
Recursos reutilizáveis, como máquinas e equipamentos, devem ser adquiridos, transportados, testados antes
de sua utilização, receber cuidados periódicos de manutenção, etc., o que novamente deve estar de alguma
forma modelado no cronograma.
Materiais consumíveis devem ser comprados, transportados, estocados, transportados novamente, etc., como
veremos ainda neste capítulo.
Atividades de controle e replanejamento

As atividades de controle do projeto geralmente consomem considerável tempo e esforço e,
consequentemente, recursos financeiros do projeto. A não modelagem destas atividades no cronograma pode
levar ao erro na estimativa dos custos do projeto, falta de pessoal capacitado para emitir os planos de trabalho,
folhas de medição, inserir os dados na ferramenta, gerar relatórios e fornecer análises dos indicadores de
desempenho do projeto.
Além da existência das atividades, a equipe de planejamento deve garantir que seus dicionários estão completos e
de acordo com as necessidades do projeto. Aqui cabe reafirmar a importância de termos bem documentados os
critérios de qualidade, critérios de aceitação e métricas de controle para garantia do entendimento único destes itens
pelos envolvidos no projeto.
A falta de informações ou excesso destas (duplicação em documentos diferentes) tornará difícil o processo de
gerenciamento das expectativas dos envolvidos, prejudicando a percepção de valor destes.
7.2.2. Critérios de Qualidade – Escopo, Tempo, Recursos e Custo
Ao longo dos capítulos do nosso livro fornecemos diversas recomendações de utilização da ferramenta e, enquanto
apresentamos suas funções e recursos, as pusemos em prática durante o desenvolvimento do arquivo do nosso
projeto Reforma da Casa Feliz. Temos, portanto, distribuído ao longo das páginas pelas quais já passamos, um
conjunto de ações recomendadas pelos autores para o desenvolvimento de um arquivo de MS Project que tenha
qualidade ou uma lista de critérios de qualidade.
O uso desses critérios obedece ao atendimento de uma “check list”, na qual o atendimento do item mostra
conformidade com o critério classificado como produto de qualidade. Nesse nosso caso, o produto é o arquivo
desenvolvido para representar o escopo do projeto e os critérios de medição, inspeção e de qualidade dos entregáveis
do projeto.
Nos limitando ao conteúdo apresentado até este ponto do livro, reunimos nesta seção o conjunto de elementos
considerados determinantes para o desenvolvimento de uma modelagem de qualidade na ferramenta MS Project
2013.
Escopo
CQ-E 1. O termo de abertura do projeto e o Preliminary Scope Statement estão registrados no arquivo MS Project
de modo persistente ou através de hyperlink;
CQ-E 2. Os parâmetros da ferramenta estão ajustados e configurados Segundo as recomendações da Microsoft e
as melhores práticas de Gerenciamento de Projetos;
CQ-E 3. A construção de tabelas, filtros e grupos respeitam a lei de “ter o mesmo nome” que identifica o modo;
CQ-E 4. Os produtos e pacotes de planejamento foram criados com nomes como substantivos;
CQ-E 5. Os marcos de início e término do projeto foram incluídos no início e término da EAP, respectivamente;
CQ-E 6. O campo NOTES é utilizado para documentar o dicionário da EAP e contém a descrição e os critérios de
medição, controle e aceitação.
CQ-E 7. Não existem linhas em branco na EAP;
CQ-E 8. O critério para construção da EAP é claro e baseado em fases, área de construção, produtos ou ciclo de
vida do projeto;
CQ-E 9. Os elementos da EAP possuem quantidade de filhos que variam de 5 a 7;
CQ-E 10. Não existem elementos com um único “filho”;
CQ-E 11. Pacotes de planejamento são claramente distinguíveis dos produtos;
CQ-E 12. As organizações responsáveis pelas diferentes partes da EAP estão declaradas no campo contact;
CQ-E 13. O código da EAP possui regra de formação clara, é único e formado a partir dos recursos específicos da
ferramenta;
CQ-E 14. Existem modos específicos para construir, organizar e criar relatórios da EAP.
CQ-E 15. A EAO – Estrutura Analítica da Organização está clara e existe modo específico para emissão de relatório;
CQ-E 16. A EAO ou qualquer outra estrutura foi desenvolvida a partir de campo tipo outline code;
CQ-E 17. O campo notes contém informações como: “expectativas dos stakeholders”, “recursos necessários” e
“estimativa de custo”;
CQ-E 18. Existe um produto claro, definido como a administração do projeto, dentro da EAP.
Critérios de Qualidade - Tempo

CQ-T 1. Os campos customizáveis foram renomeados e seus usos documentados;

CQ-T 2. Existe modo específico para definir, documentar e emitir relatório das atividades e seus atributos;
CQ-T 3. O código da lista de atividades está claro e as atividades foram definidas como verbos, representando
ações;
CQ-T 4. O tipo padrão da duração das atividades é ‘fixed duration’, outras definições foram documentadas no
dicionário da atividade;
CQ-T 5. Os marcos obrigatórios e opcionais podem ser facilmente distinguidos das atividades;
CQ-T 6. Existe modo específico para definir, desenvolver e emitir relatório de precedência do projeto;
CQ-T 7. A rede está fechada. Não existe atividade ou marco sem predecessor, com exceção do marco de início do
projeto e não existe atividade ou marco sem sucessor, com exceção do marco de término do projeto.
Excluem-se atividades com vínculo dinâmico de agendamento, como as hammocks;
CQ-T 8. Não existem produtos sequenciados;
CQ-T 9. Deadlines foram utilizadas para modelar as restrições do projeto;
CQ-T 10. Não existe uso de tipos de restrição, com exceção de “Start no earlier than”, “As soon as possible” e “As
late as possible”;
CQ-T 11. O campo “estimated” para duração das atividades não é utilizado;
CQ-T 12. Calendários foram definidos e documentados;
CQ-T 13. As atividades hammock foram bem documentadas e produzidas através de links dinâmicos para
representar atividades de controle;
CQ-T 14. Atividades recorrentes foram bem documentadas no seu dicionário, contendo regra de reprogramação e
adição/remoção de atividades;
CQ-T 15. A linha de base inicial do projeto foi definida;
CQ-T 16. Existem modos específicos para leitura, monitoramento e geração de relatórios do cronograma e seus
gráficos;
CQ-T 17. Existe modo com screen Gantt Chart, configurado com elementos gráficos que seguem os padrões de
mercado, com variações e adições documentadas;
CQ-T 18. Existe modo com screen Gantt chart em que o caminho crítico pode ser visualizado na cor vermelha;
CQ-T 19. Existe modo com screen Gantt Chart em que é possível identificar valores free sack, total slack e baseline
de forma gráfica.
Critérios de Qualidade - Recursos
CQ-R 1. Existe modo específico para definir, visualizar, ajustar, monitorar e emitir relatório da lista de recursos do
projeto e seus atributos;
CQ-R 2. Existe modo específico para visualizar, ajustar, monitorar e emitir relatório do uso dos recursos no projeto;
CQ-R 3. Existe modo específico para visualizar, ajustar, monitorar e emitir relatório do mapa de aquisição de
recursos;
CQ-R 4. Existe modo específico para visualizar, ajustar, monitorar e emitir relatório do histograma de trabalho dos
recursos;
CQ-R 5. Existem filtros e grupos para acessar as informações de um recurso específico em modo tipo Resource
Usage;
CQ-R 6. Existe modo para visualizar e emitir relatório da “agenda” de qualquer recurso humano do projeto;
CQ-R 7. Existe modo para visualizar e emitir relatório da utilização de qualquer recurso tipo material ao longo do
tempo;
CQ-R 8. Existe modo específico para exibir, monitorar e emitir relatório do “antes e depois” da nivelação automática
de recursos executada pela ferramenta;
CQ-R 9. A linha de base pós inserção e avaliação do uso dos recursos foi definida, e a linha de base inicial foi
preservada.
Critérios de Qualidade - Custo

CQ-C 1. Existe um modo específico para visualizar, ajustar, monitorar e emitir relatórios das estimativas de custo
do projeto;
CQ-C 2. Existem filtros e grupos para acessar os custos e dotação orçamentária de um recurso específico do pool
de recursos;
CQ-C 3. Existe um modo específico para visualizar, ajustar, monitorar e emitir relatório da dotação orçamentária do
projeto;
CQ-C 4. Existem recursos específicos no pool de recursos para suportar a modelagem da datação orçamentária do
patrocinador do projeto;
CQ-C 5. Existem modos específicos para visualizar, ajustar, monitorar e emitir relatórios do fluxo de caixa do projeto.
CQ-C 6. A linha de base pós inserção avaliação dos custos foi definida, e linhas de base anteriores foram
preservadas.
7.2.3. Modelagens
7.2.3.1. Estruturação Alternativa no MSProject (Múltiplas EAPs)
Alguns pontos devem ser esclarecidos no uso desse recurso do MSProject 2013. A utilização do Campo Estruturado
tem por objetivo a classificação das atividades de um projeto em função de outras estruturas que não apenas a WBS
ou EAP. Tomaremos a seguir como exemplo o conjunto de atividades necessárias para o acerto das instalações
elétricas de um complexo elétrico. Todo trabalho será realizado na ferramenta por meio do Outline Code, sem perder,
no entanto, o vinculo com as técnicas já abordadas e dispensando o uso da estruturação tradicional WBS.
Como a estrutura do nosso livro atende ao princípio da divisão dos

trabalhos orientada a produtos e seus pacotes de trabalho, deve-se
tomar os devidos cuidados:
1 - A WBS é montada dentro do campo OUTLINE CODE 1, ficando

com a identificação dos produtos principais os campos
numéricos:1,2 e 3; e os pacotes de trabalho como números que
variam de 1 a 5. Deve ser observado na tela ao lado que a escolha
do Code Mask (configuração das possíveis entradas deste campo)
foi “Numbers”, com qualquer tamanho e separador tradicional “.”.
2 - Só poderão ser admitidas classificações para as

atividades desde que sejam utilizados os códigos de EAP
listados e não é permitida a criação de nenhum outro
código extra, garantindo assim a pertinência das ações ao
escopo acordado.
3 - O campo Description é então preenchido para o perfeito

entendimento da estrutura e seus pacotes. Isso é muito
similar à montagem de uma estrutura WBS que é obtida
pela aba Project grupo Properties item WBS – Define Code.
4 - No momento do preenchimento da lista de atividades,

uma vez terminada a atividade de documentar o escopo
nesse nível de estruturação, o primeiro passo é definir qual
o item de escopo que será abordado ou qual o pacote de
trabalho que será modelado em primeiro lugar. No caso em
exemplo, tomamos como primeiro elemento sob análise o
1.1 - Procedimentos para trabalhos das Equipes de
Manutenção, que é um pacote de trabalho do 1 –
Procedimentos de Trabalho. A seguir o 1.2 –
Procedimentos para trabalhos das Equipes de
Operação e, por fim, o 1.3 – Procedimentos para
Treinamento das Equipes em Geral.
O resultado pode ser visto na listagem a seguir, tendo a tabela sido criada especificamente para esse fim, contendo
os campos ID, Indicators, Outline Code 1, Name, Notes, sendo seus títulos renomeados para dar o real sentido ao
seu preenchimento.
5 – Prosseguindo até o final, cada atividade incluída como necessária para atendimento aos problemas encontrados
nas instalações sob análise é classificada até que todas venham a pertencer a um pacote de trabalho. É importante
lembrar que as atividades registradas ao serem concluídas devem dar cabo da atividade da realização plena do seu
pacote de trabalho afim.
6 – O próximo passo é garantir a identidade das atividades

listadas através de sua ordenação e “renumeração”, isto é,
garantir que elas obedecem à sequência de lançamento
sintonizada com a estrutura do Outline Code 1 escolhida. Para
isso, é acionado o item encontrado em View – Sort - Sort By, e
escolhido como primeiro parâmetro o Outline Code 1 – nesse
caso renomeado para EAP 1. O botão “Permanently renumber
tasks” deve ficar marcado.
7 – Preparando agora um grupo para as atividades, nas

quais a referência de grupamento é a estrutura de
trabalho criada anteriormente, assim como um modo
específico que reúna a tabela criada com esse grupo
“EAP- Subestações”, é possível visualizar o projeto
com as suas atividades classificadas por essa
referência. Foi escolhida intencionalmente a tela
(Screen) Gantt Chart para mostrar que o resultado é
idêntico àquele conseguido quando utilizamos a
montagem do projeto com a endentação tradicional.
O resultado observado ao lado mostra que os

“Procedimentos” são um dos produtos principais do
projeto, e manutenção, Operação e treinamento,
seus pacotes de trabalho, sendo que as atividades
foram agrupadas para sua realização individual.
8 – No caso em estudo deve ser considerado

que por conveniência as atividades devem
ser classificadas pelos equipamentos que
elas pretendem consertar, melhorar ou
tornar viáveis ao sistema elétrico dentro de
cada unidade de subestação elétrica
definida. A classificação desse tema passa
então a ser feita pelo segundo campo
estruturado ou Outline Code 2, chamado
aqui pelo nome de EAP 2
9 – Apenas com a inclusão do campo “EAP

2” dentro do modo apresentado
anteriormente é possível classificar o
trabalho das atividades dentro da
classificação específica de equipamento a
essa atividade atribuída. Assim, o
preenchimento de dados fica facilitado e
dinâmico o suficiente para que ao final seja possível visualizar as informações sob outros aspectos.
10 - Elaboração de um modo que visualize as atividades sob a classificação de Local (outline code 1) e pelos
Equipamentos afetados (outline code 2).
Passo 1 – Criar um grupo específico. Grupo EAP – Subestações + Equipamentos;

Passo 2 – Criar um modo que utilize a mesma tabela, porém agora afetado ao grupo acima;
Passo 3 – Atribuir ao modo a tela (screen) de Task

Usage.
O que temos dessa forma é a estrutura do trabalho

ainda dividida entre os diversos tipos de equipamentos
elétricos, comuns a todas as subestações ou não, com
a possibilidade de ter seu trabalho monitorado e
acumulado nessa visão e classificação.
12 – No caso em estudo, deve ser considerado que algumas atividades são consideradas Melhorias para o sistema
elétrico, Essenciais ou Obrigatórias, sendo essa classificação uma alternativa para tomada de decisão de início de
serviços e valores de desembolso financeiro. A classificação desse tema pode ser feita por um campo simples tipo
texto.
13 – Com a criação de um novo grupo, é possível então observar onde será mais necessário atuar visando ao grau
de urgência da ação corretiva ou preventiva de manutenção.
14 – Pode-se perceber na tela ao lado que as grandezas são totalizadas dentro dos critérios escolhidos. Isso facilita
a tomada de decisão. O grupo foi escolhido para classificação de Critério de Urgência e da subestação elétrica.
15 – Para maior flexibilidade, pode ser estabelecido o nível da estrutura pela qual será
iniciada a classificação dentro do grupo. No exemplo ao lado, a partir da escolha da
linha “then by”, campo EAP 1 – que é o “Outline code 1”, ajustou-se o nível de
grupamento para 2, assim a classificação se resumirá às informações, conforme a tela
ao lado. Os subníveis de todas as estruturas do primeiro nível de Subestação agora
se confundem num grupamento só.
Pode-se perceber que a totalização no nível do critério de urgência Obrigatório se manteve igual.
16 – Outra classificação interessante, e dessa vez do ponto de vista contábil, é quanto ao destino do gasto dentro
desta classificação. Pode-se dizer que reparo e projeto estão na ordem do investimento da organização, enquanto
manutenção e segurança dentro dos gastos operacionais. Utilizando-se então o sistema de custeio pode-se classificar
independentemente as atividades e apresentar TODOS os trabalhos agora sob a ótica de investimento contra
despesas operacionais. Através de outro campo livre, dessa vez do tipo numérico, é possível classificar e grupar
nesse novo sentido.
17 – Devemos criar um grupo que prevê a classificação das atividades pelo critério
da urgência e pelo critério da categoria do gasto a ser despendido. Nesse caso em
particular, foi utilizado um campo do tipo numérico para permitir o grupamento de
FAIXAS. Através do botão “Define Group Intervals”, é possível definir que a linha
da contabilidade será “group on” Interval, começando no 1 (primeiro), e de 2 em 2
elementos. No nosso caso Projeto(1) e Reparo(2) estão classificados como
Investimento(3) e Manutenção(4), e Segurança como Operacional.
O resultado é visto a seguir:
• É obrigatório o gasto de R$
14.400,00.
• É muito urgente o gasto de
R$ 43.360,00.
Se, no entanto, o critério do grupo é invertido
• É de investimento o gasto de
R$ 17.760,00
• O gasto com investimento é
cerca de 30% dos serviços
necessários.
• Com a “verba” da
manutenção anual, pode ser
feito todos os serviços
obrigatórios de investimento
e deixar de lado as melhorias de manutenção.
18 – Entendendo a Urgência das atividades obrigatórias, pode-se então atribuir o valor “priority” a essas atividades e,
através do campo específico, lançá-las. Zero para as melhorias, 500 para as essenciais e 1000 para as obrigatórias
(inadiáveis).
19 – Como fica o orçamento original das atividades possíveis de serem realizadas pela visão tradicional da WBS (por
subestação)? Através da personalização de grupos pré-definidos, conseguido pelo clique do botão direito sobre a
área do grupo, é possível incluir um nível temporário e acima do nível de classificação “outline code 1” – EAP 1, e
incluir um campo numérico Numbern. Dessa forma, será possível totalizar nessa linha temporária todos os valores
para efeito de comparações. No nosso exemplo ilustrativo, após a priorização das atividades, solicitamos o
nivelamento dos recursos e comparamos o orçamento necessário para dar cabo de todos os serviços conforme
possível fisicamente com o novo orçamento limitado aos recursos (humanos) de execução. O resultado mês a mês
mostra que o período de execução, obedecendo às precedências e os critérios de classificação, apontam para um
consumo médio de recursos constante da ordem de R$8.000,00 mês, contra o “pico” de dispêndio de R$ 35.000,00
no segundo mês. O prazo, é claro, foi dilatado de 5 para 11 meses.
20 – Graças ao recurso de “Import Custom Fields” é possível aproveitar as estruturas já montadas para utilizar em
outros lugares. No nosso caso de exemplo, estamos importando para a tabela de recursos o Outline code 1 –
subestações que foi montado para a tabela de atividades (tasks). É necessário selecionar o próprio projeto para
escolhermos o campo adequado (field type marcado task).
21 – O grupamento já comentado também é útil para a visualização do diagrama de precedências (Network Diagram).
7.2.3.2. Restrição de Materiais
Sabemos que o MS Project não suporta nivelamento de materiais, ou seja, não é possível, de forma automática,
reagendar as atividades do projeto por falta de recursos não reaproveitáveis. Apresentamos nesta seção um conjunto
de ações simples para modelar e controlar a restrição de materiais no MS Project, e aproveitamos para comentar
sobre atividades de gerenciamento de insumos em geral.
Iniciamos preparando um modo composto que na parte superior apresente modo tipo a screen Gantt Chart, e na parte
inferior modo com screen Resource Usage. Os campos para tabela podem ser vistos na imagem abaixo, onde
visualizamos um "projeto exemplo" criado para esta seção.
O campo “compra de materiais – quantidade” é um campo livre tipo número.
Podemos perceber que neste exemplo existe uma lista de atividades nas quais foram alocados recursos do tipo
material.
O controle se dará com a inclusão do produto compra de materiais. Vejamos qual a proposta para desenho deste
produto.
Atividades de compra de material
Para gerenciar a compra de material, documentar as necessidades dos envolvidos, dados dos fornecedores, alocar
recursos humanos, definir métricas de controle e relatórios de comunicação, devemos criar atividades no nosso
cronograma, o que entendemos como pilar para o planejamento.
Propomos que a duração desta atividade seja tal que somente termine no momento do recebimento do material, ou
então que o trabalho de acompanhamento do pedido seja de outra maneira modelado.
Para cada material do projeto que se deseje utilizar este nível de controle, criamos um pacote de trabalho de compra
de material, em que foram criadas atividades de compra em quantidade definida após análise do consumo deste
material ao longo do tempo, análise facultada pelo modo Resource Usage, campo work. Configurando a escala para
mensal, podemos identificar as necessidades do projeto e agendar a quantidade de atividades de compra necessárias
para atender a demanda OU reagendar as atividades baseado na restrição de materiais.
Realizamos o agendamento aplicando a restrição “não começar antes de” e documentamos a quantidade de materiais
que será adquirida por cada atividade de compra.
Valores financeiros de compra na atividade de compra
Para controle do fluxo de caixa, incluímos os valores financeiros despendidos na compra de materiais nas atividades
modeladas para este fim, e não no momento de uso dos materiais. Para isso, criamos dois recursos na ferramenta
para cada material, um para representar a compra e outro para representar a utilização.
Dessa forma, as atividades de produção receberão alocação dos recursos materiais de uso e as atividades de compra
receberão alocação de recursos materiais de compra. Podemos começar a entender que, no mínimo, as quantidades
acumuladas desses recursos ao longo de tempo devem ser iguais, ou melhor, a quantidade de material de compra
não deve ser inferior a um limite de segurança preestabelecido pelos responsáveis das atividades de execução.
Com a ajuda do MS Excel, criamos o gráfico a seguir, que mostra o consumo mensal e quantidade de recursos
adquiridos, para o material X, em barras, e a quantidade ‘em estoque’ ao longo do tempo, em forma de linha. Estes
são os dados da fase de planejamento.
50
40
30 Material X
20 Material X - Compra
Diferença X - Acumulado
10
0
ago/13 set/13 out/13 nov/13 dez/13 jan/14
Sequenciamento das atividades de compra
Para que as atividades de execução sejam impedidas de iniciar sem que as atividades de compra tenham garantido
que existem recursos disponíveis, podemos definir um vínculo de precedência de término para início entre estas
atividades. Dessa forma, caso ocorra algum atraso na compra dos materiais, a equipe de controle poderá analisar o
impacto deste atraso e acionar a elaboração de ações para minimizar, ou contornar este problema.
É faz extremamente importante que estes links sejam documentados de forma clara e consistente no dicionário de
ambas as atividades.
7.2.3.3. Restrição Orçamentária
Vimos no capítulo 5 como incluir a dotação orçamentária no nosso cronograma, através da definição de recurso tipo
budget e sua alocação na linha 0 do projeto (Project Summary Task). Naquela ocasião, lembramos da necessidade
da verificação do valor da dotação financeira do projeto para garantia que seja superior ao custo total do mesmo.
Quando limitados a esta análise, estamos a atender as necessidades do projeto em recursos financeiros para suportar
os gastos, mas existe uma diferença entre custo analítico e orçamento, e esse último acaba por ditar as regras mais
fortemente. Muitas vezes chamadas de “saúde financeira do projeto”, mostra que a forma que o desembolso ocorre
no tempo de pode ser significativamente mais difícil de administrar que o próprio valor a se gastar.
Quando alocamos os valores cheios nas colunas relativas às rubricas de gastos pela classificação dada podemos
perceber que a distribuição se faz uniforme no tempo, ou seja, no perfil de distribuição (work contour) seria o
equivalente ao “flat” da alocação dos recursos originais. Só que desta vez, sem opção de ajuste automático de
distribuição.
Por possuir, por padrão, forma de rateio linear, essa distribuição / Alocação de recursos “Budget” muitas vezes não
satisfaz as necessidades financeiras e de carga do projeto, caso no qual se faz necessária a compatibilização de
entradas e saídas. Dessa forma, iniciamos a chamada “reconciliação” ou “compatibilização“ dos valores disponíveis
ao trabalho ou o trabalho aos valores disponíveis.
Para nosso exemplo, suponhamos que no projeto Reforma da casa Feliz tivéssemos uma restrição de valor máximo
de R$ 7000,00 para o aporte mensal do patrocinador, valor que não atende aos gastos mensais do projeto, segundo
o cronograma atual, então o cronograma desenvolvido no capítulo 5.
• Primeira forma de acerto: Valores necessários e valores fornecidos
O acerto dos valores se faz para atendimento à programação de trabalho definida pelos passos até o momento, sendo
necessário renegociar com o patrocinador muitas vezes antecipações, retardos e valores totais de aportes financeiros.
• Segunda forma de acerto: Trabalho reprogramado ou reagendado, adequando-se aos valores disponíveis
O acerto dos valores não é feito. Em seu lugar, trata-se de reagendar o início das atividades, respeitando a rede de
predecessores estabelecida; mudando a técnica de produção; estudando novas formas de contratação; e até o
dimensionamento das equipes com redução de número de participantes e aumento de prazo de realização, atendendo
à expressão: W = D x U.
Nesse caso, para efeito de programação de atividades, o reagendamento deverá ser realizado através das restrições
do campo CONSTRAINT TYPE, no tipo “start no earlier than”. Deslocando sempre para o período seguinte, buscando,
através da manutenção da rede de precedências, uma adaptação aos valores financeiros / força de trabalho
disponíveis.
Observação: Seguindo a mesma ideia da modelagem de restrição de materiais, podemos definir atividades
periódicas de garantia do recebimento da dotação orçamentária de cada período de “pagamento”, por exemplo,
mensal, agendadas com restrição do tipo “não começar antes de”.; e tornar as atividades do projeto a serem
reprogramadas por restrição de recursos financeiros sucessoras destas atividades.
Antes da modelagem de restrições por essa aproximação, deve-se estudar o impacto no aumento do trabalho de
controle, replanejamento e documentação do cronograma, que cresce de modo diretamente proporcional à
complexidade do projeto.
7.2.3.4. Estimativa da Duração pela técnica PERT
Versões anteriores da ferramenta continham o recurso de cálculo da duração das atividades através da estimativa
PERT, na qual deveríamos fornecer três valores de duração, comumente chamados de valores pessimistas (P), mais
prováveis (MP), e otimistas (O), e a duração da atividade era calculada através da fórmula (P + 4 x MP + O) / 6, que
se trata de uma aproximação da curva de distribuição normal. A utilização deste técnica traz melhores resultados
quando existem informações históricas de qualidade que possam ser utilizadas como insumo para a estimativa das
duração das atividade.
Conhecendo o uso de campos customizáveis e fórmulas, podemos criar um modo de trabalho simples para cálculo
da duração ou qualquer outra estimativa, através do método PERT. Este não incluirá automaticamente o valor
calculado no campo duration, cabendo ao usuário validar e inserir este valor.
Iniciamos renomeando quatro campos customizáveis do tipo duração, conforme tela mostrada a seguir. Ainda, para
o campo Duração – PERT, inserimos a fórmula que caracteriza este método de estimativa, e selecionamos o valor
Rolllup – Sum, para o método de cálculo do valor deste campo nos produtos do projeto.
A seguir, criamos a tabela que será utilizada pelo nosso modo, que simplificando, possui os campos mostrados na
imagem ao lado.
Para criação do modo, escolhemos a screen Task Sheet; não aplicamos filtros ou grupos.
Reparemos na imagem abaixo que alguns dos valores calculados pelo campo duração – PERT apresentam
componente fracionária, que muitas vezes não condiz com as práticas de estimativa de duração das organizações,
que se esmeram em definir valores que colaborem com a logística de alocação de equipes, no caso, valores múltiplos
dos períodos normalmente utilizados pelos envolvidos.
8. Capítulo 08: Monitoramento e Controle
8.1. Conceitos de Monitoramento e Controle

8.1.1. Monitoramento e Controle
Tomando as seguintes considerações:
1. Temos em todas as publicações de

mercado, assim como em todos os
treinamentos e cursos, uma
ênfasemuito grande no planejamento;
diversos capítulos pra essa etapa da
vida do projeto; diversas aulas nos
cursos para definir um plano de
projeto, e nas profissões até se
falando em profissional de
planejamento de projetos. Onde fica o
monitoramento e o controle na equipe
de gestão, então?
2. No Guia de Referência para

práticas de gerenciamento de
projetos - PMBOK, na sua 5ª edição,
encontramos a seguinte definição
para o monitoramento e o controle de
um projeto: “Grupo de processos de
monitoramento e controle. Mede e
monitora regularmente o progresso
para identificar variações em relação
ao plano de gerenciamento do
projeto, de forma que possam ser
tomadas ações corretivas, quando
necessário, para atender aos
objetivos do projeto.”
3. No “Guia da Experiência Prática” – aqui parafraseado por “experiência profissional”, afirmamos que o
sucesso de um projeto depende tanto do plano de projeto como do plano de monitoramento e controle. Mas,
por conta das incertezas e desvios, é que as ações corretivas são tomadas e, eventualmente, as preventivas
são desenvolvidas para resgate de prazos, custos, produtividade. Essas ações são as que de fato garantem
o sucesso e são oriundas do processo de “monitoramento e controle”.
Podemos sem medo afirmar que esse processo é tão ou mais importante que o tradicional “planejamento do
projeto”. Está muito claro que a base de referência – oriunda do planejamento, é a base de trabalho da
equipe de monitoramento, por que não dizer, a trilha a ser perseguida. Se propomos tratar o controle daquilo
que fazemos, expectativas do cliente ou patrocinador, devemos ter diversos planos: ESCOPO do projeto,
TEMPO (cronograma), CUSTO (plano de desembolso, “orçamento”) e, assim, para todas as áreas a serem
administradas, esses devem ser considerados Plano de Gerenciamento do Projeto. A equipe do projeto
deve receber, ainda dentro da proposta do TAP, em conjunto com o gerente do projeto, à luz do Termo de
Abertura do Projeto e do Requisitos de Especificação do Projeto, quais serão os processos necessários para
esse trabalho de monitoramento e controle, adequados à aplicação e nível de complexidade do projeto. A
periodicidade de medição e avaliação também deve ser definida neste momento, podendo ser flexível e
dinâmica em função do desempenho e das medidas corretivas que vierem a ser implantadas para
realinhamento com o Plano de Gerenciamento do Projeto original.
Uma vez estabelecido o período de medição, este pode e deve ser alterado para outro menor, todas as
vezes que desvios acima das tolerâncias permitidas e previstas no TAP aparecerem no projeto. Um projeto
de medição mensal que, por conta de um dado desempenho, apresenta desvio de tempo da linha de base,
deve ter seu período de controle alterado para outro menor, por exemplo, semanal, até que os marcos
intermediários de controle se mostrem alcançados e o projeto adquira a confiança anterior. Dessa maneira,
o aumento de trabalho das equipes de execução (ações corretivas para acerto de desvios), como o aumento
de trabalho da equipe de controle (por conta de novas e mais medições) se justifica face ao retorno do projeto
ao plano original.
O planejamento tem como principal missão orientar as equipes de execução para a garantia de uma
otimização dos trabalhos a serem desenvolvidos, a garantia do entendimento das partes e do todo, e da
preparação dos envolvidos e dos recursos do projeto para atuarem em busca do sucesso. O processo de
monitoramento e controle permeia todas as etapas do projeto e, nesse caso, deve-se ressaltar que sua maior
intensidade se encontra justamente na etapa de maior volume de trabalho: a etapa de execução.
A ferramenta MSProject é
extremamente eficaz e útil
nessa etapa de execução. O
trabalho de monitoramento e
(5) controle não é exclusivo
dessa etapa, mas, repetimos,
é muito mais intenso e seus
resultados mais percebidos no
fator “sucesso” do projeto.
Destaca-se a parte do
planejamento (2) que “invade”
a etapa de execução (3).
Nesse ponto, ressaltamos que
esse planejamento muitas
vezes se caracteriza como replanejamento, consequência das ações corretivas e preventivas de rumo do
projeto, em busca do resgate das referências das linhas de base: escopo, tempo, recursos e custos. As
etapas de Iniciação (1) e Encerramento (4) são afetadas também, porém com intensidade significativamente
menor.
A figura ao lado mostra essa

“divisão”: planejamento x
replanejamento, uma
realidade que ocorre no dia a
dia dos projetos, mas ainda
não é registrada dessa forma
nas publicações
contemporâneas. Trabalhos
distintos, equipes com perfis
distintos em condições
distintas.
8.1.2. Apresentação Gráfica.
Primeiro momento – planejamento

realizado. A linha reta ascendente
é o plano previsto de
comportamento do início ao
término do projeto. Os retângulos
sobre a linha mais grossa
horizontal superior são os
períodos de tempo previstos para
medição de trabalho realizado. No exemplo, 5 medições.
Segundo momento – medição

número 1 realizada, retângulo mais
escuro cumprido no tempo.
Produção inferior àquela pretendida
é representada pela linha mais
grossa e abaixo da linha mais fina
de base. Desvios existem para
menor e acima da tolerância
permitida neste projeto. Proposta
de ações corretivas são feitas neste
momento e o período de medição é
reduzido para ¼ do original.
Terceiro momento – medição

número 2 fragmentada em 4
partes para monitoramento e
posteriores ações de controle
mais rápidas. Em “a”, houve uma
recuperação de produtividade em
relação à linha de referência; em
“b” mais resultados; em “c” uma
perda de desempenho; mas em
“d” a recuperação final de produção. A medição número 3 foi programada para acontecer em 2 momentos de modo
a verificar a confiança do projeto.
Quarto momento – com a medição número 3 dividida em 2 partes, verifica-se pelo desenho que a produtividade
superou o esperado em “e”; retornando ao normal previsto em “f”. Isto significa que o projeto está sob controle e o
período de medição poderia voltar ao normal. Deve-se sempre lembrar que esse procedimento de alteração de rotina
é muito apropriado quando os prazos são pequenos (do projeto).
É uma boa prática manter o início do projeto, assim como a sua etapa de conclusão (final) ter seus períodos de
medição encurtados e alterados para um maior monitoramento de desempenho; permitir ações corretivas e
demonstrar o grau de confiança que esse projeto possui em função de suas características e comportamento. Mesmo
que não seja para fins de
pagamentos de fornecedores,
esta prática tem se mostrado
muito conveniente. As linhas
verticais representam as
medições de desempenho, mas
as linhas numeradas podem ser
consideradas medições formais de contrato, pagamentos ou de acompanhamento de projeto para fins de relatórios
gerais.
Acreditamos poder definir o monitoramento como as ações passivas de acompanhamento do estado das grandezas
passíveis de mensuração direta, por um ou mais profissionais, no intuito exclusivo de verificar os indicadores de
desempenho, as diferenças positivas ou negativas destas em relação a padrões previamente estabelecidos e
acordados.
Pelo mesmo princípio, definimos o controle como conjunto de reações ou atitudes proativas com intuito exclusivo de
restabelecer aos padrões previamente estabelecidos e acordados os indicadores de desempenho e as grandezas
livres que estiverem em desacordo, sendo também administrado por um ou mais profissionais.
O monitoramento contínuo permite que a equipe tenha entendimento claro da saúde do projeto e, pela sua
modelagem, identifique as origens organizacionais, estruturais e de fornecimento que venham a exigir ações
preventivas ou corretivas.
Itens básicos para controle em qualquer empreendimento são: os compromissos de entrega (produtos em
desenvolvimento e suas partes); o cumprimento dos prazos previstos e propostos; a manutenção dos patamares de
custos previstos para a realização destes “entregáveis”, sua composição e distribuição contábil e o esforço
despendido em horas de trabalho de equipe para realização das atividades previstas, o uso de equipamentos e
materiais de consumo nas proporções estimadas, assim como despesas gerais com fornecedores e contratados.
Destacamos como meta de controle:
 A verificação do escopo do projeto que é processo da formalização do aceite das partes do

projeto por todos os envolvidos. Ele trata exclusivamente da aceitação das entregas – “se o
que foi entregue está de acordo com as especificações do escopo”;
 O controle do escopo que é o processo de validar os pedidos de alteração e sua forma de
registro e autorização;
 O controle do cronograma do projeto que é a verificação da realização das atividades nos
prazos e datas estipuladas em plano de trabalho, assim como a forma de validação dos
pedidos de sua alteração, registro e autorização;
 O controle dos custos do projeto, que é a verificação da realização de todos os trabalhos e
acúmulo de despesas e tributos, dentro do orçamento previsto – isto é, nos tempos previstos
de desembolso financeiro - estipulados no plano de trabalho, assim como a forma de
validação dos pedidos de sua alteração, registro e autorização.
 O gerenciamento das equipes do projeto, verificando as datas de participação de cada
componente alocado, grau de participação e produtividade individual
 O controle do uso dos equipamentos e consumo de materiais de construção ou insumo.
 A geração de Relatórios de Desempenho.
Os modos de controle básicos serão:
1. Controle dos parâmetros de tempo;

2. Controle dos parâmetros de tempo, trabalho e custos das atividades
3. Controle dos parâmetros de tempo, trabalho e custos das atividades, seus recursos
4. Controle dos parâmetros de tempo, trabalho e custos das atividades, seus recursos com
e/ou pelos seus apontamentos periódicos
8.2. Uso da Ferramenta – Monitoramento e Controle

Executar ciclo de medição:

8.2.1. Etapa de Execução – Preparação da Ferramenta
De forma semelhante ao início de nossas atividades de planejamento na ferramenta, devemos realizar configurações
ao iniciarmos a etapa de execução, preparando nosso arquivo de MS Project para o novo ciclo na vida do projeto.
Novamente, esses ajustes são necessários e devem ser realizados para que a ferramenta nos forneça o resultado
esperado, mais próximo possível da realidade modelada. O entendimento dos parâmetros possíveis de serem
configurados fornece ao usuário flexibilidade e mais segurança para trabalhar seus projetos.
Através de quatro passos preparamos a ferramenta para o monitoramento e controle:
Passo 1
Através do Ribbon Project, grupo Properties, item Project Information devemos ajustar as
datas Current Date e Status Date. A Current Date representa a data atual do sistema e
posiciona o MSProject a entender em que momento estamos localizados no tempo. A segunda
data, Status Date, fornece ao MSProject as referências para suas simulações, cálculos e
estimativas do andamento do projeto. É, por exemplo, usada para as referências das linhas de
progresso Progress Lines e para a análise do valor agregado.
É importante que o conceito de Status Date seja bem fixado. Ainda não apresentamos a dinâmica de controle
utilizando o MS Project, mas suponhamos que exista um planejamento desenvolvido, no qual temos três
atividades (imagem abaixo) que estão em fase de execução, e sobre as quais recebemos informações em
períodos preestabelecidos pelo plano de controle do projeto; por exemplo, todos os responsáveis enviam
informações da semana de trabalho (período segunda a sexta) anterior, na segunda pela manhã. Vejamos a
imagem abaixo.
No nosso exemplo, os responsáveis pelas atividades 1 e 2 enviaram na segunda feira, dia 11, informações
sobre a execução das suas atividades (feito, não feito, volume produzido, consumo de recursos, resposta aos
critérios de qualidade, etc.). Ainda segundo o plano de controle do nosso exemplo, nas segundas essas
informações são recolhidas para que as informações atualizadas do cronograma do projeto sejam passadas
aos envolvidos nas terças pela manhã.
Reparando na imagem acima, vemos duas barras verticais no diagrama de Gantt (configuração gráfica
realizada através da opção Gridlines...). A Laranja (mais à esquerda) representa a Status Date, e foi
configurada através da opção Project Information para o dia 08 17:00, limite temporal das informações
recebidas. Assim, se as atividades 1 e 2 estão concluídas, nosso cronograma está no prazo, se não, estamos
atrasados; se a atividade 3 já iniciou, estamos adiantados. Alterações na Status Date representariam uma
leitura diferente da ferramenta. É importante então configurá-la de acordo com as informações disponíveis
para a atualização do projeto.
Passo 2
Na tela de opções em INFO item Advanced podemos observar dois ajustes desmarcados: Move end of
completed parts after status date back to status date e Move start of remaining parts before status data forward
to status date.
Análise 1
Se a caixa de seleção Move end of completed parts after status
date back to status date é selecionada e se para uma atividade
programada após a data de status for informado algum
trabalho realizado sobre ela, o MSProject reprograma a parte
concluída de modo que a sua conclusão coincide com a data
de status, sendo que qualquer trabalho restante permanece
programado para começar no futuro. Junto a essa opção, se a
caixa de seleção Move start of remaining parts before status
data forward to status date estiver selecionada, é possível
também marcar a caixa de seleção And move start of
remaining parts back to status date. Com as duas caixas de
seleção marcadas, o MSProject 2013 reprograma toda a tarefa
em torno da data de status.
Análise 2
Se a caixa de seleção Move start of remaining parts before
status data forward to status date estiver selecionada e se uma
atividade está programada antes da data de status e houver
trabalho real a ela atribuído, o MSProject deixa a parte real da
tarefa como informado e reprograma o trabalho
restante a partir da data de status. Se em conjunto
a anterior a caixa de seleção And move end of
completed parts forward to status date está
marcada, é possível selecionar a data de
conclusão dessa parte concluída para coincidir
com a data de status.
Atenção: Estes dois ajustes devem ficar

DESMARCADOS.
Passo 3
Incluir no modo de controle escolhido,

normalmente baseado no screen Gantt Chart, as
linhas de data atual, Current Date, e a data de
status, Status Date. Desta forma, fica mais fácil a
visualização das atividades e de seu
agendamento. Isso é conseguido com um clique do botão direito na área em branco de Gantt. Acessando o
menu suspenso, escolhemos Gridlines, conforme já apresentado.
Passo 4
Reajustar o tipo das atividades de Fixed Duration para Fixed Units com a caixa de effort driven desmarcada.
Dessa maneira, será possível incluir datas de início, fim, trabalho realizado, durações reais e remanescentes
sem implicações errôneas nos cálculos internos do software. Esta recomendação é tão importante quanto
àquela dada por nós como referência para um bom início de trabalho e pela Microsoft em seus cursos de
preparação para certificação.
Atenção: Durante a etapa de planejamento, fixamos que todas as atividades quando criadas nasceriam como ‘FIXED
DURATION de forma automática e não dirigida ao esforço.
Atenção: Esse ajuste para FIXED UNITS não é definitivo e pode sofrer alterações dependendo das características
de controle aplicadas.
Gravar Template
Terminada a fase de planejamento, todos os modos de trabalho de planejamento e controle, identificados como
necessários, foram desenvolvidos. Neste momento é interessante considerar a criação ou atualização do modelo
(template) de arquivo utilizado pela organização. A utilização do template contendo todos os modos, tabelas, filtros,
grupos desenvolvidos traz agilidade ao desenvolvimento de novos projetos, e colabora com a padronização ou
procedimentalização das atividades da organização.
Para salvar um arquivo como template, basta utilizar o

recurso ‘Salvar como’ e selecionar o tipo de arquivo Project
Template. Uma tela será exibida para que o usuário possa
selecionar informações a serem ocultadas neste template.
8.2.2. Emissão de Planos de Trabalho
Com planejamento completo e finalizado, devemos criar meios de apoiar as equipes de execução fornecendo o
conjunto de atividades a que cada uma delas será destinada e cujo trabalho deve ser executado dentro do período
de tempo caracterizado pela medição do projeto. Essa atividade deve se repetir a cada ciclo ou em quantidade de
vezes documentada no plano de controle do projeto. Esse conjunto de informações, aqui caracterizado como Plano
de Trabalho, tem portanto o objetivo de apresentar as atividades em sequência lógica, para que se possa avaliar os
impactos em outros processos, e de forma gráfica, para facilitar a leitura pelos envolvidos.
Step 25 – Emissão do Plano de Trabalho
Para atender esta necessidade, desenvolveremos um modo de trabalho que utiliza a screen Network Diagram, já
apresentada, e que deve possuir o filtro que exiba somente as atividades a serem executadas durante o período de
medição vigente.
Como devemos sempre apresentar esse modo contemplando um período específico de trabalho, o filtro a seguir deve
ser montado e configurado para atender a diversas interações com o operador. O seu nome é derivado do modo
como atende, e a condição lógica é dada pela seguinte sequência:
Todas as atividades que ainda não estão concluídas (100%) e que devem começar até (menor ou igual a) a data alvo,
aqui chamada de Data Meta. Esse filtro foi ajustado no último item para utilizar a forma de passagem de parâmetros
pelo usuário sempre que for aplicado. Fazemos isso inserindo uma sentença entre aspas e terminada com ponto de
interrogação ( “uma sentença”?). O conteúdo da sentença será apresentado ao usuário sempre que aplicar o filtro, e
o valor escolhido será utilizado para comparação na lógica programada.
Ajustaremos a forma de apresentação das informações no nosso modo Step 25 para melhor atender a atual
necessidade, iniciando pelo conteúdo. Por se tratar de um modo de rede de predecessores e obedecendo a ideia de
não fornecer as informações tradicionais de início – término das atividades do projeto e da etapa em execução, temos
que ajustar os padrões do diagrama atendendo às seguintes diretrizes:
1 – Não fornecer datas à equipe
2 – Não fornecer a ideia de atividade mais ou menos importante
3 – Não fornecer prazos para a execução dos trabalhos, mas apresentar as condições de trabalho previamente
definidas e sua métrica de medição.
Com o uso do botão direito na área branca do diagrama, de modo semelhante ao já praticado anteriormente, devemos
editar as caixas com acesso ao estilo Box Styles.... Esse ajuste não atua somente na sua forma mas também em seu
conteúdo. Na opção More Templates ..., produzir um modelo conforme apresentado na figura a seguir com os
seguintes destaques:
As células de informação possuem o item show label in cell marcados e ajustados para apresentar seu significado;
As células são escolhidas para resgate de informações do trabalho realizado pelas turmas de execução.
Esses elementos devem ter seu tamanho

ajustados para fonte valor 12, de modo a
permitir o preenchimento de dados pelas
equipes de execução. O More Template ...
deve receber o mesmo nome do modo que o
contém, com os campos apresentados com
as suas respectivas legendas de identificação
por conta dos resultados que desejamos para
serem apresentados às equipes.
Atenção: No lugar dos campos desejados,

foi incluído um campo texto livre e
SEM CONTEÚDO de modo a
permitir que o resultado final
apresente espaços em branco para
preenchimento das informações
reais, SEM previamente informar
seu valor calculado. O único campo mantido foi o Resource Names, de forma a permitir a conferência dos
recursos disponíveis e utilizados na atividade.
Existe ainda um detalhe que nos ajuda na apresentação de conteúdos longos, como podem ser os nomes, que é a
marcação da limit cell text to: . No campo name, selecionamos 2 linhas e no campo resource names, 3 linhas.
Ainda em Box Styles, alteramos a cor de fundo das caixas das atividades e marcos para branco, para facilitar a
impressão dos planos de trabalho, que provavelmente se dará em preto e branco.
Aplicando este template às atividades do projeto, o resultado parcial da rede apresentada dará, se impresso:
Atenção: para apresentar as anotações das atividades dentro dessa proposta de plano de trabalho é necessário
ajustar em Page setup, na opção de Print preview, na aba View, a caixa de marcação Print Notes. Mais
informações no próximo capítulo:
Gerenciamento da Comunicação.
Para finalizar nossa configuração gráfica deste

modo, temos na tela Layout :
1 – ajuste de setas de relacionamento para

straight;
2 – ajuste de cor de setas e relacionamento para

atender a cor de seu elemento gráfico de origem;
Atenção: Os diagramas a seguir mostram as duas formas de apresentar as ligações entre as atividades e seus
marcos de apoio e controle. Com as setas diretas e radiais e as setas em formação retangular (ângulos
retos e linhas coincidentes). Para efeito de melhor compreensão das relações apontamos a primeira como
indicada.
Informações
Podemos utilizar o filtro desenvolvido para este modo

em qualquer outro que seja do tipo Task, para
visualização das atividades relacionadas ao plano de
trabalho em vigência. Ainda, se o aplicarmos como
filtro de destaque (Highlight), não omitiremos as
informações anteriores e posteriores a essas
atividades. Vamos exemplificar com o modo Step 09
– diagrama de Rede – Visão Org.
Aplicar o filtro sobre a rede de atividades permite verificar no modo gráfico o quanto está sendo previsto
realizar no período. Isso é útil para contemplar o trabalho a realizar e total, quando o filtro é aplicado a
partir da aba View, grupo Data, item filter, pelo modo Highlight.
A formatação visual dos objetos tocados pelo filtro

pode ser realizada a partir da opção set highlight
filter style, encontrada para cada item do Box Styles.
8.2.3. Métodos de Monitoramento e

Controle.
A ferramenta apresenta várias maneiras de permitir a introdução das informações para o acompanhamento da
execução das atividades de um projeto, nos oferecendo recursos automatizados através de botões e telas pré-
construídas.
Nesta seção, apresentaremos estas diversas opções e introduziremos três metodologias de controle que utilizam
folhas de medição, que serão criadas em modos de trabalho especialmente criados para este fim.
8.2.3.1. Opções da Ferramenta
A partir da aba Task, através dos grupos Schedule e Tasks, temos o antigo grupo definido pelo item de menu Tracking
nas versões anteriores ao MSProject 2010.
O primeiro ícone Mark on track e Update tasks atua diretamente sobre a atividade ou atividades marcadas.
Mark on track – atualiza a atividade até a data de status, como se fosse cumprida exatamente como planejada.
A atualização dos trabalhos dessa forma raramente corresponde à realidade no nosso dia a dia, e por isso não
recomendamos sua utilização. Caso todas as atividades que selecionadas forem submetidas a esse comando, trarão
pelo sistema a ideia de que:
▪ O trabalho previsto de ser realizado foi realizado;
▪ A data de início prevista foi mantida;
▪ A sua data de conclusão prevista foi mantida, se essa já foi atingida;
▪ Sua produção em Hh (esforço de Homem-hora) foi exatamente a mesma programada;
▪ Os custos reais incorridos foram os mesmos; e

▪ Todos os recursos materiais e financeiros foram utilizados.
Update tasks - Abre uma janela permitindo o

preenchimento de dados específicos e selecionados pela
MS.
As informações gerais do controle da atividade ou pacote
de trabalho. A opção escolhida apresenta um formulário a
ser preenchido com diversas informações. Essa seria a
forma mais completa proposta pela Microsoft. Nele é
possível incluir as informações de início e término reais; o
prazo remanescente; e o percentual do andamento do
tempo transcorrido. As justificativas de alterações e desvios podem ser registradas no campo notes. Características
exclusivas de acertos de andamento físico do projeto.
Em Move, a opção (move) Incomplete Parts to Status Date promove o

replanejamento das atividades marcadas que não foram realizadas até o
momento de status, para que seja iniciada a partir da data de medição (Data de Status). Em caso da atividade ter
sido iniciada, a sua parte não concluída é reagendada para ser programada após a Status Date. Todas as atividades
selecionadas que forem submetidas a esse comando trarão pelo sistema a ideia de que:
▪ O trabalho restante e faltante a ser realizado será imediatamente realizado após a data de status;
▪ Eventualmente a sua duração original prevista será revista e aumentada;
▪ Sua produção em Hh (esforço de Homem-hora) será alterada;
▪ Os custos reais incorridos serão alterados; e
▪ Todos os recursos materiais e financeiros serão alterados.
Atenção: A reprogramação de trabalhos não realizados até a data de medição de andamento de serviços raramente
acontece para o dia seguinte à medição. Recomendamos não utilizá-la de forma isolada para a
reprogramação das atividades.
No grupo Schedule, encontramos os ícones reproduzidos ao lado. Essa opção atribui

um percentual de conclusão em 0, 25, 50, 75 e 100% às tarefas selecionadas. Para
efeito de medição de serviços e seu andamento, uma das técnicas de informação de
avanço de produção se dá por steps ou níveis pré-definidos. Essa técnica de avanço, quando utilizada isoladamente
no controle do projeto, traz as seguintes premissas:
▪ O trabalho previsto de ser realizado foi realizado na proporção definida;
▪ A data de início prevista foi mantida;
▪ A sua data de conclusão prevista – se essa foi atingida;
▪ Sua produção em Hh (esforço de Homem-hora) foi exatamente aquela definida pelo avanço 16;
▪ Os custos reais incorridos foram os definidos pelo avanço escolhido; e
▪ Todos os recursos materiais e financeiros foram utilizados conforme o step escolhido.
O comportamento dos três últimos itens depende da marcação de um item em File, Option, Schedule
Atenção: Pelas limitações apresentadas e posteriormente comentadas desse formulário NÃO recomendamos sua
utilização.
16
O comportamento deste e dos próximos dois itens depende da marcação do item Updating Task status upates Resource
Status, em File, Options, Schedule.
Outro recurso para a atualização do projeto fornecido pela MS é através da aba Project grupo Status o item Update
Project.
Encontramos nesta tela as opções Atualizar o andamento proporcional ao tempo (set 0% - 100% complete) e ou tudo
ou nada (set 0% or 100% complete only).
Set 0% - 100% complete - Seleciona a opção de atualização de andamento dentro de uma faixa de 0 a 100%. As
atividades que ainda não iniciaram são atualizadas como 0, aquelas que foram concluídas recebem 100% e aquelas
que estão em andamento recebem um valor calculado pelo MSProject.
Set 0% or 100% complete only – Seleciona as atividades que estão agendadas para terminar até a data de complete
through em 100% concluídas. O percentual das atividades que não terminam dentro da data de complete through não
se altera.
A seguir temos a opção Reagendar os trabalhos não concluídos a partir de... uma determinada data. É possível, por
exemplo, ter uma atividade que deveria ter seu andamento da ordem de 25% marcada apenas com 10% de
andamento. Isso faz com que o restante seja reagendado para após a data de medição (data de status), aumentando
o seu tempo de duração e impactando nas demais que a sucedem.
Atenção: Pelas condições apresentadas de uso geral não específico e

ajustadas a outros parâmetros NÃO recomendamos sua
utilização.
Atenção: Existem ainda as opções de mover uma atividade em

períodos fixos para frente (Foward) ou para trás (Back). NÃO
recomendamos sua utilização.
8.2.3.2. Folhas de Medição
Como citado para emissão do plano de trabalho das equipes, apenas com planejamento completo e finalizado
podemos apoiar as equipes de execução. As folhas de medição tem o objetivo de apresentar a lista na forma de
planilha a completar das atividades no período de avaliação. Para desenvolver as folhas impressas em papel que
serão utilizadas pelas equipes de execução para preenchimento das informações desejadas, desenvolveremos
modos personalizados na ferramenta para este fim específico.
Trabalharemos em três níveis de detalhes, definidos pelos métodos apresentados nas próximas seções, mas antes
de os apresentarmos, se faz necessário o entendimento dos campos utilizados e da dinâmica de atualização das
informações na ferramenta.
Campos utilizados nas folhas de medição:
Datas e Prazos
Data de Início Real (Actual Start)

Data de Término Real (Actual Finish)
% Completado de cada atividade ou pacote de trabalho (% Complete)
Duração Remanescente (Remain Duration)
Duração Real (ActualDuration)
Estes campos são inter-relacionados para representar o real período de dedicação dos envolvidos às atividades
do projeto.
Importante notar que o campo % Complete, por algumas equipes utilizado como única fonte de controle do projeto,
é um campo relacionado ao gerenciamento do tempo. É a representação percentual do valor Actual Duration
Incluindo o valor de término real, a ferramenta altera o % completado para 100% e duração restante para 0.
Inserindo Início real, duração real inferior à duração agendada, a ferramenta calcula a duração restante, valor que
pode ser alterado para representar a reprogramação da atividade ampliando ou reduzindo sua duração real.
Recomendamos que o campos % Complete não seja diretamente informado pela equipe de execução, e sim que
se dê preferência aos campos Início real, Duração Real e duração Restante. Caso já alocadas as informações
desses campos simultaneamente, a equipe de execução deve receber treinamento para compreender o
funcionamento dos cáclulos envolvidos. A não realização desses cuidados pode gerar informações incorretas. Por
exemplo, podemos imaginar uma atividade prevista para começar dia 1, 10 dias de linha de base de duração, com
duração real estimada para o período de 5 dias.
Suponhamos que a equipe de execução tenha passado as informações:

Início real: conforme agendado
% Complete: 40%
Actual Duration: 4 dias
Remaining duration: 10
Inserimos a informação 40% para % Complete e obtemos:
Inserindo a informação para Remaining duration, obtemos:
Podemos perceber que o valor do % Complete se ajusta para a nova realidade do valor de duração da atividade,
e torna-se impossível inserir na ferramenta os valores obtidos na folha de medição, o que pode gerar falhas de
registro, documentação e rastreabilidade de responsabilidade.
Aqui devemos relembrar que o campo duration não deve ser utilizado, durante a fase de execução, para
representar a duração planejada. O valor deste campo é o resultado da soma da duração restante com a duração
real, o que durante a fase de planejamento, quando não tínhamos nenhuma duração real, representava somente
duração restante. Agora, com a alteração de seus valores, teremos alteração no campo duration. Para uma
referência adequada devemos utilizar o campo Baseline duration.
Por padrão, os campos desta lista não devem ser utilizados para representar a simples passagem do tempo, caso
não haja dedicação à atividade. Entretanto, devido à dificuldade de se trabalhar com splits na ferramenta, muitas
vezes a equipe de controle opta por esta simplificação, e mesmo que existam períodos entre o início real e o
término real com inatividade, este é considerado no valor de duração real
% Físico completado (% Physical Complete)
Não está relacionado ao cálculo dos valores reais de duração, início ou término da atividade. Seu uso padrão se
faz para representar o valor percentual de conclusão da atividade baseado na produção de resultados. Assim,
podemos ter 50% da duração e uma atividade transcorrida (% Complete) e 60% do resultado planejado produzido,
por exemplo, 60% dos m2 de paredes construídas.
Através de File, Options, Advanced podemos selecionar este campo em detrimento do campo % Complete para
cálculo do método de Valor agregado. Mais informações na seção 8.2.4.
Produção
% do Trabalho Completado (% Work)

Trabalho Real (Actual Work)
Trabalho Remanescente (Remaining Work)
Este conjunto de campos estão inter-relacionados, sendo o % do trabalho completado a representação percentual
do valor do trabalho real. Novamente podemos utilizar o campo * remanescente com base nas informações
passadas pelas equipes de execução, para programar as projeções das medições dos volumes que serão
medidos nos próximos períodos. Assim, pode-se detectar que serão necessárias mais horas de trabalho que o
previsto, e o valor de trabalho remanescente deve ser ajustado para representar esta detecção.
Aqui devemos relembrar que o campo work não deve ser utilizado, durante a fase de execução, para representar
o trabalho planejado. O valor deste campo é o resultado da soma do trabalho restante com o trabalho real, o que
durante a fase de planejamento, quando não tínhamos nenhum trabalho real, representava somente o trabalho
restante. Agora, com a alteração de seus valores, teremos alteração no campo work. Para uma referência
adequada devemos utilizar o campo Baseline work.
Trabalho Extra Real (Actual Overtime Work)

Trabalho Extra Remanescente (Remaining Overtime Work)
Temos na ferramenta a diferenciação do valor de trabalho em hora extra do valor padrão, sendo possível controlar
seus valores reais.
Custo
Custo Real (Actual Cost)

Custo Remanescente (Remaining Cost)
Estes campos não diferenciam a fonte das despesas, somente controlando o custo total do projeto. Novamente,
devemos relembrar que o campo cost não deve ser utilizado, durante a fase de execução, para representar o
custo planejado. O valor deste campo é o resultado da soma do custo restante com o custo real, o que durante a
fase de planejamento, quando não tínhamos nenhum custo real, representava somente custo restante. Agora,
com a alteração de seus valores, teremos alteração no campo cost. Para uma referência adequada devemos
utilizar o campo Baseline cost.
Custo Extra Real (Actual Overtime Cost)

Custo Extra Remanescente (Remaining Overtime Cost)
Como podemos controlar o trabalho real exercido em característica de hora extra, podemos também controlar o
custo real relacionado a esta atividade.
O campo Status Indicator é preferível ao Indicator nas tabelas dos modos de controle por apresentar o
status da atividade:
Se a atividade está programada e ainda não iniciou: sem ícone;
Se está atrasada: ícone do Relógio com o ponto de exclamação em vermelho;
Se está concluída: ícone se apresenta com o um V (check);
Se a atividade está agendada dentro do programado:ícone do Relógio com o V;.
Ajustes gráficos para folhas de medição
Sugerimos que somente modos com screen Task sheet ou Task Usage sejam criados para apoio à emissão de folhas
de medição. Dessa forma, temos que apresentar as configurações visuais para os elementos de tabela (esquerda) e
os elementos Details (direita).
Tabelas:
Todas as colunas de dados devem possuir tamanho

de fonte 12. Isso pode ser ajustado pela aba Task
Sheet tools ou Task Usage Tools (dependendo do
modo utilizado), grupo Format, item Text Styles ....
Todas as colunas de dados a serem preenchidas pela equipe devem

ter suas fontes ajustadas para cor Branca e fundo Branco. O modo, por
padrão original do aplicativo, se apresenta com os campos escolhidos
na tabela anterior preenchidos com os valores padrão. Isso muitas
vezes traz informações do tipo NA ou zero. Daí, alguns ajustes são
necessários.
Details:
Deve ser ajustada também de modo a

permitir que os parâmetros inseridos
sejam informados. Nesse caso, também o
corpo das letras deve ser de tamanho 12,
tendo os campos ajustados nas suas
cores para contraste e facilitação de preenchimento.
O período de anotações deve ser ajustado conforme os padrões estabelecidos para o controle.
Para cada folha de medição criada
Importante respeitar a mesma regra de nomeação de modos adotada pela organização;
Deve-se criar um filtro que siga o padrão de seleção de elementos do filtro Step 25 – Emissão do Plano de
Trabalho. Pode-se copiar este filtro e renomear a cópia criada;
É necessário construir um modo de trabalho com nome equivalente, contendo os mesmos campos para que
as informações sejam inseridas na ferramenta, sem o conteúdo de suas colunas configurado para cor branca.
8.2.3.3. Controle T
Apenas Prazos e andamento físico do projeto
Descrição: Procedimento de trabalho que após o planejamento sem a alocação de recursos do tipo material, work
ou cost permite acompanhar a evolução no tempo das datas de início e término das atividades, assim como os prazos
de conclusão das atividades em andamento e os impactos que poderão ser sentidos no projeto.
Aplicação:
Esse modo é preterido quando não é necessária ou possível a alocação de recursos. Screen utilizado Task Sheet.
Fundamentos:
1 – Informação de apenas 6 parâmetros:
✓ Data de Início Real (Actual start)

✓ Data de Término Real (Actual Finish)
✓ % Completada de cada atividade ou pacote de trabalho (% Complete)
✓ Duração Remanescente (Remaining Duration)
✓ Percentual Físico CONCLUÍDO (Phisical % Complete)
✓ Duração Real (Actual duration)
2 – Ajustes na ferramenta:
✓ Confirmar que a caixa de marcação Updating

tasks status updates resource status está
marcada para essa opção em File, Options, Schedule.
✓ Confirmar que as atividades do tipo fixed Duration foram convertidas em Fixed Units.
✓ Criar um modo com screen Task Sheet, tabela com os campos listados acima, e filtro de seleção do plano
de trabalho.
Step 26 – Folha de Medição – Controle T

3 – Perguntas a serem feitas à equipe de Execução:
1 – Quando a atividade foi iniciada realmente?

2 – Quando a atividade acabou?
3 – Qual percentual da atividade foi concluído?
4 – Quanto falta para a conclusão desta atividade?
Notas:
1 - Os campos são calculados entre si, de forma que quando informamos o percentual concluído até o
momento da medição estamos mantendo uma duração remanescente proporcional ao percentual restante.
2 – Quando informamos que a atividade está 100% concluída e informamos a data de conclusão real, estamos
recalculando a duração real se as datas reais não forem aquelas previamente agendadas.
3 - Nesse modo de medição estamos focando o andamento em função apenas do tempo decorrido, ou seja,
o cronograma é atualizado em função de datas, e não de esforço.
8.2.3.4. Controle TWC

Os Prazos e andamento físico do projeto, incluindo o trabalho em HH ou consumo de materiais e os
custos.
Descrição: Procedimento de trabalho que após o planejamento com a alocação de recursos do tipo material, work
de conclusão das atividades em andamento e os impactos que poderão ser sentidos no projeto. Nesse modo, o
controle de Prazos e Datas, Recursos Humanos e Materiais, assim como Custos, Despesas e Tributos realizados, é
possível e, por isso, permite uma projeção de resultados de boa qualidade.
Aplicação:
Este modo é valioso quando temos no projeto a alocação de material, mão de obra ou custo nas atividades, de forma
geral sem a preocupação com a informação de uso em dados períodos específicos de tempo. Screen utilizada Task
Sheet.
Fundamentos:
1 – Informação de 15 parâmetros:
✓ Data de Início Real (Actual Start)

✓ Data de Término Real (Actual Finish)
✓ % Completada de cada atividade ou pacote de trabalho (% Complete)
✓ Duração Remanescente (Remain Duration)
✓ Percentual Físico CONCLUÍDO (% Physical Complete)
✓ Duração Real (ActualDuration)
✓ Percentual do Trabalho Completado (% Work Complete)
✓ Trabalho Real (Actual Work)
✓ Trabalho Remanescente (Remaining Work)
✓ Trabalho Extra Real (Actual Overtime Work)
✓ Trabalho Extra Remanescente (Remaining Overtime Work)
✓ Custo Real (Actual Cost)
✓ Custo Remanescente (Remaining Cost)
✓ Custo Extra Real (Actual Overtime Cost)
✓ Custo Extra Remanescente (Remaining Overtime Cost)
2 – Ajustes na ferramenta:
✓ Confirmar que a caixa de marcação Updating

tasks status updates resource status está
desmarcada para essa opção em TOOLS-OPTIONS.
✓ Confirmar que as atividades do tipo Fixed Duration foram convertidas para Fixed Units.
✓ Criar um modo com screen Task Sheet, tabela com os campos listados acima, e filtro de seleção do plano
de trabalho.
Step 26 – Folha de Medição – Controle TWC

3 - Perguntas a serem feitas à equipe de Execução:

3 – Qual o percentual concluído?
4 – Quanto tempo falta para a conclusão desta atividade?
5 – Qual o percentual físico de trabalho produzido?
5 – Quanto do Trabalho foi realmente realizado na atividade como um todo (total de Hh)?
6 – Quanto de Trabalho falta a ser concluído como um todo (total de Hh)?
7 – Qual percentual de trabalho foi executado ou concluído?
8 – Quanto do Trabalho Extra foi realmente realizado na atividade como um todo (total de Hh)?
9 – Quanto de Trabalho Extra falta a ser concluído como um todo (total de Hh)?
10 – Quanto de materiais foi agregado a atividade?
11 – Quanto de materiais falta a ser agregado ainda na atividade?
10 – Quanto foi realmente gasto na realização dessa atividade como um todo (total de Valores Financeiros) 17?
11 – Quanto falta a ser gasto para a conclusão da atividade como um todo (total de Valores Financeiros)?
12– Quanto foi realmente gasto na realização do trabalho extra desta atividade como um todo (total de Valores
Financeiros)?
13 – Quanto Falta a ser gasto para a conclusão do trabalho extra da atividade como um todo (total de Valores
Financeiros)?
Notas:
1 - Os campos são calculados entre si, de forma que, quando informamos um dos valores, provavelmente
estaremos validando outro.
2 – Nesse modo estamos medindo não só o andamento dentro dos prazos do projeto como também os
esforços em Hh e os valores financeiros aplicados a eles separadamente.
8.2.3.5. Controle TWC - Timesheet

Os Prazos e andamento físico do projeto, incluindo o trabalho em HH ou consumo de materiais e os
custos e dados dos recursos e materiais.
Descrição: Procedimento de trabalho que após o planejamento com a alocação de recursos do tipo material, work
de conclusão das atividades em andamento e os impactos que poderão ser sentidos no projeto. Nesse modo, o
controle de Prazos e Datas, Recursos Humanos e Materiais, assim como Custos, Despesas e Tributos realizados, é
possível, inclusive, dentro de períodos de tempo específicos, e, por isso. permite uma projeção de resultados de alto
nível, de medir item a item em produtividade e rendimento.
Aplicação:
Este modo é valioso quando temos no projeto a alocação de material, mão de obra ou custo nas atividades de forma
geral, com a preocupação com a informação de uso em dados períodos específicos de tempo. Screen utilizada Task
Usage.
Fundamentos:
1 – Informação de 15 parâmetros gerais:
17
Valores oriundos do sistema contábil da organização ou da empresa.
✓ Data de Início Real (Actual Start)

✓ Data de Término Real (Actual Finish) e
✓ % Completado de cada atividade ou pacote de trabalho (% Complete)
✓ Duração Remanescente (Remain Duration)
✓ Percentual Físico CONCLUÍDO (% Physical Complete)
✓ Duração Real (ActualDuration)
✓ Percentual do Trabalho Completado (% Work)
✓ Trabalho Real (Actual Work)
✓ Trabalho Remanescente (Remaining Work)
✓ Trabalho Extra Real (Actual Overtime Work)
✓ Trabalho Extra Remanescente (Remaining Overtime Work)
✓ Custo Real (Actual Cost)
✓ Custo Remanescente (Remaining Cost)
✓ Custo Extra Real (Actual Overtime Cost)
✓ Custo Extra Remanescente (Remaining Overtime Cost)
2 – Condições na Ferramenta
✓ Confirmar se a caixa de marcação Updating tasks status
updates resource status está também desmarcada para essa
opção em TOOLS-OPTIONS.
✓ Confirmar que as atividades do tipo Fixed Duration foram convertidas para Fixed Units.
✓ Criar um modo com screen Task Usage, tabela com os campos listados acima e filtro de seleção do plano
de trabalho.
Step 26 – Folha de Medição – Controle TWC-Timesheet
As dimensões de cada coluna devem ser ajustadas para viabilizar o preenchimento das equipes de execução. Aqui
as configuramos como estreitas para que fosse possível apresentar todas.
Configurar a área de dados da direita do modo

construído através do uso dos itens de formatação
Timeline e Detail Styles. No primeiro caso temos a
opção de colocar a camada superior em meses e a
camada inferior em semanas, de modo a entrar com
o trabalho realizado no período semanal (nosso
período de medição foi considerado semanal). No
segundo caso, devemos escolher os campos a
serem apresentados para preenchimento. Com a
formatação adequada dos campos, pode ser obtida
a representação em cores, como visto a seguir.
3 – Perguntas a serem feitas à equipe de Execução através de um sistema de informação informatizado:

3 – Quantos por cento da atividade foram concluídos (somente para atividade)?
4 – Quanto falta para a conclusão dessa atividade (somente para atividade)?
5 – Quanto do trabalho foi realmente realizado na atividade por recurso alocado (individual de hh)?
6 – Quanto de trabalho falta a ser concluído por recurso alocado (individual de hh)?
7 – Qual o percentual de trabalho que foi executado ou concluído por recurso alocado (individual de hh)?
8 – Quanto do trabalho extra foi realmente realizado na atividade por recurso alocado (individual de hh)?
9 – Quanto de trabalho extra falta a ser concluído por recurso alocado (individual de hh)?
10 – Quanto foi realmente gasto na realização desta atividade como um todo (total de Valores Financeiros)?
11 – Quanto falta ser gasto para a conclusão da atividade como um todo (total de Valores Financeiros)?
12– Quanto foi realmente gasto na realização do trabalho extra desta atividade como um todo (total de Valores
Financeiros)?
13 – Quanto falta a ser gasto para a conclusão do trabalho extra da atividade como um todo (total de Valores
Financeiros)?
Nota:
1 – Alguns campos são calculados entre si, de forma que quando informamos um dos valores, provavelmente
estaremos validando outro.
2 – Nesse modo, estamos medindo não só o andamento dentro dos prazos do projeto, como também os
esforços em hh, e os valores financeiros aplicados a eles separadamente, período a período.
8.2.4. Indicadores de Desempenho
Uma vez realizada cada interação de controle do projeto, novas informações são inseridas no modelo criado pelo MS
Project, que nos trazem diversas informações. Saber trabalhar estas informações para extrair conclusões é de suma
importância para o apoio à tomada de decisões da equipe de gerenciamento do projeto e apoio à comunicação com
os envolvidos.
O desenvolvimento de indicadores customizados que atendam às necessidades específicas de cada projeto é

altamente recomendável. Estes podem utilizar, por exemplo, informações como volume produzido, horas trabalhadas,
volume estimado e horas de trabalho estimadas para informar a produtividade das equipes, ser suporte à tomada de
decisões, fazer projeções de término para as atividades, etc.
A seguir, apresentamos um modo de trabalho que reúne diversos campos encontrados por padrão na ferramenta,
que dão suporte à análise de valor agregado, e podem ainda servir para construção dos nossos indicadores
particulares.
8.2.4.1. Método do Valor Agregado no MS Project 2013
Para aplicar os conceitos de valor agregado na ferramenta, criaremos um modo de trabalho composto de nome Step
27 – Indicadores de Desempenho – EVM. Ambos os modos superior e inferior trarão a screen Task sheet, com o
objetivo de maximizarmos a possibilidade de apresentação de campos em forma de colunas, já que estes existem
em grande quantidade.
Ao painel superior daremos o nome Step 27 - Indicadores de Desempenho - EVM-SPI, por conta dos indicadores
ligados aos volumes produzidos contra os volumes previstos. Alguns campos numéricos livres foram utilizados para
apoio à informação, uma vez que a ferramenta não dispõe de todos os elementos necessários para a nossa análise.
Esses campos serão explicados mais adiante.
Campos escolhidos para o painel superior:
ID, Name – Dispensam apresentação.
BCWP – Budget Cost of Work Performed, ou seja, o quanto foi agregado ao projeto, convertido em valor
moeda.
BCWS – Budget Cost of Work Scheduled, ou seja, o que foi previsto ou agendado a realizar dentro do
período compreendido do início até a medição dos trabalhos. Lembramos que para chegar nesta quantidade,
a ferramenta utiliza os valores da linha de base e da data de medição (Status Date).
SV – Schedule Variance, que significa a diferença, em moeda, daquilo que efetivamente foi realizado ou
agregado, contra o que deveria estar pronto. (SV = BCWP – BCWS)
SV% – Schedule Variance expresso em % do previsto, que significa o percentual da razão entre a diferença,
em moeda, daquilo que efetivamente foi realizado ou agregado, contra o que deveria estar pronto; e aquilo
que deveria ter sido realizado até o período de medição. (SV% = (SV / BCWS) * 100)
SPI – Schedule Performance Índex, que significa o indicador de desempenho de prazos do projeto.
Representando a razão entre o que foi efetivamente realizado ou agregado contra o que deveria estar pronto.
(BCWP/BCWS)
EAC18 - Schedule – Estimate At Completion, que significa a estimativa do valor que o projeto assume como
custo por conta do seu desempenho de prazo verificado até o momento. (ACWP + (Baseline cost - BCWP) /
SPI)
TSPI - indicador que mostra uma relação entre o trabalho ainda a ser feito e o restante de tempo na unidade
MOEDA para uma data de status. A sua melhor expressão é: ((BAC - BCWP) / (BAC - BCWS))
18A Microsoft definiu o EAC como uma forma rígida e dependente de forma exclusiva do desempenho de custo (CPI) do projeto,
assim, o resultado do campo EAC da Microsoft é dado pela formula: EAC = ACWP + (Baseline cost - BCWP) / CPI, por isso
colocamos aqui o termo em função do indicador de tempo.
Ao painel inferior daremos o nome Step 27 - Indicadores de Desempenho - EVM-CPI, por conta dos indicadores
ligados aos volumes produzidos contra o volume proporcional aos efetivamente pagos, ou os gastos vinculados a
eles.
Campos escolhidos do painel inferior:
BCWP – Budget Cost of Work Performed, ou seja, o quanto foi agregado ao projeto, convertido em valor
moeda.
ACWP – Actual Cost of Work Performed, ou seja, o que foi realmente despendido ou gasto para aquilo que
foi agendado dentro do período do projeto.
CV – Cost Variance, que significa a diferença, em moeda, daquilo que efetivamente foi realizado ou agregado
contra o realmente gasto ou despendido até a data de medição. (CV = BCWP – ACWP)
CV% - Cost Variance expresso em % do previsto, que significa o percentual da razão entre a diferença, em
moeda, daquilo que efetivamente foi realizado ou agregado, contra o que deveria estar pronto; e aquilo que
foi realizado até o período de medição. (CV% = (CV / BCWP) * 100)
CPI – Cost Performance Índex, que significa o indicador de desempenho dos custos incorridos do projeto.
Representando a razão entre o que foi efetivamente realizado ou agregado, contra o quanto foi efetivamente
despendido no projeto. (BCWP/BCWS)
Baseline Cost ou BAC – Custo acumulado total do projeto.
EAC19 - Cost – Estimate At Completion, que significa a estimativa do valor que o projeto assume como custo,
por conta do seu desempenho de custo verificado até o momento. (ACWP + (Baseline cost - BCWP) / CPI)
EAC - SC 20 - Novo valor de custo estimado para as condições do desempenho até o momento da data de
status, agora em função do indicador de desempenho do TEMPO (SPI) e CUSTO (CPI), sendo ainda aqui de
forma totalmente aleatória pesos diferenciados para os indicadores. (ACWP + (Baseline cost - BCWP) / (0,8
x CPI + 0,2 x SPI))
Recomendamos a utilização da fórmula IIf([CPI]=0;0;([ACWP]+[Baseline Cost]-[BCWP])/(0,8*[CPI]+0,2*[SPI]))
VAC - Variance At Completion – A diferença entre o custo previsto total e a estimativa para completar.
(Budgeted At Completion (baseline cost) - Estimated At Completion)
19 Colocamos aqui nesse campo uma dependência do desempenho do indicador de custo exclusivamente.
20
Colocamos aqui o termo em função dos diversos indicadores. Nesse campo, colocamos uma dependência de forma ponderada
(80-20) e compartilhada do desempenho de tempo (SPI) e custo (CPI) do projeto, com fórmula específica que forneça o resultado
desejado. EAC = ACWP + (Baseline cost - BCWP) / (0,8*CPI + 0,2*SPI)
Nesse caso, o modo desenvolvido deve trazer em si todos os indicadores apresentados em dois painéis conjugados.
A figura a seguir tem a pretensão de ilustrar esses campos.
Exemplo do modo Step 27, criado com informações aleatórias de medição:
Atenção: Na versão liberada por ocasião desta publicação o campo BCWS NÃO representa o valor
real do custo acumulado do projeto como a sua linha de base, pois ele NÃO totaliza os recursos tipo
COST. Dessa forma, ficam comprometidos os seguintes indicadores e campos: ACWP; BCWS; EAC
- SC ; VAC ; SV%; SPI; EAC - Schedule ; e TSPI . Isso inviabiliza o uso dessa ferramenta dentro da
metodologia de controle de acompanhamento pelo EVM.
8.2.4.2. Linhas de Progresso

Se for interessante para a equipe de controle do projeto, é possível representar o

andamento através das chamadas “linhas de progresso”. A partir de uma data de
referência, o MS Project traça uma linha unindo os elementos gráficos representantes das
atividades em andamento, com “dentes” voltados para a esquerda - atividades em atraso
- e para a direita - atividades que estiverem adiantadas -, mostrando assim o estado de
cada atividade. Essas linhas são formadas a partir dos percentuais de andamento
fornecidos.
É importante registrar que o deslocamento para a esquerda representa atraso de

produção e o deslocamento para a direita representa um adiantamento contra a produção
prevista. Isso é conseguido quando
informamos as datas de início real e o
percentual do trabalho realizado.
Esse recurso é acessado através da área

gráfica dos modos que utilizam a screen
Gant Chart. Clicando com o botão direito,
uma das opções apresentadas mostra-se
como Progress Lines.
Na primeira Guia, temos quatro grupos de

ajustes de Datas e Intervalos:
1. Opção para sempre mostrar linha de
progresso para a data de status do
projeto e data atual do projeto.
2. Opção para mostrar as linhas de progresso em intervalos regulares e recorrentes. Com vários ajustes.
3. Opção para mostrar o progresso em
data(s) distinta(s).
4. Opção para referenciar as linhas de
progresso em função do planejamento
atual ou da base de referência
(baseline)
Na segunda Guia, temos três grupos para

ajustes gráficos de estilo de linha a ser
desenhada.
1. Opção de tipos de linhas de progresso.
2. Opção de estilos das linhas e suas
cores de representação
3. Opção para incluir uma caixa contendo
a data de referência da linha de
progresso.
Atenção: Chamamos a atenção que as linhas de base NOVAS só devem ser gravadas, assim como a linha de base
em uso só deve ser alterada, mediante a uma aprovação formal de escopo. A atualização de datas de
início e término das atividades, mudanças de calendários ou número de recursos não são justificativas
para “salvar” diversas linhas de base.
8.2.5. Critérios de Qualidade

Seguindo o modelo apresentado no capítulo 7, Desenvolvimento do Cronograma, apresentamos critérios de qualidade

para a execução do monitoramento e controle do projeto com a ferramenta MS Project 2013.
CQ-MC 1. A ferramenta foi configurada para a etapa de execução do projeto;

CQ-MC 2. Toda referência aos valores de planejamento (Duração, Custo e Trabalho) são realizadas com o campo Baseline
correspondente;
CQ-MC 3. Existem parâmetros de controle definidos e documentados, para dar suporte ao controle e registro do trabalho do
projeto;
CQ-MC 4. Existem modos desenvolvidos para impressão e emissão para equipes de execução preencherem com informações dos
parâmetros de controle;
CQ-MC 5. Existem modos específicos para comunicação e recebimento dos valores reais de trabalho produzido.
9. Capítulo 09: Gerenciamento da Comunicação
9.1. Conceitos de Gerenciamento da Comunicação

A Tradição
Diversas abordagens são feitas para o gerenciamento das comunicações do projeto e, por tradição,
podemos dizer que sempre começam com os elementos da comunicação: emissor – mensagem – meio
– canal – receptor e outras variações. Isso está certo, é imprescindível o entendimento dos conceitos
para praticá-los e abordá-los em seguida. Posteriormente, envereda-se para as técnicas de
comunicação, em particular aquelas que são mais afetas a rotinas de apoio à realização de
empreendimento finitos – ou seja, projetos. Isso está correto também, pois de nada adianta ter uma
abordagem geral sem a aplicação no tema de estudo – gerenciamento de projetos. Vamos manter essa
tradição e vamos apresentar aqui, de forma sumária, um trabalho específico de uso da ferramenta de
apoio a projetos, mas ao final vamos fazer uma abordagem no sentido inverso, o que deve trazer mais
significado e importância ao trabalho com a ferramenta, a responsabilidade de seu uso e a necessidade
de garantir a “comunicação”.
Os elementos da comunicação
Diversas abordagens são feitas para o gerenciamento das comunicações do projeto e, por tradição,
podemos dizer que sempre começam com os elementos da comunicação: emissor – mensagem – meio
– canal – receptor e outras variações. A academia já definiu, e repetimos aqui que a forma de
comunicação está dividida em:
▪ Emissor – aquele que emite a mensagem – no projeto, o responsável pela PRODUÇÃO e
coleta das informações;
▪ Receptor – aquele que DEMANDOU a mensagem ou informação.
▪ Mensagem – o conjunto de informações DEMANDADAS que deve ser produzida.
▪ Linguagem – a forma como a informação será EXPRESSA e se concretizará. O receptor deve
poder decodificar a mensagem.
▪ Canal de Comunicação – o meio que será utilizado para transmitir a mensagem – podemos
dizer que a ferramenta fará a diferença aqui.
▪ Ruído – qualquer PERTURBAÇÃO na comunicação, aqui o autor declara que o maior produtor
de ruídos é o EMISSOR.
A proposta das melhores práticas

Na versão 2012 – ou 5ª edição do PMBOK – a guia de referência de gerenciamento dessa área de
conhecimento sofreu uma revisão interessante, tendo em vista que a área de gerenciamento de
stakeholders foi criada e separada em tratamentos e técnicas. De forma intencionalmente simplificada,
temos aqui:
Planejamento das Comunicações – Processo em que são determinadas as necessidades de

comunicação e informação de cada um dos “stakeholders” (interessados, envolvidos) no projeto, tanto
a coleta, como a análise das informações e requisitos das partes interessadas para desenvolver uma
abordagem de comunicação apropriada para o projeto. Tem como produto final o Plano de
Gerenciamento de Comunicações.
Gerenciar as comunicações – Esse é o processo de coleta de informações sobre o projeto para as

comunicações, criação, distribuição, armazenamento, recuperação e disposição final de acordo com o
Plano de Gerenciamento de Comunicações. Nesse processo, a ferramenta é fundamental, por isso
o plano de comunicação deve envolver as técnicas necessárias para incluí-la.
Controlar as Comunicações - O processo de monitoramento e controle de comunicações acontece

durante todo o ciclo de vida do projeto para garantir que as necessidades de informação do projeto e
das partes interessadas sejam atendidos.
O maior entendimento
Podemos dizer que o elemento mais importante do processo de comunicação é o receptor, assim como
o projeto existe para o cliente e a máquina para o homem. Sendo assim colocado, é fundamental centrar
a produção do plano de comunicação no receptor e não no emissor, assim como o gerenciamento deve
servir ao cliente. O plano de comunicação, que definirá junto à ferramenta quais relatórios – informações
deverão ser produzidos, não repetidos e otimizados, deve ser feito de trás para frente. O receptor deve
ser entrevistado para o entendimento de suas necessidades, os relatórios devem ser estruturados, as
produções analisadas em nível de logística e de redundância, os períodos de emissão estudados para
aproveitamento de ações, de modo que, ao final, o plano seja o mais eficaz, com a maior eficiência e
com o menor custo e recursos envolvidos.
Na figura ao lado vemos os RECEPTORES –

representados pelos círculos coloridos – aqui notados
como os maiores “interessados”, demandando
informações que se repetem ou se sobrepõem em
redundância – representadas pelos elementos a seguir na
direita. Uma análise técnica de melhor manipulação dos
pedidos levará com certeza a uma redução de materiais
completos, produzindo objetos de informações que serão
manipulados para compor necessidades maiores –
representados pelos elementos gráficos mais à direita da
figura.
Por fim, na figura ao lado vemos como esses objetos

de comunicação podem ser usados para montar a
matriz de comunicação ou – plano de gerenciamento
de comunicações para os RECEPTORES. O que
parceria ser muito e complexo, ficou menor e mais
administrável.
9.2. Uso da Ferramenta – Monitoramento e Controle
Diversas ferramentas são utilizadas para apoio ao gerenciamento das comunicações de um projeto, em que podemos
citar gerenciadores de correios eletrônicos (e-mails), editores de texto, editores de planilhas eletrônicas, entre outros.
O objetivo deste capítulo, em especial desta seção, é apresentar as formas como o MS Project pode colaborar com
os processos relacionados à geração, preparação e formatação das informações a serem comunicadas.
9.2.1. Modos – Relatório (Print Preview)
Todos os modos encontrados na ferramenta podem ser impressos, e, dessa forma serem transformados em relatórios
a serem distribuídos entre os envolvidos do projeto. Esta será a primeira forma de apoio à comunicação que
apresentaremos e, por sua simplicidade e capacidade de customização, mostra-se uma das mais úteis e que com
maior frequência é utilizada pelas equipes de planejamento e controle do projeto.
Antes de imprimir os relatórios obtidos pelas informações dos modos, devemos realizar a configuração da impressão
através da tela conhecida historicamente como print preview, acessada em File, Print ou através de ícone capaz de
ser inserido na barra de acesso rápido.
Nesta tela temos as seguintes opções:

1. Envia o comando para a impressora

ajustada com os padrões e parâmetros
definidos nessa tela. Lembramos que é
possível utilizar softwares de impressoras
virtuais para “exportar” o documento em
PDF, ou utilizar o opção padrão “Microsoft
XPS Document Writer, que suporta as
extensões .oxps e .xps;
2. Seleciona a impressora a ser utilizada;
3. Define os ajustes da impressora selecionada em “2”;
4. Opção “Settings” ou ajustes libera um menu suspenso como cópia ao acima para escolha das páginas
que serão contempladas na impressão. Permite ainda incluir os campos anotações, mostrar todas as
colunas ou apresentar apenas as colunas da esquerda das páginas. Por padrão, somente as colunas
que estejam visíveis na tela no momento da impressão serão impressas; excluem-se, portanto, as que
estejam escondidas pela separação vertical encontrada nos modos de screen Gantt Chart, Task Usage
ou Resource Usage;
5. Complementa a seleção em “4”, definindo-lhe os detalhes de datas e páginas;
6. Define a forma de orientação vertical ou horizontal da impressão;
7. Define o tamanho do papel a ser utilizado na impressão;
8. Configurações de página, como margem, cabeçalho, legenda, entre outros. Mais informações a seguir;
9. Pré-visualização do resultado;
10. Setas de navegação entre as páginas a serem impressas;
11. Apresentação do tamanho (zoom) das páginas configuradas.
Page Setup
Esta tela contém ao todo 6 guias com possibilidades de configuração para serem impressas. O domínio destes
recursos é importante para que se obtenha liberdade e segurança no momento de desenvolver os modelos de
relatórios e para que seja alcançada a produtividade durante sua utilização.
Iniciando pela guia Page, encontramos algumas informações repetidas como orientação e tamanho do papel,
mas também a possibilidade de configurar a escala e numeração das páginas. Na configuração da escala,
destacamos a possibilidade de definirmos um limite de páginas verticais e horizontais, recurso útil, mas que
deve ser utilizado para que o conteúdo do relatório seja legível.
A guia Margins mostra opções para definição do espaço entre a borda da folha e o conteúdo. Possui utilização
intuitiva e dispensa maiores comentários. Na guia Header podemos configurar o cabeçalho do nosso relatório
em três áreas (esquerda, centro e direita), incluindo texto, cuja fonte pode ser ajustada, e imagens. Podemos
ainda incluir valores de campos do projeto na forma de texto pelos atalhos encontrados nesta tela, ou
diretamente através da inclusão do símbolo ‘&’ antes do nome do campo cercado por “square brackets” ( “[ ]”
), tal como nas fórmulas. A guia Footer segue o mesmo padrão para configuração do rodapé.
Em Legend temos as opções de configuração da Legenda, somente quando estamos imprimindo modos que
comportem este conteúdo, como os que utilizam screen Gantt Chart. Novamente, temos a opção de configurar
o texto padrão que será exibido, no entanto, não recomendamos que seja inserido demasiado conteúdo, uma
vez que o espaço disponível para legenda é pequeno, principalmente se se estiver utilizando papel em
tamanho A4 ou A3. Importante destacar a possibilidade de apresentação da legenda em todas as páginas,
somente em folha à parte ou de não imprimir este conteúdo. Para a maioria dos casos, recomendamos a
escolha da segunda opção.
Por fim, em View temos as configurações finais, nas quais destacamos a possibilidade de repetir uma certa
quantidade de colunas em todas as páginas através da opção Print first [ ] columns on all pages, o que pode
se mostrar interessante caso as colunas do relatório não caibam todas em uma única página. Sem este recurso
o leitor deverá sobrepor as folhas para conseguir identificar a quais campos os valores pertencem, enquanto
que se repetirmos a coluna ID em todas as páginas, por exemplo, minimizaremos este inconveniente.
Nos processos que representam o trabalho desenvolvido nos capítulos do nosso livro, quando encontramos atividades
como “Realizar comunicação dos resultados do ...” pensamos neste recurso aliado aos modos desenvolvidos nestes
capítulos.
9.2.2. Comunicação do andamento do projeto

Uma atenção especial deve ser dada aos relatórios com as informações colhidas nas medições do projeto. Todo o
planejamento que modelamos no arquivo de MS Project culmina na utilização deste modelo para controlar a execução
do projeto e, caso selecionemos informações incompletas ou equivocadas para passar aos envolvidos do projeto
responsáveis pelas todas de decisões estratégicas, poderemos comprometer os resultados do projeto.
Muitas vezes um grande conjunto de valores, campos e informações não é a melhor forma de comunicar o andamento
do projeto a um gestor que possui pouca familiaridade com ferramentas de gerenciamento de projetos, ou mesmo
com conceitos de gerenciamento de projetos, mas que possuem grande poder de influência sobre o projeto. Nessas
circunstâncias, espera-se que a equipe de planejamento e controle seja capaz de interpretar os resultados e com
base nas diretrizes documentadas de controle do projeto, possa criar relatórios periódicos adequados à linguagem
desejada por cada um dos envolvidos.
Contamos também com a possibilidade de desenvolvimento de indicadores de desempenho na forma de gráficos, a

ficarem disponíveis permanentemente em páginas web, intranet, ou murais; e, se atualizados periodicamente,
colaboram com as informações recebidas pelas medições do projeto. Em projetos com atividades repetitivas, ou
atividades que produzam grande volume de resultados semelhantes, recomendamos a criação de indicadores de
desempenho que meçam o volume produzido contra o volume planejado.
Um conjunto de indicadores deve gerar uma central de acompanhamento do projeto. Abaixo, mostramos, como
exemplo, uma central de acompanhamento de projeto de inspeção dos quadros de uma instalação elétrica.
Finalizando nossa breve explanação deste rico assunto, que extrapola o escopo do nosso livro, relembramos a
importância da extrapolação das informações históricas para desenvolvimento de previsões e indicadores de
tendências, que são aliados importantes para tomada de decisão. Por exemplo, no projeto de inspeção citado acima,
caso o indicador de produtividade fosse inferior ao medido na semana anterior por duas semanas seguidas, mesmo
que maior que 1, um alerta era emitido a certos envolvidos, para que fossem identificadas as causas da queda de
produção, antes que a produtividade acumulada fosse inferior à unidade.
9.2.3. Relatórios Visuais (Visual Reports)
Na versão 2013, o recurso de relatórios

visuais encontrado também nas versões
anteriores foi superado pela utilização
dos novos relatórios, que serão
apresentados no item 9.2.4. No entanto,
por ainda fazerem parte do aplicativo, apresentaremos aqui sua utilização.
O objetivo deste recurso é tornar mais fácil a transposição das informações da ferramenta Project para a ferramenta
Excel ou visio, para nestes outro softwares detalharmos nossos relatórios. Logo de imediato temos a tela de
“entrosamento” entre os aplicativos que permite a escolha dos tipos de gráficos e informações a serem apresentados.
Lembramos que os campos a serem apresentados são eminentemente numéricos e, por conseguinte, não teremos
sucesso na escolha de certos dados que pelo processo anterior (Print Preview) nos era possível.
A tela reproduzida ao lado mostra as escolhas

e sua classificação. A tela apresenta de modo
amigável o entrosamento que o Excel e o Visio
apresentam ao Project. As abas permitem a
classificação dos relatórios em função das
tabelas que eles utilizam e sempre
referenciando-se à Task, Resource e
Assignment. No caso, utilizamos a aba “all”,
que apresentaria por princípio todos os
relatórios disponíveis.
No caso ao lado temos a opção de incluir

novos modelos – ou templates, alterá-los e
organizá-los pelo “manage templates”. A
escolha da escala é verificada logo a seguir e
abaixo da lista de relatórios em “select level of
usage data ...”. Um fato curioso que poderá
ser pesquisado pelo leitor é o uso da escala mês em separado de semana, não amigáveis, por não serem encontrados
juntos nas opções de gráficos dinâmicos.
Para mostrar os possíveis resultados, mostramos dois exemplos abaixo, um utilizando o template Critical Tasks Status
Report, do MS Visio, e outro com o Cash Flow Report do MS Excel. Utilizamos um arquivo de exemplo construído
para este capítulo para geração destes relatórios.
Estes relatórios são criados graças ao recurso PivotTables destas ferramentas. Caso o usuário domine este recurso
no MS Excel, a exportação automatizada de informação, aliada ao vínculo dinâmico gerado entre os arquivos, será
uma aliada interessante na busca pelo aumento da produtividade na emissão de relatórios com alta qualidade gráfica.
No entanto, no caso da utilização única destes relatórios, percebemos que este recurso se mostra mais trabalhoso
que a simples ação de copiar o conteúdo das tabelas dos modos e colar no Excel para geração dos gráficos com total
liberdade.·.
9.2.4. Comparação de Projetos
Contamos na ferramenta com a possibilidade de

comparar dois arquivos distintos para buscar
semelhanças e diferenças. Na prática, utilizamos
este recurso para comparar versões diferentes do
mesmo projeto.
Aproveitamos o assunto para lembrar a importância das organizações possuírem regras de nomeação de
arquivos, incluindo os modelos de MS Project, que contemplem identificação da versão. Também deve-se ter
cuidado quanto à regra de organização dos arquivos do projeto, tanto do MS Project, quanto dos demais
arquivos digitais que possam ou não estar vinculados àquele através de hyperlinks.
Caso a empresa não possua uma regra de nomeação e organização dos arquivos, a equipe do projeto deve
desenvolver um padrão e documentá-lo. Esta prática colabora em muito para o aumento da produtividade,
facilitando, por exemplo, o resgate de informações históricas, como relatórios; independente da data de
emissão.
Preferencialmente, o projeto com o qual desejamos comparar a versão atual do nosso projeto deve estar aberto na
máquina. Para utilizar o recurso de comparação de projetos, devemos nos encaminhar para a aba Report, grupo
Project, ícone Compare Projects. A tela Compare Project Versions será exibida; nela, devemos selecionar o arquivo
da versão com o qual compararemos esta versão.
Na parte inferior desta tela devemos selecionar as tabelas de atividade (Task) e de recursos que serão comparadas.
Esta função da ferramenta não compara todo o projeto, e sim colunas específicas das tabelas que selecionarmos na
opção que acabamos de referenciar. Claramente percebemos que. para correta utilização, tabelas com nomes
idênticos devem ser encontradas nos dois arquivos.
O número de colunas na tabela utilizada para comparação é limitado pela capacidade de processamento da
ferramenta. Acrescentamos também o fato do arquivo relatório gerado por este recurso utilizar campos livres do tipo
texto para apresentação dos resultados da comparação e, como apresentado anteriormente, estes campos são
encontrados em quantidade limitada, 30 unidades para tipo atividade (task) e 30 para tipo recurso.
São três os campos utilizados para cada coluna das tabelas comparadas; dessa forma, caso selecionemos uma tabela
com mais de 10 colunas, a ferramenta não será capaz de comparar todas as colunas e a seguinte mensagem será
exibida:
Para mostrar o funcionamento da comparação, selecionamos as tabelas

Entry e Usage para Task e Resource, respectivamente. Clicando em Ok
estaremos iniciando uma sequência de ações. Como citado, o formato de
exibição do resultado é um arquivo de MS Project que receberá uma cópia
dos elementos do nosso projeto (atividade, marcos, produtos, recursos...) e
a comparação será exibida nos campos tipo texto.
Após a execução dos processos de comparação e ajustes dos arquivos, que serão posicionados de forma que
possamos visualizar os três, simultaneamente, teremos uma tela equivalente à exibida a seguir.
O MSProject entende que sempre compararemos o arquivo da versão mais nova com o arquivo de versão anterior,
ou seja, que utilizaremos a versão mais recente e selecionaremos, com o recurso de comparação, o arquivo mais
antigo. Dessa forma, nomeia os campos de comparação como Current, Previous e Diff, que representam o valor
encontrado na versão atual, o valor encontrado na versão comparada e a diferença entre eles, respectivamente.
Para nos ajudar na análise dos resultados, temos a aba compare project. Com o grupo View, podemos passar
facilmente da tabela de comparação de atividades para a tabela de comparação dos recursos. Em Show destacamos
a possibilidade de filtrar o conteúdo para exibir somente os elementos que possuam algum valor diferente entre as
versões, e ainda, a escolha de quais colunas desejamos apresentar. Data Columns são as colunas com informações
das versões Current e Previous. Diferences Columns são as colunas de comparação.
Como conclusão, podemos perceber que este recurso faz-se de fácil replicação com o auxílio de um gerenciador de
planilhas eletrônicas e fórmulas simples, ambiente no qual não estaremos limitados por quantidade de campos,
formatação ou fórmulas específicas de comparação.
9.2.5. Novos Relatórios do MS Project 2013
Temos uma nova forma de relatório estreando na ferramenta MS Project na sua versão 2013, que responde pelo
nome simples de Report. Esta versão de relatórios substitui a de mesmo nome, que se apresentava com outros
recursos e somente em texto e tabelas, nas versões anteriores.
Possuindo grande capacidade de customização, este

novo recurso nos abre possibilidades interessantes de
geração de conteúdos dinâmicos e simples, com
visual atraente para apresentação aos envolvidos do
projeto, na própria ferramenta ou através de
impressão.
Apesar desta novidade apoiar a apresentação de informações simples; para relatórios e análises mais sofisticadas,
ainda recomendamos, na ferramenta, a criação de modos de trabalho para serem impressos via Print Preview e, fora
da ferramenta, o trabalho com editores de texto e de planilhas eletrônicas para geração de novos conteúdos a partir
dos dados simples do projeto, principalmente os oriundos das medições.
Encontramos modelos de relatórios prontos para utilização, e a possibilidade de criarmos os nossos próprios,
customizados. Estes são os relatórios que por padrão são encontrados na ferramenta e podem ser utilizados para
apoio ao gerenciamento da comunicação. O estudo destes relatórios, com entendimento da forma como foram
desenvolvidos, se faz interessante para que possamos perceber padrões de desenvolvimento, como disposição dos
conteúdos, seleção de campos e filtros para as tabelas e gráficos, entre outras configurações que os especialistas da
Microsoft desenvolveram.
Infelizmente, não podemos renomear estes relatórios. Caso tentemos, estaremos criando uma cópia, esta sim com o
nome escolhido, que ficará localizada no conjunto Custom. No entanto, o conteúdo pode ser livremente modificado.
Os relatórios estão organizados em quatro grupos, cuja lista é fixa e invariável, não sendo possível incluir novos
elementos.
9.2.5.1. Criando um novo relatório
Vamos explorar os recursos de customização dos relatórios através da criação de um relatório-exemplo. Podemos
perceber através do conjunto de ícones do Tools Tab do Reports, reproduzido abaixo, que existem diversas opções
de elementos a serem utilizados nos reports.
No grupo Themes encontramos possibilidades de configuração visual dos elementos incluídos no projeto. No ícone
Themes, podemos selecionar as cores padrões destes elementos, que seguirão um padrão harmonioso pré-
configurado pelos desenvolvedores, mas possível de ser editado por nós. As opções Colors, Fonts e Effects modificam
as cores, fontes de texto e efeitos visuais dos objetos, respectivamente.
Passemos agora para os elementos do grupo Insert, responsável por gerenciar todo o conteúdo dos nossos relatórios.
Tudo que é exibido nas telas de relatório está ligado a uma das opções deste grupo.
Caixas de Texto
Sempre que tivermos texto não pertencente a uma tabela ou gráfico, esse texto foi
inserido e deve ser editado, através das opções das caixas de texto. Selecionando-se
o ícone, devemos desenhar uma caixa que inicialmente apenas representará os limites
desta caixa, e em seguida poderemos preencher e editar o conteúdo. A caixa na qual
o texto está contido pode ter sua cor de preenchimento e bordas modificada.
Para configuração do texto, seleção da fonte, cor, tamanho e efeitos negrito, itálico ou
sublinhado, podemos utilizar a guia Task, ou utilizar as telas de Text options e
Paragraph para maiores possibilidades. Ambas as telas podem ser acessadas a partir
do clique com o botão direito do mouse na caixa de texto, e seleção das opções Format
text Effects e Paragraph, respectivamente. As telas citadas estão reproduzidas a seguir, e as possibilidades
de configuração são intuitivas, dispensando maiores informações.
Incluiremos uma caixa de texto na parte superior do nosso relatório para inserir um título do nosso relatório.
Desenhando uma caixa grande, podemos pintá-la de alguma cor (no nosso caso, verde) e selecionar o
alinhamento horizontal e vertical no modo centralizado, para obter um resultado visualmente agradável.
Imagens e Formas
Outro recurso básico é a inclusão de imagens e formas geométricas. Começando pelas imagens, podemos
inseri-las através da importação de uma grande variedade de extensões de arquivos, através do ícone Images
ou simplesmente copiar a imagem em algum editor e colar na área do nosso relatório.
Uma vez inserida, a imagem pode ser redimensionada e posicionada onde desejarmos na área do relatório.
Quando selecionada, uma nova Tools Tab é exibida, a Picture Tools, reproduzida abaixo, que nos fornece as
possibilidades de edição de imagens padrão dos aplicativos do Office 2013. Podemos configurar efeitos de
borda, correções de brilho e contraste, aplicar efeitos artísticos e de cor, rotacionar, entre outras possibilidades.
O uso das formas também não guarda

mistérios, se comportando da mesma
maneira como nos outros aplicativos do
Office 2013. Novamente, quando
selecionamos as formas criadas, a guia
Drawing Tools é exibida, nos fornecendo possibilidades de configuração das nossas formas. Destacamos a
possibilidade de inserção de texto. Desse modo, percebemos que a caixa de texto se comporta da mesma
maneira que uma forma retangular.
Até o momento nosso relatório tem a aparência mostrada na imagem a seguir.
Tabelas
Podemos afirmar que as tabelas são a forma mais simples de apresentação de conteúdo nos
relatórios. As tabelas possíveis de serem criadas possuem diversas possibilidades de personalização,
passando pela seleção dos campos, formas de agrupamento e aplicação de filtros, além de, claro, as
possibilidades de formatação visual.
Clicando no ícone de inserção de tabelas, a ferramenta inclui uma tabela padrão contendo os campos Name,
Start, Finish e % Complete, ao mesmo tempo que exibe o painel Field List reproduzido ao lado, onde podemos
personalizar nossa tabela.
1. Seleção de campos tipo Task ou tipo resource, alterando assim o tipo

da tabela para dados de atividade ou de recurso;
2. Seleção de campos, que serão convertidos em colunas na tabela;
3. Exibição dos campos selecionados. Para alterar a ordem de exibição,

clique e arraste os campos até a posição desejada;
4. Aplicação de filtros. Podem ser selecionados os filtros padrão da

ferramenta ou qualquer filtro criado anteriormente, ou ainda um novo;
5. Seleção de grupo, que se comporta semelhante à seleção dos filtros;
6. Seleção do nível de exibição dos elementos da EAP.
7. Opção de mostrar a hierarquia; caso selecionada, os elementos da

tabela serão indentados conforma seus valores na hierarquia da EAP.
8. Ordenação. Pode ser realizada da mesma maneira que nos modos.
As tabelas possuem duas Tools Tab, a Design e a Layout. Na primeira

encontramos opções para alterar o estilo da nossa tabela, como cores
das colunas e linhas, formatação diferenciada da última linha ou coluna,
aplicação de efeitos à fonte, etc. Destaque para a possibilidade de ocultar
o cabeçalho das colunas, que se mostrará útil em nosso relatório exemplo em breve.
Na aba Layout encontramos as opções de alteração do formato da tabela. Podemos alterar a altura e largura
das linhas e colunas (o que também pode ser obtido diretamente na tabela com recursos de clique e arraste),
orientação e alinhamento do texto, etc.
Para nosso relatório exemplo criaremos duas tabelas. A primeira exibirá uma lista contendo somente as
atividades que possuam valor do campo CPI maior que 1. Para isso, criamos uma tabela tipo Task (item 1),
selecionamos os campos name, CPI e text10, que renomeamos para Responsável (item 2); alteramos o outline
level para valor máximo (item 6) e aplicamos um filtro que exiba somente atividades que possuam CPI > 1.
Acima desta tabela inserimos uma caixa de texto simples, para exibir a descrição da tabela.
Com a outra tabela mostramos outro uso interessante para tabelas, em que estas contêm somente uma célula,
comportando-se, assim, simulando um campo de texto automaticamente atualizável. No nosso exemplo
incluímos o valor do Campo Cost para o outline level igual a Project Summary, ou seja, o valor estimado de
custo do projeto. Veja abaixo o resultado do nosso relatório até o momento.
Atenção: Sempre que for visualizar tabelas nos seus relatórios, expanda a visualização dos elementos da
EAP + Atividades para o outline level adequado, ao nível que deseja visualizar na sua tabela, ou ao nível
máximo (9), por segurança. Caso haja elementos suprimidos (minimizados), estes serão ocultados na
visualização da tabela. Este comportamento é similar ao encontrado com diagramas de rede.
Gráficos
Finalizamos a apresentação de inclusão e

alteração de conteúdo dos nossos relatórios com
os gráficos. Os possíveis tipos são os mesmos
encontrados no aplicativo MS Excel 2013, no
entanto, os gráficos mais simples, tipo linha,
coluna, barra e pizza (ou torta, “pie”, em inglês) são
aqueles que mais comumente atendem às
necessidades de comunicação em um projeto.
Após selecionar o tipo de gráfico, de forma

semelhante ao ocorrido com as tabelas, o
programa nos apresenta um conteúdo padrão e
abre o painel Field List para que possamos realizar as
configurações no nosso gráfico.
1. Seleção de campos tipo Task ou tipo Resource, alterando

assim o tipo do gráfico para dados de atividade ou de
recurso;
2. Seleção da categoria. Existem 5 possíveis valores: Time,

Name, ID, Resource Names e Unique ID. Esta seleção será a responsável pela definição de que tipos de
elementos serão utilizados para construção do nosso gráfico. Assim, se selecionarmos Name, o nome das
Atividades, marcos e produtos, ou os nomes dos recursos, serão exibidos no eixo das abscissas, enquanto
que nas ordenadas, a escala, adequando-se ao valor dos campos selecionados em “3”.
Destas categorias, a Time apresenta um comportamento diferente das demais, ao apresentar a escala de
tempo no eixo das abscissas, tornando assim possível criarmos gráficos de linha e de coluna que
representam a evolução histórica dos valores analisados.
3. Seleção de campos, que serão convertidos em elementos do gráfico;
4. Exibição dos campos selecionados. Para alterar a ordem de exibição, clique e arraste os campos até a
posição desejada;
5. Aplicação de filtros. Podem ser selecionados os filtros padrão da ferramenta, ou qualquer filtro criado
anteriormente, ou ainda um novo;
6. Seleção de grupo, que se comporta semelhante à seleção dos filtros;
7. Seleção do nível de exibição dos elementos da EAP. Não gera diferença em todos os gráficos;
8. Opção de mostrar a hierarquia, caso selecionada, os elementos do gráfico serão organizados conforme
seus valores na hierarquia da EAP. Não gera diferença em todos os gráficos;
9. Ordenação. Pode ser realizada da mesma maneira que nos modos.

A configuração visual segue o mesmo padrão dos outros aplicativos da família Office.
Encontramos novamente duas abas em Chart Tools. Em Design, podemos alterar
elementos gráficos gerais com os layouts .e modificar a forma de apresentação do
conteúdo. Destacamos a opção Add Chart Element, com a qual podemos adicionar
eixos, títulos, rótulos, legenda, entre outros elementos.
Com a aba Format, encontramos a possibilidade de configuração visual pontual dos

elementos do gráfico, como cor de borda e preenchimento.
Lembramos que este foi um relatório criado unicamente para exemplo e apresentação das funções de customização
de material.
9.2.5.2. Uso especial
Gostaríamos de apresentar brevemente uma possibilidade alternativa de utilização dos

nossos recursos de relatórios do MS Project 2013, que não passam necessariamente
pela apresentação de conteúdo dinâmico, gerado e organizado pela ferramenta.
Ao entrarmos pela primeira vez no MS Project 2013, encontramos a opção de ver uma
recepção de boas vindas, um projeto criado pelos desenvolvedores para auxiliar os
usuários. De fato, este arquivo é um template, o qual pode ser selecionado ao criarmos
um novo projeto (File, New).
Nesse projeto de boas vindas, logo que entramos somos recepcionados por uma tela interessante, que mais nos
parece um website, pois possui uma barra de navegação no topo e links que se assemelham a botões no estilo
Windows 8.
Simplificando nossa apresentação, a referida tela trata-se de um relatório criado pelos desenvolvedores da ferramenta
que faz uso de formas e imagens para levar mensagens aos usuários, e que, vinculada a outros relatórios através de
hyperlinks, forma uma rede de navegação.
Através da análise deste relatório, que todos os leitores têm a sua disposição, entenderemos como este resultado foi
alcançado. Primeiramente, vamos selecionar a caixa que nos informa “Start >” com o botão direito, para em seguida
selecionar a opção edit hyperlink.
Na janela Edit Hyperlink, vemos na parte inferior o valor em Address definido em “#Schedule Your Work”.
Percebemos, assim, que para criarmos um link para um relatório do nosso arquivo, basta incluir neste campo o
caractere “#” antes do nome deste relatório (Schedule Your Work é o nome de um relatório deste template).
Comprovando esta afirmação, se clicarmos neste ‘ícone’, somos levados ao referido relatório (o nome do relatório
pode ser percebido no canto esquerdo da tela).
Além de formas e figuras, caixas de texto podem conter hyperlinks; portanto, também podem receber esta versão de
link que nos leva a outras áreas do aplicativo. Vemos no canto inferior esquerdo do relatório a opção de pular a
apresentação e introdução se clicarmos em “Skip Intro”. Selecionando esta caixa de texto com o botão direito para
alcançarmos a tela Edit Hyperlink, percebemos que aqui foi utilizado um recurso diferente para a criação do link.
Através da opção “Place in This Document”, foi selecionada a opção Gantt with Timeline. Percebemos, assim, que é
possível vincular os elementos do gráfico também aos modos de trabalho. No entanto, a opção “Place in this
Document” somente exibe os modos contidos no Global (mais informações sobre o Global ao final do capítulo). O
mesmo para relatórios, que também podem ser alcançados por este recurso.
Acrescentamos que uma forma mais simples de adicionar links aos modos do arquivo é através da mesma
configuração apresentada anteriormente, ou seja, incluir “#” seguido do nome do modo no campo Address da opção
“Existing File or Web Page”.
Podemos perceber, após esta apresentação, que a navegação criada pelos desenvolvedores trata-se de um conjunto
de relatórios vinculados entre si através de hyperlinks, e com configuração gráfica amigável, para que fiquem
visualmente agradáveis.
Muitas são as possibilidades de criação que este recurso nos habilita a desenvolver. Apresentamos a seguir a
possibilidade de criação de procedimentos de trabalho a partir de uma imagem de processo já apresentada em nosso
livro. Com esta apresentação final, citaremos algumas dicas para o trabalho.
Iniciamos criando um modo em branco. Para isso, acessamos a guia Reports, qualquer um dos tipos de relatórios e,
em seguida, More Reports, New Report, Blank; ou diretamente a opção New Report, Blank.
Em seguida, devemos dar um nome ao nosso relatório.
Criamos, assim, um relatório em branco, que possuirá um título equivalente ao nome recebido, alterando a cor de
fundo deste título e inserindo a imagem referente ao processo do capítulo 2 do nosso livro. O resultado está
reproduzido a seguir. Desejamos que cada atividade do nosso processo contenha um hyperlink para um modo já
desenvolvido.
Chegaremos ao resultado desejado incluindo formas transparentes sobre a imagem do nosso processo, uma sobre
cada atividade, que receberão os hyperlinks. Assim, os usuários terão a impressão de estarem clicando nas
atividades. Fazemos assim para não necessitarmos editar a imagem.
A inclusão de uma forma retangular, redimensionamento e

posicionamento em cima de cada atividade não deve ser motivo de
dúvidas, uma vez que pode ser realizada de forma intuitiva e de forma
semelhante em todos os aplicativos Office.
Para retirar a borda e o preenchimento, selecionamos através da aba Drawing Tools, Format, grupo Shape Styles, as
opções Shape Fill e Shape Outline, escolhendo as opções No Fill e No Outline, respectivamente. Por motivos óbvios,
encontramos dificuldade em mostrar o resultado aqui no livro, mas podemos perceber as pequenas caixas brancas
ao redor da atividade Criar EAP, mostrada abaixo, que mostra os limites da nossa caixa invisível.
Dica: Uma vez que as caixas estão sem preenchimento, pode ser difícil selecioná-las. Para realizar a seleção de
forma simples, crie uma caixa de seleção clicando e arrastando o mouse ao redor da caixa que deseja
selecionar. Pode ser interessante também somente transformar os objetos em invisíveis após termos terminado
as demais configurações.
Lembramos que, para criar a EAP, desenvolvemos o modo Step 01 – WBS. Assim, criaremos um hyperlink na primeira
caixa invisível, sobre a atividade Criar EAP, para este modo. Clicando com o botão direito sobre a caixa (isso pode
ser difícil se ela estiver invisível; tente acertar a borda), selecionamos Hyperlink e incluímos o valor #Step 01 – WBS
no campo Address. É importante que o nome do modo seja incluído exatamente igual ao seu nome real, ou o link não
funcionará.
A partir do momento que incluímos o hyperlink na forma, sempre que quisermos selecioná-la, deveremos fazê-lo com
o botão direito, uma vez que se clicarmos com o botão esquerdo seremos direcionados ao destino do hyperlink.
Assim, se quisermos reposicionar ou redimensionar este objeto, deveremos primeiramente selecioná-lo com o botão
direito ou com caixa de seleção, para, posteriormente, fazermos estas alterações.
Procedemos de maneira semelhante para as atividades “Documentar EAP” e “Realizar comunicação .. do escopo”,
vinculando-as aos modos Step 02 e Step 03, respectivamente.
Finalizando nosso relatório – procedimento, criaremos um hyperlink sobre o logo da empresa Bizagi, que levará o
usuário até a home page desta empresa, cujo software Bizagi Modeler, gratuito, viabilizou a apresentação deste e
diversos outros exemplos.
10. Capítulo 10: Gerenciamento de Múltiplos Projetos
10.1. Conceitos de Gerenciamento de Múltiplos Projetos

Não se pode falar de múltiplos projetos sem antes falar de sua razão de existir. Isso é falar sobre programas
e portfólios, antes reforçando o conceito de “mudança” e “projeto”; o primeiro como fator demandante do
segundo, e o segundo como meio de atingir o primeiro. De acordo com a definição mais clássica, um projeto
é “um esforço temporário empreendido para criar um novo produto, serviço ou resultado exclusivo”. Fica
claro que esse resultado é o degrau desejado, e degrau de subida, para a promoção da mudança, e sempre
para melhor.
De mesma forma, a necessidade da mudança, se encarada como algo maior e de proporções corporativas
ou até mesmo sociais, define não um, mas vários projetos que, atuando de forma simultânea ou não, levam
ao conjunto de resultados necessários. Daí, tiramos a definição de programa como conjunto de projetos com
objetivo único, por mais distintos que sejam seus resultados individuais. Podemos chamar de sinergia de
ações a um propósito. Assim como um projeto, o programa tem caráter temporário em que se deve ter um
início e um fim definido.
Com esse entendimento de programa, estendido de projetos, pode-se agora trazer o significado de portfólio
como uma classificação específica desse conjunto de projetos ou programas, que, mesmo atendendo a um
objetivo ou meta, por razões específicas, podem ser agrupados em “carteiras” ou “pastas”. A melhoria de
um país pode contar com um ou diversos programas, e esses programas conter em si diversos e múltiplos
projetos. Porém, quando se fala na “área da saúde” ou “área da educação”, é possível entender conjuntos
de projetos ou programas, com expressões e especificidades únicas “de saúde” ou “de educação”. Essa
classificação apoia o entendimento de que há “stakeholders” ligados a esse ou àquele setor, mostrando a
necessidade de classificar, assim, portfólio de projetos de saúde ou portfólio de programas de educação,
separadamente.
A gestão de projetos, objeto desse livro, pela ferramenta e na extensão dos seus limites, se faz pelo
entendimento das áreas e dos processos de trabalho com as entradas e saídas desses. É evidente que um
conjunto de projeto ou programa deve estar aderente/alinhado aos objetivos estratégicos e corporativos.
Evidenciamos aqui três tópicos:
Gerenciamento dos resultados esperados - benefícios: principal foco quando se

estabelece diretrizes para resultados. Como nos projetos, as métricas e procedimentos
para acompanhamento das metas parciais e finais se assemelham ao acompanhamento
dos produtos parciais e finais do projeto, com regras claras para isso.
Gerenciamento de Interessados - Stakeholders: segundo ponto a ser abordado como
foco e controle, não menos importante que o anterior, os interessados agora em muito
maior número, nível e interesses, devem ser administrados com a mesma intensidade e
atenção que os projetos. É possível entender que o nível de envolvimento, agora definido
pelas classificações e grupamentos, traz muito mais trabalho ao gestor para manter todos
os envolvidos engajados.
Governança dos Programas: Esse terceiro elemento, aqui colocado por último, pode ser
considerado talvez o mais importante. De mesma forma que o termo de abertura dá o tom
do planejamento e controle do projeto ao Gestor do Projeto, a governança estabelece:
metodologia de Gestão. Isso é traduzido como políticas, processos, procedimentos,
modelos, desenho das estruturas envolvidas, gestão de riscos específica, etc.
Nesse livro, no capítulo 7, foi apresentado, e já apresentado em outras obras, os “critérios de qualidade”
para avaliação de um planejamento e controle eficientes e eficazes na busca de resultados. Na gestão de
programas pode-se trabalhar algo muito similar.
Votando ao início, a gestão de programas, portfólio e de projetos como subprojetos, se apresenta nesse
capítulo pela ferramenta de forma simples, porém cuidadosa. A inclusão de dependências e recursos entre
projetos diferentes não só facilita o controle geral, como também traz a visão de necessidades de
dependências muitas vezes negligenciadas pela falta de metodologia.
Foi pensando nesta relação com mais esse “stakeholder” (partes interessadas) do projeto, o contratado, que
o PMBOK, na sua 5ª edição, apresenta a sua décima segunda área de conhecimento: o Gerenciamento de
Aquisições do Projeto que engloba todos os processos necessários à aquisição e contratação de bens e
serviços externos à organização executora, a fim de cumprir o escopo do projeto. A fim de simplificar, será
usado o termo “produto” para referenciar quaisquer bens ou serviços, quer sejam um ou vários. Essa área
de conhecimento foi dividida agora em quatro processos:
• Planejar as Aquisições – é o processo que determina e documenta os requisitos do produto
a ser adquirido, define a forma de contratação e identifica os possíveis fornecedores.
• Conduzir as Contratações – é o processo que obtém a resposta dos fornecedores,
seleciona, e celebra o contrato.
• Administrar os Contratos – é o processo responsável por todo o gerenciamento e
administração do relacionamento e desempenho dos fornecedores e efetua as correções e
acertos necessários.
• Encerramento do Contrato – é o processo responsável por completar e liquidar o contrato,
incluindo a resolução de quaisquer itens em aberto.
Os quatro processos do Gerenciamento das Aquisições colaboram para a realização da proposta geral de um projeto.
O MSProject 2013 também atua como um elemento facilitador para o controle dos subprojetos que são contratados
para a composição de outro maior. A inclusão dos planejamentos desses subprojetos dentro do planejamento geral
é uma atividade que pode ser implementada no nosso trabalho.
As condições básicas para o sucesso desse controle geral é a “criação de critérios de trabalho” comuns a todos os
participantes, antes de iniciar a modelagem dos subprojetos.
Foi comentado logo no início desse trabalho que a opção Project Summary Task marcada facilitaria a inclusão dos
projetos dentro de projetos por conta da criação de uma linha sumária ZERO, na qual o projeto seria automaticamente
referenciado como o elemento mais alto da EAP. Nos exemplos a seguir essa opção não foi marcada, daí termos os
projetos começando com a linha número UM e, por conta disto, uma repetição de títulos ao praticar a inclusão de
projetos dentro de projetos.
10.2. Uso da Ferramenta – Múltiplos Projetos
10.2.1. Gerenciamento de Portfólios
Como visto na seção teórica deste capítulo, o desenvolvimento de práticas e conceitos de gerenciamento de múltiplos
projetos se justifica pelas diversas oportunidades geradas. Entre estas, a centralização das informações dos projetos
para análise de uma equipe de gerenciamento de portfólio está entre as que trazem maiores retornos às organizações
que as praticam.
Os projetos que compõem os portfólios sempre guardam semelhanças entre si, semelhanças estas justamente as
que foram utilizadas para organização e definição dos portfólios. Assim, por exemplo, é comum que estes projetos
utilizem recursos em comum, concorrendo pela sua utilização, a partir do momento que este se torna escasso.
Sem um controle e uma gestão unificada, cada projeto e cada gestor de projeto trabalharão – corretamente – pela
maximização dos seus resultados, impossibilitado analisar quais seriam as definições de prioridades que melhor
atenderiam o negócio da organização. Quando existe o gerenciamento de portfólios, as organizações ganham uma
ferramenta de otimização global, alinhada às diretrizes e objetivos organizacionais, que
superam projetos individuais.
Para apresentarmos a utilização de múltiplos projetos no MS Project 2013, criamos três

arquivos de projetos simples, os projetos X, Y e Z, e um arquivo de Pool de Recursos,
que está cedendo recursos para estes três projetos. Os projetos receberam um
conjunto de atividades genéricas e alocações dos recursos do pool.
10.2.1.1. Criando um projeto Master
Seguindo o padrão de nomenclatura da ferramenta, chamaremos de arquivo Master aquele que contém outros
projetos nele inseridos, independente da intenção conceitual que nos levou a fazê-lo. A referência ao nome Master
pode ser observada, por exemplo, na terceira opção de abertura dos arquivos de pool de recursos, que nos dá a
possibilidade de abrir o pool, somado a todos os projetos a ele relacionados, em um novo arquivo Master que os
conterá.
A criação do arquivo Master em si não é diferente da criação de qualquer outro arquivo. Tal como os pools de recursos,
podemos afirmar que os arquivos de MS Project estão Master, ou não, se contêm, ou não, outros projetos inseridos
na sua estrutura de EAP + Atividades. Afirmamos então que, assim como Pool, mais que um tipo, Master é um estado.
Criamos então um arquivo em branco, tomando o cuidado de revisar e realizar a formatação inicial do ambiente de
trabalho. Adicionalmente, para nos facilitar a modelagem, selecionamos uma data de início anterior à data de início
de qualquer projeto que desejamos inserir. Para incluirmos nossos três projetos (X, Y e Z), nos direcionamos à aba
Project, grupo Insert, opção Subproject. Devemos abstrair o nome Subprojeto, e entender este recurso como “inserir
referência a outro arquivo de MS Project”.
Quando inserimos uma referência a outro projeto, não estamos simplesmente copiando as informações deste projeto,
e sim criando um vínculo dinâmico entre o que será apresentado no arquivo Master e o arquivo em si. Podemos dizer
que o arquivo Master ao mesmo tempo espelha as informações dos projetos individuais e permite a edição destas
informações. Qualquer alteração poderá ser salva e distribuída para os arquivos individuais.
Devido à possibilidade de edição dos projetos inseridos, faz-se extremamente necessária a criação de procedimentos
de trabalho que possuam regras rígidas de controle da forma e local onde as informações serão alteradas, visando
assim reduzir a probabilidade de erros, conflitos de versões, perda de confiabilidade e desacreditação das
informações. A documentação das responsabilidades e privilégios de edição colaboram com esta iniciativa.
Inicialmente, este é o resultado obtido com a inclusão dos projetos:
O que vemos é o equivalente à linha de ID 0 nos arquivos dos projetos. Reparemos também no ícone no campo
indicators.
Reparemos que o elemento projeto possui o nome dado ao elemento Project Summary Task, no seu arquivo. Dessa
forma, para facilitar a identificação dos projetos no arquivo de gerenciamento do portfólio, devemos dar nomes
significativos, de acordo com os padrões organizacionais, para as ‘linhas zero’ dos nossos projetos. Ainda, para evitar
repetição desnecessária de produto sumário, não devemos criar na linha de ID 1 dos nossos projetos um produto no
qual todos os demais elementos estarão dentro. Esta
será a função da linha 0.
Observação: É possível a criação de uma cadeia de

incorporação de projetos. Na imagem
ao lado vemos um projeto filho inserido
dentro de um projeto pai, e esse projeto
pai inserido dentro do projeto avô.
Como podemos deduzir pela observação acima, é possível a criação de produtos, atividades e marcos, no arquivo
Master. Poderíamos, assim, definir atividades de gerenciamento do Portfólio no arquivo Master, atividades essas que
não pertencem a nenhum projeto específico. A definição ou não destas atividades em arquivo de MS Project, ou de
quais atividades serão definidas, deverá ser uma decisão de cada equipe de trabalho ou da política da organização,
que pode possuir outras ferramentas de gerenciamento de atividades. Aqui, não definiremos atividades para o
portfólio, e deixaremos a análise da relação entre projetos para a seção subprojetos.
Ao abrirmos algum destes projetos, percebemos que o campo ID se comporta de um modo diferente do que estamos
acostumados, no momento que ele assume o valor que seria encontrado no projeto. Devemos levar isto em
consideração, posteriormente, ao falarmos de subprojetos, quando criarmos vínculo entre as atividades de projetos
diferentes. Importante notar, no entanto, que a individualidade das linhas no projeto Master é mantida através do
campo Unique ID, que assume novos valores pra referência e trabalho do arquivos Master.
A partir do momento que inserimos outros projetos no nosso arquivo, no momento que o fecharmos receberemos
uma ou diversas mensagens nos perguntando se desejamos salvar as alterações nos projetos de origem. A opção
sim para todos (Yes to All) e Não para todos (No to All) pode ser bastante útil nestes momentos.
10.2.1.2. Uso de Recursos
Todos os projetos inseridos no nosso Master utilizam recursos do mesmo Pool. Em situações como esta
recomendamos que o arquivo de Pool seja mantido aberto sempre que o Master também estiver, para que seja evitada
uma possível réplica (ou tréplica, em nosso caso) de recursos, na lista de recursos do arquivo Master.
Propositalmente, não abrimos o Pool e obtivemos a seguinte lista de recursos no nosso modo Resource Sheet do
Master:
Através da coluna Project, podemos perceber que a ferramenta está considerando os recursos como pertencentes
aos arquivos dos projetos e, portanto, elementos distintos. Confirmando este fato, temos em destaque os valores
distintos para o campo Unique ID do Recurso A.
Abrindo o pool, a lista imediatamente é reduzida e a

compreensão correta é alcançada pela ferramenta, que
percebe que os recursos não pertencem aos projetos, e sim
ao Pool. Veremos abaixo que o conteúdo de Unique ID e
Project é atualizado.
Podemos perceber também que, onde antes havia somente

um único recurso superalocado, de fato existem três. Logo, a
superalocação se dá pela necessidade de utilização
simultânea dos recursos da organização em projetos distintos.
Reparemos que o arquivo Master não foi vinculado ao Pool, no entanto, está vinculado indiretamente, e qualquer
alteração na sua lista de recursos, que na verdade é o Pool, será levada ao repositório de recursos da organização.
Todas as análises e conclusões trabalhadas no capítulo de Gerenciamento dos Recursos podem ser utilizadas aqui.
Acrescentamos a providencial utilização do campo Project, principalmente nos modos tipo Resource Usage para
detecção dos projetos aos quais as alocações pertencem, uma vez que é possível, apesar das boas práticas não
recomendarem, que tenhamos atividades com nomes similares ou, muitas vezes, nomes coincidentes.
Certamente aconselhamos a criação de modos de trabalho para o gerenciamento de portfólios. Nestes, apontamos a
importância do campo Prioridade (Priority) estar presente, sendo dois os motivos. O primeiro, documentação de apoio
à tomada de decisão estratégica. Se os níveis de prioridade forem padronizados, por exemplo, em faixas de
prioridade, será possível identificar facilmente a que categoria um dado projeto pertence. Ainda, este campo apoia o
nivelamento dos recursos, informando à ferramenta quais atividades deverão ser ‘deslocadas’ em detrimento de
outras.
Para utilização de prioridade no nivelamento de recursos, além do campo com valor preenchido, as configurações da
tela Resource Leveling devem mostrar o valor Priority, Standard na opção Leveling order. Lembramos que um valor
maior significa maior prioridade.
Quando aplicamos ao projeto Master um modo que utilize a screen Resource Usage, temos a exata noção do
uso dos recursos dentro de cada projeto e, de modo consolidado, dentro da organização verificando as
superalocações onde elas ocorrerem. O uso desse recurso no aplicativo, múltiplos projetos, facilita não só a
verificação de superalocações como também do nível de ociosidade dos recursos e de sua aplicação. Essas
visões e cenários associados ao recurso do “level resources” dá ao gerente de recursos condições para a
tomada de decisão.
Quando aplicamos ao projeto Master o modo Resource Graph, geralmente como painel inferior em modo
composto, temos a noção das superalocações e do nível de ociosidade dos recursos. A linha escura na cor
preta demonstra o número de recursos disponíveis; as barras azuis, conforme a legenda, o utilizado nos três
projetos; e as áreas em branco, o nível de disponibilidade ou em certos casos – ociosidade.
Pudemos perceber até o momento que no gerenciamento de múltiplos projetos existem poucas novidades quanto à
utilização da ferramenta e seus recursos, mas existe grande carga de conhecimento teórico de gerenciamento de
portfólios envolvida com este tema, que deve ser domado e dominado pela equipe de planejamento e controle, para
que um resultado de qualidade seja alcançado.
10.2.2. Subprojetos
As aquisições e contratos do Projeto nos mostram que muitas vezes não é possível atender ao escopo compreendido
no projeto apenas com recursos internos à organização executora. Surge a necessidade de aquisição e contratação
de bens e serviços externos. Este é um exemplo em que um mesmo projeto não poderá ser modelado, planejado e
controlado em um único arquivo, sem que muito esforço seja despendido pelos envolvidos do empreendimento. Dessa
forma, o projeto é dividido em subprojetos, cada um sob a responsabilidade de uma equipe de planejamento, mas
todos seguindo diretrizes, características e premissas coordenadas, mas, ainda, os subprojetos são interdependentes,
uma vez que um necessita dos resultados gerados nos demais para que o real valor do seu trabalho seja alcançado.
A diferença deste arquivo para um de gerenciamento de portfólio se encontra no campo teórico. Para a ferramenta,
não existe distinção. Decidimos dividir a apresentação para facilitar o entendimento e aproveitar a segmentação
natural para organizar o conteúdo deste capítulo.
Novamente, criamos arquivos para desenvolvimento de um exemplo ilustrativo. Desta vez, contamos com quatro
projetos, representando cada um o subprojeto de um grande empreendimento, e um arquivo Master, que reúne estes
subprojetos na sua estrutura, que exibimos abaixo.
Observação: Aqui já incluímos os arquivos como se o planejamento realizado por cada uma das equipes
dos subprojetos já estivesse encerrado e aprovado. É comum, no início de
empreendimentos, modelarmos subprojetos ainda não detalhados como grandes pacotes
de planejamento, para estimativas de alto nível e comunicação e apresentação aos
envolvidos. Posteriormente, estes pacotes de planejamento são substituídos pelos projetos.
No caso de contratação de empresas executantes de todos ou algum subprojeto,

provavelmente serão avaliadas diversas propostas de prestação de serviços. Caso as
empresas que ofereçam seus serviços sejam solicitadas a fornecer informações
complementares de formação, experiência e comprovações de serviços similares
anteriores, torna-se possível a avaliação de diferentes cenários de contratação, onde se
poderá selecionar não somente a melhor empresa para cada subprojeto, mas sim o melhor
conjunto de empresas para o projeto em geral.
10.2.2.1. Sequenciamento entre subprojetos
Pela natureza interdependente dos subprojetos, muitas vezes é necessário trazer uma referência de data de
conclusão ou de dependência mandatórias entre atividades e marcos que não pertencem ao mesmo arquivo. Dessa
forma, a maneira de incluir essas referências a atividades ou marcos externos é com a inclusão das chamadas
“external tasks” ou atividades externas.
No nosso exemplo, podemos imaginar que a elaboração do subprojeto chamado Projeto somente deverá iniciar após
a conclusão do estudo de viabilidade. Dessa forma, deveremos incluir uma dependência do tipo Término para Início,
com o marco de término do subprojeto Viabilidade sendo predecessor do marco de início do subprocesso Projeto.
Para sequenciar estes marcos, podemos proceder de qualquer uma das maneiras apresentadas no nosso capítulo
de Gerenciamento do Tempo, no entanto, existem algumas pequenas diferenças que devem ser levadas em
consideração. A mais importante delas é que, devido ao valor do campo ID não ser mais único no arquivo Master,
não podemos realizar o sequenciamento de atividades e marcos simplesmente adicionando o valor de ID nos campos
predecessor e sucessor, uma vez que a ferramenta não saberá a que projeto você está se referenciando. Em verdade,
ela considerará que está selecionando os elementos naturais do arquivo Master.
Para contornar este inconveniente, devemos sequenciar as atividades pertencentes a arquivos diferentes,
preferencialmente, por outros métodos. O sequenciamento através do gráfico de Gantt e do ícone Link
the Selected Tasks ( Ctrl + F2) se mantém inalterado. Utilizando-o um, ou o outro, chegamos ao resultado abaixo.
Podemos perceber que, no campo Predecessors, a ferramenta incluiu o caminho completo do arquivo com o qual o
marco de “início do projeto” do subprojeto “Projeto” está sequenciado, encerrando com o ID do elemento que lhe é
predecessor, no caso ID = 8. É possível, porém pouco produtivo, digitar o endereço no campo predecessor, ou
sucessor, para realizar o sequenciamento. No caso da entrada de um caminho inválido, uma mensagem de erro como
a que segue abaixo será exibida.
Completando, não é possível sequenciar atividades de outros arquivos utilizando a aba Predecessors da tela Task
Information.
Não é necessário, porém é recomendável, que os

arquivos vinculados estejam abertos na máquina.
Qualquer usuário com acesso ao diretório no qual um
projeto está armazenado pode criar vínculos com este
projeto a partir de outros arquivos. Devemos ficar
atentos à tela ao lado, que informa que novos vínculos
foram criados com nosso projeto, ou que os existentes
foram de alguma forma alterados.
Percebemos que a melhor forma de realizar este sequenciamento é

através da opção Link Selected Tasks. Uma forma simples de criar um
projeto Master temporário que viabilize a utilização deste recurso é
através da opção New Window, encontrada na aba View. Usualmente,
esta função é utilizada para a criação de uma nova janela de visualização
do mesmo arquivo, no entanto, caso exista mais de um projeto aberto na
máquina, e caso os selecionemos na tela New Window, estes serão
incorporados a um arquivo Master, no qual poderemos sequenciar
nossas atividades rapidamente.
Fora do Master, nos subprojetos, quando existem links de atividades ou marcos de outros arquivos, estes são exibidos
com formatação visual diferenciada, para facilitar a identificação e avaliação do relacionamento entre os subprojetos,
o que colabora com a análise dos impactos sobre os demais envolvidos no planejamento e controle do projeto, e
identificação dos responsáveis a quem se deverá emitir comunicações e relatórios, sem que seja ter acesso a todo
ou outro subprojeto.
Vejamos como as precedências externas ao subprojeto Comissionamento são apresentadas neste arquivo.
É possível customizar a aparência das External Tasks através do Text Styles e do Bar Styles, recursos já
apresentados. O campo Project, sempre útil ao lidarmos com informações de diversos projetos, deve ser utilizado
com parcimônia do bar Styles, uma vez que imprime na tela todo o caminho do projeto, não somente seu nome.
Apesar dessa aparente poluição visual, recomendamos sua utilização para que fique bem claro que é uma fonte
externa ao projeto, e que de que fonte se trata.
10.2.2.2. Apresentação e análise do Projeto

As análises de tempo, recurso, custo e risco que apresentamos ao longo do livro podem ser utilizadas na gestão de
projetos Master de forma similar ao realizado em projetos atômicos. Entretanto, existe espaço para comentários que
podem auxiliar o desenvolvimento de modos de trabalho voltados à análise do empreendimento (arquivo com
subprojetos). Esperamos que os exemplos a seguir possam inspirar o desenvolvimento de outros.
Suponhamos que os subprojetos utilizem recursos a partir de um mesmo pool de recursos, e que se deseje avaliar a
utilização de um recurso específico ao longo do empreendimento, identificando os locais nos quais está alocado, para
levantar momentos em que este recurso está alocado em atividades sequenciais, em projetos distintos.
Podemos criar um modo com a screen Network diagram, aplicar um agrupamento por projeto, configurar o layout para
exibição somente do ID das atividades e ocultação dos produtos e filtrar as atividades para apresentação somente
daquelas nas quais este recurso está alocado. Abaixo, imagens que resumem as configurações realizadas.
Nesse momento é oportuno destacar a possibilidade de apresentar o caminho crítico de cada projeto componente (ou
subprojeto) ou do projeto “Master - Empreendedor”. Na figura abaixo, o diagrama de relacionamento apresenta o
caminho crítico pelos subprojetos. Isso foi
conseguido com o apoio de File, Options,
Advanced, sem marcar o “Calculate multiple
critical paths”.
Analisando desta maneira, o gestor de contratos ou gestor do empreendimento atuará sempre de forma geral, sem
se preocupar com os problemas individuais dos subprojetos e suas folgas livres ou totais. A missão nesse caso é
observar os interesses do projeto Master.
10.2.3. Análise das medições do Projeto por arquivo Master
Nesta ferramenta é essencial que cada medição do projeto seja preservada em arquivo com versão única para o
resgate posterior de informações parciais e de desempenhos específicos ao longo do tempo. Encontramos na
utilização de múltiplos projetos, uma boa oportunidade de modelar o controle do projeto de modo a facilitar a
verificação da evolução histórica de todas as características, de todos os elementos da ferramenta.
Tal resultado pode ser obtido facilmente com a configuração de um arquivo Master, que deve importar para sua
estrutura cada versão gerada pelo projeto, após cada medição. Para fixação deste conceito, recomendamos a criação
de um projeto simplório, composto de algumas poucas atividades, marco de início e término. Sequencie as atividades
e marcos, insira duração para as atividades e salve uma linha de base. Este será o arquivo que representará o
resultado do planejamento, a última versão aprovada antes da etapa de execução do projeto.
O projeto que usamos neste exemplo possui três atividades:
Task Name Duration Start Finish Predecessors

Projeto 25 days Mon 08/04/13 Fri 10/05/13
Início do Projeto 0 days Mon 08/04/13 Mon 08/04/13
Atividade 1 10 days Mon 08/04/13 Fri 19/04/13 1
Término do projeto 0 days Fri 10/05/13 Fri 10/05/13 4
Em seguida, com base na duração total do seu "projeto exemplo", defina o período de medição. No nosso caso,
definimos como semanal. Como nosso projeto possui atividades durante 5 semanas, teremos cinco medições do
andamento do projeto. Realizamos cada medição repetindo o seguinte procedimento:
1. Configuramos a Status Date para o término da semana de trabalho;
2. Inserimos os valores simulando a medição;
3. Salvamos uma cópia do arquivo (Salvar Como) com o nome referente à versão do projeto.
Podemos ver abaixo o resultado da primeira medição
Procedemos de maneira semelhante, realizando medições e criando cópias do projeto medido. Ao término das cinco
medições, teremos seis arquivos, o inicial e as cinco medições. Neste ponto, criamos um novo projeto e inserimos as
cinco medições com o recurso Subproject.
Inserimos as medições em ordem cronológica. Imediatamente podemos perceber, através do diagrama de Gantt, a
variação do término do projeto. Este é um exemplo imediato do que alcançaremos com todos os campos do MS
Project, ou seja, poder comparar seus valores em todos os arquivos dos projetos. Assim, se desejarmos saber como
o índice CPI de um pacote de trabalho variou ao longo das medições, basta-nos inserir este campo na tabela que
estivermos trabalhando e comparar os valores.
O recurso linha de base nos ajudará na comparação das informações medidas com as planejadas. Para verificar de
forma mais precisa como a data de término do projeto variou ao longo do tempo, expandiremos a visualização do
nosso outline level e selecionaremos o autofiltro do campo name para que exiba somente os marcos de término.
Ainda, ocultamos a visualização dos produtos e incluímos os campos Project e Finish Variance, que nos mostra a
diferença do Baseline Finish com o Finish.
Assim, onde antes tínhamos uma análise imediata, mais qualitativa que quantitativa, agora temos melhores condições
de verificar e comunicar a variação da data de término do projeto. Esta informação específica pode ser utilizada para
ilustrar o impacto de eventos ocorridos ao longo do projeto, e/ou das ações de controle da equipe do projeto. Podemos,
então, extrapolar esta utilização para qualquer campo da ferramenta, e onde não existirem campos naturais de
comparação, como o finish Variance que utilizamos, podemos utilizar os campos customizáveis da ferramenta, ou
ainda o apoio de gerenciadores de planilhas eletrônicas para organizar e trabalhar os dados em análise.
Percebemos na imagem anterior que a informação de linha de base se repete em todos os arquivos, o que pode
resultar em poluição visual em algumas análises. É possível inserir na estrutura do nosso arquivo Master o arquivo
de planejamento utilizado para salvar a linha de base, e, dessa forma, não necessitaremos exibir a representação
gráfica ou numérica dos campos da linha de base em nosso arquivo. Por exemplo, no exemplo no qual comparamos
a evolução da data de término do projeto, não necessitaríamos incluir a exibição da linha de base no diagrama de
Gantt, pois o marco de data de término do arquivo de planejamento já representaria, uma única vez, esta data.
Por fim, citamos campos cuja comparação do valor histórico deve ser perseguido, na maioria dos projetos, pela equipe
de planejamento e controle:
▪ Data de início e término de marcos estratégicos;
▪ Data de término do projeto;
▪ Indicadores de desempenho utilizados para métrica;
▪ Produtividade das atividades de grande volume ou duração (baseado no período de medição estipulado no
plano de controle);
▪ Custo de produtos estratégicos;
▪ Custo do projeto.
11. Anexos
A. Índice de Modos
Step 01 - WBS......................................................................................................................................... 49
Step 02 - Documentação da EAP ........................................................................................................... 64
Step 03 – WBS – ORG............................................................................................................................ 71
Step 04 – WBS + Atividades................................................................................................................... 91
Step 04 – WBS + Atividades - inf ........................................................................................................... 93
Step 04 – WBS + Atividades - sup.......................................................................................................... 91
Step 05 – WBS + Atividades - Relacionamento................................................................................... 101
Step 05 – WBS + Atividades – Relacionamento - Inf .......................................................................... 102
Step 05 – WBS + Atividades – Relacionamento - Sup......................................................................... 102
Step 06 – Atributos das Atividades ..................................................................................................... 104
Step 07 – Análise do Caminho Crítico ................................................................................................. 130
Step 08 - Diagrama de Rede - PDM ..................................................................................................... 140
Step 09 - Diagrama de Rede - Visão ORG............................................................................................ 147
Step 10 – Definição e documentação dos recursos ............................................................................ 160
Step 11A – Organograma – ORG ......................................................................................................... 173
Step 11B – Organograma - Habilidades .............................................................................................. 173
Step 12 – Alocação dos Recursos ........................................................................................................ 175
Step 13 – Alocação Detalhada ............................................................................................................. 187
Step 14 – Matriz de Responsabilidade (RACI) .................................................................................... 193
Step 15 – Mapa de Materiais .............................................................................................................. 196
Step 16 – Apresentar os Insumos do Projeto ..................................................................................... 198
Step 17 – Gerar o Histograma ............................................................................................................. 199
Step 18 – Solução de superalocação ................................................................................................... 209
Step 18 - Solução de superalocação – Inf ........................................................................................... 209
Step 18 - Solução de superalocação – Sup .......................................................................................... 209
Step 19 - Agenda dos Recursos ........................................................................................................... 217
Step 20 – Estimativa dos Custos.......................................................................................................... 233
Step 20b – Estimativa dos Custos - Cost ............................................................................................. 236
Step 21 – Dotação Orçamentária ........................................................................................................ 240
Step 22- Agrupamento dos Custos – ORG .......................................................................................... 242
Step 23 – Apresentação da Dotação Orçamentária ........................................................................... 243
Step 24 – Desembolso Financeiro ....................................................................................................... 245
Step 25 – Emissão do Plano de Trabalho ............................................................................................ 302
Step 26 – Folha de Medição – Controle T ........................................................................................... 313
Step 26 – Folha de Medição – Controle TWC .................................................................................................... 315
Step 26 – Folha de Medição – Controle TWC-Timesheet ..................................................................................... 317
Step 27 - Indicadores de Desempenho - EVM-CPI.............................................................................. 320
Step 27 – Indicadores de Desempenho – EVM ................................................................................... 319
Step 27 - Indicadores de Desempenho - EVM-SPI ............................................................................... 319
B. Desenhos e Imagens no Diagrama de Gantt

É possível Ilustrar o diagrama de Gantt com legendas para
melhor entendimento ou customização visual adequada à
emissão de relatórios e melhor comunicação com os envolvidos.
Com o uso de um editor de imagens é possível criar as legendas

necessárias para a ilustração do gráfico de Gantt, no próprio
modo de trabalho. A próxima etapa é incluir esse objeto gráfico
dentro da área do Gráfico de Gantt, através do “corta e cola”
intuitivo, já conhecido pelos produtos Microsoft.
A formatação desse objeto pode ser conseguida através do uso do botão direito do mouse diretamente sobre ele,
depois de incluído na área de Gantt.
Temos a reprodução das abas que a tela de formatação do objeto (objeto tipo imagem) disponibiliza. A primeira tela
acima mostra o estilo de linha e preenchimento da figura. Na segunda guia temos os recursos de amarração desse
objeto ao gráfico de Gantt e seu dimensionamento ou de forma absoluta ou ancorada a uma atividade em particular.
Contamos também com a possibilidade de inserção de formas geométricas simples na área do gráfico de Gantt, a
partir do grupo Drawings, item Drawing da aba Gantt Chart Tools Format, acessada como mostrado abaixo.
Incluir desenhos e caixas de texto no diagrama de Gantt para melhor entendimento. Através da barra de ferramentas
reproduzida ao lado, é possível incluir desenhos simples, mas que podem colaborar com o entendimento do diagrama,
como a criação de uma caixa ao redor das barras de algumas atividades para simular a criação de um grupo
Esse recurso permite ilustrar os elementos gráficos do diagrama de Gantt de forma a auxiliar seu entendimento ou
identificar a empresa que o criou. É possível criar linhas, setas e figuras simples, assim como caixa de texto. As cores
e configurações são definidas pelas propriedades dessas figuras e caixas de texto, sendo possível ainda ancorá-las
aos elementos gráficos das atividades e produtos principais da mesma forma que explicado anteriormente.
C. Organizador (Organizer)
Pode ser acessado pela aba Developer Item Organizer, ou nas telas Mora
Tables, More Groups, More Filters e Mora Views, item Organizer, e nos
serve para administrar os recursos Modos e elementos de composição
desses modos, a serem utilizados no projeto.
Uma vez que sejam definidos critérios ou modos especiais dentro de um

projeto, é possível compartilhá-los com outros projetos, ou até mesmo
torná-los referências para outros através do módulo “organizador” ou
“organizer”.
Através de 9 orelhas é possível transferir parâmetros e características entre os projetos e entre projetos e “referências
globais” do MSProject. A referência global é um arquivo contido na máquina que fornece informações para todos os
arquivos de MS Project gerados e visualizados nesta máquina.
Quando é aberto um arquivo novo para

inclusão das estruturas e do planejamento,
os modelos, referências e configurações
disponíveis são aqueles originais do
MSProject ou aqueles que foram
disponibilizados para o sistema. Usando o
“organizador” ou “organizer” é possível
intercambiar esses elementos. Essas
informações são gravadas e armazenadas
no arquivo “Global.MPT”, em que
percebemos que, pelo formato .mpt , trata-
se de um template.
São eles Views – Modos; Reports – Relatórios; Visual Basic for Applications modules – Módulos Programados em
VBA; Tables – Tabelas; Filters – Filtros; Calendars – Calendários; Export/import maps - Mapas de Dados para
Exportação e Importação; Fields (including custom fields) - Campos – Incluindo os campos personalizados; e Groups
– Grupos.
Uma vez que os critérios de trabalho de uma organização estão definidos, esses podem ser incluídos dentro do
“organizador”.
É importante que tenhamos a atenção na composição dos objetos antes de colocá-los à disposição do GLOBAL.MPT.
1 - Uma tabela, grupo ou filtro define um conjunto de campos dispostos e formatados de acordo com as conveniências
da apresentação dos dados desejados. Nesse caso, é importante lembrar que elas podem conter campos
personalizados.
2 – Um MODO ou Relatório pode ter uma tabela, um grupo ou um filtro específico e definido pelo usuário.
3 – Um MODO composto pode ter um MODO específico e definido pelo usuário.

Visto isso, devemos lembrar que, para um dos objetos criados funcionarem dentro do GLOBAL.MPT, todos os objetos
de apoio devem ser colocados à disposição também. Isso requer uma análise apenas do objeto que é limitado pelo
sistema: o objeto FIELD.
D. Filtros
Normalmente, os manuais e livros apresentam o recurso
de filtros de forma simplificada e sem explorar todos os
recursos que muitas vezes são necessários para as
simulações e análises que são necessárias e desejadas
em um projeto.
Os filtros são acessados através da sequência da aba

View, grupo Data, opção Filters. A partir deste ponto
poderemos selecionar um filtro que esteja sendo exibido
‘no menu’, gerenciar os filtros com More filters, criar um
novo filtro em New Filter, habilitar/desabilitar o autofiltro ou
remover o filtro atual em Clear Filter.
Caso não desejemos remover a visualização dos

elementos não contemplados pelo filtro, devemos utilizar
o recurso Highlight Filter, que destaca os elementos
‘filtrados’, mantendo os demais visíveis.
Durante nosso livro, desenvolvemos diversos filtros para

atender às necessidades de cada capítulo. Passemos agora para o detalhamento de cada possibilidade deste recurso.
Testes que o filtro na Versão 2013 pode efetuar:
• Equals: Apresenta ou evidencia as linhas na tabela de atividades ou

recursos cujo campo seja IGUAL ao conteúdo da coluna “Value”. Quando
aplicado a campos que possuem uma lista de valores, só aceita como
verdadeiro o critério se a linha em análise for de fato IGUAL ao valor para
teste.
• Does not equal: Apresenta ou evidencia as linhas na tabela de atividades

ou recursos cujo campo NÃO seja IGUAL ao conteúdo da coluna “Value”
• Is greater than: Apresenta ou evidencia as linhas na tabela de atividades

ou recursos cujo campo seja MAIOR QUE o conteúdo da coluna “Value”
• Is greater than or equal to: Apresenta ou evidencia as linhas na tabela de atividades ou recursos cujo campo
seja MAIOR OU IGUAL Ao conteúdo da coluna “Value”.
• Is less than: Apresenta ou evidencia as linhas na tabela de atividades ou recursos cujo campo seja MENOR que
conteúdo da coluna “Value”.
• Is less than or equal to: Apresenta ou evidencia as linhas na tabela de atividades ou recursos cujo campo seja
MENOR OU IGUAL Ao conteúdo da coluna “Value”.
• Is within: Apresenta ou evidencia as linhas na tabela de atividades ou recursos cujo campo estejam DENTRO
DO INTERVALO definido em dois valores da coluna “Value”.
• Is not within: Apresenta ou evidencia as linhas na tabela de atividades ou recursos cujo campo NÃO esteja
DENTRO DO INTERVALO definido em dois valores da coluna “Value”.
• Contains: Apresenta ou evidencia as linhas na tabela de atividades ou recursos cujo campo CONTENHA o
conteúdo da coluna “Value”.
• Does not contain: Apresenta ou evidencia as linhas na tabela de atividades ou recursos cujo campo NÃO
CONTENHA o conteúdo da coluna “Value”.
• Contains exactly: Apresenta ou evidencia as linhas na tabela de atividades ou recursos cujo campo SEJA DE
FATO encontrado dentro do conteúdo da coluna “Value”. Esse teste pode ser aplicado com mais propriedade em
campos que possuam múltiplas informações, como “Nome dos Recursos” ou “Atividades Predecessoras”, uma
vez que dentre uma relação de valores ele deve orientar a seleção para aqueles que contenham de fato o valor
apresentado para filtragem.
Forma de Inclusão de Valores de Teste na Versão 2013
• Valores que definem uma faixa para teste: Deve ser usado o caractere de separador de lista, definido na
configuração do seu sistema operacional. O primeiro valor é seguido do separador e, por fim, do segundo valor
da faixa.
• Usando um caractere coringa: Quando for interessante efetuar um teste tipo “pesquisa”, é possível utilizar os
caracteres “?” (ponto de interrogação) e “*”(asterisco) em qualquer parte do texto. No caso de um teste que seja
feito exatamente dentro de um asterisco ou ponto de interrogação é possível identificá-los utilizando o caractere
“^”(acento circunflexo) antes do caractere desejado.
• Filtros Interativos: Para criar filtros interativos é necessário colocar no campo “Value” uma mensagem ao
operador entre aspas e seguido, sem espaço, de um ponto de interrogação. Na caixa de texto que aparece na
caixa de diálogo (tela de apoio), deve ser introduzido pelo operador o parâmetro, ou parâmetros, de teste. É
importante observar que na mensagem devem estar claros os limites e tipos de valores a serem introduzidos.
• Filtros a partir de campos calculados: para criar um filtro a partir desse tipo de campo devemos referenciar
esse campo calculado na coluna “Value”. Esses campos devem vir dentro de “[ ] “ (colchetes).
• Filtros para detector “sem valor” atribuído: Nos campos que possuem datas, se for interessante detectar quais
linhas não possuem atribuição específica, é possível introduzir o “NA” (not available); em campos numéricos pode
ser utilizado o “0” (zero) e nos campos tipo texto apenas um “Enter” (vazio) é suficiente.
• Análise da Lógica Boolena: Quando trabalhamos com conectores de decisão temos que atentar para as suas
características.
Um conector do tipo “OR”, que significa “Ou”, toma como verdade na sua saída, quando pelo menos uma das suas
entradas é verdadeira (SIM). Nos conectores de decisão do tipo “AND” ou “e”, só teremos uma saída verdadeira se
TODAS as entradas forem satisfeitas.
A primeira coluna da tela de criação ou edição de filtros do MSProject apresenta a necessidade de introdução desse
conector a partir da sua segunda linha. Se não for escolhido pelo operador, o software considera como escolhida a
opção “AND”.
Apresentamos a seguir alguns filtros com suas descrições.
FILTRO - PDM ACTIVITIES I.

Para apresentarmos apenas as
atividades do nosso cronograma,
eliminando as linhas que demarcam os
produtos ou pacotes de trabalho
(Summary), dentre todas as linhas que
aparecem na tela, elaboramos uma
condição lógica composta.
Na primeira linha informamos que o filtro
estará eliminando as linhas “SUMMARY”;
esse flag é marcado com “Yes” quando a
linha é do tipo “SUMMARY”. Na segunda
linha, o filtro estará eliminando os
“MILESTONE”s. Esse campo também é marcado com o flag “Yes” quando a linha possui duração ZERO. Observe
que existe um “conector” do tipo AND para garantir que as duas condições têm de existir.
FILTRO - PDM ACTIVITIES II.

Esse filtro foi desenvolvido para
demonstrar que é possível introduzir uma
interação como o operador, através da
entrada de informações que concluirão a
definição do filtro.
No campo ”Value” foi introduzida uma
pergunta cuja resposta entrará na
composição e aplicação do filtro.
Para realizarmos essa tarefa, é
necessário introduzir ENTRE ASPAS, no
campo “Value”, a sentença de apoio e
esclarecimento do pedido de parâmetro,
seguida, sem espaço, de um PONTO DE INTERROGAÇÃO.
Dessa forma, só será apresentada a linha cuja condição seja
satisfeita na seguinte forma: “not summary” AND “not
milestone” AND “duration greater than x”; na qual“x” é
informado pelo operador.
FILTRO - PDM ACTIVITIES III


demonstrar que é possível introduzir um
grupo de decisores lógicos e incluir nele
a entrada de informações que concluirão
a definição do filtro pelo operador.
Se for necessário criar um grupo de

condições lógicas e seus resultados
submetidos a outras lógicas AND e OR, é
possível incluir após o primeiro grupo de
conectores uma linha em branco
escolhendo na coluna “and/or” o conector
desejado entre os grupos.
O filtro dentre todas as linhas seleciona aquelas que: atendiam ao primeiro grupo de lógica “and”, gerando somente
as “linhas atividades”, e aquelas que atendiam o segundo grupo de lógica “and”, fazendo ao final a comparação
daquelas que atendiam simultaneamente as duas.
FILTRO - PDM ACTIVITIES IV – FREE ACTIVITIES

demonstrar que é possível introduzir um
grupo de decisores lógicos, composto por
“and” e “or”, sendo seu resultado muito
útil à análise do planejamento.
Esse filtro permite que apresentemos as
linhas que representam as atividades E
que forçosamente não possuam
PREDECESSORES ou SUCESSORES.
Esse filtro é muito útil para garantir o

fechamento da rede de Precedências de
um projeto.
O primeiro grupo define se é uma atividade e o segundo grupo se existem linhas que não possuem uma atividade
sucessora OU uma atividade predecessora.
Recomendamos que este filtro seja utilizado com a opção highlight filter para verificar dentro do conjunto de atividades
aquelas que não atenderam ao critério de “bom comportamento”. Dessa maneira fica mais fácil visualizar as relações
que estão faltando e suas dependências.
FILTRO - REGRA DE 1-10% DO TEMPO

Essa regra é conhecida como uma referência de bom dimensionamento na duração das atividades que junto a outras
irão produzir um determinado pacote de trabalho para o projeto. Elas não devem ser maiores que 10% do tempo de
vida de um projeto, ou menores que 1% dele.
Esse filtro foi desenvolvido para demonstrar que é possível exemplificar os filtros a partir de campos calculados. Para
montar esse filtro é necessário utilizar o nome dos campos personalizáveis, usados como operadores, dentro de
colchetes. É importante lembrar que os campos têm que ser combatíveis.
Definimos inicialmente o campo NUMBER19 como um campo a ser utilizado por esse filtro e a ele deve ser associado
na hora da “exportação” desse filtro através do “organizer”,
conforme já mencionado. Esse campo foi renomeado para
“Regra 1-10%” e foi referenciado na tela de montagem do filtro
“Regra 1-10%”. É uma boa prática do uso do aplicativo
MSProject 2013 dar nomes semelhantes aos objetos que são
interdependentes.
Através da fórmula: [Duration]/(([Project Finish]-[Project

Start]))/60/8; inserida em um campo “Duration” disponível, é
possível estabelecer o filtro da “Regra de 1-10% “.
Estarão enquadrados dentro desse filtro as

“linhas” que: forem atividades (externas ou
não), e que tiverem sua duração menor que
1% ou maior que 10% do tempo total de
vida do projeto. Para eliminar as atividades
externas, devemos colocar mais uma
condição no primeiro grupo do filtro:
“ExternalTask” – “equals” - “No”
A partir dessa informação, se for conveniente, podemos melhorar o planejamento das atividades a serem realizadas,
repensando sua estrutura.
FILTRO - REGRA DE BOM COMPORTAMENTO DAS ATIVIDADES I

Esse filtro foi desenvolvido para demonstrar que é possível introduzir um grupo de decisores lógicos, composto por
“and” e “or” de maior complexidade, sendo seu resultado muito útil à análise do planejamento.
Algumas das boas práticas:
1 - Toda a atividade marco deve possuir

pelo menos um predecessor, e toda a
atividade ou marco deve possuir pelo
menos um sucessor. As únicas exceções
são o “início do projeto” e o “término do
projeto”.
2- Todas as relações entre atividades

devem evitar o retardo ou antecipação de
início promovidos pelo recurso de “lag”,
positivo ou negativo. Esse tipo de recurso
cria ou amplia as condições de risco na
execução das atividades envolvidas e,
portanto, deve ser evitado e, na sua
exigência, monitorado. Deve ser registrado e avaliado antes de se aceitar o planejamento como concluído.
No caso do nosso exemplo, eliminamos no nosso filtro os marcos; dessa forma, o filtro não estará monitorando esses
elementos.
3 – As ligações entre atividades devem sempre que possível ser do tipo “terminar-para-iniciar “(FS) no aplicativo. As
outras ligações e sequenciamento podem trazer problemas no algoritmo do software.
O primeiro grupo define a “atividade não externa” que não contenha nas suas ligações com predecessores
(automaticamente com os sucessores) “lags” ou folgas positivas ou negativas (+ e -); e que não sejam do tipo Iniciar-
para-Iniciar, Iniciar-para-Terminar e Terminar-para-Terminar.
Recomendamos a aplicação deste filtro com o recurso highlight.
FILTRO - REGRA DE BOM COMPORTAMENTO DAS ATIVIDADES II

demonstrar que é possível introduzir
campos de pesquisa pouco comuns nas
literaturas abordadas atualmente, sendo
seu resultado muito útil à análise do
planejamento.
As atividades devem ser definidas sempre

na forma de “o mais breve possível” para
a sua execução. Isso consequentemente
trará o planejamento para o mais breve
possível. É desejado por todos que os
custos fixos, aluguéis e outros sejam reduzidos ao máximo durante a realização de um projeto. Dessa maneira, as
únicas restrições possíveis a serem “desejadas” de aparecer numa atividade ou marco é: “ As soon as possible”; “
Start no sooner than”; “ Finish no sooner than”.
No caso de restrições contratuais legais de caráter social ou por determinação de forças externas ao projeto, muitas
vezes o planejamento deve refletir essas condições “emperrando” o bom funcionamento do software.
Nesses casos, o acompanhamento poderá ser feito pelo recurso “deadline” disponível na Guia “avançado” das
atividades.
Recomendamos a aplicação deste filtro com o recurso highlight.
FILTRO - INTERVALO DE CUSTOS

demonstrar que é possível permitir ao
operador a seleção de limites que
atendam a um intervalo de pesquisa. A
partir de dois valores apresentados, um
mínimo e o outro máximo, listar todas as
atividades que estejam dentro desse
perfil. A caixa de “show related summary
rows” foi marcada intencionalmente.
Dessa forma poderemos ver a
contribuição das atividades dentro dos
produtos.
Uma tela de apoio deve surgir solicitando os

valores.
Para auxiliar o operador do filtro, talvez seja
interessante colocar uma instrução dentro dos campos
disponíveis para evitar surpresas na aplicação desse
filtro. Quando os campos são incompatíveis o
MSProject não apresenta muitas explicações.
FILTRO - REGRA DA MEDIÇÃO E CONTROLE – ATIVIDADES

demonstrar, mais uma vez, que é
possível permitir ao operador a seleção
de valores limites que atendam a um
critério de análise. A boa prática de
controle de atividades e sua conclusão
apontam para que a duração das
atividades não superem o período de
medições de acompanhamento, com
exceção das atividades que sejam
contadas em dias corridos, por questão
de produção com métricas definidas.
Tipo “elapsed” como a “cura de concreto” ou “secagem da parede pintada” ou “aprovação de autoridades” (atividades
externas)
FILTRO - REGRA DE MEDIÇÃO E CONTROLE – PRODUTOS

Esse filtro foi desenvolvido para demonstrar novamente que é possível permitir ao operador a seleção de valores
limites que atendam a um critério de análise. A boa prática de controle dos pacotes de trabalho e sua conclusão
apontam para a avaliação do tempo em que haverá produtos em desenvolvimento durante um projeto que seja menor
que um período de medição e controle.
E. Criação de novo projeto a partir de arquivo Excel

Foi comentado no capítulo 1 a possibilidade de criação de um novo arquivo de MS Project a partir dos dados contidos
em um arquivo de MS Excel. Vejamos aqui como aproveitar da melhor forma possível esta importação.
Para este exemplo, criamos um arquivo simples no Excel com informações de atividades e recursos, conforme
mostrado abaixo.
Name Quantidade Máxima valor da hora
Recurso A 5 45,5
Recurso B 5 25
Recurso C 10 20
Recurso D 10 30
Recurso E 5 35
Outline level Name Duration Cidade Responsável

1 Projeto
2 Início do Projeto 0
2 Produto 1
3 Atividade 1 10 Rio de Janeiro André
3 Atividade 2 20 Rio de Janeiro Thiago
3 Atividade 3 20 Rio de Janeiro Júlio
3 Atividade 4 30 Salvador Teresa
3 Atividade 5 10 Salvador Bianca
2 Produto 2
3 Atividade 6 20 Rio de Janeiro André
2 Término do Projeto 0
Iniciamos nos dirigindo para File, New e selecionando a opção New from Excel workbook.
Uma janela de seleção será exibida nos pedindo que selecionemos o

arquivo que desejamos utilizar. Devemos reparar no canto inferior direito
um campo de seleção, no qual devemos escolher o formato do arquivo que
utilizaremos; no nosso caso, Excel Worknook.
A seguir, seremos recepcionados pelo Import Wizard, que nos guiará durante sua sequência de telas e do processo
de importação. Logo no início, temos a oportunidade de selecionar um map existente ou criar um novo. Um map, ou
mapa, é um conjunto de informações sobre equivalência de campos de um arquivo para o outro. No caso do Excel e
Project, esses mapas fazem referência ao nome dado às colunas da planilha excel e aos campos do Project que elas
representam; assim, os valores do excel serão transportados para o local correto.
Supondo que não temos um mapa desenvolvido, criaremos um novo.

Na tela seguinte, devemos escolher onde as informações importadas serão utilizadas: na criação de um novo projeto,
adicionando em um projeto existente (a partir da última linha) ou mesclando a um projeto existente. Selecionamos a
primeira opção.
Passamos para a seleção de que tipos de tabelas estamos importando. Lembramos que existem três tipos: atividades,
recursos e alocação. Podemos ter informação de todas as três sendo trazidas pelo arquivo .xlsx, no entanto,
entendemos que na maior parte do tempo desejamos trazer somente informações das tabelas task e resource, já que
a tabela assignment não é facilmente modelada no excel, o que pode levar à ocorrência de erros.
Recomendamos que as colunas da planilha excel contenham cabeçalho; portanto, marcamos a opção Import includes
headers.
Já perto da finalização, devemos fazer a equivalência de campos. Devemos selecionar a planilha onde estão
localizadas as informações da tabela Task e, em seguida, selecionar em “To: Microsoft Project Field” o campo no qual
desejamos incluir as respectivas informações. Na tela seguinte, repetimos para recursos.
O processo tendo ocorrido bem, receberemos a tela de

confirmação da importação e poderemos salvar o mapa
para reutilização no futuro.
O resultado da importação está mostrado abaixo para

a tabela Task. Podemos perceber que a importação
ocorreu com sucesso, inclusive a indentação.
F. Processos
i. Criar Tabela
ii. Criar Novo Filtro

iii. Criar Novo Grupo

iv. Criar Novo Modo

O uso de ferramentas para apoio aos trabalhos dos profissionais, tem se tornado nos últimos anos,
indispensáveis aos RESULTADOS. Tenho insistido muito no uso da palavra RESULTADOS, desde que vivi novas
demandas do mercado, naquilo que ele espera receber ao final, seja oriundo dos profissionais ou das empresas
contratadas.
Esse RESULTADO passou a ser sinérgico simultaneamente, e não exclusivamente, ao acordo
contratual e aos objetivos, missão e propósitos originais que demandaram esse projeto. Por consequência
observamos que isso se estabeleceu como um dos determinantes na avalição de desempenho dos profissionais
e empresas executantes. As ferramentas de apoio ao gerenciamento de projetos são de fato indispensáveis aos
bons RESULTADOS, sendo esses, rápidos e precisos. Temos utilizado essa ferramenta MSProject, em diversos
níveis e propósitos desde 1990, e reconhecemos seu potencial, tanto quanto as suas limitações. Podemos
afirmar que como ferramenta de alto nível, aliada sem dúvida à inteligência de seu uso e modelagem,
conseguimos os resultados iniciais ao planejamento e controle necessários.
Esta publicação, primeira registrada desse aplicativo no Brasil, em uso corrente em nossos
treinamentos desde o início desse ano, foi pré-lançada no 1º Fórum Global de Gerenciamento de Projetos
2013 promovido pelo PMIRIO, em agosto de 2013. Ela apresenta, extrapola e orienta o melhor uso de seus
inúmeros recursos, capacidade de apresentação de resultados e qualidade gráfica no exato limite das melhores
práticas de gestão de projeto, processo e uso de técnicas do aplicativo, em sua modelagem mais extensa
possível até o momento, mas também entende, declara, contorna as suas limitações.
Mais que a simples busca de manuais de uso, a busca pelas melhores ideias, aplicações e técnicas se faz
essencial agora. Busquemos agora resultados mais rápido e mais preciosos, e não apenas precisos. Os
“stakeholders” de mais alto nível agradecerão.
Marcus Possi
Sócio e Diretor da Ecthos Consultoria e Desenvolvimento
Editora

MSP13 Edicao Lancamento Revisao Gabriel.003-Site-0800

Enviado por

Dados do documento

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

MSP13 Edicao Lancamento Revisao Gabriel.003-Site-0800

Enviado por

Direitos autorais:

Formatos disponíveis

1

Gabriel Cardozo Prado, MCTS, SpP

Gabriel Cardozo Prado, MCTS, SpP

MS Project 2013: Uma Abordagem Sistemática

Editor: Marcus Possi

da Silva, Gabriel Cardozo Prado e Possi, Marcus

MS Project 2013: Uma Abordagem Sistemática

Rio de Janeiro: Editora Ecthos, 2013-08-20

MS Project 2013: Uma Abordagem Sistemática

ISBN: 978-85-66491-01-2 (e-book)

Dedico esta obra à minha família, pilar que me sustenta, e à

Mi tre amas vin.

Dedico esse trabalho aos meus filhos Luciana e Lucas Possi,

Agradeço primeiramente a Deus pelas luzes

Agradeço a Deus pela oportunidade de

No caso especial do Gerenciamento de Riscos, os autores trazem uma aplicação interessante de

Peter Mello, PMP, SpS, PMP

Este livro, ainda na fase de pré-lançamento, foi especialmente produzido na

Sendo no Brasil o primeiro livro de MSProject 2013 pela editora Ecthos,

Adicione o endereço www.ecthoscd.com.br e localize a editora.

Boa Leitura e bom trabaho,

2. Capítulo 02: Gerenciamento do Escopo ..................................................................... 37

3. Capítulo 03: Gerenciamento do Tempo ..................................................................... 77

4. Capítulo 04: Gerenciamento dos Recursos .............................................................. 153

5. Capítulo 05: Gerenciamento dos Custos .................................................................. 223

5.2.1. Estimativa dos Custos do Projeto ................................................................................. 233

6. Capítulo 06: Gerenciamento dos Riscos................................................................... 249

7. Capítulo 07: Desenvolvimento do Cronograma ....................................................... 263

8. Capítulo 08: Monitoramento e Controle ................................................................. 293

8.1.2. Apresentação Gráfica. .................................................................................................. 295

9. Capítulo 09: Gerenciamento da Comunicação ......................................................... 325

10. Capítulo 10: Gerenciamento de Múltiplos Projetos ................................................. 351

11. Anexos ................................................................................................................... 367

F. Processos ................................................................................................................................. 386

1. Capítulo 01: Introdução

1.1. Introdução Teórica ao planejamento de projetos

1.1.1. Globalização e as Estruturas Econômicas

O processo de globalização pelo qual passou a economia de todos os países do mundo

Mudanças são melhorias ou novas ideias.

1.1.2. As Organizações e os Impactos das suas mudanças

IPMA – International Project Management Association (Associação Internacional de Gerenciamento de

PMI – Project Management Institute (Instituto de Gerenciamento de Projetos)

Devemos lembrar que, conforme comentado, os trabalhos executados

1.1.4. O Estudo do Gerenciamento dos Projetos

 O Capítulo 1 - A Introdução define os termos chaves e apresenta uma

1.1.5. Fases dos Projetos e o seu Ciclo de Vida

1.1.6. Os Interessados do Projeto

1.1.7. Os Processos e o Projeto

Os projetos são compostos por processos. Um processo é “uma série

Processo de Iniciação – É a etapa inicial do projeto, quando

Os processos apoiados pela ferramenta MSProject 2013 estão destacados aqui.

1.2. Introdução à Ferramenta MS Project 2013

O Project começa a sua história em 1984, dentro do ambiente MS DOS, e em

1.2.1. O Ambiente de Trabalho

1 Application Item ou Backstage

2 Quick access toolbar

Se apresenta como uma barra de ferramentas customizável, na qual o usuário pode

É possível ainda de ser apresentada abaixo do Ribbon, selecionando-se a opção

Caso não esteja visualizando esta aba, é possível que ela

4 Tool tabs ou Contextual tab set

Abaixo temos exemplos de tool tabs, ou Contextual tab sets

Esse é um controle que apresenta uma coletânea de itens

No exemplo ao lado, mostramos a galeria de formatação pré-

Como exemplo, mostramos o grupo font,