Gerenciamento de Projetos Fundamentos e Pratica Integrada - 1 Edição - Marta Rocha Camargo - 2014 PDF

Gerenciamento
de Projetos
Gerenciamento
de Projetos
Fundamentos e Prática Integrada
Marta Camargo
© 2014, Elsevier Editora Ltda.
Todos os direitos reservados e protegidos pela Lei n° 9.610, de 19/02/1998.
Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida ou
transmitida sejam quais forem os meios empregados: eletrônicos, mecânicos, fotográficos, gravação
ou quaisquer outros.
Copidesque: Lucas de Souza Cartaxo

Revisão: Bruna Baldini
Editoração Eletrônica: Thomson Digital
Elsevier Editora Ltda.

Conhecimento sem Fronteiras
Rua Sete de Setembro, 111 – 16° andar
20050-006 – Centro – Rio de Janeiro – RJ – Brasil
Rua Quintana, 753 – 8° andar
04569-011 – Brooklin – São Paulo – SP
Serviço de Atendimento ao Cliente

0800-0265340
atendimento1@elsevier.com
ISBN 978-85-352-6366-4
ISBN digital 978-85-352-6367-1
Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer
erros de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a
comunicação ao nosso Serviço de Atendimento ao Cliente, para que possamos esclarecer ou
encaminhar a questão. Nem a editora nem o autor assumem qualquer responsabilidade por
eventuais danos ou perdas a pessoas ou bens, originados do uso desta publicação.
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO

SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
C176g
Camargo, Marta Rocha

Gerenciamento de projetos: fundamentos e prática integrada / Marta Rocha
Camargo. - 1. ed. - Rio de Janeiro : Elsevier, 2014.
28 cm
ISBN 978-85-352-6366-4
1. Administração de projetos. 2. Empreendimentos. 3. Planejamento estratégico.

I. Project Management Institute. II. Título.
13-03453 CDD: 658.404

CDU: 65.012.3
Sobre o Autor
Marta Rocha Camargo é Project Management Professional (PMP®), título obtido em 2010 pelo Project
Management Institute (PMI), e ph.D. em Administração de Empresas Aplicada à Tomada de Decisão, com es-
pecialização em Liderança e Mudanças Organizacionais pela Walden University, Minnesota, Estados Unidos
(2006), revalidado no Brasil pela Universidade de São Paulo como doutorado em Administração de Empresas
em 2009. É também mestre em Administração de Empresas, com especialização em Gestão de Sistemas
de Informação pela Westminster College, em Salt Lake City, Utah – Estados Unidos (1998), revalidado pela
Universidade Federal do Rio Grande do Sul (UFGRS) como mestrado profissional em 2006.
Sua experiência profissional inclui 12 anos como gerente de projetos na área de localização e interna-
cionalização de produtos de software em multinacionais de grande porte como WordPerfect, 3COM, Novell
e Adobe Systems, onde gerenciou centenas de projetos de pequeno, médio e grande porte para cerca de
20 mercados internacionais em todos os continentes.
Lecionou a disciplina Gestão de Projetos nos cursos de Tecnologia da Informação e Administração de
Empresas da Faculdade Prudente de Moraes em Itu (São Paulo) entre 2007 e 2010, onde coordenou a Agência
de Projetos da instituição, gerenciando cerca de 40 projetos de conclusão de curso cujos temas abrangeram
soluções a problemas reais em empresas da região, projetos de tecnologia da informação e melhorias da
infraestrutura de organizações sem fins lucrativos.
Atualmente, é professora da disciplina de Gestão de Projetos no MBA em Gestão Empresarial e no MBA
em Gestão Estratégica da Tecnologia da Informação, e também da disciplina de Gerenciamento de Escopo
no MBA em Gerenciamento de Projetos da Rede FGV Management em todo o Brasil, desde 2008. Orienta
também Projetos de Conclusão de Curso do MBA em Gerenciamento de Projetos, tendo sido responsável,
até 2013, por cerca de 50 projetos em diferentes áreas, dentre as quais destacam-se as engenharias civil e
mecânica, a bancária, a tecnológica e os novos negócios.
Agradecimentos
Agradeço aos profissionais de gerenciamento de projetos com quem trabalhei na área de localização e
internacionalização de produtos de software, pois eles me ensinaram muito, principalmente no que se refere à
comunicação das necessidades e informações de projetos complexos para equipes de diversas nacionalidades
e formações profissionais.
Também agradeço aos meus clientes de consultoria, que me oferecem oportunidades de aplicar e
customizar práticas de gerenciamento de projetos nos mais variados ambientes organizacionais e culturais.
Deixo agradecimentos especiais a todos os meus alunos pelo incentivo e pela motivação para que eu
colocasse minha experiência em um material prático e integrado – e com exemplos, muitos exemplos! Espero
ter alcançado esse objetivo, e que este livro sirva como um guia para ajudá-los com sugestões de práticas,
ferramentas, ideias e dicas para utilização no dia a dia.
Também agradeço a contribuição dos seguintes colaboradores:
• Equipe de projeto composta por Ivan Scaravelli (líder do projeto), Elias Libânio, João Benedetti e Paulo
Campos, que realizou um projeto de implantação de práticas de sustentabilidade a uma rede de super-
mercados na cidade de Itu (São Paulo), o qual serviu como inspiração para o projeto aplicado deste livro.
• Equipe de projeto composta por Eliana Sassagima (líder do projeto), Cristiano Sandrin, Renato César
Queiroz e Roniselton Barreto, da cidade de Cuiabá, estado do Mato Grosso, pelos exemplos de documentos
de projeto.
• Stephen Zhu, cofundador da XMind Ltd., por autorizar as referências e indicação da utilização do programa
de software livre XMind em diversas partes deste livro.
• Equipe da editora Elsevier, em especial ao gerente editorial Marco Pace, pelo apoio e auxílio no desenvol-
vimento deste livro.
Apresentação
Nos dias de hoje, é cada vez mais comum encontrar profissionais de áreas diferentes – como engenheiros,
arquitetos, analistas de sistemas, programadores, contadores, médicos, veterinários, advogados, entre outros
– atuando como líderes de projetos ou membros de uma equipe de projeto. Muitas vezes, esses profissionais
recebem um treinamento genérico, baseado primariamente em material teórico que, por vezes, tende a
confundir mais do que esclarecer.
Há casos também de gerentes de projetos recém-formados em cursos de Gerenciamento de Projetos em
escolas de graduação ou pós-graduação que conhecem a teoria, mas não conseguem entender como tudo
aquilo se traduz na prática da empresa onde trabalham. Muitos desses profissionais acreditam que há uma
distância muito grande entre o que dizem os conceitos dos manuais de gerenciamento de projetos e o que a
realidade do dia a dia na empresa ou organização onde atuam impõe a eles.
Há ainda casos de gerentes de projetos veteranos que são profundos conhecedores de conceitos e ferra-
mentas sofisticadas, mas têm dificuldades em fazer com que a equipe do projeto execute corretamente as
tarefas que foram planejadas. Esses profissionais veteranos criam documentação de projeto que ninguém lê
ou segue, acarretando atrasos e retrabalhos nos projetos.
Este livro vem ao encontro dessa demanda por um material prático e real para a realização de projetos,
dentro de uma abordagem amigável, fácil de entender e aplicar, voltada a um público e contexto empresarial
e organizacional multidisciplinar.
Objetivo
O objetivo deste livro é apresentar, de forma prática e integrada, os conceitos principais em gerenciamento
de projetos expressos no Project Management Book of Management (PMBOK) do Project Management Ins-
titute (PMI) para aqueles que estão iniciando na área de projetos. Profissionais experientes também poderão
se beneficiar com inúmeros exemplos de documentação de projetos e dicas valiosas de como formular e
comunicar as informações de um projeto a todos os envolvidos.
A quem se destina
Alunos de graduação, pós-graduação e profissionais de qualquer área que queiram ou precisem aprender
processos e técnicas para gerenciar projetos.
Do que este livro trata (escopo incluído)

Faz parte do escopo deste livro uma cobertura dos principais conceitos das áreas de conhecimento do PMBOK:
• Integração
• Escopo
• Tempo
• Custos
• Qualidade
• Recursos Humanos
• Comunicações
• Riscos
• Aquisições
• Partes Interessadas
Por meio de exemplos práticos e aplicações dos conceitos, cada capítulo oferecerá sugestões sobre o que
fazer em cada área de conhecimento, com ideias para elaboração de documentos e utilização de ferramentas
específicas quando necessário.
Do que este livro não trata (escopo excluído)
Não faz parte do escopo deste livro:
• Conteúdo específico ou exercícios de preparação ao exame de certificação para o Project Management
Professional (PMP®).
• Detalhamento de todos os capítulos e processos do PMBOK: o conteúdo aqui apresentado foi adaptado
de forma a cobrir os itens mais importantes de cada capítulo do PMBOK e incorporá-los em uma
metodologia de trabalho fácil de entender e utilizar, considerando o dia a dia de um gerente de projetos
iniciante.
• Explicações detalhadas ou passo a passo para a utilização das ferramentas sugeridas em alguns capítulos:
como são ferramentas comuns e populares a profissionais que trabalham com projetos, parte-se do pres-
suposto de que o leitor terá condições de baixar as ferramentas das fontes livres sugeridas nos capítulos e
utilizar o software por si só ou fazer buscas na internet (ou outras fontes) para obter material informativo
sobre os recursos das ferramentas.
Organização do conteúdo
O conteúdo dos capítulos baseia-se nos princípios do Project Management Book of Knowledge (PMBOK) do
Project Management Institute (PMI), porém não segue à risca sua lógica. No PMBOK, iniciação, planejamento,
execução, monitoramento e controle e encerramento são tratados como processos, não como fases de um
projeto. Fases de um projeto pertencem a ciclos de vida específicos para cada setor ou indústria.
Para fins de aprendizado a um nível iniciante, a proposta deste material é facilitar o entendimento
colocando o projeto em uma linha de tempo lógica. Todo projeto tem um começo, é planejado, executado,
monitorado e controlado e, depois, encerrado. Dessa forma, cada capítulo segue uma linha de raciocínio
fácil de acompanhar para a realização de um projeto simples por um gerente de projeto iniciante na área de
gerenciamento de projetos.
Obviamente que essa sequência lógica pode variar de projeto a projeto. É premissa deste livro que é
importante, em primeiro lugar, ter um ponto de partida para entendimento dos conceitos essenciais às
atividades de gerenciamento de projetos para, posteriormente, ajustar essa forma de trabalhar a uma
metodologia de gerenciamento de projeto mais sofisticada e adaptada à realidade de cada projeto e de cada
empresa ou organização.
Como este livro está estruturado?

A parte I, Introdução ao Gerenciamento do Projeto, é um apanhado geral com base na literatura existente
sobre o assunto. É interessante observar que o gerenciamento de projetos não é algo que surgiu nos tempos
modernos, mas tem sua origem em grandes projetos que fazem parte da história da humanidade. O que se
aprende com a história é que, até mesmo em projetos considerados impossíveis para determinada época,
princípios de uma boa gestão dos recursos (financeiros, humanos, materiais etc.) garantiram o sucesso – e
seus resultados podem ser vistos até os dias de hoje.
O segundo capítulo na parte II, Princípios Básicos em Gerenciamento de Projetos, aborda princípios que
são normalmente colocados em glossários ou anexos a um livro-referência. Porém, é importante que esses
princípios sejam entendidos antes que o leitor passe para a forma de gerenciar projetos, que será vista nos
capítulos posteriores, para evitar confusões no entendimento das diferentes áreas de conhecimento. O
capítulo seguinte, Nascimento de um Projeto, trata das fases de pré-projeto e iniciação de um projeto.
Já a parte III, Planejando o Projeto, aborda todas as áreas de conhecimento do PMBOK. Em cada capítulo,
planeja-se o projeto a partir de documentação e ferramentas específicas.
A parte IV, Realizando o Projeto, trata dos aspectos relacionados à execução do projeto. Nela, o projeto
que foi iniciado e planejado nos capítulos anteriores será executado, monitorado e controlado e encerrado.
Importante! Há uma repetição proposital de determinadas informações nos documentos de gerencia-
mento de projeto. Isso se dá, porque certos documentos podem ser enviados para diferentes pessoas ou
grupos trabalhando nos projetos. Além disso, uma informação definida no início do projeto pode ser neces-
sária para o entendimento de uma tarefa no decorrer ou no final do projeto. Essa repetição é comum nas
documentações do projeto e, muitas vezes, esperada para ênfase e confirmação de entendimento por todos
os envolvidos no projeto.
Convenção tipográfica
O conteúdo dos capítulos será dividido em seções que seguirão uma convenção gráfica para fácil consulta
e referência:
1. C
onceito: Para cada área de conhecimento do PMBOK, foram extraídos os pontos mais
importantes e essenciais ao gerenciamento de um projeto de nível iniciante. Nessa parte
do capítulo, o conceito é explicado sob o ponto de vista do PMBOK, de uma forma sim-
plificada e objetiva.
2. N
a prática: Essa seção cobrirá exemplos de como o conceito pode ser utilizado na vida
real.
3. A
plicação: Essa seção é uma espécie de um projeto-estudo de caso que será realizado no
decorrer deste livro. Assim, um projeto de implantação de práticas de sustentabilidade em
um supermercado será iniciado, planejado, executado, monitorado e controlado e, depois,
encerrado.
Atenção! Os exemplos práticos e aplicados servem apenas para ilustrar o conteúdo apresentado. Como
todo projeto é único e exclusivo, não é recomendável utilizar esse material (pelo menos não na forma
em que se encontra nas seções) em projetos reais sem que se faça uma análise e uma adaptação para as
necessidades específicas de cada projeto e de cada empresa ou organização.
4. F
erramentas: Quando houver ferramentas específicas para a realização das tarefas mais
comuns em uma determinada área, haverá explicações sobre as ferramentas e os recursos
mais utilizados naquela área.
5. D
icas úteis: Nos casos em que a prática for muito abrangente, haverá dicas úteis com
base nas experiências de gerentes de projeto veteranos. Essas dicas abrangerão desde
ferramentas até técnicas ou atalhos para que o projeto seja feito de forma eficiente e
eficaz.
6. I mportante: Observações importantes com relação a uma determinada parte do concei-

to ou prática que estiver sendo explicada.
7. E
xercícios: Ao final de cada capítulo, haverá exercícios para praticar o que foi aprendido.
Esses exercícios irão gerar a documentação para um projeto de reforma de uma loja de
roupas femininas.
8. M
aterial de apoio: Esse símbolo indicará a necessidade de baixar um material específico
para realização do exercício na página do livro no site da Editora - www.elsevier.com.br/
martacamargo.
Convenção da documentação de projeto nos exemplos
Para uma consistência no tipo de informação e garantia da exatidão do conteúdo dos documentos de
gerenciamento de projetos, é importante estabelecer uma padronização, conforme mostrado a seguir:
FIGURA A.1 Modelo de documento padrão.
Recursos de apoio na web

• Modelos de documentos originais para gerenciamento de projetos mencionados nos capítulos.
• Modelos de formulários específicos para a realização dos exercícios no final de cada capítulo.
• Videoclipes com demonstrações das ferramentas de software mencionadas nos capítulos.
• Documentos originais e completos do Plano de Gerenciamento do Projeto (Plano de Gerenciamento da
Integração) e seus anexos, conforme projeto aplicado deste livro.
• Exemplos adicionais de documentos de planejamento de projetos.
• Exemplos adicionais de análises estratégicas de pré-projeto.
• Respostas aos exercícios do final de cada capítulo (acesso restrito ao professor)
• Apresentações em PowerPoint de cada capítulo (acesso restrito ao professor).
PA RT E
I–
Introdução ao Gerenciamento
de Projetos
Muitas pessoas acreditam que o gerenciamento de projetos surgiu no século XIX ou no século XX, com o
surgimento da disciplina de Administração. Apesar de ter se tornado popular no século XX, o gerenciamento
de projetos está presente na forma de trabalhar do homem há muito tempo, como será descrito a seguir.
CAPÍTULO 1 Breve História do Gerenciamento de Projetos............................................................03

1
Breve História do Gerenciamento de Projetos
OBJETIVOS DE APRENDIZAGEM
Após o estudo deste capítulo, você será capaz de:
• Entender a evolução do gerenciamento de projetos.
• Saber como o gerenciamento de projetos foi aplicado em obras históricas da humanidade.
• Conhecer as tendências atuais em gerenciamento de projetos.
1.1 Obras Históricas

O gerenciamento de projetos é realmente algo que veio com o surgimento da disciplina de Adminis-
tração de Empresas nos meados do século XIX? Ou será que seus conceitos podem ser encontrados em
marcos históricos da construção civil, como a Muralha da China?
O projeto da Muralha da China levou 1.588 anos para ser concluído e atingiu uma extensão de
2.300 quilômetros de distância. Acredita-se que milhões de trabalhadores – na sua maioria, escravos
que trabalhavam até a exaustão –, foram utilizados em todos esses anos de construção. O material e as
técnicas de construção variavam à medida que os tempos evoluíam e novas tecnologias de construção
eram introduzidas (SIDAOUI, 2004) (Figura 1.1).
FIGURA 1.1 Muralha da China. © Margaretwallace | Dreamstime.com.
E quanto aos grandes projetos de infraestrutura, como os aquedutos e as estradas, construídos pelo
Império Romano (24 a.C.–476 d.C.) nos territórios conquistados? Aquedutos eram canais que corriam
no subsolo ou na superfície e levavam a água das fontes até as cidades romanas. Durante a época do
Império Romano, esses canais de água eram construídos de forma precisa para manter uma leve in-
clinação que permitia o transporte da água até os pontos de abastecimento. Esses aquedutos formavam
sistemas complexos, como o sistema dos onze aquedutos que forneciam água a Roma; um deles chegava
a ter 90 km de extensão (AICHER, 1995). Muitos desses aquedutos podem ainda ser vistos em vários
pontos da Europa, conforme o exemplo na Figura 1.2.
3
4 Gerenciamento de projetos
FIGURA 1.2 Aqueduto romano em Segóvia, Espanha. © Mariusz Prusaczyk | Dreamstime.com.
Já o famoso ditado “todos os caminhos levam a Roma” não é força de expressão: a engenharia romana
utilizada nos projetos de construção de estradas era tão sofisticada que, de fato, todo o sistema “rodo-
viário” (uma parte desse sistema é mostrada na Figura 1.3) de aproximadamente 150 mil quilômetros
foi construído para levar produtos, serviços, pessoas e animais das diversas partes do Império até sua
capital – Roma – e vice-versa (DUIKER; SPIELVOGEL, 2007).
FIGURA 1.3 Mapa de trecho das estradas romanas. © Joanne Zh | Dreamstime.com.
Essas estradas eram tão resistentes que sobrevivem até os dias de hoje, como pode ser visto na
Figura 1.4.
FIGURA 1.4 Exemplo de estradas romanas. © Witr | Dreamstime.com.

Capítulo 1 • Breve História do Gerenciamento de Projetos 5
Para projetos tão grandes e complexos, deve ter havido alguma organização dos recursos humanos,
financeiros e naturais, bem como um tempo predeterminado para entrega da obra, em vista das neces-
sidades políticas e econômicas dos líderes da época.
Segundo Walker e Dart (2011), o estudo das grandes obras da Antiguidade, principalmente no
Império Romano, demonstra que havia práticas e processos de gerenciamento de projetos similares
aos que praticamos hoje. Os gerentes de projetos antigos, por exemplo, planejavam, executavam
e gerenciavam seus recursos dentro de prazos e de um escopo bem claro e definido. A diferença
entre o que os autores chamam de “gerentes de projetos acidentais” daquela época e os gerentes de
projetos profissionais de hoje é a forma como passou a ser feita a execução desses processos, que
se transformou com o avanço nas tecnologias de produção: foram introduzidas novas ferramentas
para o planejamento, monitoramento e controle de projetos. Também houve uma evolução nas
necessidades do homem em relação ao seu trabalho: passou-se de uma obrigação ou questão de
honra nos tempos do Império Romano para uma forma de escolha e realização profissional nos
dias de hoje.
Considerando que há um paralelo entre os grandes projetos da humanidade e o moderno gerencia-
mento de projetos, Kozak-Holland (2011) realizou estudos com o auxílio de profissionais das áreas de
engenharia, história e arquitetura para analisar grandes obras da construção civil, como:
• o Parthenon, na Grécia (447–438 a.C.), cuja construção teve como principal objetivo gerar trabalho
para a população grega e estimular a economia da época. Completado em nove anos, foi um marco
na arquitetura, copiado até os dias de hoje (Figura 1.5);
FIGURA 1.5 Parthenon em Atenas, Grécia. © Vassilis | Dreamstime.com.
• o Coliseu, construído em um período de dez anos e localizado em Roma (69–79 d.C.), na Itália, no qual
se utilizou vários tipos de matérias-primas consideradas revolucionárias para a época (o concreto,
por exemplo) e mão de obra especializada, composta por soldados romanos, escravos, engenheiros
e empreiteiros (Figura 1.6);
FIGURA 1.6 Coliseu em Roma, na Itália. © Vladimir Sazonov | Dreamstime.com.
• a Basílica de Santa Sofia (532–537 d.C.), construída em Constantinopla (área que atualmente
corresponde a Istambul, na Turquia) em uma área de terremotos foi concluída em cinco anos.
Construída com materiais flexíveis e executada a partir de projeto inteligente, a Basílica já sobreviveu
a inúmeros terremotos e seu projeto é copiado em outras partes do mundo, especialmente nos países
muçulmanos (Figura 1.7);
FIGURA 1.7 Basílica de Santa Sofia em Istambul, Turquia. © Jackmalipan | Dreamstime.com.
• e as Pirâmides de Gizé (2550–2530 a.C.), no Egito; a criação das bases das pirâmides apresentou muitos
desafios técnicos pois deveriam estar exatamente no mesmo nível para a construção das câmaras
fúnebres (Figura 1.8).
FIGURA 1.8 Pirâmides de Gizé, Egito. © Witr | Dreamstime.com.

Considerando as Pirâmides de Gizé, Kozak-Holland (2011) fez um paralelo entre as ações da época
e as áreas de conhecimento atuais de gerenciamento de projetos, conforme resumo apresentado na
Tabela 1.1 a seguir.
Tabela 1.1 Construção das Pirâmides de Gizé e Áreas de Gerenciamento de Projetos
Área de conhecimento Aplicação no Projeto das Pirâmides de Gizé
Escopo Havia uma Estrutura Analítica do Projeto que serviu como base ao planejamento do escopo
e tempo.
Preparação do local
Terraplenagem
Colocação de base sólida
Determinação do sentido norte
Criação de blocos de pedra calcária
em quadrados perfeitos
Construção
Criação de um porto e canal no Rio Nilo
Criação da vila dos trabalhadores
Construção de rampas
Operações de pedreiras
Transporte da pedra acabada
Realização do trabalho de acabamento
Tempo O faraó Khufu estava com 40 anos e tinha uma expectativa de vida de 60 a 70 anos.
Havia um prazo claro para a conclusão do projeto – antes de o Faraó morrer ou,
aproximadamente, vinte anos.
A equipe do projeto calculou 10 anos para a extração do granito para o teto da câmara
funerária do rei. No décimo ano do projeto, a pirâmide deveria apresentar uma altura de
45,72 metros e estar pronta para a construção da câmara fúnebre.
Qualidade A precisão nas medidas foi fundamental para o sucesso do projeto.
Cada lado tem 230 metros de comprimento, em um alinhamento quase perfeito
de 15 milímetros. As dimensões da pirâmide são bastante precisas, e o local da obra
foi igualado em termos de centímetros sobre uma base de 5,3 hectares.
Recursos Humanos A força de trabalho não era apenas escrava. A grande maioria era de fazendeiros que
recebiam salários e benefícios. Registros da época mostram que búfalos e carneiros eram
enviados ao local da obra para alimentar os operários e mantê-los motivados. Havia incentivos
também no abatimento de impostos para quem trabalhasse na construção da pirâmide.
Comunicações A organização da comunicação seguia uma hierarquia estilo militar, de cima para baixo,
feita, na sua grande parte, oralmente. Havia serviço de mensageiros que levavam e traziam
informações sobre o projeto em papiros e mantinham o fluxo de informação entre as partes
interessadas em diversos pontos da região.
Riscos Como os riscos de acidentes eram altos, os equipamentos e as ferramentas utilizados foram
desenvolvidos para evitar movimentos bruscos que causassem deslocamentos de pedras ou o
desequilíbrio dos operários. Os blocos maiores eram colocados por meio de rampas que davam
acesso direto ao posicionamento na pirâmide. Buscava-se manter a ocorrência de acidentes no
nível mais baixo possível, para não afetar o moral e a produtividade dos operários.
Aquisições Havia uma rede de fornecedores de materiais dentro e fora da região da obra, bem como um
sistema para transporte, recebimento e pagamento do material fornecido no local da obra.
Além de Kozak-Holland (2011), outros autores, como Chiu, em um livro de 2010 intitulado An In-
troduction to the History of Project Management: From the Earliest Times to A.D.1900, analisaram grandes
projetos ao longo da história sob a perspectiva do moderno gerenciamento de projetos e descobriram
várias similaridades no gerenciamento do tempo, dos custos e das pessoas – semelhanças que confirmam,
acima de tudo, a necessidade de algum tipo de organização formal dos recursos para a conclusão dos
projetos.
À medida que o homem evoluiu e suas necessidades ficaram mais sofisticadas, o número de projetos
necessários para acompanhar essa evolução e reduzir o tempo de entrega desses projetos aumentou.
Os três últimos séculos, particularmente, trouxeram grandes avanços nas práticas de gerenciamento
de projetos e no papel do gerente de projetos, conforme explicado a seguir.
1.2 Século XIX

O século XIX foi marcado por obras governamentais de infraestrutura de grande porte nos Estados
Unidos, as quais ofereciam um nível cada vez maior de complexidade devido à escala dos projetos.
Projetos de construção de linhas de trem transcontinentais por volta de 1870, por exemplo, exigiam
dos gerentes dos projetos a habilidade de organizar o trabalho de milhares de operários, sem falar na
fabricação e montagem de quantidades exorbitantes (para a época) de material de construção para as
obras (KOZAK-HOLLAND, 2011). Nenhum método formal de gerenciamento das tarefas e dos recursos
foi desenvolvido nessa época, porém as empresas começaram a perceber que era necessário estabelecer
uma maior organização e um maior controle do trabalho e dos trabalhadores para que as obras fossem
terminadas dentro do tempo e do custo esperados (Figura 1.9).
FIGURA 1.9 Construção das ferrovias no século XIX. © Georgios Kollidas | Dreamstime.com.
1.3 Século XX
Os primeiros registros de ferramentas específicas para gerenciamento de projetos surgem no início
do século XX na figura de Henry Gantt, que desenvolveu as primeiras técnicas de planejamento e con-
trole de um projeto.
Seguindo os passos das teorias de administração científica de Frederick Taylor, Gantt começou a observar
o trabalho dos operários na construção de navios da marinha norte-americana na época da Primeira Guerra
Mundial para identificar atividades e as durações dessas atividades. Durante esses estudos, Gantt desenvolveu
um método de utilizar gráficos com barras de tarefas e marcadores de pontos importantes do projeto, deli-
neando a sequência e a duração de todas as tarefas no processo da produção (CHIU, 2010). Esses gráficos ou
diagramas de Gantt se tornaram uma ferramenta valiosa para os gerentes da época, pois assim conseguiam
ter uma visão melhor da duração do trabalho e da utilização dos recursos para executar esse trabalho. Eles
auxiliavam, também, na comparação entre trabalho planejado e trabalho realizado (Figura 1.10).
FIGURA 1.10 Exemplo de um gráfico de Gantt. Fonte: Modelos de Cronograma do MS Project.

Outro aspecto importante da história do gerenciamento de projetos ainda no século XX é o inves-

timento do governo norte-americano em projetos de energia atômica e nuclear a partir dos anos
1940. Um marco da época foi o Projeto Manhattan, que durou de 1942 a 1945, pioneiro em pesquisa e
desenvolvimento para a produção de bombas atômicas, envolvendo cerca de 125 mil trabalhadores a
um custo de aproximadamente dois bilhões de dólares (KELLY, 2004) (Figura 1.11).
FIGURA 1.11 Pesquisas nucleares no projeto Manhattan. © Witold Krasowski | Dreamstime.com.
Além de projetos associados a armas nucleares, os anos 1950 foram marcados também pelos grandes
projetos de conquista espacial, com o início da operação da NASA (National Aeronautics and Space
Administration – Administração Nacional da Aeronáutica e do Espaço, em português) em 1958.
Ainda disponível na internet (o endereço eletrônico encontra-se nas Referências ao final deste livro),
o manual do gerenciamento do programa Apollo (NASA-Apollo Program Management), de 1967, detalha
todas as informações do programa, com vários elementos do moderno gerenciamento de projetos, como
divisão em fases, estrutura analítica, realização em uma estrutura matricial, linhas de base, requisitos,
riscos, aquisições etc. (Figura 1.12).
FIGURA 1.12 Missões Apollo. © Philcold | Dreamstime.com.
Como esses projetos eram extremamente complexos na sua logística e dispendiosos nos seus gastos,
o congresso do governo norte-americano começou a exigir uma organização e documentação para
definir o trabalho e, principalmente, justificar e comprovar os gastos e as despesas (VERZUH, 2008).
Começaram a surgir, então, modelos matemáticos para demonstrar informações de projetos.
Por volta de 1958, surgiu o Program Evaluation and Review Technique ou PERT, desenvolvido pela
marinha norte-americana como parte do programa do míssil do submarino nuclear Polaris (trabalho em
conjunto com a Lockheed Corporation). A ideia era trabalhar com um método quantitativo e probabilís-
tico para estimar as durações das atividades, em situações nas quais essas durações eram incertas. Em
linhas gerais, o PERT apresentava uma ilustração gráfica de um projeto como um diagrama de rede
formado por nós numerados (que podiam ser círculos ou retângulos) representando eventos ou marcos
do projeto conectados por meio de vetores (STRETTON, 2007). A direção das setas nas linhas indicava
a sequência das tarefas, como pode ser visto na Figura 1.13.
FIGURA 1.13 Exemplo de um PERT simples.
Outra ferramenta para auxiliar profissionais no gerenciamento de projetos surgiu mais ou menos
na mesma época, entre 1956 e 1958, e foi denominada Critical Path Method (CPM) ou método do
caminho crítico, desenvolvido em conjunto pela DuPont Corporation e a Remington Rand Corporation
para projetos de manutenção de plantas industriais. Diante de um número muito grande de projetos,
as empresas procuravam formas de reduzir o tempo de conclusão de um determinado projeto inves-
tindo mais em certas partes dele. A ideia era a seguinte: identificar partes do projeto que afetavam sua
data de conclusão e decidir se alocar mais recursos a essas partes traria benefícios, como a redução dos
prazos de entrega (WEAVER, 2006). A Figura 1.14 ilustra (caminho em negrito) o caminho crítico para
um projeto a exemplo do PERT.
FIGURA 1.14 PERT-CPM mostrando o caminho crítico (caminho mais longo).
O método do caminho crítico concebido naquela época é basicamente o mesmo que continua sendo
utilizado nos dias de hoje. Conhecido agora como PERT-CPM, o método do caminho crítico permite
definir a sequência das atividades para que o projeto seja concluído dentro do prazo estipulado. É o
caminho mais longo das atividades que compõem o projeto, desde o início até o fim, e determina a data
de conclusão ou entrega final do projeto. Se uma das atividades que se encontra no caminho crítico
não for concluída no tempo determinado, isso significa que o projeto terá um atraso. É por isso que é
importante entender a sequência das atividades no caminho crítico, pois um atraso em uma atividade
crítica afeta o prazo final do projeto. Um aspecto interessante do PERT-CPM é evidenciar o fato de que,
quando o projeto está atrasado, não adianta alocar recursos para tarefas fora do caminho crítico, pois
elas não afetam as datas finais. As tarefas do caminho crítico sempre terão prioridade nesse sentido.
Por volta de 1959, Haugan (2002) menciona que Malcolm, Roseboom, Clark e Fazar publicaram
um estudo sobre o Program Evaluation and Review Technique (PERT) que incluía um gráfico com os
principais componentes do projeto Polaris, que viria a se chamar Work Breakdown Structure (WBS),
conforme exemplo na Tabela 1.2 a seguir.
Tabela 1.2 Subsistemas do Projeto Polaris
Subsistemas do Programa de Míssil Balístico da Frota
Míssil Corpo de reentrada
Guia
Revestimento balístico
Propulsão
Controle de voo
Disparador
Navegação
Controle de disparo
Navios
Comunicações de comando
Fonte: Adaptado de Haugan (2002).
Ainda segundo Haugan (2002), em junho de 1962, o Departamento da Defesa dos Estados Unidos e
a NASA publicaram um documento para orientar o desenho de um sistema de custo com base no PERT.
Esse documento continha uma descrição de uma WBS, similar à forma em que é feita hoje, conforme
ilustrado na Figura 1.15.
FIGURA 1.15 WBS em documento da NASA de 1962. Fonte: Adaptado de Haugan (2002).
Os anos 1960 foram marcados por grandes projetos nas áreas de construção civil, bélica e aeroespa-
cial. Nesse período, a disciplina de Gerenciamento de Projetos passou a ser reconhecida e conduzida por
um profissional denominado gerente de projetos. Começaram a aparecer instituições dedicadas a essa
área com o objetivo de reunir profissionais com interesses similares e compartilhar práticas comuns.
Uma das primeiras instituições a padronizar os processos de gerenciamento de projetos foi o Project
Management Institute (PMI). O PMI é uma instituição sem fins lucrativos, fundada em 1969 por cinco
voluntários na cidade de Filadélfia, estado da Pensilvânia, nos Estados Unidos.
À medida que os negócios evoluíam e o mercado se tornava cada vez mais competitivo, principal-
mente a partir dos anos 1980, as empresas começaram a perceber que precisavam encontrar formas
de trabalho mais eficientes e utilizar seus recursos ao máximo para atender aos prazos cada vez mais
curtos de seus clientes internos e externos.
Como já visto, para que se tornassem mais competitivas e assim acelerassem o tempo de entrega
de seus produtos e serviços ao mercado, as empresas começaram a compartilhar uma estrutura orga-
nizacional com base em projetos gerenciados pelo seu gerente de projetos, que organizava o trabalho
e assegurava a integração e a comunicação do fluxo de trabalho entre profissionais e funções diferentes.
Dentro dessa nova visão organizacional multidisciplinar, tornou-se necessário padronizar as práticas
de gerenciamento de projetos.
Em 1987, os conceitos e os processos de gerenciamento de projetos praticados por diversas ins-
tituições foram consolidados em um guia chamado PMBOK – Guide to the Project Management Body
of Knowledge (Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos) –, organizado pelo
PMI. Esse guia oferece uma estrutura básica para entender o gerenciamento de projetos e o ambiente
no qual o projeto ocorre. O PMBOK oferece também uma visão geral da maneira como os diversos
processos de gestão interagem durante a realização de projetos.
A segunda versão do PMBOK foi publicada em 1996, a terceira em 2000 e a quarta em 2008. Em 2013,
o PMI lançou a 5ª edição do manual, com a criação de uma nova área de conhecimento: Partes Interes-
sadas. Atualmente o PMBOK está disponível em 10 idiomas: alemão, árabe, chinês, coreano, espanhol,
francês, italiano, japonês, português e russo.
Empresas no mundo todo vêm adotando os processos e as áreas de conhecimento do PMBOK para
garantir uma consistência nas formas de gerenciar seus projetos, principalmente quando se trata de
empresas grandes ou multinacionais com operações em vários países.
O guia está organizado por áreas de conhecimento (ver Tabela 1.3) e processos de gerenciamento de
projetos (ver Tabela 1.4). Cada área de conhecimento se refere a um aspecto a ser considerado e tratado
pela gerência de projetos.
Tabela 1.3 Áreas de Conhecimento do PMBOK

Área de Conhecimento Descrição
Integração Permite que os diversos elementos do projeto sejam coordenados de forma eficiente e uniforme.
Escopo Assegura que o trabalho necessário, e apenas o necessário, seja realizado de forma a concluir
o projeto de forma bem-sucedida.
Tempo Assegura que o projeto seja realizado dentro do prazo previsto.
Custos Assegura que o projeto seja concluído dentro do orçamento aprovado.
Qualidade Garante que o projeto satisfaça necessidades ou requisitos para os quais foi idealizado.
Recursos Humanos Torna a utilização dos recursos humanos mais eficiente durante a realização do projeto. Define
os papéis e as responsabilidades – quem vai fazer o que no projeto.
Comunicações Registra e administra a coleta, a disseminação e o armazenamento das informações do projeto.
Riscos Identifica, analisa e responde aos riscos do projeto.
Aquisições Obtém bens e serviços externos ou terceirizados, bem como cuida da administração de
fornecedores, provedores, licitações e contratos.
Partes Interessadas1 Prevê uma identificação e um registro abrangentes das partes interessadas. Prevê, também, o
gerenciamento e o monitoramento das inter-relações das partes interessadas de forma a garantir o
nível de envolvimento ou engajamento adequado de cada uma em diferentes pontos do projeto.
1
A área de conhecimento Partes Interessadas foi introduzida no início de 2013, na 5ª edição do PMBOK.
Tabela 1.4 Processos do PMBOK

Processo Descrição
Iniciação Processo que trata principalmente da obtenção da autorização do projeto
ou, em um projeto com várias fases, de uma fase do projeto. É o processo
necessário para a documentação das necessidades de negócios relacionados
ao projeto.
Planejamento Processo que permite a coleta de informações de muitas fontes para desenvolver
os planos de gerenciamento para cada área de conhecimento do projeto.
Execução Processo em que o trabalho definido no plano de gerenciamento do projeto é
realizado.
Monitoramento e Controle Processo que observa a execução do projeto para resolver problemas à medida
que ocorrerem, alinhando também a execução ao planejamento e controlando-o
para que apenas mudanças aprovadas sejam implantadas.
Encerramento Nesse processo, as atividades do projeto são formalmente encerradas.
O PMI oferece uma certificação chamada Project Management Professional (PMP®), concedida
a quem consegue demonstrar, avaliado por uma prova, a experiência efetiva em gerenciamento de
projetos, com pleno conhecimento dos conceitos e das abordagens de projetos descritos no PMBOK.
A primeira certificação PMP® foi estabelecida em 1984.
Além da certificação PMP®, os padrões PMI de gerenciamento de projetos incluem os PMOs ou
Project Management Offices, escritórios de gerenciamento de projetos que são basicamente locais
físicos dentro das empresas onde profissionais especializados e credenciados nos processos do PMBOK
orientam e dão suporte a outros gerentes, equipes e partes interessadas dos projetos. Um PMO funciona
como um centro de operações e informações para acompanhamento do projeto e da resolução de dú-
vidas e problemas relativos a processos e objetivos. Ele pode operar continuamente, prestando suporte
a gerentes de projetos com treinamentos, softwares, modelos de documentação etc., ou arcando com a
responsabilidade pelos resultados do projeto.
Há vários centros de informação do PMI em cidades de todo o mundo. Chamados de capítulos
(do inglês chapters), esses centros fornecem informações sobre certificações e eventos. No Brasil,
há 13 capítulos nos seguintes estados: Amazonas, Bahia, Ceará, Distrito Federal, Espírito Santo,
Goiás, Minas Gerais, Paraná, Pernambuco, Rio de Janeiro, Rio Grande do Sul, Santa Catarina e
São Paulo.
O site do PMI no Brasil é http://www.pmi.org.br. Nesse endereço eletrônico poderão ser encon-
tradas informações sobre sites regionais, cursos, eventos e materiais relativos a gerenciamento de
projetos.
1.4 Século XXI

No Brasil e no mundo, o PMI se tornou o padrão em gerenciamento de projetos. Cursos de graduação
e pós-graduação incluíram programas específicos para gerenciamento de projetos cujos módulos se
baseiam nos conceitos do PMBOK.
Vagas para contratações no setor de engenharia (todas as áreas), tecnologia da informação, suporte
técnico e outras, geralmente incluem exigências de conhecimentos ou certificações em gerenciamento
de projetos. Mesmo quando o cargo de gerente de projetos não é o pretendido, as empresas esperam que
os colaboradores conheçam a forma de trabalhar voltada para projetos, a qual segue uma metodologia
consistente de trabalho.
Independentemente do cargo ou da posição na empresa, o profissional impreterivelmen-
te atuará ou como gerente, coordenador ou líder de projetos, ou como membro da equipe de um
projeto.
Exercícios
1. Dentre todas as grandes obras citadas neste capítulo, qual delas você consideraria o maior desafio
se fosse o gerente de projetos? Justifique sua resposta.
2. Qual a diferença entre as práticas de gerenciamento de projetos de 2 mil anos atrás e as atuais?
3. Que participação teve a NASA na história do gerenciamento de projetos?
4. Quando o Project Management Institute (PMI) foi criado e com que finalidade?
5. Quais as áreas de conhecimento e os processos do PMBOK? No que eles consistem?
PA RT E
II–
Começando o Projeto
Muitos iniciantes em gerenciamento de projetos adquirem livros ou outros materiais ou iniciam cursos na
área que discutem processos e documentos de projetos já utilizando a terminologia específica de gerenciamento
de projetos segundo o PMBOK.
Antes de mais nada, é importante entender determinados termos-chave1 que fazem parte das descrições de
atividades e documentos envolvidos no gerenciamento de qualquer projeto. Após entender esses termos-chave,
o gerente de projetos estará pronto para dar início a um projeto, conforme os processos e procedimentos
explicados a seguir.
CAPÍTULO 2 Princípios Básicos em Gerenciamento de Projetos......................................................17

CAPÍTULO 3 Nascimento de um Projeto............................................................................................25
1
O original em inglês de alguns termos ficará entre parênteses, pois muitos iniciantes trabalham em empresas globais (ou que
prestam serviços para empresas globais) nas quais se utilizam alguns dos termos em inglês e outros em português.
2
Princípios Básicos em Gerenciamento
de Projetos
• Entender conceitos importantes relacionados ao gerenciamento de projetos.
• Conhecer a aplicação dos conceitos do gerenciamento de projetos por meio de exemplos práticos.
• Utilizar esse embasamento conceitual como preparação ao entendimento dos próximos capítulos.
2.1 Introdução
Este capítulo irá explicar os conceitos que serão repetidamente utilizados nas descrições e práticas
de cada área de gerenciamento de projeto. O objetivo é que isso sirva como uma referência desses
conceitos para facilitar o entendimento do conteúdo descrito e aplicado no decorrer dos vários capítulos
que formam este livro.
2.1.1 Projeto
Projeto é um esforço temporário (com começo, meio e fim) empreendido para criar um resultado
exclusivo. Projetos existem em todos os níveis organizacionais e devem ser gerenciados de uma forma
consistente e eficiente, independentemente do seu tamanho. Os princípios contidos no PMBOK (que
serão discutidos e demonstrados no decorrer deste livro) pressupõem projetos complexos e de grande
porte, como o desenvolvimento de um novo produto ou serviço, o desenvolvimento de um novo modelo
de veículo, a construção de um prédio ou uma casa, uma campanha publicitária ou de marketing, uma
campanha de vacinação ou a realização de um concurso nacional.
Nas mesmas empresas que desenvolvem esses projetos de grande porte poderá haver projetos de
pequeno porte, que deverão ser gerenciados seguindo princípios similares para que toda a organização
de projetos da empresa trabalhe de forma consistente.
São exemplos de projetos de pequeno porte: o desenvolvimento de um programa de treinamento,
a criação de um website, o desenvolvimento de uma nova estratégia de vendas ou a elaboração de um
sistema de avaliação da qualidade dos serviços prestados aos clientes de um restaurante.
2.1.2 Cliente
Há dois tipos de clientes de projetos: interno e externo. Cliente interno é um representante de
uma divisão, departamento ou unidade internos à organização que está realizando o projeto. Esse
cliente será o receptor de produtos, resultados ou serviços oriundos de um projeto. Cliente externo
é uma pessoa ou organização externa que compra os produtos, resultados ou serviços oriundos de
um projeto.
A diferença básica entre os dois tipos de clientes é que os clientes internos são pessoas conectadas
com a empresa, enquanto os clientes externos não fazem parte da organização que está realizando
o projeto. As necessidades e os requisitos de ambos os tipos de clientes devem ser satisfeitos para
que o projeto tenha sucesso.
2.1.3 Objetivo
Objetivo é o porquê ou a razão de se fazer um projeto. Não é uma lista das atividades ou tarefas de
um projeto; é uma explicação do motivo de se fazer o projeto em vista das necessidades da organização.
17
Os objetivos são fundamentais para comunicar claramente as expectativas de resultados, planejar

estratégias, medir o desempenho e conseguir o resultado desejado. Hoje em dia, as empresas ou
organizações não podem desperdiçar tempo e dinheiro com projetos que não lhe tragam benefícios
mensuráveis ou que não lhe agreguem valor.
Um objetivo deve ser SMART, que em inglês significa “inteligente ou esperto”. SMART é um acrônimo
para:
• S (Specific) – o objetivo deve ser específico na definição clara e inequívoca do resultado desejado.
• M (Measurable) – o objetivo deve ser mensurável, ou seja, medido e avaliado com números.
• A (Achievable) – o objetivo deve ser alcançável, ou seja, deve estar dentro da realidade da empresa
ou da organização.
• R (Relevant) – o objetivo deve ser relevante, alinhado com a visão da empresa da ou organização,
pois deve estar de acordo com seus objetivos estratégicos.
• T (Time-Framed) – o objetivo deve estar dentro de um limite de tempo ou prazo específico, de forma
a permitir que os resultados sejam verificados e confirmados.
Exemplo: O objetivo de investir na produção e lançamento de um determinado novo produto
é aumentar as vendas da empresa na região Sudeste em 20%, dentro do segmento de produtos infantis,
em um prazo de um ano após o lançamento da primeira linha.
2.1.4 Escopo
Escopo é o trabalho que será feito para entregar o produto final de acordo com os objetivos e requi-
sitos previstos para o projeto. O escopo do projeto é definido de forma progressiva. Na fase de iniciação,
há informações preliminares sobre o produto final ou o resultado esperado do projeto. No planejamento,
os limites do escopo (o que será feito em linhas gerais e exclusões específicas) são estipulados em um
documento chamado Declaração de Escopo.
Após esses limites serem aprovados pelas partes interessadas, o escopo é detalhado, considerando-se
fases, subprojetos, entregas e pacotes de trabalho na Estrutura Analítica do Projeto (EAP). O Dicionário
da EAP descreve os pacotes de trabalho e fecha o ciclo de definição no escopo do projeto. O escopo
deverá ser monitorado durante a execução do projeto para que não saia da linha de base (veja neste
capítulo, mais adiante, a definição de linha de base).
Há também o escopo do produto, que não deve ser confundido com o escopo do projeto. Enquanto
o escopo do projeto identifica todo o trabalho que deverá ser feito no projeto, o escopo do produto
identifica características, recursos, especificações, funcionalidades e requisitos que deverão estar in-
corporados no resultado, produto ou serviço que o projeto irá gerar.
Exemplo: Projeto de desenvolvimento de um novo software.
• Escopo do produto: O software deverá conter duzentos itens de menu principal, quinhentos arquivos
de ajuda formato HTML, cinco tutoriais com as operações principais, testes em todos os sistemas
operacionais e testes de usabilidade em um departamento piloto na empresa do cliente final.
Com base nesses itens do escopo do produto, são criados os itens no escopo do projeto:
• Escopo do projeto: O escopo do projeto contempla a concepção, o desenvolvimento, os testes, o piloto
em um departamento da empresa e a homologação de uma versão 2.5 do software X.
2.1.5 Estrutura Organizacional

A função do gerente do projeto varia de acordo com a estrutura organizacional em que os projetos
são realizados. A estrutura organizacional define o nível de autoridade e autonomia que o gerente de
projetos terá para administrar os recursos do seu projeto. Há três estruturas organizacionais básicas
que afetam o trabalho do gerente de projetos: a funcional, a projetizada e a matricial. Cada uma dessas
estruturas tem vantagens e desvantagens que se adéquam, em grande parte, à natureza do produto do
projeto. A Tabela 2.1 resume cada estrutura, com as respectivas vantagens e desvantagens.
Capítulo 2 • Princípios Básicos em Gerenciamento de Projetos 19
Tabela 2.1 Resumo das Diferentes Estruturas Organizacionais, com Suas Vantagens e Desvantagens
Estrutura Definição Vantagens Desvantagens
Funcional O gerente do projeto está Funciona melhor em pequenas O papel do gerente do projeto é garantir a boa
subordinado a uma das áreas organizações em que as execução de processos e projetos, porém o
funcionais da empresa, como diferentes seções estão gerente funcional centraliza a tomada de decisão.
vendas, suporte técnico, geograficamente próximas O gerente do projeto tem autoridade limitada e
contabilidade, setor financeiro e que fornecem apenas um um plano de carreira sem muitas perspectivas.
ou tecnologia da informação. pequeno número de bens e/ou
serviços.
Uma vantagem da estrutura
funcional vem do papel do
gerente funcional, que é o
encarregado de gerenciar os
recursos. Esse gerente funciona
como o único chefe para
decisões sobre o projeto. Isso
reduz ou impede conflitos
entre as áreas funcionais e as
áreas de projeto, facilitando o
gerenciamento dos recursos.
Projetizada Todo o trabalho faz parte de um O gerente do projeto tem o Como a equipe se dispersa após a conclusão
projeto. Não há departamentos controle completo, e todos do projeto em uma estrutura projetizada, há a
ou áreas funcionais. Os os membros da equipe se ausência de metas de longo prazo ou garantia
membros da equipe são reportam diretamente a ele. Há de emprego aos colaboradores, que se sentem,
permanentes ou contratados uma melhor comunicação, pois também, “sem teto”, ou seja, quando o projeto
como recursos temporários todos estão trabalhando com acaba, eles não têm para onde ir, pois não
para trabalharem no projeto dedicação exclusiva ao projeto pertencem a áreas funcionais. Se não houver
em período integral até sua e se reportam a apenas uma novos projetos, eles perdem o emprego.
conclusão. pessoa: o gerente do projeto.
Matricial A estrutura matricial combina Uma vantagem da estrutura Devido à certa complexidade de gerenciamento
a estrutura funcional com a matricial é a utilização eficiente das partes, esse tipo de estrutura pode levar a
projetizada. Cada membro dos recursos. Quando há problemas se não for bem administrado. Uma
da equipe tem dois chefes: o projetos compatíveis com as boa comunicação é essencial para o sucesso do
gerente funcional e o gerente habilidades dos recursos, eles projeto. Por exemplo, se o gerente funcional e o
do projeto. Se a matriz for forte, são chamados para participar; gerente do projeto não se relacionarem bem, os
o poder estará mais com o do contrário, continuam seus membros da equipe poderão ficar no meio de
gerente de projeto. Se a matriz trabalhos nas respectivas áreas conflitos, causando confusão e retrabalho. Há
for fraca, o poder estará mais funcionais. também um problema de saber qual a prioridade
com o gerente funcional. – se é o projeto ou se é o trabalho funcional – e
quem resolve a situação no caso de conflitos –
gerente funcional ou gerente do projeto.
2.1.6 Linha de Base (Baseline)

A linha de base é uma medida de desempenho ou do sucesso do projeto. Uma linha de base mede
a capacidade de o projeto cumprir os requisitos conforme o planejado. O PMBOK prevê três linhas de
base principais como medidas de sucesso do projeto: escopo, tempo e custo.
A linha de base do escopo é a soma de todas as entregas do projeto. Essa linha de base representa
todo o trabalho que deve ser realizado e concluído pelo projeto. Entregas (ou deliverables) não inclusas
na linha de base do escopo não serão realizadas.
Portanto, a linha de base do escopo inclui:
• Declaração de Escopo aprovada pelas partes interessadas;
• Estrutura Analítica do Projeto;
• Dicionário da EAP.
A linha de base do tempo engloba o cronograma de todo o trabalho que será realizado para compor
as entregas definidas no escopo. Cada atividade do cronograma é um item do trabalho necessário para
produzir as entregas definidas para o projeto. Atividades que não contribuem especificamente para as en-
tregas definidas no escopo do projeto não podem fazer parte do seu cronograma e, portanto, não podem
ser executadas.
Embora a linha de base de custos esteja normalmente associada ao valor do orçamento final do
projeto, Mulcahy (2009) e a nova versão do PMBOK (5ª Edição) esclarecem que essa linha de base é, na
verdade, formada pelo valor do orçamento total do projeto menos as reservas gerenciais (consulte o
capítulo 7, Custos). Dessa forma, a linha de base de custos inclui os custos relativos a todas as atividades
do projeto mais as reservas de contingência (custos conhecidos) associadas aos riscos, porém sem as
reservas gerenciais (custos desconhecidos).
Há também a linha de base da qualidade, vinculada a padrões específicos de qualidade para deter-
minados projetos, como os padrões de Total Quality Management – TQM ou o ISO 9000.
2.1.7 Premissa ou Suposição (Assumption)

Premissa é aquilo tido como certo no projeto. Normalmente, as premissas são itens que o gerente
de projetos dá como certo e acordado para dar início ao projeto.
Nesse caso, o gerente do projeto manifesta suas premissas às partes interessadas do projeto para
obter uma validação às suas suposições iniciais ou uma modificação nas suposições que forem falsas.
Suposições ou premissas podem mudar durante o projeto e precisam ser monitoradas, pois podem
representar um risco à sua consecução.
Exemplos de premissas:
• Os recursos que irão trabalhar no projeto são: a, b, c e d.
• A equipe de projeto será a mesma até o término do projeto.
• O orçamento do projeto já foi aprovado.
• O projeto contará com o apoio da diretoria do departamento até a sua conclusão.
2.1.8 Parte Interessada (Stakeholders ou os Envolvidos no Projeto)

Partes interessadas são todas as pessoas ou organizações que possuem um envolvimento direto ou
indireto no projeto e que podem afetá-lo positivamente ou negativamente. O PMBOK utiliza a tradução
partes interessadas, porém em organizações que trabalham com projetos é comum manter o termo em
inglês: stakeholders.
Exemplos de partes interessadas ou stakeholders de um projeto:
• Cliente: a pessoa ou organização que irá utilizar o produto do projeto.
• Organização executora: a empresa cujos funcionários estão diretamente envolvidos na execução
do trabalho do projeto.
• Membros da equipe do projeto: a equipe que está executando o projeto.
• Outros: proprietários e provedores de fundos, fornecedores e contratados, membros da equipe e seus
familiares, agências governamentais e meios de comunicação e cidadãos comuns, além da sociedade
em geral.
2.1.9 Patrocinador (Sponsor)

Pessoa, grupo ou organização que fornece os recursos financeiros para a execução de um projeto.
São exemplos de patrocinadores:
• Diretor financeiro.
• Banco ou qualquer agente financiador.
• Dono da empresa.
2.1.10 Entregas (Deliverables ou Entregáveis)

Qualquer documento, produto ou resultado tangíveis e verificáveis produzidos para terminar um
processo, fase ou projeto.
São exemplos de entregas:

• Plano do projeto
• Cronograma
• Programa (software)
• Protótipo
• Piloto
• Apostila
2.1.11 Pacotes de Trabalho (Work Packages)

São as unidades de trabalho que serão necessárias para compor a entrega. São os últimos itens na
hierarquia da Estrutura Analítica do Projeto.
Por exemplo a (Figura 2.1) a seguir.
FIGURA 2.1 Exemplo de pacote de trabalho.
2.1.12 Atividades ou Tarefas (Activities, Tasks)

Uma atividade é um componente do trabalho realizado no decorrer de um projeto. As atividades
consomem tempo e recursos e são melhor descritas utilizando-se verbos de ação. As atividades fazem
parte do gerenciamento de tempo de um projeto e são detalhadas no cronograma. São exemplos de
atividades para os pacotes de trabalho do item anterior (Figura 2.2).
2.1.13 Recursos (Resources)

Na terminologia do gerenciamento de projetos, segundo o PMBOK, o termo, recursos, na maioria
das vezes, se refere aos recursos humanos. Mas tais recursos podem ser também recursos físicos, como
equipamentos ou materiais, e recursos financeiros, como fundos ou orçamento.
Exemplos:
• Engenheiro de software
• Assistente financeiro
• Gerente do produto
• Analistas
• Programadores
FIGURA 2.2 Exemplo de atividades.
2.1.14 Restrição (Constraint)

Restrição é todo e qualquer fator limitante à execução do projeto. É basicamente um estado, qualidade
ou sentido que impõe restrição a uma determinada ação ou inatividade; algo que afetará o desempe-
nho do projeto ou de um processo. Normalmente, as restrições críticas do projeto refletem os fatores
da restrição tripla.
Exemplos:
• O orçamento desse projeto não deverá ultrapassar R$ 500.000,00.
• Este projeto deverá estar encerrado até o final do segundo bimestre deste ano, não sendo permitida,
em hipótese alguma, prorrogação desse prazo.
2.1.15 Restrição Tripla (Triple Constraint)

A restrição tripla (conhecida também como triple constraint) descreve o equilíbrio entre o escopo,
o custo e o tempo de um projeto.
A qualidade foi adicionada depois da criação desse triângulo, subentendendo-se que se encaixa
dentro do escopo. Em todo o projeto, é importante que o término se dê até certa data, que deve ser
determinada de acordo com o valor, o custo ou ambos. Da mesma forma, as entregas do projeto nor-
malmente devem seguir especificações mínimas (qualidade) para serem úteis à organização (Figura 2.3).
Durante o planejamento do projeto, o gerente de projeto trabalha com sua equipe para definir o
escopo, o cronograma, o custo e a qualidade do projeto. À medida que o projeto evolui, é comum per-
ceber que o plano precisa de ajustes ou que as partes interessadas estão solicitando mudanças. Se a
solicitação de mudança incorrer em aumento do escopo, então pelo menos um dos outros vértices do
triângulo também sofrerá mudanças. Por exemplo, se for solicitado que se aumente o escopo da localiz
ção de um software para incluir um novo idioma, será necessário gastar mais dinheiro para alocar mais
recursos ou gastar mais tempo para terminar o projeto com mais trabalho. Dessa forma, a mudança
em uma das restrições forçará a mudança de pelo menos uma ou mais das outras restrições. Uma das
FIGURA 2.3 Elementos da restrição tripla.
responsabilidades mais importantes do gerente de projetos é determinar o impacto que cada mudança
solicitada pelas partes interessadas terá no triângulo e, consequentemente, no projeto (isso será dis-
cutido com mais detalhes no capítulo 4 Integração).
2.1.16 Requisitos (Requirements)

Há dois tipos de requisitos: do produto e do projeto. Requisito do produto é uma condição ou
capacidade que deve ser obedecida por um sistema, produto, serviço, resultado ou componente para
satisfazer um contrato, um padrão, uma especificação ou outros documentos formais. A seguir, um
exemplo de requisitos relativos a um produto:
• O produto deverá ser testado de acordo com os padrões ACDE-830 de 30 de janeiro de 2011.
• O software deverá gerar relatórios financeiros de hora em hora.
• As cores que deverão ser produzidas para esse produto são verde, amarela e azul.
• O diâmetro da peça principal não poderá ultrapassar 60 centímetros.
• O sistema X deverá funcionar nas configurações do Windows 8 a partir de 15 de janeiro de 2013.
Os requisitos do projeto refletem as necessidades, os desejos e as expectativas do patrocinador, do
cliente e de outras partes interessadas, de forma específica, detalhada, quantificada (sempre que pos-
sível) e formalmente documentada com relação ao gerenciamento do projeto. A seguir, exemplos de
requisitos do projeto:
• O gerente funcional da área técnica deverá aprovar o plano de gerenciamento de recursos
humanos.
• O planejamento do tempo do projeto deverá utilizar a ferramenta MS Project.
• O patrocinador deverá assinar o Termo de Abertura do projeto com pelo menos um mês de
antecedência do início efetivo do projeto.
É importante observar aqui que o maior desafio de qualquer gerente do projeto é obter os requisitos
do produto durante o planejamento do projeto. Muitas partes interessadas introduzem novas exigên-
cias ou necessidades com relação ao produto do projeto durante a execução, acarretando atrasos e
estouros de orçamentos. Isso será explicado com mais detalhes no capítulo 5 Escopo.
Exercícios
1. Faça a correspondência do conceito com o respectivo significado.
a. Objetivo ( ) Fornece os recursos financeiros ao projeto.

b. Entrega ( ) São as tarefas que os recursos do projeto deverão executar.
c. Pacote de trabalho ( ) São os produtos ou resultados do projeto.
d. Projeto ( ) Deve ser específico, mensurável, relevante, realizável e estar em conformidade a um
prazo determinado.
e. Atividades ( ) São itens de trabalho que compõem as entregas.
f. Patrocinador ( ) É um esforço temporário com começo, meio e fim.
2. Para os exemplos seguintes, indique o conceito ao qual se referem as frases:

a. A data de conclusão do projeto não pode ultrapassar 120 dias.
Conceito: ____________________________________________________________________________
b. O motor desse equipamento deverá ser do tipo ABC-423, modelo A2, do fornecedor ADD.
Conceito: ____________________________________________________________________________
c. Para a realização desse projeto, o gerente do projeto poderá contar com o suporte da alta
direção da empresa até a conclusão do projeto.
Conceito: ____________________________________________________________________________
d. O projeto contempla concepção, desenvolvimento, protótipo e testes do software MRC.
Conceito: ____________________________________________________________________________
e. O projeto não contempla a produção em massa do software MRC.
Conceito: ____________________________________________________________________________
f. Farão parte e participarão das reuniões do projeto as seguintes pessoas: gerente de produção,
gerente de marketing, assistente financeiro e supervisor da manutenção.
Conceito: ____________________________________________________________________________
g. Realizarão as tarefas desse projeto: Mario Sanchez; Ida Camargo; Irineu Peixoto e Bruna da Silva.
Conceito: ____________________________________________________________________________
h. A estrutura organizacional, em que o gerente do projeto trabalhará, irá requerer que este se
reporte ao diretor do departamento para todas as decisões relativas ao projeto.
Conceito: ____________________________________________________________________________
i. A estrutura organizacional em que o gerente do projeto trabalhará dará a ele controle e plenos
poderes sobre os recursos que trabalharão no projeto.
Conceito: ____________________________________________________________________________
3
Nascimento de um Projeto
• Entender a origem dos projetos em empresas e organizações.
• Coletar informações necessárias para obter a autorização para iniciar um novo projeto.
• Desenvolver a documentação necessária para iniciar um projeto – o Termo de Abertura.
3.1 Pré-projeto
Conceito
Antes de falar sobre o início de um projeto, é importante entender qual a sua origem. Há uma
fase anterior ao início do projeto chamada pré-projeto. Nessa fase, há um estudo ou uma avaliação
de ideias que são transformadas em propostas de projeto. Normalmente, uma proposta para a
realização de um projeto pode ser criada em atendimento a um ou mais dos itens (seguidos de
exemplos) a seguir:
• Necessidades do negócio: o projeto irá atender a uma demanda do mercado, necessidades específicas
de algum cliente, avanços tecnológicos, requisitos legais ou novas regulamentações governamentais.
• Alinhamento com as estratégias da empresa: o projeto é necessário para atingir alguma meta
estratégica da empresa, pela qual ela deseja se tornar líder em um determinado segmento de mercado
ou simplesmente se manter competitiva.
• Necessidades organizacionais: o projeto é necessário para implantar uma melhoria dos sistemas
internos ou será a solução de um problema que está afetando a produtividade da empresa.
Na prática
O tipo de documentação elaborado nas propostas de pré-projeto irá variar, dependendo da empresa
ou organização e do tipo de produto ou serviço com que trabalha. Por exemplo, para um projeto in-
terno, a fase de pré-projeto pode ser constituída por um estudo de viabilidade no qual o departamento
solicitante indica o que será necessário no projeto para que se alcance uma melhoria interna que trará
benefícios à empresa. Estudos de viabilidade também são úteis para analisar a possibilidade de lançar
um novo produto no mercado. Outra forma de escolher projetos são as análises estratégicas do mercado,
acompanhadas de estudos de viabilidade financeira para o produto do projeto no mercado desejado.
Exemplos dessas análises na fase de pré-projeto encontram-se no Apêndice A e na pasta de conteúdos
extras, na página web do livro (www.elsevier.com.br/martacamargo).
Os projetos também podem ser mais simples, como um projeto de implantação de práticas de
sustentabilidade a uma rede de supermercados A, exemplo que daremos a seguir e que funcionará
25
como um estudo de caso aplicado dos conceitos abordados neste livro na seção Aplicação de cada
capítulo.
Aplicação
A rede de supermercados A atende a clientes da classe B e C em uma cidade do interior do estado de São
Paulo. A rede possui sete lojas na cidade e tem também participação em outros supermercados pequenos
com outras bandeiras em cidades da região. O primeiro supermercado começou a funcionar naquela cidade
em 1984, como uma pequena mercearia. Estima-se que agora a rede esteja atendendo a um terço da popu-
lação da cidade – cerca de 50 mil pessoas. Em 2010, a rede contava com aproximadamente 300 funcionários.
A ascensão da classe C no Brasil trouxe novas exigências desse mercado consumidor, também
preocupado em manter uma atitude sustentável em relação ao meio ambiente; essa necessidade vem
ao encontro da tendência nas redes de supermercado em adotar práticas de sustentabilidade (por
exemplo, estações de reciclagem de lixo, não utilização de sacolas plásticas, reutilização de caixas de
papelão para embalar mercadorias dos clientes etc.). Tendo isso em vista, um dos gerentes de uma das
lojas da rede (Loja 1) manifestou interesse em incorporar práticas de sustentabilidade a uma das lojas
para, depois, implantar em todas as lojas da rede. Para obter aprovação do dono da rede (sr. José S.),
esse gerente elaborou a proposta exibida na Figura 3.1.
A proposta desse projeto foi aprovada pelo patrocinador (dono da rede, sr. José S.). Em seguida, o
gerente do projeto partiu para a fase de iniciação do projeto, conforme explicado a seguir.
FIGURA 3.1 Exemplo de pré-projeto.

Capítulo 3 • Nascimento de um Projeto 27
FIGURA 3.1 (cont.)
3.2 Iniciação
Conceito
A fase de iniciação de um projeto se caracteriza pela sua abertura e faz parte da área de conhecimento
de integração.
A iniciação começa a partir do momento em que o projeto é selecionado pela empresa por conta de
alguma necessidade (interna, estratégica ou de mercado). Seja qual for a necessidade da empresa que
culminou na aprovação do projeto, deve haver um plano de negócios (motivação focada no negócio
da empresa ou organização) que justifique o investimento no projeto e deixe claro quais os benefícios
para a empresa e seus clientes, sejam eles internos ou externos.
A iniciação se caracteriza basicamente pela criação de um documento chamado Termo de Abertura
ou Project Charter. Esse documento é de extrema importância, pois autoriza formalmente o início dos
trabalhos em um determinado projeto.
O Termo de Abertura registra, também, as primeiras informações sobre o projeto, contextualizando
suas necessidades principais.
Nenhum projeto pode ser iniciado sem um Termo de Abertura com a assinatura de um patrocinador.
Sem esse documento confirmando que há um patrocinador, o gerente de projeto não tem fundos dis-
poníveis para o projeto, e sem dinheiro especificamente alocado nenhum projeto tem condições de
ser concluído ou sequer existir.
Um resumo das atividades da iniciação e seus documentos, conforme exemplos neste capítulo, pode
ser visto na Tabela 3.1.
Tabela 3.1 Atividades da Iniciação

Área Atividades Documentos
Iniciação Selecionar o gerente do projeto Termo de Abertura
Determinar a autoridade do gerente do projeto
Identificar as principais partes interessadas
Determinar objetivos mensuráveis
Obter aprovação do patrocinador (sponsor)
Além das atividades específicas listadas anteriormente, o gerente do projeto coleta informações his-
tóricas de projetos anteriores que poderão auxiliá-lo como referência nas decisões do projeto. Mesmo
quando a empresa não possui uma metodologia padronizada para a documentação e o arquivamento dos
projetos, sempre há históricos de projetos em documentos diversos, como orçamentos, e-mails, relatórios
de conformidade etc. Esse material referente a projetos anteriores pode conter informações de grande valia
que podem ser aproveitadas para evitar que erros do passado sejam repetidos no projeto atual. É sempre
importante saber o que deu certo e o que deu errado em projetos anteriores para continuar fazendo o certo
e evitar o errado.
O Termo de Abertura pode ter os mais variados formatos e incluir informações conforme as neces-
sidades ou os padrões da empresa. A Figura 3.2 apresenta um modelo genérico de um Termo de Abertura,
com uma explicação do tipo de informação necessária em cada campo.
FIGURA 3.2 Modelo genérico de um Termo de Abertura.

Na prática
O PMBOK sugere que o Termo de Abertura seja criado por uma organização externa àquela
do gerente do projeto, ou seja, nas empresas que possuem um escritório de projetos ou algum outro
departamento responsável pela avaliação de projetos candidatos ou qualquer outra análise na fase de
pré-projeto.
Em muitas empresas que não contam com um departamento voltado para essa finalidade, o próprio
gerente do projeto é quem levanta as primeiras informações para a elaboração de um Termo de Abertura
e para trabalhar com o patrocinador, a fim de confirmar essas informações preliminares e obter uma apro-
vação formal, confirmando ainda que a empresa disponibilizará fundos para a realização desse projeto.
É recomendável, inclusive, que o Termo de Abertura seja impresso e uma assinatura desse pa-
trocinador seja obtida para uma validação total da autorização do projeto, conforme informações
preliminares constantes desse Termo. A Figura 3.3 apresenta um exemplo preenchido de Termo de
Abertura, conforme veremos a seguir.
FIGURA 3.3 Exemplo de Termo de Abertura preenchido – solução para gestão do Imposto sobre Serviços (ISS).
FIGURA 3.3 (Cont.)
Aplicação
Além da elaboração e da aprovação do Termo de Abertura, para o projeto de implantação de práticas

de sustentabilidade à rede de supermercados A, o gerente do projeto, em conjunto com o dono da rede,
decidiu padronizar os formulários de documentação de projeto, conforme aqueles que serão utilizados
em todas as seções Aplicação deste livro, de acordo com a Figura 3.4 a seguir
FIGURA 3.4 Termo de Abertura do projeto sustentabilidade para a rede de supermercados A.

FIGURA 3.4 (Cont.)
Importante
Não é aconselhável detalhar o Termo de Abertura com descrições de entregas ou atividades

específicas ou estimativas de custo detalhadas. Esse documento é apenas uma autorização para
realizar o projeto, e de preferência, por um patrocinador que não faz parte do escritório de projetos.
Durante o planejamento do projeto, muitos itens que podem ser considerados como certos no início
do projeto podem se tornar inviáveis. Portanto, não se pode “engessar” o projeto no Termo de Aber-
tura estabelecendo entregas, custos ou prazos sem ter certo nível de confiança de que poderão ser
realizados.
Exercícios – Iniciação: Termo de Abertura
A partir de agora, você fará um projeto conforme as instruções dadas ao longo dos capítulos. Quando
aplicável, haverá uma indicação sobre os recursos de apoio, que você poderá encontrar no site do livro.
Projeto: Reforma da loja de roupas femininas
Carlos Peixoto é o dono de várias lojas no centro da cidade e em dois shopping centers na região. Nos
últimos seis meses, Carlos observou que houve uma redução de 20% no faturamento de uma de suas
lojas no centro da cidade.
Ao conversar com um cliente antigo, Carlos foi informado de que um concorrente abriu uma loja de
roupas femininas na rua de trás de sua loja. Essa loja concorrente está chamando muito a atenção dos
clientes de roupas femininas pelo seu visual e pelo atendimento dos vendedores. Carlos decide inves-
tigar a loja concorrente e percebe que, de fato, a outra loja conta com uma melhor infraestrutura e um
atendimento ao público mais profissional se comparada à sua.
Para sobreviver nesse mercado competitivo, Carlos decide investir em um projeto de reforma da
sua loja, utilizando R$ 20.000,00 que já estavam em uma reserva na sua caderneta de poupança para
melhorias nas lojas, caso houvesse necessidade.
Nesse momento, Carlos parte do pressuposto que terá condições de gerenciar esse projeto, anteci-
pando que esse orçamento será suficiente e que, de fato, o problema de redução de faturamento está
diretamente relacionado à infraestrutura da loja e ao atendimento do pessoal de vendas em comparação
à concorrência local.
Paulo está limitado a um prazo de 30 dias úteis para completar o projeto, pois a loja precisa voltar a
faturar como antes o mais rápido possível. A operação da loja deverá continuar normalmente apesar
da reforma, limitando o trabalho do pessoal da obra para o período noturno somente. O orçamento
de R$ 20.000,00 em custos variáveis e diretamente relacionados ao trabalho do projeto não poderá ser
ultrapassado, pois Carlos não dispõe de reservas adicionais.
Com essa reforma, Carlos tem como meta recuperar os 20% do faturamento perdido e aumentar
em 10% o faturamento mensal da loja em pelo menos três meses após a inauguração da loja refor-
mada.
Nesse momento do projeto, Carlos sabe que poderá contar com a gerente da loja Ana Maria Costa e
o engenheiro Silvio Rocha como membros da equipe do projeto.
Material de apoio
Baixe o arquivo Termo de Abertura, na pasta Exercícios em Conteúdos extras, na página web do livro
(www.elsevier.com.br/martacamargo).
1. Faça o Termo de Abertura contendo as seguintes informações:

a. Título e descrição do projeto.
b. Gerente do projeto designado e nível de autoridade no projeto.
c. Motivação ou justificativa do projeto.
d. Objetivo do projeto.
e. Principais partes interessadas (stakeholders) no projeto.
f. Recursos já alocados ao projeto.
g. Produtos ou resultados do projeto.
PA RT E
III–
Planejando o Projeto
Depois que o projeto é aprovado por um Termo de Abertura assinado por um patrocinador, está pronto
para ser planejado.
O planejamento eficiente de um projeto é essencial ao seu sucesso. É no planejamento que informações
de cada área de conhecimento em gerenciamento de projetos são coletadas, analisadas e documentadas,
em vista das necessidades do projeto e das partes interessadas. A tabela a seguir apresenta um resumo das
principais atividades e documentos gerados em cada área de conhecimento (Tabela III.1).
CAPÍTULO 4 Integração....................................................................................................................37
CAPÍTULO 5 Escopo........................................................................................................................... 49
CAPÍTULO 6 Tempo...........................................................................................................................99
CAPÍTULO 7 Custos..........................................................................................................................111
CAPÍTULO 8 Qualidade...................................................................................................................123
CAPÍTULO 9 Recursos Humanos.....................................................................................................139
CAPÍTULO 10 Comunicações.............................................................................................................145
CAPÍTULO 11 Riscos...........................................................................................................................151
CAPÍTULO 12 Aquisições...................................................................................................................163
CAPÍTULO 13 Partes Interessadas.....................................................................................................169
Tabela III.1 Atividades de Planejamento de um Projeto

Área Atividades Documentos
Integração Apresentar a estratégia para a realização do projeto Plano de Gerenciamento do Projeto, incluindo
e integrar as áreas de conhecimento em um todo coeso planejamento de cada área de conhecimento
listada no quadro
Escopo Coletar requisitos Documentação de Requisitos
Definir entregas e pacotes de trabalho Estrutura Analítica do Projeto (EAP)
Descrever os pacotes de trabalho e definir critérios Dicionário da EAP
de aceitação desses pacotes
Tempo Definir atividades Cronograma – Planilha
Sequenciar atividades Cronograma – Gantt
Estimar duração das atividades Cronograma de Marcos
Alocar recursos às atividades
Custo Estimar custos Estimativa de Custos
Determinar orçamento Orçamento do projeto
Qualidade Estabelecer procedimentos e ferramentas para gerenciar Fluxogramas
e controlar a qualidade Listas de Verificação ou Checklists
Recursos Humanos Definir necessidades associadas aos recursos humanos Matriz RACI
Atribuir papéis e responsabilidades aos recursos
Comunicações Elaborar um esquema para as comunicações entre as Esquema das Comunicações
partes interessadas durante o projeto
Riscos Planejar o gerenciamento dos riscos Análise Qualitativa de Riscos
Identificar os riscos
Realizar análise qualitativa dos riscos
Realizar análise quantitativa dos riscos
Planejar as respostas aos riscos
Aquisições Definir procedimentos para aquisições e contratações Plano de Gerenciamento das Aquisições
Partes Interessadas Manter e atualizar o registro das partes interessadas Plano de Gerenciamento das Partes Interessadas
Elaborar um plano de gerenciamento e monitoramento Matriz de Gerenciamento das Partes Interessadas
do nível de envolvimento de cada parte interessada
em pontos diferentes no projeto
É importante observar que as áreas de conhecimento do planejamento não ocorrem necessariamente na

sequência mostrada na tabela anterior.
Normalmente, há uma sequência intuitiva formada por Escopo–Tempo–Custo e, depois, as outras áreas.
Porém, à medida que as áreas são planejadas, pode ser necessário voltar e replanejar algum item que já havia
sido definido anteriormente. Além de ser necessária uma total integração entre as áreas de conhecimento
(conforme explicado a seguir), elas são interativas. Por exemplo: após definir a EAP e o Cronograma, pode
ser que haja problemas nos Custos, o que requer uma volta ao Escopo para um remanejamento do que será
feito no projeto. A alocação de recursos no cronograma precisa estar conectada com a área de Recursos
Humanos. O mesmo se repete nas outras áreas. O importante é que no final da fase de planejamento, após
toda essa interação e uma total integração das áreas, as linhas de base estejam sólidas e reflitam uma realidade
atingível, conforme estipulado no objetivo do projeto.
Esse processo é basicamente o foco das exigências de documentação de um projeto, conforme proposta
do PMBOK; por isso, os capítulos a seguir abordarão, mais detalhadamente, o planejamento de cada área
de conhecimento de um projeto.
4
Integração
• Integrar as áreas de conhecimento de um projeto com um plano de gerenciamento do projeto.
Conceito
Uma das funções principais do gerente de projeto é integrar as diferentes áreas de conhecimento do
projeto. A integração consiste na coordenação do projeto para que as áreas de conhecimento formem
um todo coeso. Os prazos, por exemplo, precisam estar integrados com escopo e custos; já os riscos,
precisam estar integrados com praticamente todas as áreas do projeto – e assim por diante.
A integração é iniciada no Termo de Abertura, no qual se faz o levantamento inicial das necessidades
do projeto, e planejada por um plano de gerenciamento do projeto. Esse plano deve incluir informações
sobre todas as áreas de conhecimento e estabelecer como essas informações serão gerenciadas até o
encerramento do projeto.
Outro componente da integração fundamental ao sucesso de qualquer projeto é o gerenciamento
das mudanças, que devem ser controladas e analisadas em relação ao impacto que terão em todas as
áreas do projeto, não apenas na área em que está sendo solicitada. Por exemplo, uma solicitação de
mudança no prazo pode afetar o custo e a qualidade do projeto.
O gerente de projeto deve estabelecer um processo formal para solicitação e aprovação de mudanças,
bem como uma definição dos limites de aprovação. Normalmente, mudanças que não afetam as linhas
de base podem ser avaliadas e aprovadas (ou não) pelo gerente de projeto. Mudanças que afetam as
linhas de base devem ser analisadas por um grupo ou comitê de partes interessadas que terá poder para
aceitar ou rejeitar as mudanças solicitadas, em função do impacto das mudanças nas áreas-chave do
projeto (geralmente são as áreas escopo, custo, tempo e qualidade).
Na prática
Para projetos grandes e complexos, cada área de conhecimento requer um plano detalhado que
funciona como um subplano ao plano de gerenciamento do projeto, que nesse caso pode chegar a
centenas de páginas.
Considerando um nível iniciante em gerenciamento de projetos, o importante é documentar os
aspectos básicos de como o projeto será gerenciado. Em vez de estabelecer planos separados e com-
plicados – considerando também que o projeto de um gerente de projetos iniciante será menos com-
plexo e terá uma duração menor –, bem como subplanos separados, o plano de gerenciamento do
projeto descrito neste livro incluírá seções que cobrirão o planejamento de cada área de conhecimento,
como o monitoramento, o controle e o encerramento do projeto.
A seguir, um exemplo de como esse plano de gerenciamento do projeto pode ser elaborado para
integrar as áreas de um projeto. O texto em itálico explica o tipo de informação que deve ser inserido
em cada campo (Figura 4.1).
37
FIGURA 4.1 Modelo genérico de Plano de Gerenciamento de Projeto.

Capítulo 4 • Integração 39
FIGURA 4.1 (Cont.)

Aplicação
A seguir, o plano de gerenciamento do projeto produzido para o projeto de sustentabilidade para a
rede de supermercados A – loja 1.
Importante
Cada item do planejamento, do monitoramento, do controle e da fase de encerramento deste plano
será explicado em maiores detalhes nos próximos capítulos, bem como os respectivos anexos (Figura 4.2).
FIGURA 4.2 Plano de Gerenciamento de Projeto.

FIGURA 4.2 (Cont.)

FIGURA 4.2 (Cont.)

FIGURA 4.2 (Cont.)

FIGURA 4.2 (Cont.)

FIGURA 4.2 (Cont.)

FIGURA 4.2 (Cont.)

Exercícios
Planejamento: Integração
1. Qual a função do gerente de projeto na integração do projeto?
2. Que tipos de informação devem fazer parte do Plano de Gerenciamento do Projeto e por quê?
3. Por que o gerenciamento de mudanças faz parte da integração de um projeto?
5
Escopo
• Definir e documentar o que será feito e o que não será feito em um projeto por meio de uma Declaração
de Escopo.
• Descobrir e documentar desejos, necessidades e exigências das partes interessadas no projeto, com a
documentação de requisitos.
• Detalhar o trabalho que será realizado no projeto mediante o desenvolvimento de Estruturas Analíticas
de Projeto (EAP) e de seu respectivo Dicionário.
Conceito
Escopo é o que o projeto se propõe a fazer para garantir que todo o trabalho, e somente esse traba-
lho, seja realizado no projeto. O planejamento do escopo é de grande importância ao projeto, pois é a
partir dele que as outras áreas de conhecimento serão planejadas. O planejamento do escopo envolve
atividades e documentos que serão explicados a seguir (ver Tabela 5.1).
O plano de gerenciamento do escopo deve incluir o planejamento das estratégias para gerenciar
o escopo do projeto com informações sobre formulários específicos que serão utilizados para regis-
trar as informações sobre o escopo, processos e procedimentos para coletar, documentar e rastrear os
requisitos do projeto, bem como os processos e procedimentos para construir a EAP do projeto e seu
respectivo dicionário.
Tabela 5.1 Atividades e Documentos de Planejamento do Escopo

Atividades para planejar o escopo Documentos gerados
Planejar estratégias para gerenciar o escopo Plano de Gerenciamento do Escopo
Definir limites do escopo Declaração do Escopo
Definir requisitos do projeto Documentação dos Requisitos
Definir entregas principais Estrutura Analítica do Projeto (EAP)
Definir os pacotes de trabalho Dicionário da EAP
5.1 Declaração de Escopo

No início da fase de planejamento, é importante definir os limites do escopo, ou seja, o que será in-
cluído ou não no projeto. A Declaração de Escopo do projeto é a primeira tentativa de determinar esses
limites do escopo, principalmente o que deve ser feito, em linhas gerais, para alcançar os objetivos do
projeto. A Declaração de Escopo é desenvolvida com base em informações fornecidas pelo patrocinador
e outras partes interessadas de maior influência no projeto.
A finalidade da Declaração de Escopo é garantir que o gerente do projeto e as partes interessadas
tenham um entendimento similar ou opiniões semelhantes sobre o escopo do projeto antes do início
do planejamento, estipulando limites ao escopo do projeto (isto é, estabelecendo o que fará parte do
escopo e o que não fará parte do escopo).
A Declaração de Escopo varia em formato e conteúdo, e as declarações mais comuns normalmente
incluem as seguintes informações (Figura 5.1):
49
FIGURA 5.1 Modelo genérico da Declaração de Escopo.

Capítulo 5 • Escopo 51
Na prática
O escopo de um projeto é definido de forma progressiva, à medida que as informações sobre o pro-
duto do projeto vão aparecendo no processo de planejamento. Esse processo de definição do escopo se
torna mais fácil quando há um histórico de projetos semelhantes na empresa, bastando apenas verificar
o que já foi feito e aproveitar as informações coletadas anteriormente para o projeto atual. Quando o
projeto é inédito ou diferente dos que foram realizados anteriormente na empresa, ou em casos em
que não há um histórico para se verificar registros sobre como projetos anteriores foram realizados,
a equipe do projeto tem mais dificuldades para levantar as informações de escopo do projeto. Nesses
casos, é fundamental que haja um bom entrosamento entre as partes interessadas para que o escopo
seja definido de forma real e clara, minimizando a necessidade de ajustes e mudanças posteriores.
A seguir, um exemplo de uma Declaração de Escopo de um projeto, com base no modelo fornecido
anteriormente (Figura 5.2).
FIGURA 5.2 Exemplo de Declaração de Escopo.

FIGURA 5.2 (Cont.)

FIGURA 5.2 (Cont.)

FIGURA 5.2 (Cont.)
Aplicação
Declaração de Escopo para o projeto de sustentabilidade para a rede de supermercados A – loja 1

(Figura 5.3).
FIGURA 5.3 Declaração de Escopo do projeto de sustentabilidade à rede de supermercados A – loja 1.

FIGURA 5.3 (Cont.)

FIGURA 5.3 (Cont.)
Exercício
Planejamento – Escopo: Declaração de Escopo

Continuação do projeto reforma da loja de roupas femininas
Após elaborar o Termo de Abertura do projeto, Carlos Peixoto já tem uma ideia geral do que será
necessário fazer para concluir o projeto de forma bem-sucedida. Três grandes componentes de trabalho
deverão ser realizados: estrutura da loja, treinamento dos colaboradores e promoção das melhorias. O
orçamento reservado para o projeto não permitirá reformas nas estruturas dos banheiros ou na cozinha,
apenas na área da loja em si.
A equipe que trabalhará no projeto será composta por:
• Carlos Peixoto, o dono da loja, que atuará como gerente e patrocinador do projeto.
• Ana Maria Costa, a gerente da loja, que cuidará da organização interna da loja e de todas as aquisições
de produtos e serviços.
• Silvio Rocha, o engenheiro responsável pela obra, com sua equipe de dois pedreiros, um pintor e um
eletricista.
• Roberto Santos, um consultor externo que dará o treinamento ao pessoal de atendimento.
• Felipe Camargo, um consultor que ficará responsável por todo o marketing e promoção da loja depois
da reforma.
O trabalho começará no dia 1o de março e deverá estar concluído em 30 dias úteis no máximo. Carlos
gostaria que os principais eventos do projeto ocorressem da seguinte maneira:
• A conclusão do planejamento deve se dar até o terceiro dia após a assinatura do Termo de Abertura.
• O mestre de obras deverá estar contratado até o quinto dia do projeto.
• Todos os novos produtos e serviços já deverão estar disponíveis até o sétimo dia do projeto.
• A execução da obra deverá estar concluída até o vigésimo quinto dia do projeto.
• A verificação do trabalho deverá estar concluída até o vigésimo sétimo dia do projeto.
• O treinamento do pessoal deverá estar concluído até o vigésimo nono dia do projeto.
• No trigésimo primeiro dia, o projeto deverá estar encerrado.
Material de apoio
Baixe o arquivo Declaração de Escopo, da pasta Exercícios em Conteúdos extras, na página web do
livro (www.elsevier.com.br/martacamargo).
1. Elabore a Declaração de Escopo para o projeto da reforma da loja, com as seguintes informações:
a. Título e descrição do projeto.
b. Patrocinador (sponsor).
c. Gerente do projeto e autoridade.
d. Equipe.
e. Objetivos.
f. Justificativa.
g. Fatores de sucesso.
h. Restrições.
i. Premissas.
j. Exclusões específicas.
k. Entregas principais (escopo incluído).
l. Orçamento previsto.
m. Marcos principais (principais acontecimentos do projeto).
n. Critérios de aceitação do projeto.
5.2 Documentação de Requisitos
Conceito
Requisitos são condições ou capacidades que devem ser obedecidas por um sistema, produto,
serviço, resultado ou componente para satisfazer um contrato, um padrão, uma especificação ou outros
documentos formais. Os requisitos de um projeto incluem as necessidades, os desejos e as expectativas
do patrocinador, cliente e outras partes interessadas, de forma quantificada (sempre que possível) e
documentada.
A criação de três documentos está prevista para cobrir as necessidades de uma documentação ade-
quada dos requisitos e o posterior rastreamento da incorporação dos requisitos aprovados no projeto.
Cada um desses documentos é explicado a seguir.
5.2.1 Plano de Gerenciamento de Requisitos

O plano de gerenciamento de requisitos é parte do plano de gerenciamento do escopo do projeto.
Ele especifica como os requisitos serão gerenciados durante todo o projeto, considerando:
1. Métodos de levantamento e coleta dos requisitos.
2. Definição das categorias que serão estabelecidas para os requisitos.
3. Esquema de priorização das categorais de requisitos.
4. Procedimento para rastrear a inclusão dos requisitos aprovados no projeto.
5. Procedimento para mudanças nos requisitos.
6. Verificação do cumprimento dos requisitos.
5.2.2 Documentação de Requisitos

Um formato básico e genérico para o início da documentação dos requisitos é uma tabela com o
nome da parte interessada que está solicitando o requisito, uma descrição detalhada do requisito, a
categoria ou o tipo de requisito e uma classificação da prioridade desse requisito, conforme ilustrado
no Figura 5.4 a seguir.
FIGURA 5.4 Início do Documento de Requisitos.
Essa tabela de requisitos se transforma em uma matriz de rastreabilidade de requisitos quando

se insere informações de situação ou status do requisito, ou seja, informações sobre como e em que
momento o requisito foi incorporado no projeto ou se não foi incorporado devido a algum critério
predefinido de priorização dos requisitos, conforme ilustrado mais adiante neste capítulo.
5.2.3 Matriz de Rastreabilidade de Requisitos

Uma matriz de rastreabilidade de requisitos é usada para controlar os vários atributos de requisitos
ao longo do ciclo de vida do projeto. Essa matriz é praticamente a mesma que foi utilizada para os
levantamentos dos requisitos, porém inclui um campo ou um local para rastrear o requisito à medida
que o projeto é planejado e executado. No exemplo a seguir, a rastreabilidade é feita na coluna Status,
que deverá ser atualizada conforme isso for necessário durante o projeto (Figura 5.5).
FIGURA 5.5 Exemplo de Matriz de Rastreabilidade de Requisitos.
Na prática
Um dos grandes motivos de mudanças depois que um projeto se inicia é a inclusão, modificação ou
exclusão de requisitos. Dessa forma, a habilidade de o gerente conseguir coletar e documentar todos os
requisitos do projeto antes da execução do mesmo diminui a probabilidade de mudanças, que custam
tempo e dinheiro.
O gerente do projeto deve fazer o possível para entender as necessidades e as exigências em relação ao
gerenciamento do projeto – e, principalmente, aquelas relacionadas ao produto do projeto. Há requisitos
relativos ao gerenciamento do projeto, porém o grande desafio é levantar os requisitos que o produto do
projeto deverá ter. O que dificulta esse processo de coleta de exigências e necessidades com relação ao
produto do projeto é que muitas partes interessadas não sabem expressar necessidades e exigências de
suas áreas. Por exemplo, em uma entrevista ao gerente financeiro para levantar requisitos para um sis-
tema de controle de orçamentos automatizado, esse gerente tenderá a focar nos aspectos financeiros do
sistema e não na interface do usuário ou aspectos mais técnicos relacionados à tecnologia da informação.
O resultado, como muitos gerentes de projetos da área de TI poderão confirmar, é o desenvolvimento de
um sistema que, ao ser testado na área solicitante, não atende às necessidades das partes interessadas,
gerando uma necessidade de adaptações e mudanças.
Para facilitar a coleta de requisitos, o gerente do projeto pode se valer de ferramentas que auxiliam
as partes interessadas a expressarem suas necessidades e exigências que se transformarão em requisitos
do projeto.
Uma ferramenta muito útil para coletar e organizar requisitos é o mapa mental. Mapa mental é uma
ferramenta de brainstorming que monta diagramas com base em uma ideia ou imagem central para
fazer um levantamento de soluções ou possibilidades para resoluções de problemas. O mapa mental é
útil na coleta de requisitos, pois auxilia as partes interessadas a criarem um quadro intuitivo em torno
de uma ideia central.
Exemplo: Mapa mental para requisitos de um projeto
O gerente de um projeto de implantação de um refeitório em uma empresa precisa saber quais
as exigências ou necessidades das principais partes interessadas daquela empresa. Para o gerente do
projeto, é necessário saber logo no início do planejamento quais as expectativas e necessidades des-
sas partes interessadas em relação às principais áreas do projeto, a fim de que o escopo seja definido
e já considere essas necessidades. Se isso não for feito logo no início do planejamento, o escopo será
definido de forma incompleta ou incorreta, acarretando necessidades de mudanças no decorrer da
execução do projeto.
Após consultar a diretoria da empresa, o gerente do projeto descobre que as principais partes
interessadas que irão contribuir com informações sobre requisitos para esse projeto são os gerentes
das seguintes áreas: Recursos Humanos, Contabilidade, Nutrição, Refeitório, Jurídico e Tecnologia da
Informação. Com essa informação em mãos, o gerente do projeto começa a desenhar o mapa mental e
prepará-lo para entrevistas com as partes interessadas; nessa fase, ele também faz o levantamento dos
requisitos, colocando no centro o objetivo central, e representando como ramificações desse objetivo
central as áreas que irão gerar os requisitos (Figura 5.6).
FIGURA 5.6 Exemplo do início de um mapa mental para coleta de requisitos.
Na próxima fase, cada parte interessada é entrevistada para completar o mapa mental com os
requisitos de cada uma. Por exemplo, o gerente de Recursos Humanos estipulou que o refeitório não
pode operar se as seguintes condições não forem cumpridas:
1. Apenas funcionários designados como gerentes de menu pelo gerente do refeitório podem criar,
modificar ou deletar menus.
2. Funcionários temporários ou prestadores de serviços deverão pagar as refeições à vista e em espécie
apenas no caixa da tesouraria, que fornecerá um recibo que deverá ser entregue ao gerente do
refeitório.
3. Apenas funcionários com carteira registrada podem se cadastrar para obterem desconto do valor
das refeições em folha de pagamento.
Em um mapa mental, essas condições seriam consideradas requisitos, conforme ilustrado a seguir
(Figura 5.7):
FIGURA 5.7 Exemplo da coleta de requisitos com um mapa mental.
Assim também para as demais áreas, conforme ilustrado na Figura 5.8.

FIGURA 5.8 Exemplo dos requisitos de partes interessadas coletados com um mapa mental.
Ferramentas
Existem softwares livres na internet que auxiliam o gerente do projeto nessa coleta de requisitos
junto às partes interessadas. O mapa mental desta seção Na Prática, por exemplo, foi feito com uma
ferramenta chamada FreeMind, um software livre cujo download é gratuito na internet (requer versão
mais recente do Java no computador).
Outra ferramenta de software livre com download gratuito na internet para desenvolvimento de
mapas mentais é o XMind, que será utilizado na seção Aplicação, a seguir. Como os links para download
dessas ferramentas podem mudar, é melhor realizar uma pesquisa rápida na internet para saber onde
essas ferramentas se encontram neste momento.
Dica
Para projetos pequenos ou de médio porte, o gerente de projetos pode convocar todos para uma
reunião de requisitos. Utilizando um projetor (datashow), ele pode colocar o software em uma tela
branca e começar um processo de levantamento dos requisitos por parte interessada. As necessidades
e exigências de cada parte interessada seriam colocadas em um mapa mental para fácil visualização
de todos e para discussão imediata de conflitos ou maior detalhamento de algum requisito. Para ser
considerado, o requisito deve ser específico e incluir quantificações ou especificações. Por exemplo,
não seria aceito o requisito: Opção de prato de baixa caloria, pois é vago. Baixa caloria pode significar
coisas diferentes para pessoas diferentes. O requisito certo incluiria um dado específico, e poderia
ser, nesse caso: uma opção de prato de baixa caloria com um máximo de 500 calorias e um mínimo de
300 calorias.
Importante
É importante que o gerente do projeto esclareça às partes interessadas que o levantamento inicial,
com um mapa mental, é apenas isso mesmo: inicial. Esse processo de levantamento de requisitos
pode – e, muitas vezes, deve – ser feito várias vezes durante o planejamento para garantir que todos os
requisitos importantes sejam analisados e incluídos no projeto, conforme o caso.
Após esse levantamento preliminar dos requisitos do projeto, o gerente de projeto deve lançar
esses requisitos em uma matriz de rastreamento dos requisitos, conforme exemplo mostrado a seguir
(Figura 5.9):
FIGURA 5.9 Exemplo de Documentação de Requisitos após mapa mental.
Aplicação
Os documentos de requisitos produzidos para o projeto de sustentabilidade à rede de supermercados

A – loja 1 encontram-se listados a seguir (Figura 5.10).
O Plano de Gerenciamento de Escopo encontra-se no Plano de Gerenciamento do Projeto, item 6A.
FIGURA 5.10 Exemplo de Documentação de Requisitos.

FIGURA 5.10 (Cont.)

FIGURA 5.10 (Cont.)

FIGURA 5.10 (Cont.)
Exercícios
Planejamento – Escopo: Documentação dos requisitos

Continuação do projeto da reforma da loja de roupas femininas
Para dar continuidade ao projeto da reforma da loja, Carlos Peixoto gostaria de fazer um levantamento
dos requisitos. O foco desse levantamento estará nos requisitos (desejos, necessidades e exigências) das
partes interessadas do projeto com relação ao produto ou resultado final do projeto. Para isso, Carlos
marca uma reunião para entrevistar as partes interessadas do projeto e elaborar um mapa mental com
os principais requisitos resultantes dessa entrevista.
Material de apoio
Baixe os arquivos Mapa Mental e Matriz de Rastreabilidade de Requisitos, na pasta Exercícios em

Conteúdos extras, na página web do livro (www.elsevier.com.br/martacamargo).
1. Utilize o mapa mental já iniciado e complete-o com mais dois requisitos para cada parte interessada
do projeto. Você deverá criar esses requisitos com base nas áreas que essas partes interessadas
representam, considerando, por exemplo, quais seriam as possíveis exigências da área de compras
ou de marketing em relação a um projeto de reforma.
2. No formulário Matriz de Rastreabilidade de Requisitos, classifique os requisitos conforme as
categorias e as prioridades que constam no fim do formulário.
5.3 Estrutura Analítica do Projeto (EAP) ou Work Breakdown

Structure (WBS)
Conceito
Estrutura Analítica do Projeto (EAP) é uma expressão traduzida do inglês Work Breakdown Structure
(WBS). Todo o trabalho do projeto deve estar representado de alguma forma na EAP e, caso não seja,
não será trabalho que poderá ser realizado no projeto. A EAP existe basicamente para:
1. Organizar e confirmar o escopo total do projeto.
2. Evitar que algum trabalho seja esquecido.
3. Detalhar todo o trabalho definido na Declaração de Escopo.
A EAP permite que o gerente do projeto produza estimativas de custo, prazo e recursos com
uma visão total do projeto, e pode ter o formato de uma lista itemizada ou de um gráfico similar
ao de um organograma. Como o grande valor da EAP está em auxiliar as partes interessadas do
projeto a desenvolver uma visão clara do produto final do projeto e dos componentes que irão
produzi-lo, as partes interessadas preferem que a EAP esteja em formato similar a um organogra-
ma sempre que possível. Os exemplos deste capítulo apresentarão as EAPs apenas em seu formato
gráfico.
Em linhas gerais, a EAP decompõe o trabalho em partes menores cuja soma totalizará o todo do
projeto. A decomposição se inicia com uma divisão macro dos componentes ou fases ou entregas
principais do projeto, que em seguida é dividido em entregas menores e pacotes de trabalho. Pacote de
trabalho é o subcomponente que forma uma entrega e é o nível mais baixo na EAP – ou seja, é o último
nível que aparece na EAP.
Na prática
Dois gerentes de projeto em uma mesma empresa, com a mesma experiência e o mesmo conheci-
mento sobre o produto do projeto, podem fazer EAPs diferentes do mesmo projeto, porém perfeitamente
corretas.
Para a empresa que já trabalha com uma metodologia baseada nos princípios do PMBOK, é
provável que haja uma padronização para a elaboração de EAPs em vista de projetos anteriores.
É sempre bom, de qualquer forma, ter toda a equipe em uma sala analisando a EAP para verificar
se o novo projeto inclui a mesma estrutura de entregas de projetos anteriores ou se há novos
componentes que precisam ser incluídos, ou ainda componentes ultrapassados que precisam ser
retirados da EAP.
Dica
Muitos iniciantes em gerenciamento de projetos têm dificuldades em produzir EAPs reais para o
projeto que estão gerenciando por não entenderem corretamente o conceito de decomposição do
trabalho em unidades menores. A tradução para o português da palavra breakdown, ou seja, o termo
“analítica”, talvez seja a culpada por certa confusão com relação ao que deve ser feito. Por trás de uma
EAP, não há uma análise no sentido literal da palavra, mas sim um desmembramento do trabalho em
unidades menores que formarão o todo.
Para ilustrar essa ideia de desmembramento do todo em partes menores, veja a Figura 5.11. O projeto
seria representado pelo animal, enquanto que o breakdown ou desmembramento de seus componentes
seriam as partes que compõem esse animal.
FIGURA 5.11 Exemplo de breakdown ou desmembramento das partes.
Importante
O propósito da EAP é mostrar os componentes do trabalho que precisarão ser feitos de acordo com
o projeto, NÃO as ações envolvidas nesse trabalho. As ações do projeto são refletidas nas atividades ou
tarefas que fazem parte do gerenciamento de tempo de um projeto, conforme descrito em Planejando
o Tempo.
5.3.1 Níveis de uma EAP

A forma de uma EAP variará muito, dependendo da natureza do projeto. Geralmente, a EAP é dividida
nos seguintes níveis:
Nível 1: O produto final do projeto. Tem apenas um nível e representa o escopo total do projeto.
Numerado como 1.0 na EAP.
Nível 2: Esse nível reflete o breakdown ou a quebra das categorias maiores do trabalho que será feito
no projeto. Inclui normalmente os componentes básicos que irão formar o projeto. Numerados
como 1.1, 1.2, 1.3 e assim por diante na EAP, podem ser fases, componentes, localizações geográficas,
entregas maiores etc.
Nível 3: Esse nível reflete os subcomponentes dos componentes maiores refletidos no nível 2. Devem
ser específicos e refletir as partes do que está espeficado no nível 2. Numerados como 1.1.1, 1.1.2,
1.1.3 ou 1.2.1, 1.2.2, 1.2.3 (e assim por diante) na EAP, podem ser entregas ou pacotes de trabalho,
dependendo dos níveis acima.
Nível 4: Esse nível reflete o trabalho que será necessário para compor o que está representado no
nível 3. Numerados como 1.1.1.1, 1.1.2.1, 1.1.3.1 ou 1.2.1.1, 1.2.1.2, 1.2.1.3 (e assim por diante) na
EAP, geralmente são pacotes de trabalho das entregas constantes em um nível acima.
Normalmente, a EAP vai no máximo até o nível 4, abrindo-se depois em atividades no cronograma
(Figura 5.12).
FIGURA 5.12 Estrutura genérica de uma EAP.

5.3.2 Estratégias para Criação de uma EAP

Há várias formas de se fazer uma EAP. Como dito anteriormente, dois gerentes de projeto em uma
mesma empresa podem criar EAPs diferentes para o mesmo projeto e obterem os mesmos resultados.
As estratégias mais comuns para sua elaboração são:
1. Top-down (de cima para baixo). Consiste em uma decomposição e hierarquização do trabalho de
cima para baixo. Geralmente envolve ciclos de vida ou fases predefinidas ou uma elaboração com
base em projetos similares feitos anteriormente. Se o gerente do projeto trabalha em uma empresa
produtora de motocicletas que segue um ciclo de vida padrão, os itens do primeiro nível da EAP
serão geralmente padronizados, conforme ilustrado a seguir (Figura 5.13).
FIGURA 5.13 Exemplo 1 do nível 2 de uma EAP top-down.
Poderíamos considerar o caso de uma empresa organizadora de eventos como outro exemplo
de uma estratégia top-down para a criação de uma EAP. Todo o evento segue o mesmo “ritual”
de trabalho, com basicamente os mesmos componentes ou categorias de trabalho de nível 1,
conforme ilustrado a seguir (Figura 5.14).
FIGURA 5.14 Exemplo 2 do nível 2 de uma EAP top-down.
2. Bottom-up (de baixo para cima). Consiste em uma decomposição e hierarquização do trabalho de
baixo para cima. Geralmente envolve projetos para produtos ou serviços nunca antes feitos, com uma
equipe de projeto nova, ou produtos customizados aos requisitos do cliente. Nesse caso, o processo
de elaboração de uma EAP é mais complicado e requer mais tempo.
Ferramenta
Uma forma comum de criar uma EAP bottom-up (de baixo para cima) é realizar uma reunião de
brainstorming em que as partes interessadas do projeto são convidadas a participar com ideias do
trabalho que precisa ser desenvolvido no projeto. Esse processo de elaboração de uma EAP gera uma
série de ideias que são organizadas em uma folha de flipchart. Gradativamente, os itens do nível 2 vão
aparecendo, e a EAP vai se estruturando.
Considere-se, por exemplo, um projeto que trata da organização e da realização de um banquete

em homenagem ao presidente de uma empresa. Ninguém na equipe do projeto tem experiência com
esse tipo de evento e isso nunca foi feito na empresa. Um dos colaboradores da empresa foi convidado
para ser o líder do projeto e está contando com a ajuda dos diversos departamentos para cobrir todas
as necessidades do projeto e providenciar todos os componentes que devem fazer parte do evento. Para
isso, ele convida representantes dos diversos departamentos para uma reunião de brainstorming e a
criação de uma EAP, seguindo esses passos:
• Primeiro passo: Brainstorming. Todos escrevem, individualmente, os componentes que acreditam
que devam fazer parte da EAP. Essa lista é normalmente longa e reflete preferências individuais. É
importante que o líder do projeto atue como facilitador da sessão e deixe as partes interessadas à
vontade para colocarem tudo o que eles quiserem, pois se trata mesmo de uma “chuva de ideias”.
Muitas vezes, uma ideia que uma pessoa pode considerar absurda acaba se tornando relevante
depois, à medida que a discussão sobre o que deve ser feito no projeto é realizada sob um ponto de
vista multidisciplinar.
• Segundo passo: Consenso. O facilitador pergunta a cada um sobre os itens propostos. Os itens sobre
os quais todos concordarem são escritos em post-its e colocados em uma folha de flipchart afixada a
uma parede. É importante que todos vejam os itens aprovados e um possível escopo sendo formado
gradativamente.
• Terceiro passo: Organização por afinidades. Depois que se esgotarem os post-its com as ideias que
todos concordaram, é hora de o grupo todo organizar os post-its por afinidades ou semelhanças
entre os itens. Para isso, todos os itens que forem móveis são agrupados em um ponto, e todos
os itens que se referirem à infraestrutura são agrupados em outro ponto, e assim por diante.
Itens redundantes ou muito granulares (que não representam trabalhos ou entregas) são
descartados.
• Quarto passo: Definição das entregas e pacotes de trabalho. Aos poucos, o grupo percebe que os
itens do nível 2 da EAP e seus subcomponentes estão sendo formados, e agora é possível dar nomes
aos grupos de itens com a mesma afinidade. Por exemplo, itens relativos às adaptações ao local
ou equipamento de som e imagem são classificados como pertencentes a um componente maior
chamado Instalações, que se tornará a entrega principal para esses itens que, por consequência,
se tornaram pacotes de trabalho dessa entrega na EAP (ou subcomponentes de um componente
maior).
• Último passo: Apresentação final. Agora, é só organizar os resultados em um formato gráfico de
uma EAP (com uma numeração hierárquica), conforme a Figura 5.15, que mostra a EAP em formato
gráfico.
Dica
Para o processo descrito anteriormente, não é necessário cobrir as entregas e pacotes de trabalho do
gerenciamento do projeto, pois já estão padronizadas. Porém, na apresentação final é importante que
essa área seja representada, conforme metodologia de gerenciamento de projetos adotada pela empresa.
FIGURA 5.15 EAP do projeto banquete em homenagem ao presidente de uma empresa.

Ferramenta
Pode-se substituir o processo de brainstorming com post-its por um processo de brainstorming com
mapas mentais, com uma das ferramentas mencionadas anteriormente (como o software livre XMind ou
FreeMind). Assim, para o projeto do banquete, o líder do projeto pediria à equipe que falasse livremente
sobre o que todos achassem que deveria fazer parte do projeto, colocando essas ideias em um mapa
mental simples, conforme o exemplo a seguir, no qual se usou o XMind (Figura 5.16).
FIGURA 5.16 Brainstorming com mapa mental realizado com a ferramenta XMind.
Em seguida, o líder do projeto e a equipe eliminariam redundâncias ou itens que não refletem itens
de trabalho associados a uma EAP e agrupariam os itens em comum, conforme o exemplo seguinte,
que considera uma das entregas (Figura 5.17):
FIGURA 5.17 Organizando por afinidades das ideias.
O processo se repetiria para cada item, e assim agrupariam-se os itens relevantes e eliminariam-se
outros que não se encaixassem a um nível de EAP (por exemplo, vinho do Porto ou prato vegetariano
seriam eliminados, bem como itens granulares que não se referem a pacotes de trabalho, como sacos de
lixo), definindo-se os nomes das entregas principais. Os itens são agrupados e renomeados (conforme
o caso) gradativamente pela equipe até que as entregas e os pacotes de trabalho fiquem definidos.
Dica
Após o mapa mental estar pronto, basta arrastar e soltar os itens para agrupá-los à frente de uma
categoria que englobaria ideias semelhantes. Depois de organizado, o mapa mental se transforma em
uma EAP na própria ferramenta XMind, escolhendo-se, no menu “Estrutura”, o formato de organograma
(Figura 5.18).
FIGURA 5.18 EAP do projeto banquete em homenagem ao presidente de uma empresa feita com o XMind.
Importante
Os exemplos da EAP neste livro seguem uma determinada padronização; assim, na primeira coluna
coloca-se toda a documentação de gerenciamento de projetos, e na última coluna consta o processo de
encerramento do projeto. Essa padronização não é obrigatória. A EAP deve incluir entregas ou delivera-
bles referentes à documentação do projeto, porém o formato padrão contido aqui é apenas uma forma
– ou uma sugestão – de como fazer isso. Fica a critério do gerente de projeto encontrar a melhor forma
de representar a documentação na EAP do respectivo projeto.
5.3.3 Tipos de EAP

Uma boa forma de os iniciantes em gerenciamento de projetos aprenderem a desenvolver uma
EAP é definir um formato para sua criação, considerando o tipo de projeto que será realizado. Nesse
sentido, Haugan (2002) sugere que é possível ter tipos distintos de EAP que seguiriam uma lógica para
a organização das entregas e dos pacotes de trabalho. A seguir, listamos alguns exemplos de como essa
abordagem para a criação de EAPs poderia ser colocada em prática. Nesse ponto é importante lembrar
novamente que tudo isso é apenas uma sugestão. Cada projeto tem suas próprias necessidades e pode,
até mesmo, envolver uma combinação de dois ou mais tipos.
EAP para produtos: geralmente essa EAP é organizada de acordo com uma estrutura física natural
do produto final que está sendo desenvolvido no projeto, conforme ilustrado a seguir (Figura 5.19).
FIGURA 5.19 EAP para um projeto de construção de aeronave. Fonte: Adaptado do Work Breakdown Structure do Department of Defense Handbook,
MIL-HDBK-88, 1998.
Em projetos envolvendo produtos, pode-se fazer uma EAP para o escopo total do projeto e criar EAPs
secundárias para cada componente importante e distinto do projeto. Por exemplo, para a EAP anterior,
pode ser que haja um departamento específico (ou até mesmo uma empresa contratada) para o item
1.5 Dados, que abriria a EAP em itens adicionais, conforme ilustrado a seguir (Figura 5.20).
FIGURA 5.20 EAP secundária.
A seguir, outro exemplo de EAP para produto (Figura 5.21):

FIGURA 5.21 EAP para um projeto de desenvolvimento de um sistema.
EAP para serviços: esse tipo de EAP normalmente reflete as entregas estruturadas do projeto. O
trabalho é dividido em uma ordem lógica das áreas de trabalho envolvidas para produzir o serviço. Para
a organização de um congresso, por exemplo, a EAP teria os seguintes itens (Figura 5.22):
FIGURA 5.22 EAP para um projeto de organização e realização de um congresso.
Outro exemplo: A empresa da EAP anterior também realiza Formaturas, dentro de um formato
padrão que permite customizações, conforme solicitação dos clientes (Figura 5.23).
FIGURA 5.23 EAP para um projeto de organização e realização de uma formatura.
EAP para produtos com ciclo de vida: esses projetos normalmente se baseiam em um ciclo de vida
formal que é seguido pela empresa para organizar o trabalho dos seus projetos. Esse tipo de EAP é
comum em projetos mais técnicos, como aqueles relacionados às áreas de engenharia e tecnologia.
Por exemplo, para um projeto de desenvolvimento de software, as fases, entregas principais e pacotes
de trabalho da EAP seriam os seguintes (Figura 5.24):
FIGURA 5.24 EAP para um projeto de desenvolvimento de um novo software.
EAP para um resultado: esse tipo de EAP seria utilizado em projetos que visam um resultado e não
formam um produto propriamente dito, mas normalmente produzem uma série de produtos que levará
ao resultado desejado. Poderia ser, por exemplo, o caso de um projeto para adequação de uma empresa a
uma legislação específica ou a um padrão – uma certificação ISO, conforme ilustrado a seguir (Figura 5.25).
EAP mista: esse tipo de EAP tem um pouco de todos os tipos mencionados anteriormente. Envolve
um produto final, mas inclui também trabalho relativo a serviços e resultados em uma determinada
sequência que poderia ser um ciclo de vida. O exemplo a seguir ilustra uma possível EAP para um projeto
de uma construção de um prédio sustentável (Figura 5.26).
FIGURA 5.25 EAP para um projeto de certificação na ISO 27001. Fonte: Baseado na Norma ISO 27001.
FIGURA 5.26 EAP para um projeto de construção de um prédio sustentável.
Dicas
• A EAP é a definição das entregas e dos pacotes de trabalho do projeto. Deve refletir o que o cliente
final do projeto irá receber quando o projeto for concluído. Não é uma lista de atividades ou tarefas
necessárias para completar o projeto; isso faz parte do cronograma.
• A EAP é uma ferramenta útil para que todas as partes interessadas tenham uma visualização
rápida e de fácil entendimento quanto ao escopo total do projeto. Não pode ser utilizada como
a única documentação do projeto ou substituir um cronograma colocando-se datas diretamente
nas entregas ou nos pacotes de trabalho – isso não faz sentido. Os recursos que trabalham nos
projetos precisam saber exatamente o que terão que fazer para concluir os pacotes de trabalho
e comporem as entregas pelas quais são responsáveis. Esse “fazer” é refletido por atividades ou
tarefas que reflitam ações específicas que o recurso ou os recursos terão que realizar durante o
projeto.
• Depois que a linha de base do escopo for definida, não será possível alterar a EAP sem que haja uma
aprovação formal de um grupo de partes interessadas que fazem parte de algum tipo de comitê de
controle de mudanças do projeto. Durante o planejamento, o gerente do projeto pode definir uma
data-limite em que mudanças ou adaptações à EAP possam ser feitas antes que a linha de base do
escopo seja congelada.
• A EAP não reflete o sequenciamento das entregas no tempo. Embora geralmente a EAP siga uma
lógica que pode ser sequencial aos acontecimentos do projeto, isso não é um pré-requisito para sua
elaboração ou aceitação. O sequenciamento do projeto no tempo é feito no planejamento do tempo,
refletido no cronograma do projeto, como será visto na próxima seção deste capítulo.
• Há uma regra geral de que a realização de um pacote de trabalho não pode ter mais do que
oitenta horas ou menos do que oito horas. Para os iniciantes, essa determinação pode ser difícil
de entender, pois o cronograma ainda não foi realizado para determinar a duração das atividades
que comporão cada pacote de trabalho. De qualquer forma, essa é uma regra geral intuitiva
que pode ser considerada, em alguns casos, como uma referência para saber quando parar no
desmembramento das entregas em pacotes de trabalho.
Aplicação
A EAP para o projeto de sustentabilidade para a rede de supermercados A – loja 1 ficou assim definida
(Figura 5.27):
FIGURA 5.27 Estrutura Analítica do Projeto – EAP.

Ferramentas
EAPs em formato gráfico podem ser feitas com o recurso “Organograma” no menu do SmartArt do
MS Word, MS Excel ou MS PowerPoint. Há também o software WBS ChartPro™ da empresa Critical
Tools, que custa US$ 199,00 e é considerado o mais completo, com recursos avançados de visualização
e inclusão de vários tipos de informações na EAP. As EAPs deste capítulo foram elaboradas, na sua
maioria, com o WBS Chart Pro™.
A ferramenta de download gratuito XMind também pode ser utilizada para elaborar EAPs, porém o
programa ainda não numera o produto do projeto (o item 1.0 do produto ou resultado do projeto) e não
segue a numeração hierárquica recomendada (1.0, 1.1, 1.2 etc.). Para projetos simples e pequenos, uma
EAP elaborada no XMind (escolhendo-se a opção “Organograma” no menu “Estrutura” e “Numeração”
em “Propriedades”) teria o mesmo efeito do que uma EAP realizada no WBS Chart Pro™ com todos os
recursos. O importante é que a EAP mostre o escopo do projeto, com todas as entregas e respectivos
pacotes de trabalho. A seguir, um exemplo de uma EAP feita com o WBS Chart Pro™ e, em seguida, uma
EAP criada com o XMind (Figuras 5.28 e 5.29).
FIGURA 5.28 Exemplo de EAP com o WBSChart Pro™. Fonte: Adaptado (com permissão) de Projetos para Web – Planejamento
(www.avellareduarte.com.br).
FIGURA 5.29 Exemplo de EAP com o Xmind. Fonte: Adaptado (com permissão) de Projetos para Web – Planejamento (www.avellareduarte.com.br).
5.3.4 Dicionário da Estrutura Analítica do Projeto (EAP)
Conceito
O Dicionário da EAP é uma espécie de glossário que inclui definições de cada pacote de trabalho da
EAP. Essa descrição é importante por vários motivos, pois:
1. Esclarece o significado do nome de trabalho e garante um entendimento consistente entre as partes
interessadas do projeto.
2. Define o significado de um termo técnico que não seja do conhecimento de todos os participantes
do projeto.
3. Descreve o que deve acontecer em cada pacote de trabalho.
4. Serve como base ou orientação para a elaboração das atividades do projeto no cronograma.
Na prática
O nível de detalhamento do Dicionário da EAP depende da complexidade do trabalho e do tipo de

projeto. A seguir, um formato de EAP comumente utilizado (Figura 5.30):
FIGURA 5.30 Formulário para Dicionário de EAP.

Para EAPs de produtos, a descrição do pacote pode incluir uma descrição de um componente físico,
e não do trabalho propriamente dito para fazer esse componente. Como tudo relacionado a projetos,
depende de cada caso. Para EAPs de serviços e resultados, é mais comum ter uma descrição do trabalho
propriamente dito, com atividades específicas que deverão ser realizadas pelos membros da equipe
para concluir cada pacote.
Importante
Um dicionário de EAP não pode existir sem um número de identificação. Após realizar uma EAP,
todo o trabalho do projeto deverá ser acompanhado de um número, conforme aparece na EAP. Sem
esse número, o trabalho será considerado como não aprovado. Apenas o trabalho com um número de
identificação da EAP é considerado aprovado e será executado no projeto.
A seguir, um exemplo do dicionário dos pacotes de trabalho de uma EAP da entrega Convite do
projeto Formatura – exemplo mostrado anteriormente (Figura 5.31).
FIGURA 5.31 Exemplo de Dicionário da EAP.

Dicas
• Dependendo do projeto, o Dicionário da EAP consumirá muitas horas de trabalho do gerente do

projeto e dos membros da sua equipe. Porém, uma vez realizado, o conteúdo poderá ser reaproveitado
para outros projetos que tiverem pacotes de trabalho semelhantes. Isso é verdadeiro especialmente
para os componentes do gerenciamento do projeto, que serão padronizados e se repetirão em todos
os projetos.
• Se o dicionário estiver descrevendo componentes técnicos de um produto, pode ser necessário
primeiro explicar o que o componente é e o que ele faz para, depois, listar o que a equipe do projeto
terá que fazer para completar o pacote de trabalho para esse componente.
Aplicação
A seguir, o Dicionário da EAP do projeto de sustentabilidade à rede de supermercados A – loja 1

(Figura 5.32):
FIGURA 5.32 Dicionário da EAP do projeto de sustentabilidade para a rede de supermercados A – loja 1.
FIGURA 5.32 (Cont.)

FIGURA 5.32 (Cont.)

FIGURA 5.32 (Cont.)
Dicas
A criação de um dicionário de EAP é simples, porém esse processo precisa da colaboração de todas as
áreas envolvidas no projeto. O gerente de projeto pode solicitar a colaboração de cada área na elaboração
do Dicionário da EAP e também explicar aos colaboradores das áreas envolvidas no projeto que, ao
colaborarem com a elaboração do Dicionário da EAP por meio de descrições com atividades específicas,
nas quais são especializados, o cronograma elaborado no gerenciamento de tempo, realizado com base
nesse dicionário, será mais completo e real para a área de cada um.
Exercícios
Planejamento – Escopo: Estrutura Analítica do Projeto (EAP) e respectivo Dicionário

Carlos Peixoto está pronto para detalhar o que deverá ser feito no projeto. Após reunião com os
colaboradores e fornecedores, as entregas e os pacotes de trabalho do projeto são definidos como:
1. Gerenciamento do projeto: todos os documentos padrão serão produzidos.
2. A obra propriamente dita, que envolverá um trabalho de análise da estrutura atual, definição de
novo layout, definição de mobiliário e acessórios, reforma interna, reforma externa, montagens e
instalações.
3. O treinamento dado aos colaboradores, que em primeiro lugar deve considerar a definição do
conteúdo que será ministrado, e depois a elaboração do material do treinamento, bem como a
preparação do local onde o treinamento irá acontecer.
4. Deverá ser realizada também uma promoção da iniciativa da loja com o novo visual da estrutura e da
equipe de vendas. Para isso, primeiro será necessário haver uma definição do material promocional
que deverá ser elaborado, e em seguida uma preparação do material, bem como sua reprodução e
distribuição a clientes atuais e em potencial.
5. Por último, o encerramento, com os componentes padrão.
Material de apoio
Baixe os arquivos EAP e Dicionário da EAP, na pasta Exercícios em Conteúdos extras, na página web
do livro (www.elsevier.com.br/martacamargo).
1. Complete a Estrutura Analítica do arquivo EAP, feito com o software livre Xmind, considerando
as entregas e os pacotes de trabalho do projeto. Você poderá utilizar qualquer outra ferramenta,
desde que a EAP final apareça em formato gráfico (estilo organograma), conforme exemplos deste
capítulo.
2. Elabore o Dicionário da EAP para os pacotes de trabalho considerando apenas a entrega Treinamento
dos colaboradores, no formulário Dicionário da EAP, incluindo os seguintes itens:
a. Número do pacote de trabalho.
b. Nome do pacote de trabalho.
c. Descrição (crie descrições com base em ações comuns a esse tipo de trabalho).
d. Critérios de aceitação (crie critérios de aceitação com base em práticas comuns a esse tipo
de projeto).
6
Tempo
• Dividir o tempo do projeto em atividades com durações e recursos específicos por meio da elaboração
de um cronograma para o projeto.
Conceito
O planejamento do tempo de um projeto define o tempo que será necessário para realizar o projeto
e alcançar seus objetivos. As atividades e os documentos gerados no planejamento do tempo serão
explicados a seguir (Tabela 6.1).
Tabela 6.1 Atividades e Documentos no Planejamento do Tempo

Atividades para planejar o tempo Documentos gerados
Elaborar o plano de gerenciamento de tempo. Plano de Gerenciamento do Tempo
Identificar atividades. Cronograma
Sequenciar as atividades.
Estimar recursos para as atividades.
Estimar durações para as atividades.
A forma como essas atividades serão desenvolvidas pelo gerente do projeto e equipe deve ser docu-
mentada em um plano de gerenciamento de tempo. Esse plano poderá incluir, por exemplo, informações
sobre as ferramentas que serão utilizadas para desenvolver o cronograma, a maneira como os gerentes
funcionais serão comunicados das necessidades de recursos para o projeto, como os recursos serão
alocados, como as durações serão calculadas e assim por diante.
6.1 Cronograma
O cronograma define as atividades que serão feitas no projeto com base em uma decomposição dos
pacotes de trabalho da EAP. Em primeiro lugar, identificam-se as atividades ou tarefas que deverão ser
executados durante o projeto. Depois, há um sequenciamento dessas atividades por meio da identifi-
cação e do estabelecimento de relacionamentos lógicos entre elas (o que precisa vir antes, o que vem
depois etc.). Após identificar as atividades e sequenciá-las, é necessário determinar o tipo e a quantidade
de recursos (pessoas, equipamentos e materiais) necessários para a realização do projeto, bem como
estabelecer quando cada recurso deverá estar disponível.
O processo de desenvolvimento do cronograma determina as datas iniciais e finais para a execução
de cada atividade do projeto, e é interativo e contínuo durante todo o projeto.
As durações das atividades podem ser determinadas de várias formas:
1. Dados históricos de projetos similares.
2. Opinião especializada de profissionais da área.
99
3. Estimativas análogas, que utilizam uma duração de uma atividade anterior semelhante.
4. Estimativas paramétricas, que utilizam uma relação estatística entre os dados históricos e outras
variáveis (por exemplo: metros quadrados em construção, linhas de código no desenvolvimento de
software, horas/funcionário etc.) para calcular a duração padrão para aquela atividade.
5. Estimativas de três pontos, na qual a duração da atividade pode ser construída usando uma média
de três durações, conforme a equação a seguir:
(O + 4 M + P )
Dur. Atividade =
6
Observação: O seria o tempo mais otimista, M, o mais provável, e P, o pessimista.

A estimativa de três pontos é utilizada em casos em que não se tem nenhuma referência para a
duração de uma atividade. Matematicamente falando, a utilização da fórmula mostrada anteriormente
garante uma maior probabilidade de acerto.
No desenvolvimento do cronograma é importante determinar o caminho crítico do projeto. Caminho
crítico é o caminho mais longo do diagrama de rede do projeto e possui folga zero, e em um diagrama
de rede pode haver mais de um caminho crítico. Ele indica quais atividades necessitam de maior
monitoramento (menor folga). A maioria das ferramentas e softwares que fazem cronogramas calcula
o caminho crítico de um projeto automaticamente.
Na prática
Embora a necessária habilidade dos envolvidos no projeto em seguir o cronograma à risca seja con-
siderada o maior desafio de gerentes e membros da equipe de qualquer projeto, o processo de criação
de cronogramas em si é simples. Ou melhor, é simples se o trabalho for benfeito no planejamento do
escopo.
Quando o planejamento do escopo é feito de forma eficiente, o planejamento do tempo torna-se
uma questão de simplesmente abrir os pacotes de trabalho da EAP em atividades, sequenciá-las em
uma ordem lógica dentro dos componentes do projeto, designar a duração para cada atividade e os
responsáveis pela execução dessas atividades.
Assim como o gerente do projeto trabalha como um facilitador para a formação da EAP, ele deve
trabalhar com os recursos de cada área para determinar as atividades, suas durações e os responsáveis
por cada uma. Um projeto dificilmente terá sucesso se o gerente de projeto tomar sozinho a iniciativa
de criar atividades, impor durações e delegar responsabilidades aos membros da equipe. Por mais que
o gerente de projeto conheça a área que está gerenciando, é sempre recomendável trabalhar com os
especialistas de cada área para estipular atividades, durações e responsáveis. É importante também
envolver o pessoal da linha de frente, principalmente na definição das atividades e suas durações, pois
são eles que irão executar o trabalho.
As formas de estimar o tempo para executar as atividades variarão dependendo do projeto. Uma
estimativa análoga será usada quando o projeto for similar a um projeto anterior. Uma estimativa para-
métrica será utilizada quando os elementos do projeto forem estruturados em medidas padronizadas,
como a hora-homem de um engenheiro civil ou de um programador.
O Dicionário da EAP é um grande auxílio na definição das atividades, pois a descrição de um pacote
de trabalho inclui atividades que precisarão ser executadas. Vejamos o exemplo de um projeto visto
anteriormente (Figura 6.1).
Capítulo 6 • Tempo 101
FIGURA 6.1 Exemplo de descrição de pacote de trabalho.
Com base na descrição do trabalho para o item Design, é possível definir as seguintes atividades:
1. Entrevistar representante da turma.
2. Obter preferências.
3. Alocar designer.
4. Elaborar design.
5. Submeter diferentes testes de design para aprovação.
6. Aprovar design.
Após defini-las, o gerente do projeto coloca as atividades em uma sequência lógica, incluindo suas
durações, conforme explicado anteriormente. Quando o projeto não tem uma referência da duração,
o gerente do projeto poderá utilizar as estimativas de três pontos, conforme explicado neste capítulo.
Definidas as durações de todas as atividades, o gerente do projeto monta o cronograma. Para o grupo
de atividades mencionadas, o cronograma seria o seguinte (Figura 6.2):
FIGURA 6.2 Exemplo de atividades no cronograma.
Ferramenta
Cronogramas são normalmente feitos com softwares específicos. Os mais comuns são o Microsoft®
Project ou MS Project e o software livre OpenProj (download gratuito na internet). A interface do usuário
e a funcionalidade do OpenProj são similares àquelas do MS Project.
Dica
O nível de detalhamento das atividades no cronograma dependerá do contexto do projeto. Por

exemplo, para uma equipe interna experiente, que já trabalhou inúmeras vezes no mesmo tipo de
projeto com atividades semelhantes, não há necessidade de detalhar todo o trabalho passo a passo.
Para componentes do projeto cujas atividades serão realizadas por terceiros ou por recursos que nunca
fizeram aquele tipo de componentes, seria melhor que o gerente de projeto detalhasse as atividades
passo a passo para evitar problemas de interpretação do que deve ser feito, bem como problemas de
percepção do tempo de duração das atividades ou tarefas do projeto.
Importante
A duração das atividades não pode ser calculada sozinha. É necessário considerar a duração em
relação aos recursos que irão fazer a atividade. Por exemplo, uma atividade precisa de 24 horas, porém
o recurso só trabalhará quatro horas por dia nessa atividade; assim, a atividade ou tarefa não precisará
de três dias (recurso trabalhando o dia todo no projeto), mas de seis (recurso trabalhando em meio
período todo dia). É necessário ficar atento à forma como a ferramenta de elaboração de cronograma
está configurada. Por exemplo, no MS Project é possível definir durações em horas, dias, semanas, meses
ou até mesmo minutos. Já o OpenProj (software gratuito) só permite em dias.
Aplicação
O Plano de Gerenciamento de Tempo encontra-se no Plano de Gerenciamento do Projeto, item 6B.

Para o projeto de sustentabilidade para a rede de supermercados A – loja 1, o cronograma foi elabo-
rado em três formatos no MS Project:
1. Formato planilha, para auxiliar o gerente do projeto no controle do tempo e dos recursos
(Figura 6.3).
2. Formato gráfico de Gantt, para que os recursos tenham uma visualização rápida (normalmente no
arquivo eletrônico) dos picos de trabalho e do sequenciamento do projeto como um todo. A seguir
um exemplo de uma das sequências de atividades do cronograma com apresentação em formato
de gráfico de Gantt (Figura 6.4).
3. Formato de cronograma de marcos, para que o dono da rede e os gerentes tenham uma visualização
rápida dos pontos mais importantes do projeto (Figura 6.5).
FIGURA 6.3 Cronograma do projeto de sustentabilidade à rede de supermercados A – loja 1 – Formato planilha.
(continua)
FIGURA 6.3 (Cont.)

FIGURA 6.3 (Cont.)

(continua)
FIGURA 6.3 (Cont.)

FIGURA 6.4 Cronograma do projeto de sustentabilidade para a rede de supermercados A – loja 1 – Formato gráfico de Gantt.
FIGURA 6.5 Cronograma de marcos do projeto de sustentabilidade para a rede de supermercados A – loja 1.
Dicas
1. Os dois primeiros tipos de cronogramas são apenas visualizações diferentes do cronograma gerado
no MS Project, no menu “Exibir”.
2. A planilha do MS Project aqui apresentada que reflete, na íntegra, o cronograma do projeto, foi
transformada em planilha do MS Excel para permitir uma melhor visualização do leitor nas páginas
deste livro. Essa técnica de conversão do arquivo do MS Project em planilha do MS Excel é útil,
também, para envio de arquivos de cronogramas a partes interessadas que preferem receber e editar
arquivos em formato de planilha Excel. Para transformar planilhas do MS Project em planilhas do
MS Excel, basta seguir os seguintes passos1:
a. Salve o arquivo do MS Project como “Página da web”.
b. O assistente para exportação será iniciado.
c. Escolha “Usar mapa existente”.
d. Clique em “Exportar para HTML usando modelo padrão”.
e. Clique em todos os botões “Avançar” e conclua.
f. Encontre o arquivo salvo.
g. Mude a extensão do arquivo de .html para .xls ou .xlsx.
h. O cronograma abrirá em MS Excel com a estrutura intacta.
i. Edite como quiser.
3. O cronograma de marcos é um filtro, também no MS Project, escolhido no menu “Projeto”, “Filtro
para:” e “Etapas”. É necessário configurar os marcos no cronograma para que o filtro possa
gerar essa visualização (clique duas vezes na atividade, escolha “Avançado”, selecione “Marcar
tarefa como etapa” e, depois, coloque zero (0) na coluna “Duração da atividade na planilha do
cronograma”.
Ferramentas
(Há vídeo clipes com demonstrações do abaixo na pasta de conteúdos extras na página do livro na
internet www.elsevier.com.br/martacamargo)
• No MS Project, o cabeçalho com informações sobre o projeto pode ser inserido no menu “Exibir”,
em “Cabeçalho”; aparecerá apenas quando o arquivo for impresso no papel ou estiver em formato
PDF.
• No MS Project, é possível modificar a escala do tempo clicando com o botão direito do mouse na
barra de tempo e configurando a visualização (por mês, semana, hora etc.).
• Pode-se também configurar as informações que aparecem nas barras do gráfico de Gantt, clicando
com o botão direito do mouse no gráfico e escolhendo “Assistente do Gráfico de Gantt”.
• No MS Project, para saber o caminho crítico do projeto, basta clicar com o botão direito do mouse no
gráfico de Gantt, escolher “Assistente de Gráfico de Gantt” e assinalar “Caminho Crítico”. O caminho
crítico para o projeto aparecerá em vermelho.
• O cronograma completo pode ficar disponível no formato eletrônico, o que permite aumentar o
tamanho do conteúdo para uma melhor visualização por parte da equipe que trabalha no projeto.
1
Passos obtidos do web site da empresa PMTech em http://www.pmtech.com.br/faqmsp.html.
Importante
Os projetos que começarem direto com um cronograma, sem um Termo de Abertura, Declaração
de Escopo, documentação de requisitos e, principalmente, sem uma EAP e seu respectivo Dicionário,
estarão condenados ao fracasso. A importância de se fazer essa documentação antes do crono-
grama não é simplesmente uma questão de cumprir um padrão PMBOK ou uma metodologia de
gerenciamento de projetos que a empresa possa ter definido: todos esses processos e documentos
facilitam o levantamento e ativam a participação das partes interessadas no fornecimento de
informações-chave ao projeto. Sem essa participação e sem essa visão em comum do que é o pro-
jeto, principalmente no que se refere ao seu escopo, para que depois se entenda como esse escopo
será desmembrado em atividades a serem executadas pelos recursos alocados a ele, o cronograma
funcionará apenas como um documento sem credibilidade, com constantes atualizações e retraba-
lhos. É necessário ter um cronograma real para o gerente do projeto e, principalmente, para quem
irá executar as atividades contidas nele.
Exercícios
Planejamento – Tempo: Cronograma

Projeto: Reforma da loja de roupas femininas
Depois de definir o trabalho que será realizado no projeto considerando entregas e pacotes de traba-
lho na EAP, Carlos Peixoto está pronto para definir as atividades do projeto, ou seja, definir o que cada
membro da sua equipe deverá fazer.
Material de apoio
Material de apoio: baixe o arquivo Cronograma, na pasta Exercícios em Conteúdos extras, na página
web do livro (www.elsevier.com.br/martacamargo). Você poderá fazer o exercício com o MS Excel, MS
Project ou OpenProj. Há vídeos demonstrativos para as operações básicas com o MS Project e o OpenProj.
1. Após baixar o arquivo, realize as seguintes tarefas para concluir o cronograma relativo a uma das
entregas do projeto – o Treinamento:
a. Complete o Cronograma com as atividades para cada pacote de trabalho. Lembre-se que o
Dicionário da EAP contém descrições dos pacotes de trabalho que geram atividades. Atenção!
Você precisará das descrições dos pacotes de trabalho do Dicionário da EAP que elaborou no
capítulo anterior para fazer este exercício.
b. Inclua uma data de início e uma de fim para cada atividade.
c. Insira a duração de cada atividade.
d. Aloque um recurso (quem irá fazer) para cada atividade.
7
Custos
• Definir estratégias e realizar levantamentos de custos dos projetos para a elaboração de orçamentos.
Conceito
O planejamento dos custos de um projeto calcula o dinheiro que precisará ser gasto para fazer o
projeto e alcançar os objetivos propostos. O planejamento dos custos envolve as atividades e os docu-
mentos descritos a seguir (Tabela 7.1).
Tabela 7.1 Atividades e Documentos no Planejamento de Custos

Atividades para planejar custos Documentos gerados
Definir procedimentos de levantamento e controle de custos Plano de Gerenciamento de Custos
Estimar os custos do projeto Estimativas de Custos
Elaborar o orçamento do projeto Orçamento
O plano de gerenciamento de custo irá incluir informações sobre as estratégias para cálculo dos
custos e quais os tipos de custos considerados no orçamento do projeto.
7.1 Estimativas de Custos e Orçamentos

Há várias formas de elaborar estimativas de custo em projetos. As mais comuns são:
• Top-down ou de cima para baixo (com base em projetos anteriores – custos mais genéricos).
• Bottom-up ou de baixo para cima (por componente, pacote de trabalho ou atividade – custos mais
detalhados).
• Paramétrica, na qual se utiliza a relação estatística entre os dados históricos e outras variáveis
(por exemplo: metros quadrados em construção, linhas de código no desenvolvimento de software)
para calcular a estimativa.
Os tipos de custos geralmente considerados nas estimativas de projetos são:
• Custos diretos: custos diretamente relacionados ao trabalho específico do projeto, como custos de
mão de obra contratada especificamente para o projeto, passagens aéreas da equipe que trabalhará
exclusivamente no projeto ou equipamentos comprados para a realização do projeto.
• Custos indiretos: custos indiretamente relacionados ao trabalho do projeto, por exemplo: despesas
de luz, água ou Internet.
• Custos fixos: custos que não estão conectados diretamente ao projeto, como aluguel do prédio onde
a empresa opera, salários e benefícios.
• Custos variáveis: custos que variam conforme o trabalho executado especificamente para o projeto,
como hora/funcionário de trabalhadores temporários contratados para realizar testes em um
componente do projeto ou aluguel mensal de instalações alocadas especificamente para a execução
de alguma parte do projeto.
111
O orçamento considera o custo das atividades e dos recursos que o projeto utilizará, bem como as
reservas de contingência e as reservas gerenciais.
As reservas de contingência cobrem os custos dos riscos conhecidos que apareceram na análise rea-
lizada no planejamento de riscos do projeto. Quanto maior o índice de risco geral do projeto resultante
na análise de riscos, maior deverá ser essa porcentagem para cobrir contingências.
As reservas gerenciais referem-se aos custos dos imprevistos. É uma reserva alocada para cobrir etapas
que podem dar errado no projeto e que não foram identificadas como riscos pela equipe. Normalmente,
em projetos inéditos com variáveis desconhecidas haverá uma maior porcentagem dessa reserva
gerencial do que em projetos já realizados anteriormente.
A linha de base de custos do projeto é composta pelos custos das estimativas e custos das reservas
de contingência. O orçamento total do projeto é formado pelos custos da linha de base mais as reservas
gerenciais, conforme ilustrado a seguir (Figura 7.1).
FIGURA 7.1 Custos que compõem um orçamento. Fonte: Adaptado de Mulcahy, R. PMP® Exam Prep, p. 238, 2009.
Na prática
A maneira como os custos serão estipulados e gerenciados dependerá do tipo do projeto e do poder que
o gerente do projeto tem para criar estimativas de custos e fechar o orçamento do projeto. Se o gerente do
projeto receber um valor fixo para o orçamento do projeto, o planejamento do escopo e das outras áreas de
conhecimento do projeto girará em torno desse valor. O valor servirá como a restrição-mãe de todas as
decisões do projeto. Se o projeto não tiver um valor predeterminado, ou se o valor puder ser negociado,
o gerenciamento dos custos do projeto englobará quatro etapas básicas, conforme veremos a seguir:
Capítulo 7 • Custos 113
• 1a Etapa: Desenvolver uma estimativa de custos com ordem de grandeza de –50% a +100% na fase
inicial do projeto. Na maioria dos casos, essa estimativa é utilizada apenas como uma referência para
saber o limite máximo dos custos que o projeto pode alcançar. O nível de confiança nessa estimativa
inicial deve ser baixo, e ela não poderá ser utilizada como base para decisões sobre as atividades ou
sobre o escopo do projeto. Em algumas empresas, esse valor inicial é decidido pelo patrocinador do
projeto apenas como referência para aprovação do projeto.
• 2a Etapa: Desenvolver um orçamento detalhado e com uma ordem de grandeza de –10% a +15%,
resultado da análise dos custos de todas as atividades do projeto e obtenção da aprovação formal
do valor. Esse valor será utilizado como linha de base e também para medir o sucesso do projeto.
• 3a Etapa: Refinar o orçamento enquanto o trabalho é executado e os custos incorridos no decorrer
do projeto. No final dessa etapa, os números deverão ficar na faixa de 5 a 10% acima ou abaixo do
valor orçado para o projeto.
• 4a Etapa: Monitorar e controlar o orçamento no decorrer da execução das atividades do projeto. É
importante que o gerente de projeto fique atento a certas situações que podem causar alterações no
orçamento:
a. Se os recursos alocados para executar certas atividades demonstrarem menos experiência do que
o esperado, isso pode causar atrasos ou necessidade de treinamento adicional.
b. Os preços de mercadorias ou serviços podem aumentar em relação ao seu orçamento inicial.
c. Alguns recursos alocados no planejamento talvez não estejam mais disponíveis na execução. Por exemplo:
uma sala para testes que estava livre e fora reservada para o projeto foi ocupada por outro departamento
sem o conhecimento do gerente do projeto, e não há como retirar o pessoal que já está lá.
d. O cliente pode solicitar mudanças ao escopo original acordado no planejamento.
Uma boa prática para qualquer gerente de projetos, seja ele iniciante ou experiente, é sempre trabalhar
com a equipe e, em especial, junto dos especialistas das respectivas áreas do projeto para garantir que os
custos sejam levantados com base em um conhecimento técnico do que está sendo orçado. Além do conheci-
mento técnico, quando participa das estimativas a equipe compartilha a responsabilidade pelo cumprimento
do orçamento do projeto. O gerente de projeto continua com a responsabilidade de facilitar o processo de
levantamento das informações de custos com base em ferramentas e técnicas específicas (listadas a seguir);
porém, quando os números vêm de quem conhece o trabalho, o orçamento fica mais real a todos.
Para se chegar a estimativas mais reais, o ideal é combinar técnicas diferentes, conforme o que está sendo es-
timado ou orçado. Por exemplo, para estimar horas/funcionário, é interessante utilizar dados paramétricos. Há
dados no mercado ou no departamento de Recursos Humanos da empresa para diferentes profissionais. Para
partes do projeto similares a procedimentos anteriores realizados pela empresa, é possível utilizar dados
análogos pesquisando a documentação desses projetos. Nesse aspecto, espera-se que a empresa tenha um
mínimo de organização para arquivar orçamentos de fornecedores e outros dados financeiros dos projetos.
O planejamento dos custos do projeto é facilitado quando acontece depois do gerenciamento do
escopo e do tempo. No planejamento do escopo, definem-se as entregas e os pacotes de trabalho que
deram origem às atividades ou tarefas do projeto. No planejamento do tempo, define-se a duração
das tarefas juntamente com os recursos necessários para execução de cada uma dessas tarefas. Dessa
forma, agora no planejamento dos custos do projeto, o gerente de projetos tem condições de fazer um
levantamento mais preciso para saber quanto todas essas atividades e recursos custarão.
Há várias formas de calcular os custos de um projeto. Muitas empresas ou organizações têm processos
específicos no departamento financeiro ou comercial que determinam sistemas informatizados ou formu-
lários específicos para estimativas e orçamentos. Focando sempre o gerenciamento de projetos em nível
iniciante e as formas mais práticas e fáceis de trabalhar com projetos, serão propostas aqui duas categorias
para dividir os custos de um projeto: custos relativos à mão de obra e custos não relativos à mão de obra.
Custos relativos à mão de obra são as horas/funcionário necessárias para a execução de cada atividade
e podem ser:
1. Custos externos, quando o projeto requer recursos humanos de fora da organização do projeto
ou a contratação de consultores ou temporários. Esses custos precisam obrigatoriamente
ser estimados, orçados e acordados com os devidos fornecedores na fase de planejamento
para garantir certo nível de estabilidade ao projeto. Para a maioria dos projetos, há fornecedores
dispostos a darem orçamentos ou, quando isso não for possível, há sempre fontes na internet com
horas/funcionário padrão (ou faixa salarial) para engenheiros, programadores, contadores e outros
profissionais para o cálculo dos custos com mão de obra em projetos.
2. Custos internos; nesse caso, o custo do projeto deve incluir o custo do pessoal interno à empresa. Muitas
empresas consideram esses custos como zero, uma vez que o recurso já está na folha do pagamento, faz
parte do custo fixo da empresa e receberá o salário de qualquer forma. Porém, recomenda-se sempre
incluir os custos de hora/funcionário internos, pois é necessário ter um controle sobre quanto o projeto
irá custar. Não é uma questão de quem vai pagar essas horas/funcionário que serão utilizadas no projeto,
mas é preciso ter uma visão do custo total e real do projeto.
Dica
Cada empresa tem um jeito próprio de tratar custos internos dos projetos. Algumas empresas utilizam
um valor interno para cada cargo, outras utilizam o valor médio do salário no mercado, enquanto ou-
tras assumem um custo zero para aquele determinado recurso humano interno. Gerentes de projetos
veteranos aprenderam que, nos casos em que o departamento financeiro da empresa não considera
custos internos para fins de orçamentos ou estimativas de custos dos projetos, a melhor saída é incluir
uma coluna no orçamento para custos não incrementais, indicando que o valor daquele recurso não virá
necessariamente do orçamento do projeto (que normalmente inclui apenas os custos diretos e variáveis),
mas faz parte do custo do projeto como um todo, que deve ser previsto, monitorado e controlado.
Custos não relacionados à mão de obra, como o nome já diz, referem-se a todo e qualquer custo que
não esteja diretamente relacionado a salários (e respectivos benefícios) ou valores horas/funcionário.
Normalmente, para fins de cálculo de custos não relacionados à mão de obra, os seguintes itens são
considerados:
1. Hardware e software.
2. Equipamentos em geral.
3. Materiais e suprimentos de qualquer natureza.
4. Viagens e eventos.
5. Treinamentos.
6. Aluguel de instalações ou maquinários.
7. Transporte.
8. Refeições.
A seguir, um exemplo de um orçamento genérico para um projeto de tecnologia da informação.
Trata-se de um exemplo de uma empresa hipotética trabalhando em uma estrutura organizacional
projetizada em que todos os recursos humanos são considerados terceirizados para fins de orçamento
do projeto. Os valores no orçamento são apenas para fins ilustrativos, não são valores reais.
Importante
Os exemplos de orçamentos aqui colocados não refletem o custo do produto ou serviço do projeto
ao cliente, mas sim os custos de se fazer o projeto em si. O custo ao cliente envolve uma política de pre-
cificação de serviços e produtos de cada empresa, o que não faz parte do escopo deste livro (Figura 7.2).
FIGURA 7.2 Exemplo de orçamento para um projeto de TI. Fonte: Adaptado (com permissão) do Project Budget Template da Axia
Consulting (www.axia-consulting.co.uk).
(continua)
FIGURA 7.2 (Cont.)
Aplicação
O Plano de Gerenciamento de Custos para esse projeto encontra-se no Plano de Gerenciamento do
Projeto, item 6C.
O orçamento para o projeto de sustentabilidade à rede de supermercados A – loja 1 teve três momentos:
1. No planejamento dos custos, os fundos alocados para o projeto foram divididos com base nas
necessidades para atingir os objetivos do projeto, conforme planilha a seguir. As porcentagens das
reservas foram colocadas às tentativas, condicionadas à revisão após planejamento dos riscos (Figura 7.3).
FIGURA 7.3 Custos no planejamento do projeto de sustentabilidade para a rede de supermercados A – loja 1.
2. Como o escopo do projeto incluiu uma análise de componentes específicos que seriam instalados na
loja 1 e dos tipos de material de marketing que seriam produzidos com base nas pesquisas e estudos,
os itens a serem implementados foram selecionados sem vista dos fundos alocados no orçamento
do projeto e, depois, discriminados em uma planilha detalhada para monitoramento e controle do
projeto, conforme ilustrado a seguir. Após a análise dos riscos (conforme demonstrado no capítulo 11
Riscos), as porcentagens das reservas foram confirmadas e mantidas (Figura 7.4).
FIGURA 7.4 Custos detalhados do projeto de sustentabilidade à rede de supermercados A – loja 1.
3. Por fim, o gerente de projeto produziu uma planilha final, incluindo os custos detalhados, conforme o
item anterior, e os custos fixos dos recursos humanos que trabalharam no projeto, conforme planilha a
seguir. Essa planilha foi importante para mostrar ao patrocinador o custo total do projeto, incluindo custos
diretos, fixos, indiretos e variáveis. O valor da hora/funcionário foi calculado com base na média do salário
do recurso por hora, dividindo o salário mensal pelo número de horas trabalhadas em um mês (Figura 7.5).
FIGURA 7.5 Orçamento com todos os custos do projeto de sustentabilidade à rede de supermercados A – loja 1.
Ferramenta
No MS Project é possível colocar o valor da hora/funcionário de cada recurso que trabalhará no

projeto na Planilha de Recursos. Após a conclusão do cronograma, o programa calcula automatica-
mente o total de horas/funcionário, com base nas alocações das atividades para os recursos humanos
do projeto. Para uma visualização do valor total, calculado pela multiplicação do total de horas que o
recurso trabalhará no projeto pelo valor hora/funcionário do recurso, é só clicar em “Uso dos Recursos”,
conforme mostrado a seguir (Figura 7.6).
FIGURA 7.6 Custos dos recursos como aparecem no MS Project.
Observação: André (Z) é custo zero, pois o recurso é da empresa Z, responsável pelo marketing (custo
do recurso embutido nos custos das entregas de marketing da empresa terceirizada).
Dicas
Há várias formas de minimizar os problemas relativos às estimativas de custos e orçamentos. A seguir,

algumas sugestões com base nas melhores práticas de gerentes de projetos experientes, similares às
propostas por Verzuh (2008):
• Não passar estimativas de custos no elevador, corredor ou durante um cafezinho com o
chefe ou cliente. Eles podem até insistir, mas se o gerente do projeto ceder, ele pagará caro por
isso depois (literalmente!). Embora o PMBOK preveja que, no início do projeto, o gerente de
projeto pode fornecer uma estimativa com uma porcentagem de erro de –50% ou +100%, isso
é muito perigoso em organizações em que não há um processo oficial com base no PMBOK
ou, até mesmo, quando o solicitante dessa estimativa inicial é um gerente de alto escalão
que conhece muito pouco de gerenciamento de projetos. Tudo o que o gerente do projeto disser desse
momento em diante poderá ser usado contra ele depois. A situação se agrava quando ele envia – por
e-mail – uma estimativa de custos e avisa que é apenas preliminar. Esse e-mail é então encaminhado a
outras pessoas, e isso aumenta a probabilidade de que uma delas acredite que aquela é a estimativa sólida
e não preliminar (apesar de estar escrito no e-mail, muitos não leem as mensagens corretamente e agem
em função de informações que entenderam errado). Diante dessas situações, a melhor saída é explicar
que ainda não é possível fornecer estimativas de custos naquele momento do projeto e sugerir uma data
em que essa informação será apresentada formalmente, com dados mais específicos para validar os
números.
• Fazer o possível para não fornecer valores sem ter visto as especificações ou os requisitos do projeto
em primeiro lugar. Por exemplo, para projetos de construção civil é necessário ver, no mínimo, a
blueprint da obra. Em projetos que envolvam algum tipo de maquinário ou tecnologia, é necessário
ter um prévio acesso a todos os requisitos do produto. Uma estimativa de custos que se baseia em
ideias ou “achismos”, em vez de fatos concretos, estará condenada ao fracasso. Toda análise que
envolve custos precisa ter algo concreto a partir do qual os cálculos e as pesquisas de preços serão
feitos.
• As estimativas devem refletir a realidade dos custos. Colocar um “dinheirinho extra para
emergências” não é uma boa prática, a não ser que isso seja fundamentado. Reservas financeiras
são incluídas no orçamento com base em análises específicas confirmando a necessidade
dessas reservas para cobrir determinados riscos associados ao projeto. É importante ser honesto
em qualquer estimativa do projeto, seja ela feita em custos ou prazos, pois a eficiência de
um gerente de projetos é medida principalmente pela sua capacidade de planejar e estimar
corretamente todos os aspectos no projeto. Inflar desnecessariamente as estimativas de custos
dos componentes de um projeto pode levar à sua inviabilidade ou cancelamento.
Exercícios
Planejamento – Custos: orçamento

Chegou a hora de saber quanto Carlos Peixoto irá gastar com cada elemento do projeto. A gerente
da loja – Ana Maria Costa – fez uma pesquisa junto a fornecedores de produtos e serviços e obteve as
seguintes estimativas de custos:
Araras R$ 500,00
Prateleiras R$ 500,00
Balcões R$ 1.000,00
Vitrine R$ 500,00
Fachada R$ 1.000,00
Iluminação externa R$ 500,00
Material de construção R$ 2.000,00
Tintas e acessórios R$ 300,00
Material de treinamento R$ 500,00
Local do treinamento R$ 500,00
Coffee break R$ 150,00
Material promocional R$ 2.000,00
Engenheiro civil (e equipe) R$ 5.000,00
Consultor de marketing R$ 1.000,00
Consultor de treinamento R$ 1.000,00
Além desses custos dos fornecedores de produtos e serviços, Ana Maria fez uma lista dos custos que
serão cobertos pela folha de pagamento da empresa ou pelo orçamento operacional existente:
Salário da faxineira R$ 300,00

Salário da gerente da loja R$ 1.500,00
Água e luz R$ 150,00
Produtos de limpeza R$ 100,00
Material de escritório R$ 100,00
Carlos Peixoto analisou todos esses itens e pediu a Ana Maria para elaborar um orçamento do projeto
organizando os custos em duas categorias: fixos e variáveis.
Material de apoio
Baixe o arquivo Orçamento, na pasta Exercícios em Conteúdos extras, na página web do livro (www.
elsevier.com.br/martacamargo).
1. Faça o orçamento do projeto conforme a solicitação de Carlos Peixoto, incluindo inicialmente os
custos fixos e variáveis relativos à mão de obra e não relativos à mão de obra.
2. Inclua agora uma reserva de contingência de 10% e uma reserva gerencial de 5% no subtotal, e depois
recalcule o valor final do orçamento do projeto.
3. Qual o valor orçado para o projeto? Esse valor está de acordo com a restrição de custos expressa no
início do projeto (não ultrapassar R$ 20.000,00 em custos variáveis)?
4. Que valor será considerado como linha de base do projeto?
8
Qualidade
• Definir e documentar procedimentos de verificação da qualidade dos projetos por meio de fluxogramas
e listas de verificação (checklists).
Conceito
O planejamento da qualidade de um projeto tem como objetivo estabelecer formas de garantir que
as expectativas das partes interessadas sejam atendidas. Em termos gerais, e até certo ponto, simplistas,
qualidade é o resultado de satisfazer os requisitos do projeto.
No passado, a ideia de controlar a qualidade era baseada na inspeção total dos produtos, após sua
conclusão. Esse conceito evoluiu. Atualmente, o foco da qualidade está voltado para o planejamento,
possibilitando a prevenção da ocorrência de falhas. A qualidade deve ser planejada e não somente ins-
pecionada, pois o custo da prevenção de erros é sempre menor do que o custo da correção dos erros.
O planejamento da qualidade envolve, normalmente, três atividades de grande importância ao
projeto e respectiva documentação, conforme explicado a seguir (Tabela 8.1).
Tabela 8.1 Atividades e Documentos do Planejamento da Qualidade

Atividades para planejar a qualidade Documentos gerados
Identificar os padrões de qualidade relevantes ao produto ou produtos do projeto Plano de Gerenciamento da Qualidade
e como satisfazê-los. Fluxogramas
Definir as atividades que serão realizadas no decorrer do projeto para garantir Listas de Verificação ou Checklists
que os requisitos predefinidos sejam atendidos.
Escolher as ferramentas que serão utilizadas para monitorar e controlar a qualidade
durante todo o projeto.
Para a primeira atividade descrita na Tabela 8.1, uma boa prática para iniciantes em gerenciamento
de projetos é fazer um benchmarking, ou seja, pesquisar e descobrir as práticas de sucesso que ou-
tros gerentes de projetos fizeram em projetos semelhantes (dentro ou fora da empresa). A técnica de
benchmarking permite estabelecer padrões realísticos de qualidade com base no que deu certo em
outros projetos e evitar as armadilhas que colocaram outros projetos em perigo.
A segunda atividade descrita na Tabela 8.1 deve contar com formas eficientes de realizar a garantia
da qualidade. A garantia da qualidade acontece durante todo o projeto e é voltada à prevenção de pro-
blemas que podem afetar a qualidade de algum componente do projeto. Esse processo de garantia de
qualidade é feito por meio de auditorias durante a realização das entregas do projeto que verificarão
se os requisitos estão sendo cumpridos conforme o planejado.
As ferramentas de qualidade da terceira atividade irão variar, dependendo do produto ou serviço
do projeto. O PMBOK prevê uma série de ferramentas para planejamento, execução, monitoramento
e controle da qualidade, como gráficos de Pareto, diagramas de causa e efeito, histogramas, gráficos
de dispersão, fluxogramas e listas de verificação ou checklists. A seção a seguir abordará duas dessas
ferramentas: fluxogramas e listas de verificação ou checklists.
123
Na prática
Os padrões de qualidade de um projeto dependerão da área ou do setor em que o projeto estará sendo
realizado e do produto do projeto. Considerando um nível iniciante em gerenciamento de projetos, este
capítulo mostrará duas ferramentas básicas que podem ser utilizadas em qualquer tipo de projeto e em
diversos pontos do projeto. Essas ferramentas são os fluxogramas e as listas de verificação ou checklists.
8.1 Fluxogramas
O formato de um fluxograma pode variar, porém a ideia é sempre a mesma: visualizar a sequência
do trabalho ou dos processos para atingir um fim específico.
A elaboração ou o desenho de um fluxograma genérico segue algumas regras básicas:
1. Determinados símbolos ou formas geométricas representam os processos no fluxograma.
2. Os símbolos devem ter tamanhos e formas uniformes, além de guardar a devida proporção entre si.
3. O tamanho do desenho do fluxo varia de acordo com a complexidade do processo sendo representado.
O tamanho ideal é aquele que permite visualizar o processo sem grandes movimentos, tanto lateral
como verticalmente.
4. O desenho deve ser feito da esquerda para a direita e de cima para baixo.
Há uma série de formatos geográficos ou símbolos para fluxogramas. Para um fluxograma básico,
os símbolos seguintes são os mais usados:
Terminal – Representa o início e o fim do processo.
Processo – Representa qualquer ação para criar, transformar, conferir ou analisar.
Decisão – Indica um ponto do processo que apresenta ações condicionais.
Documento – Representa qualquer documento criado ou transformado no fluxo

do processo.
Linhas de fluxo – Representam o sentido do fluxo da informação.
Dados sequenciais – Representam a continuidade do fluxo no processo.
Exemplo: Uma empresa não tinha um estoque informatizado, e os pedidos ao estoque ocorriam
da seguinte forma: o estoquista, ao receber uma solicitação de peça, verificava na listagem do estoque
sua disponibilidade. Caso estivesse disponível, a peça era entregue ao solicitante e, em seguida, era
dada a baixa no estoque. Caso a peça não estivesse disponível, verificava-se o prazo de entrega junto
aos fornecedores de peças. Informava-se o tempo necessário ao solicitante. Caso ele ainda desejasse
a peça, o pedido ao fornecedor era efetuado imediatamente. Aguardava-se a chegada da peça e a sua
entrada no estoque. Em seguida, a peça era entregue ao solicitante e era dada a baixa no estoque.
Considera-se, neste exemplo, que o fornecedor sempre tinha a peça solicitada disponível para entrega.
Capítulo 8 • Qualidade 125
O fluxograma para o processo de solicitação da peça, conforme essa descrição, seria o seguinte
(Figura 8.1):
FIGURA 8.1 Exemplo de um fluxograma.

8.2 Listas de Verificação ou Checklists

Uma das ferramentas mais utilizadas em processos de verificação em projetos é a lista de verificação
ou checklist. Listas de verificação ou checklists são ferramentas muito úteis para monitorar e controlar
tarefas ou resultados de um projeto. Essas listas variam no formato e no conteúdo do que será verificado.
A Figura 8.2 ilustra um formato genérico que será utilizado nos exemplos a seguir.
FIGURA 8.2 Formato genérico de uma lista de verificação (checklist).
Exemplo: No exemplo anterior do fluxograma para as peças, existe um ponto em que será neces-
sário verificar a qualidade da peça antes de entregá-la ao solicitante. Nesse caso, uma lista de verificação
poderia ser elaborada (Figura 8.3):
FIGURA 8.3 Exemplo de uma lista de verificação (checklist).

No exemplo atual, o fluxograma incluiria um comentário fazendo referência a essa lista de verificação
(Figura 8.4):
FIGURA 8.4 Exemplo de fluxograma com lista de verificação (checklist).
Outro exemplo: Você está abrindo uma empresa para produzir e vender sabonetes artesanais. Como
irá contratar outras pessoas para ajudar na produção, você desenvolveu um processo mediante um
fluxograma e incluiu pontos de verificação para a equipe de produção verificar a qualidade do produto
que está sendo produzido (Figuras 8.5 e 8.6).
FIGURA 8.5 Exemplo de fluxograma projeto de produção de sabonetes.

FIGURA 8.6 Lista de verificação (checklist) para fluxograma do projeto de produção de sabonetes.
Ferramentas
• Para fazer fluxogramas, a melhor ferramenta é o software MS Visio®. É só escolher a opção “Fluxograma
Básico”, clicar na forma, arrastar e soltar.
• Para fazer checklists ou listas de verificação, o MS Word® e o MS Excel® contêm o recurso Desenvolvedor
para criar listas de verificação com interatividade. Há tutoriais da Microsoft na internet com metódos
passo a passo para ativar o recurso “Desenvolvedor” e utilizar os recursos para desenvolver listas de
verificação.
Aplicação
O Plano de Gerenciamento de Qualidade encontra-se no Plano de Gerenciamento do Projeto, item 6D.

Foram feitos fluxogramas e checklists para diversos pontos do projeto que necessitavam de verifica-
ção. A seguir, exemplos de dois fluxogramas e respectivas checklists ou listas de verificação do projeto
sustentabilidade para a rede de supermercados A – loja 1 (Figuras 8.7 a 8.13).
FIGURA 8.7 Fluxograma com listas de verificação (checklists) para o projeto sustentabilidade para a rede de supermercados A – loja 1.
FIGURA 8.8 Lista de verificação (checklist) para o projeto sustentabilidade para a rede de supermercados A – loja 1.
FIGURA 8.9 Lista de verificação (checklist) para o projeto sustentabilidade para a rede de supermercados A – loja 1.
FIGURA 8.9 (Cont.)

FIGURA 8.10 Fluxograma para processo de aquisição – projeto Sustentabilidade para a Rede de Supermercados da Rede A – loja 1.
FIGURA 8.11 Checklist para fluxograma do processo de aquisição – projeto Sustentabilidade para a Rede de Supermercados
da Rede A – loja 1.
Exercícios
Planejamento: Qualidade
Para o processo do treinamento, Carlos Peixoto elaborou o fluxograma (Figura 8.14), que aparece
na próxima página.
Material de apoio
Baixe os arquivos Listas de verificação T-01 e T-02, na pasta Exercícios em Conteúdos extras, na página
web do livro (www.elsevier.com.br/martacamargo).
1. Elabore duas listas de verificação para serem utilizadas na verificação dos pontos de decisão do
fluxograma anterior. Cada lista de verificação deverá ter um mínimo de 10 (dez) itens.
a. A primeira lista (T-01) deverá incluir itens necessários para aprovar o material que foi elaborado
para o treinamento, considerando questões como: o material está claro para o público-alvo? Há
erros gramaticais? O texto está diagramado de forma profissional?
b. A segunda lista (T-02) deverá incluir itens necessários à aprovação da qualidade de reprodução
do material considerando questões como: as cópias estão legíveis? As ilustrações podem ser vistas
claramente? Há espaços para as anotações dos participantes?
FIGURA 8.14 Fluxograma para etapas do treinamento.

9
Recursos Humanos
• Desenvolver matrizes RACI para documentar papéis e responsabilidades das partes interessadas
de um projeto.
Conceito
Em gerenciamento de projetos, os Recursos Humanos consistem basicamente na gestão das pessoas

que irão trabalhar no projeto. Há quatro atividades principais relacionadas aos Recursos Humanos que
devem ser planejadas para, depois, serem executadas, monitoradas e controladas, conforme descrito
a seguir (Tabela 9.1):
Tabela 9.1 Atividades e Documentos para Planejamento dos Recursos Humanos
Atividades para planejar os Recursos Humanos Documentos gerados
Identificar as habilidades necessárias para que os recursos participem do projeto,
adquirir os recursos necessários à execução bem-sucedida do projeto, documentar Plano de Gerenciamento de Recursos Humanos
a hierarquia do projeto, identificar e documentar papéis e responsabilidades. Matriz RACI
Providenciar treinamento e desenvolvimento das habilidades do pessoal do projeto.
Acompanhar o desempenho da equipe, dar feedback, resolver conflitos
e gerenciar mudanças.
O planejamento dos Recursos Humanos requer o desenvolvimento de um plano de Recursos Humanos

para identificar e documentar funções, responsabilidades e relações hierárquicas do projeto. Em todo
projeto, é importante que haja uma definição clara da responsabilidade de cada indivíduo, bem como os
limites de cada um para a resolução de conflitos ou problemas e as tomadas de decisões durante o projeto.
O gerente de projeto é responsável pelo planejamento dos recursos propriamente ditos, pois ele
determina quantas pessoas são necessárias para realizar o projeto e quais tipos de conhecimento essas
pessoas devem ter.
Quando há necessidade de buscar recursos humanos fora da empresa, o gerente de projeto,
geralmente em conjunto com o departamento de RH, planeja o recrutamento, a seleção e o treina-
mento dos recursos que irão trabalhar no projeto. Para esse planejamento, o gerente de projeto precisará
contar com os cronogramas e as estimativas de custos, de forma a adquirir o pessoal necessário ao
projeto dentro do tempo e custo alocados.
As atividades relacionadas ao treinamento e ao desenvolvimento dos recursos envolverão atividades
como um treinamento para o pré-projeto ou workshops com todos os membros da equipe para desen-
volvimento de habilidades de trabalho em equipe entre eles.
Na prática
Para a maioria dos projetos, o planejamento de Recursos Humanos em projetos consistirá ba-
sicamente na definição de que tipo de recursos o projeto irá precisar, bem como os papéis e as
139
responsabilidades específicas para as necessidades daquele projeto. Pode ser que o gerente de projeto
identifique também necessidades de contratações adicionais ou treinamentos para determinados
membros da equipe.
Também faz parte do papel do gerente de projeto identificar como e quando os membros da equipe
começarão a participar do projeto, de que áreas da empresa esses membros virão, quais gerentes
funcionais precisarão aprovar a liberação desse pessoal para trabalho no projeto, qual treinamento
esse pessoal poderá precisar e, por fim, como os membros da equipe serão liberados dos trabalhos do
projeto quando de sua conclusão. Tudo isso é documentado no Plano de Gerenciamento de Recursos
Humanos e variará muito, dependendo do tipo do projeto e dos recursos disponíveis em cada empresa
ou organização.
9.1 Matriz RACI

Independentemente de como os Recursos Humanos serão planejados e gerenciados, será necessário
especificar papéis e responsabilidades específicos para cada projeto. Uma ferramenta muito útil para
documentar papéis e responsabilidades em projetos é a matriz RACI, um acrônimo (em inglês) para:
R = RESPONSIBLE ou responsável pela execução do trabalho envolvido na entrega, pacote de
trabalho, processo ou atividade, ou seja, responsável por assegurar que o trabalho seja realizado.
Refere-se ao executor de determinadas partes do trabalho.
A = ACCOUNTABLE ou responsável pela aprovação do trabalho envolvido na entrega, pacote de
trabalho, processo ou atividade. Refere-se ao aprovador de determinados componentes do trabalho
do projeto.
C = CONSULTED ou consultado para fornecer conhecimentos ou informações para completar o
trabalho. Refere-se ao consultor para a realização de determinados componentes do trabalho do
projeto.
I = INFORMED ou informado sobre o status do trabalho em questão. São aqueles recursos que só
precisam ser copiados nos e-mails ou relatórios em determinados pontos do projeto.
A matriz RACI é útil para definir a participação dos membros da equipe nos diferentes papéis neces-
sários para concluir o trabalho do projeto de forma bem-sucedida. A RACI evidencia a necessidade da
participação de todos, e não apenas daqueles envolvidos diretamente na execução das atividades do
projeto. A matriz é geralmente criada com o eixo vertical – RESPONSABILIDADE –, o qual expressa os
processos ou componentes maiores do projeto, e o eixo horizontal – PAPEL –, que indica a área funcional
à qual a responsabilidade será designada. A Figura 9.1 ilustra o formato genérico de uma matriz RACI.
FIGURA 9.1 Formulário genérico da matriz RACI.

Capítulo 9 • Recursos Humanos 141
A matriz RACI pode ser utilizada para cada atividade do projeto, porém, para projetos de grande
porte, pode ser inviável. Um projeto grande pode ter centenas ou milhares de atividades e a res-
ponsabilidade pela conclusão de cada atividade é, normalmente, alocada a indivíduos na coluna
“Recursos” de um cronograma genérico (feito, por exemplo, com o MS Project ou OpenProj). As res-
ponsabilidades em uma RACI são geralmente atribuídas para entregas, processos ou componentes
maiores do projeto.
Essa matriz pode também ser utilizada para fazer um levantamento das necessidades de contratações,
principalmente quando houver um excesso de R's para um papel funcional, significando que haverá
necessidade de reforços para a realização do trabalho envolvido naquele papel.
Importante
Na elaboração da matriz RACI, é importante considerar o seguinte:

• As designações devem ser atribuídas a uma função ou a um papel funcional, não ao nome de uma
pessoa específica. A alocação a pessoas é feita no cronograma.
• Um papel funcional pode ter duas ou mais responsabilidades. Por exemplo, o Analista de Sistemas
pode ser R – Executor e A – Aprovador em pontos diferentes do projeto.
• É recomendável ter apenas um A por item da matriz (processo, entrega etc.), ou seja, não se recomenda
ter mais do que um Aprovador para evitar gargalos ou jogos de “empurra-empurra”.
• Quando um papel tiver muitos R's (Executores) designados a ele, o gerente do projeto precisa se
perguntar se esse papel conseguirá executar todo o trabalho que o projeto irá gerar, no nível de
desempenho desejado.
• Se ninguém assumir um R (Executor), o item não será realizado – e isso não pode acontecer. Todo
item na matriz RACI precisa de pelo menos um R.
• Os níveis de R (Executor) e A (Aprovador) devem estar próximos do nível de conhecimento e de ação,
ou seja, só pode ser A ou R se estiver familiarizado com o trabalho que está sendo realizado naquela
parte do projeto.
• Todo A tem que ter autoridade para a respectiva aprovação ou não do que está sendo designado.
A autoridade é direta, ou seja, quando um papel funcional recebe um A, esse papel é diretamente
responsável pela aprovação, e não precisa da obtenção da aprovação de outra fonte.
• Deve-se tentar minimizar o número de C's e I's considerando apenas o necessário. Quem não precisar
ser consultado ou informado, não precisa participar daquele item do trabalho. Não se recomenda
colocar C ou I só para ter algo designado a um papel funcional. Se não fizer parte daquela área de
trabalho, é só deixar em branco na matriz RACI.
• Todo C deve participar ANTES da decisão ou ação. É sempre bom verificar se quem está recebendo
um C precisa mesmo participar daquele item e terá disponibilidade para essa participação no tempo
alocado, a fim de que assim não se trave o trabalho.
• A matriz não precisa ter todos os campos preenchidos – apenas o necessário para realizar o projeto.
Não é necessário preencher um determinado papel com C's ou I's só para não deixar vazio.
• A matriz é feita em equipe com as partes envolvidas e pode ser modificada ou adaptada no decorrer
do projeto, conforme o necessário.
• Depois de pronta, a matriz RACI deve ser aprovada pelos papéis funcionais para os quais estão sendo
designadas responsabilidades.
Veja um exemplo de matriz RACI na Figura 9.2.
FIGURA 9.2 Exemplo de uma matriz RACI. Fonte: Adaptado (com permissão) de Roadmap para o Projeto de Implantação do Escritório
de Processos, 2008 (www.elogroup.com.br).
Aplicação
Para o projeto sustentabilidade para a rede de supermercados A – loja 1, o planejamento de Recursos

Rumanos foi bastante simples. Por ser um projeto dentro de uma estrutura organizacional funcional em
uma empresa de médio porte, a hierarquia dos recursos do projeto refletiu praticamente a hierarquia
da empresa. Um organograma considerando a organização dos recursos foi colocado no Plano de
Gerenciamento do Projeto para confirmar apenas como todos se encaixavam no projeto. Não houve
necessidade de treinamentos adicionais ou contratações.
Para ver o Plano de Gerenciamento de Recursos Humanos, consulte o Plano de Gerenciamento do
Projeto, item 6E.
O que foi considerado essencial pelo gerente do projeto foi a elaboração de uma matriz RACI con-
firmando os papéis e as responsabilidades de cada um, como na figura a seguir (Figura 9.3):
Capítulo 9 • Recursos Humanos 143
FIGURA 9.3 Matriz RACI do projeto de sustentabilidade para a rede de supermercados A – loja 1.
Exercícios
Planejamento: Recursos Humanos

Para deixar claro quais serão as responsabilidades de cada um no projeto, Carlos decide utilizar uma
matriz RACI.
Material de apoio
Baixe o arquivo Matriz RACI, na pasta Exercícios em Conteúdos extras, na página web do livro (www.
elsevier.com.br/martacamargo).
1. Elabore uma matriz RACI para o projeto da reforma da loja para designar as responsabilidades de:
a. Gerenciamento e documentação do projeto.
b. Seleção e pagamento dos fornecedores.

c. Treinamento dos colaboradores.
d. Reformas na estrutura interna.
e. Reformas na estrutura externa.
f. Entrega e instalação das prateleiras e das araras.
g. Entrega e montagem das vitrines.
h. Entrega e montagem dos móveis.
i. Recebimento e verificação dos produtos comprados.
j. Decoração das vitrines.
k. Arrumação das prateleiras com produtos e mercadorias.
l. Promoção e divulgação da loja reformada.
E considerando os papéis organizacionais:
a. Dono da loja.
b. Engenheiro civil (e equipe).
c. Consultor em treinamento de vendas.
d. Consultor em marketing.
e. Equipe de vendas da loja.
f. Gerente da loja.
g. Fornecedores.
10
Comunicações
• Elaborar um Esquema das Comunicações para padronizar o fluxo de informações durante a realização do projeto.
Conceito
O planejamento das comunicações terá que definir estratégias e processos para a comunicação das
informações do projeto a todas as partes interessadas. Há duas atividades básicas de comunicações em
qualquer projeto, apresentadas na tabela a seguir (Tabela 10.1).
Tabela 10.1 Atividades e Documentos para o Planejamento das Comunicações

Atividades para planejar as comunicações Documentos gerados
Definir como o fluxo de informações será realizado durante o projeto. Esquema das Comunicações
Definir formas de coletar informações, elaborar relatórios e distribuir Relatório de Andamento
informações sobre o desempenho do projeto. Registro de Problemas
Na prática
O gerente de projeto deve elaborar um documento para registrar os meios e as formas de comuni-
cação específicas para o projeto.
A eficiência desse documento depende, em grande parte, da habilidade do gerente de projeto em
já ter feito, desde o início do projeto, um levantamento correto das partes interessadas e respectivas
influências no projeto. Muitos dos problemas que surgem no decorrer do projeto são devidos à falta da
informação que nunca chegou à pessoa que deveria ter recebido essa comunicação referente a algum
aspecto do projeto. Em empresas de grande porte com atividades globais, há ainda o agravante de a
comunicação estar sendo feita em inglês em países que falam outro idioma, o que adiciona obstáculos
a uma comunicação eficiente.
Não há uma fórmula perfeita de se resolver todos os problemas de comunicação de um projeto.
Contudo, é obrigação de qualquer gerente de projetos primeiro fazer o possível para descobrir quem
de fato precisa ser comunicado do que e quando e, depois, entregar a informação da forma como essa
parte interessada quer e entende. Não adianta, por exemplo, enviar um cronograma detalhado no MS
Project a um supervisor da fábrica que não está acostumado com essa ferramenta. Muitas vezes, um
cronograma em formato de gráfico de barras simples no MS Excel é a solução.
A documentação do projeto é fundamental para a comunicação eficiente a todos os envolvidos.
Porém, o formato em que essa documentação é apresentada não é necessariamente o que o gerente do
projeto prefere (em função de uma determinada ferramenta, por exemplo) ou quer, mas o que é melhor
para o entendimento das partes interessadas.
145
10.1 Esquema das Comunicações

Todo projeto precisa de um documento em que fiquem registrados os nomes das partes interessadas
e suas preferências quanto ao método e a frequência em que querem receber informações do projeto.
Esse documento pode ter vários formatos e conteúdos. O modelo que será utilizado a seguir receberá o
nome de Esquema das Comunicações do Projeto e conterá informações sobre formas de recebimento
das informações, quem receberá essas informações, quando e em que formato, bem como as premissas
e restrições relacionadas especificamente às comunicações do projeto (Figura 10.1).
No planejamento da área de conhecimento “Comunicações”, devem ser elaborados também rela-
tórios e documentos que irão conter informações para monitoramento e controle do projeto. Esses
documentos serão explicados e ilustrados na próxima seção.
FIGURA 10.1 Formulário genérico para o Esquema das Comunicações.
Aplicação
O Plano de Gerenciamento das Comunicações encontra-se no Plano de Gerenciamento do Projeto,

item 6F.
O Esquema das Comunicações para o projeto sustentabilidade para a rede de supermercados A – loja 1
encontra-se a seguir (Figura 10.2).
FIGURA 10.2 Esquema das Comunicações para o projeto sustentabilidade para a rede de supermercados A – loja 1.
Capítulo 10 • Comunicações 147
FIGURA 10.2 (Cont.)

FIGURA 10.2 (Cont.)
10.2 Relatórios e Registros de Informações

Conforme mencionado anteriormente, serão necessários alguns documentos de apoio à comuni-
cação do projeto. Esses documentos são concebidos na fase de planejamento, porém são preenchidos
durante o monitoramento e controle do projeto. Esses documentos são:
1. Relatório de Andamento do Projeto. Incluirá informações sobre o que está acontecendo a em
determinados pontos do projeto. Esse relatório será elaborado conforme as datas no cronograma
e colocado em formato PDF na pasta “SustentaA”, no servidor HJH (Figura 10.3).
FIGURA 10.3 Formulário para Relatório de Status ou Relatório de Andamento do Projeto.
2. Documentação do Gerenciamento das Mudanças. Quando houver necessidade de alguma

mudança no projeto, o solicitante deverá enviar um formulário por e-mail ao gerente de projeto,
que irá analisar a solicitação e analisar o impacto. Se não afetar a linha de base, o próprio gerente
Capítulo 10 • Comunicações 149
do projeto poderá aprovar ou não a mudança. Se afetar a linha de base, a solicitação deverá
ser analisada por um comitê formado pelo sr. José S. (proprietário da rede e patrocinador do
projeto), por Ivan S. (gerente do projeto) e o gerente da área que será afetada pela mudança (por
exemplo, sr. Ernesto S., se as mudanças forem relacionadas às instalações, ou sr. Vicente A., se
forem relacionadas ao marketing, e assim por diante). A situação final da mudança será registrada
no Registro de Problemas para uma rápida visualização do que foi mudado no projeto e para ser
utilizada no processo de lições aprendidas do projeto (Figuras 10.4 e 10.5).
3. Registro de Problemas. Quando houver um problema durante o projeto que leve a um risco ou
que se refira a algum aspecto não planejado no projeto, o gerente de projeto deverá lançá-lo
no Registro de Problemas. Toda solicitação de mudança durante a execução do projeto será
considerada problema e lançada no registro. Esse Registro de Problemas será uma fonte
importante de informações durante a elaboração do Relatório de Lições Aprendidas, no processo
de encerramento do projeto (Figura 10.6).
FIGURA 10.4 Formulário para Solicitações de Mudanças.
FIGURA 10.5 Formulário para Análise de Impacto das Solicitações de Mudanças.

FIGURA 10.5 (Cont.)
FIGURA 10.6 Formulário para Registro de Problemas.
Exercícios
Planejamento: Comunicações
Para confirmar como a comunicação do projeto ocorrerá entre os diversos participantes, Carlos
decide utilizar o formulário Esquema das Comunicações.
Material de apoio
Baixe o arquivo Esquema das Comunicações, na pasta Exercícios em Conteúdos extras, na página
Simule as possíveis necessidades de comunicação no projeto da reforma da loja e elabore um
esquema de comunicação para os membros da equipe do projeto, considerando o tipo, a duração
e as pessoas que trabalharão no projeto. Esse esquema deverá conter as seguintes informações:
a. Tipo de comunicação.
b. Público-alvo.
c. Método.
d. Frequência.
e. Formato.
f. Remetente.
11
Riscos
• Identificar, analisar e avaliar qualitativamente os riscos do projeto, considerando a elaboração de planos
de ação e reservas financeiras para contingências.
Conceito
Riscos são circunstâncias ou acontecimentos inesperados ou incertos que, quando ocorrem, afetam
o projeto de alguma forma. Os riscos que exigem maior atenção são aqueles que tendem a afetar as
linhas de base do projeto, pois impactam diretamente a consecução de seus objetivos. As atividades
normalmente realizadas no planejamento dos riscos são descritas a seguir (Tabela 11.1).
Tabela 11.1 Atividades e Documentos do Planejamento dos Riscos

Atividades de planejamento de riscos Documentos gerados
Definir a abordagem e os processos para gerenciar os riscos Plano de Gerenciamento de Riscos
Identificar riscos Análise dos Riscos
Analisar os riscos
Elaborar as respostas aos riscos identificados
Deve haver um plano que inclua informações específicas de como a equipe irá identificar os riscos,
analisá-los de forma qualitativa e quantitativa (dependendo do projeto), desenvolver planos de ação
em resposta a eles e a definir a maneira como serão monitorados e controlados.
Há basicamente duas abordagens à análise dos riscos:
1. Qualitativa: A análise qualitativa de risco é uma análise subjetiva em que os riscos são analisados
considerando suas implicações ao cumprimento dos objetivos do projeto. Essa análise é feita em
matrizes nas quais se analisa o risco em escalas – de 1 a 5, por exemplo – para probabilidade e
severidade, ou outros fatores qualitativos.
2. Quantitativa: A análise quantitativa de risco conta com números rígidos. Cada risco recebe uma nota,
e não uma avaliação baixa, média e alta. A análise quantitativa de riscos não é necessária para todos
os projetos e pode ser pulada para se passar direto para o planejamento de respostas a riscos. As
técnicas mais comuns utilizadas em análises quantitativas de riscos são: análise de valor monetário,
árvore de decisão e simulação de Monte Carlo. Devido à sua complexidade, esse tipo de abordagem
quantitativa não será discutido neste livro.
Os riscos a um projeto podem ser divididos em categorias como:
1. Externos: Itens regulatórios, ambientais, governamentais, fornecedores, condições do mercado ou
concorrência.
2. Internos: Tempo, custo, mudanças no escopo, inexperiência, planejamento inadequado, pessoas,
pessoal, materiais, equipamentos, área contratual ou jurídica.
3. Técnicos: Aspectos relacionados à tecnologia, especificações técnicas, requisitos do produto.
151
Na prática
Neste material voltado para gerentes de projetos iniciantes, a prática e a aplicação referentes ao
gerenciamento de riscos será focada em uma abordagem qualitativa, conforme explicado a seguir. É
importante lembrar que a abordagem proposta a seguir é apenas uma sugestão. Há inúmeras formas
de realizar esses tipos de análises, e esta é apenas uma delas.
11.1 Estrutura Analítica dos Riscos – EAR (Risk Breakdown

Structure – RBS)
A análise qualitativa dos riscos de um projeto pode começar com uma identificação das categorias
principais dos riscos específicos para aquele projeto.
Por um processo semelhante à criação da Estrutura Analítica do Projeto (EAP), as categorias e sub-
categorias dos riscos específicos para o projeto podem ser hierarquizadas em uma Estrutura Analítica
dos Riscos – EAR (Risk Breakdown Structure – RBS, em inglês), para uma posterior identificação dos
riscos específicos dentro de cada subcategoria (Figura 11.1).
O formato gráfico das categorias e subcategorias dos riscos facilita a visualização dos tipos de riscos
que podem acontecer no projeto e da maneira como eles estão relacionados entre si.
FIGURA 11.1 Exemplo de Estrutura Analítica de Riscos (EAR).
11.1.1 Matriz de Análise Qualitativa dos Riscos

A partir das categorias e subcategorias de riscos definidas na EAR, o gerente do projeto e as partes
interessadas se reúnem para identificar os riscos específicos do projeto. Isso pode ser realizado por meio
de uma reunião de brainstorming para identificação livre de todo risco possível e imaginável para, em
seguida, agrupar os riscos considerados relevantes para uma análise mais detalhada. Nessa primeira
análise qualitativa, a equipe do projeto classifica o risco considerando os seguintes itens:
Capítulo 11 • Riscos 153
1. Impacto de cada risco no projeto ou a maneira como o risco afeta os elementos da tripla restrição
formada por custo, tempo e qualidade, ou qualquer outro impacto considerado importante para o
projeto.
2. Probabilidade ou a chance de o risco acontecer.
3. Severidade ou gravidade dos efeitos do risco.
4. Respostas aos riscos – estratégias que têm como objetivo diminuir um possível efeito prejudicial do
risco aos objetivos do projeto.
Em análises qualitativas de riscos, as seguintes respostas são consideradas padrão:
1. Evitar: Eliminar a ameaça acabando com a causa. Por exemplo: um item do escopo do projeto pode
contaminar um riacho que passa perto da fábrica. Evitar o risco significa remover esse item do escopo
do projeto.
2. Mitigar: Reduzir a probabilidade ou o impacto de uma ameaça, tornando-a um risco menor. Por
exemplo: um projeto precisa contratar 10 engenheiros de software em um prazo de uma semana. Há
o risco de a única agência de empregos com a qual a empresa trabalha não conseguir suprir o número
de recursos necessários. Nesse caso, mitigar significa solicitar os recursos a mais duas agências, para
aumentar a probabilidade de conseguir os recursos no tempo necessário.
3. Transferir: Tornar outra parte responsável pelo risco com a aquisição de seguros, terceirização do
trabalho etc. Por exemplo: algumas atividades do projeto de engenharia civil serão realizadas em uma
área de deslizamento. Transferir o risco seria providenciar seguros de acidente aos trabalhadores e
à obra.
4. Aceitar: Simplesmente aceita-se o risco porque nenhuma outra ação é viável, ou então os riscos são
considerados de pouca probabilidade e baixo impacto, ou ambos. Não há muito a fazer, por exemplo,
quando há riscos de mudanças na legislação ou regulamentação governamental que afetam um
determinado item do projeto.
Há várias formas de identificar e analisar os riscos de forma qualitativa. Geralmente, utiliza-se uma
planilha desenvolvida no MS Excel, similar ao formato ilustrado a seguir (Figura 11.2):
FIGURA 11.2 Formulário genérico para Análise de Riscos de um projeto.
Como preencher o formulário de análise de riscos:

No do risco: Número identificador que pode ser sequencial para cada risco identificado.
Categorias: São definidas para cada projeto, conforme os exemplos a seguir:
• Financeiro – Praticamente todo e qualquer risco que afete os custos do projeto, como os itens que
podem fazer o orçamento estourar ou causar erros nas estimativas de custos.
• Recursos Humanos – Qualquer tipo de item que afete a disponibilidade de recursos ou sua capacidade
de realizar atividades do projeto.
• Cronograma – Qualquer item que afete durações e datas, como problemas de disponibilidade de
recursos nas datas predeterminadas, erros nas estimativas de durações das atividades e atrasos.
• Técnico – Qualquer item que esteja diretamente relacionado aos aspectos técnicos do projeto, como
complexidade técnica, tecnologias novas e integração da tecnologia nova com as existentes na
empresa.
• Gestão – Itens relacionados à habilidade em gerenciamento de projetos ou gestão da empresa como
um todo, em especial quanto ao comprometimento de todos para a realização bem-sucedida do
projeto.
• Comunicação – Itens relacionados ao entendimento dos requisitos e ao controle do fluxo de

informação durante o projeto.
• Operacional – Itens relacionados a problemas relacionados a treinamento inadequado ou
disponibilidade de recursos.
• Político – Itens relativos a órgãos públicos, governo, legislação ou leis.
• Mercado – Itens relativos a instabilidades do mercado, estratégias dos concorrentes e mudanças no
ambiente externo da empresa.
• Fornecedor – Itens relativos ao cumprimento de contratos e entrega de produtos ou serviços pelos
fornecedores, conforme necessário para a realização do projeto.
• Tecnológico – Itens relacionados a mudanças na tecnologia ou introdução de uma nova tecnologia.
• Infraestrutura – Itens relacionados às instalações onde o projeto irá acontecer, condições da área de
trabalho, suporte técnico ao equipamento utilizado no projeto.
Probabilidade – Significa a chance de o risco acontecer. Na análise qualitativa, geralmente há

uma escala de 1 a 5:
1 Muito improvável.
2 De certa forma improvável.
3 Chance de 50% de ocorrer.
4 Altamente provável.
5 Quase certeza.
Severidade – Significa a gravidade do risco, se ele acontecer. Pode ser expresso também em uma
escala de 1 a 5:
1 Impacto pequeno nas linhas de base do projeto.

2 Impacto moderado nas linhas de base do projeto.
3 Impacto significativo nas linhas de base do projeto.
4 Impacto muito significativo nas linhas de base do projeto.
5 Impacto desastroso aos resultados do projeto.
Nível de controle – Expressa o nível de controle sobre o risco da equipe do projeto. Pode ser ex-
presso também em uma escala de 1 a 5:
1 Evitável por meio de ações de mitigação do risco.

2 Altamente controlável pela organização ou ações do projeto.
3 Moderadamente controlável pela organização ou ações do
projeto.
4 Altamente incontrolável pela organização ou ações do projeto.
5 Totalmente incontrolável pela organização ou ações do projeto.
Significância – Obtida pela soma de probabilidade, severidade e nível de controle sobre os riscos:
3-5 Baixa - pouco impacto ao projeto.

6-10 Média - impacta algumas áreas do projeto.
Acima de 10 Alta - impacta os objetivos e os resultados do projeto.
Estratégias para gerenciar o risco – Ações padronizadas que são acionadas dependendo da condição
imposta pelo risco. Essas ações são: aceitar, evitar, mitigar e transferir, conforme explicado anterior-
mente.
A seguir, um exemplo de análise de riscos para um projeto de desenvolvimento de uma solução
de software para integração de outros sistemas em uma determinada empresa com atuação nacional
(Figura 11.3).
FIGURA 11.3 Exemplo de uma Análise de Riscos para um projeto de TI.
FIGURA 11.3 (Cont.)
Aplicação
O Plano de Gerenciamento de Riscos encontra-se no Plano de Gerenciamento do Projeto, item 6G.

Para a análise de riscos para o projeto sustentabilidade à rede de supermercados A. – Loja 1, a equipe
realizou a Estrutura Analítica dos Riscos (EAR) do projeto, conforme ilustrado na Figura 11.4:
FIGURA 11.4 Estrutura Analítica dos Riscos (EAR) do projeto de sustentabilidade para a rede de supermercados A – loja 1.
Com base nas categorias que apareceram na EAR, foram identificados e analisados os riscos para
cada subcategoria, conforme ilustrado a seguir (Figura 11.5).
Após essa análise de risco, considerando a média da significância (que foi 8,6) e seguindo a mesma
classificação para significância (descrita anteriormente na seção Na Prática), verifica-se que a equipe
classificou qualitativamente o projeto atribuindo-lhe um risco geral médio, e decidiu manter a reserva
de contingência de 4% dos custos para os riscos conhecidos e a reserva gerencial de 5% para riscos não
previstos, ou seja, aqueles que a equipe não identificou, mas que podem acontecer no projeto (assim
como em qualquer projeto). Essa porcentagem seria maior se a análise qualitativa dos riscos do projeto
indicasse riscos com alto impacto e alta severidade que a equipe do projeto não tivesse condições de
controlar ou mitigar.
FIGURA 11.5 Análise de riscos para o projeto de sustentabilidade para a rede de supermercados A – loja 1.
FIGURA 11.5 (Cont.)

FIGURA 11.5 (Cont.)
Exercícios
Planejamento: Riscos
Carlos Peixoto está preocupado com relação a alguns aspectos do projeto. Como ele não tem ex-
periência com reformas, Carlos não sabe se haverá problemas no decorrer do projeto, para os quais não
estará preparado. Ele gostaria de fazer um levantamento de tudo o que pode dar errado para ter uma
solução já planejada, no caso de um evento inesperado ocorrer. As áreas que mais preocupam Carlos
encontram-se representadas a seguir pelas questões “e se”:
1. E se o dinheiro não for suficiente?
2. E se suas habilidades como gerente de projeto não derem conta do recado?
3. E se a gerente da loja contratar os fornecedores errados?
4. E se os fornecedores não fizerem as entregas em dia?
5. E se o pessoal da loja não gostar do treinamento?
6. E se o pessoal da obra não aparecer nos dias programados no cronograma?
7. E se os pedreiros não trabalharem com qualidade?
8. E se a instalação de novos aparelhos e equipamentos causar um curto-circuito no prédio?
9. E se o prazo de 30 dias úteis não for suficiente para concluir todas as atividades do projeto?
10. E se as prateleiras compradas não couberem na área reservada para elas?
11. E se a promoção e a divulgação da loja não tiverem os efeitos desejados no mercado?
12. E se o investimento não obtiver o retorno esperado?
13. E se a prefeitura não autorizar a reforma?
Com base nesses receios, Carlos elaborou a Estrutura Analítica de Riscos (EAR) (Figura 11.6):
FIGURA 11.6 Estrutura Analítica de Riscos (EAR).
Material de apoio
Baixe o arquivo Análise de riscos, na pasta Exercícios em Conteúdos extras, na página web do livro
(www.elsevier.com.br/martacamargo).
1. Dê continuidade à análise de riscos com base nas categorias de riscos da Estrutura Analítica de Riscos
(EAR) anterior e nos receios de Carlos Peixoto refletidos nas questões “e se”. Você poderá identificar
riscos adicionais e incluir na análise. Essa análise deverá incluir:
a. Categoria do risco (conforme especificado na EAR do projeto que você elaborou no exercício
anterior).
b. Descrição do risco.
c. Probabilidade.
d. Severidade.
e. Nível de controle.
f. Significância.
g. Estratégia para gerenciar o risco.
h. Plano de ação.
2. Como você classificaria o risco geral do projeto: alto, médio ou baixo? Justifique sua resposta com
base no resultado da análise de riscos do exercício anterior.
12
Aquisições
• Entender e gerenciar o processo de aquisições de bens e serviços do projeto por meio de um plano formal de
aquisições.
Conceito
‘Aquisições’ é, provavelmente, uma palavra estranha para quem não está acostumado com os termos
de gerenciamento de projetos com base nos princípios do PMBOK. O termo em inglês é “procurement”,
que designa o processo de adquirir mercadorias, trabalhos e serviços de terceiros. O processo envolve
um ciclo completo desde a identificação das necessidades antes das contratações até o fechamento
do contrato. As atividades normalmente realizadas no planejamento das aquisições do projeto serão
descritas a seguir (Tabela 12.1).
Tabela 12.1 Atividades e Documento do Planejamento das Aquisições

Atividades para planejar as aquisições Documentos gerados
Decidir se as aquisições serão feitas internamente ou compradas
de fornecedores externos à empresa.
Criar critérios de seleção de fornecedores e prestadores de serviços,
Plano de Gerenciamento das Aquisições
selecionar fornecedores.
Definir o tipo de contrato para o projeto, bem como seus termos
e condições.
Como pode ser observado na Tabela 12.1, a área de aquisições é complexa e envolve toda e qualquer
ação envolvida em compras, aquisições e contratações para o projeto. O planejamento das aquisições
envolverá a elaboração de um Plano de Aquisições em que todas as atividades da Tabela 12.1 serão
detalhadas, conforme as necessidades do projeto e as práticas internas da empresa ou organização.
Uma das ações mais importantes nas decisões durante o planejamento das aquisições é definir o
tipo de contrato que deve ser fechado com parceiros e fornecedores. O PMBOK prevê três tipos básicos
de contratos:
1. Preço fixo ou contratos de preço fechado para contratos com um preço total fixo para um produto
bem definido.
2. Contratos de custos reembolsáveis para contratos que envolvam o pagamento (reembolso) ao
vendedor pelos custos reais.
3. Contratos de preço unitário, em que é paga uma quantia preestabelecida (por exemplo, R$ 70,00 por
hora trabalhada ou R$ 5,00 por metro de grama plantada) ao prestador dos serviços ou vendedor
do produto. O valor total do contrato é uma função das quantidades necessárias para concluir o
trabalho previsto no projeto.
163
Dentro de cada um desses tipos básicos de contratos, há ainda subdivisões em outros tipos de con-
tratos, dependendo da necessidade do projeto e dos procedimentos internos de cada empresa.
Embora o gerente do projeto precise ter conhecimentos nessa área para gerenciar o processo como
um todo, é fundamental que ele trabalhe com os Departamentos de Compras, Jurídico e outros em
todos os aspectos relacionados às aquisições para o projeto. Deve haver um trabalho conjunto entre
as áreas de projeto e outros departamentos da empresa para que o processo como um todo ocorra de
forma eficiente e clara a todas as partes envolvidas.
12.1 Plano de Gerenciamento das Aquisições
Na prática
Como mencionado anteriormente, a área de aquisições de um projeto pode ser bastante complexa,
principalmente se o projeto envolver vários fornecedores de produtos e serviços. Não se espera que
um gerente de projetos iniciante domine todos os aspectos relativos às aquisições, mesmo porque até
os gerentes de projeto experientes precisam de ajuda do pessoal de outros departamentos na empresa
para atender a todos os requisitos dessa área de conhecimento.
De qualquer forma, é importante que o gerente de projetos tenha condições de gerenciar o processo das
aquisições e definir o que precisa ser feito para poder acionar os recursos cabíveis a cada situação que pode
ocorrer durante as aquisições de produtos ou serviços, dependendo do tipo de projeto que estiver gerenciando.
O Plano de Gerenciamento das Aquisições deverá definir claramente os papéis e as responsabilidades
da equipe do projeto no que se refere aos produtos ou serviços que serão adquiridos. O gerente do
projeto precisa identificar quem terá participação na gestão de fornecedores e terceiros e como serão
divididas as responsabilidades de forma a não sobrecarregar desnecessariamente sua equipe com essas
tarefas. É necessário que todos ajudem na gestão de fornecedores e terceiros, porque será necessário
o conhecimento técnico de áreas diferentes. Portanto, o papel do gerente do projeto é fundamental
na definição da relação entre os membros da equipe do projeto, do departamento de compras, do
departamento jurídico e de outras áreas que serão chamadas para auxiliar na gestão de fornecedores e
terceiros (por exemplo, os departamentos de controle de qualidade ou financeiro).
Depois de definidas as responsabilidades da equipe do projeto e as relações com os outros departa-
mentos da empresa, será necessário decidir o que deverá ser fornecido por terceiros e quais as condições
desse fornecimento. Nesse caso, deve-se considerar as seguintes questões:
1. Esse item pode ser fornecido ou produzido internamente ou temos que obtê-lo fora da empresa?
2. Se o item for produzido internamente, ele tem condições de ser fornecido na data estipulada no
cronograma?
3. Quais os itens que precisarão ter fornecedores externos ou ser realizados por terceiros?
4. Que tipos de fornecedores são os mais indicados para fornecer o que o projeto precisa?
5. Quem aprovará as aquisições?
O gerente do projeto, em conjunto com o departamento jurídico ou de compras da empresa (ou
outro departamento, conforme o caso), deverá então decidir que tipo de contrato deverá ser utilizado,
dependendo do item que será adquirido de fornecedores ou terceiros.
O próximo passo é decidir como os assuntos relativos a fornecedores, terceiros e respectivos
contratos serão resolvidos. Como explicado anteriormente, todos esses procedimentos variam de
empresa para empresa, mas, de qualquer forma, é importante ter algum tipo de processo formal
para definir quem é o responsável pela decisão final. Normalmente, quando se trata de contratos de
grande porte, é importante ter um processo de licitação formal para a escolha da empresa contratada.
Capítulo 12 • Aquisições 165
Aquisições ou compras de pequeno porte podem ter processos menos formais e ficarem a cargo do
gerente do projeto. O que seria “grande” e o que seria “pequeno” são, normalmente, definidos pelos
processos internos de cada empresa ou estipulados no plano de aquisições para cada projeto.
Aplicação
O Plano de Gerenciamento do Projeto (item 6.8) inclui as estratégias gerais que foram seguidas para
elaborar o seguinte Plano de Gerenciamento das Aquisições (Figura 12.1):
FIGURA 12.1 Plano de Gerenciamento das Aquisições.

FIGURA 12.1 (Cont.)
Exercícios
Planejamento: Aquisições
Ana Maria Costa entrou em contato com três fornecedores para os novos balcões da loja e des-
cobriu que cada um tem pontos positivos e negativos. Em uma reunião com Carlos Peixoto, ela explica
a situação da seguinte forma:
Capítulo 12 • Aquisições 167
1. Fornecedor A
• Custo na média do mercado.
• Itens fornecidos de boa qualidade.
• Reputação de não cumprir os prazos acordados por problemas administrativos internos da
empresa.
2. Fornecedor B
• Custo 5% acima do mercado.
• Itens fornecidos sempre de boa qualidade.
• Entrega sempre em dia.
• Ótima reputação entre os clientes.
3. Fornecedor C
• Custo 5% abaixo da média do mercado.
• Itens fornecidos de qualidade variável, pois trabalha com vários fabricantes e sempre fecha
com o mais barato, sem preocupação com a qualidade.
• Entrega mais ou menos em dia; não é consistente.
• Reputação varia entre os clientes – alguns deram referências positivas, outros não.
Material de apoio
Baixe o arquivo Avaliação de fornecedor, na pasta Exercícios em Conteúdos extras, na página web
do livro (www.elsevier.com.br/martacamargo).
1. Avalie cada fornecedor com base nos critérios de avaliação do formulário.
2. Qual fornecedor é o melhor para o projeto da reforma da loja? Justifique sua resposta com base na
sua avaliação de cada fornecedor em função das necessidades do projeto.
13
Partes Interessadas
• Documentar e classificar a importância de cada parte interessada, conforme a influência de cada uma no projeto.
• Definir estratégias para gerenciar e monitorar o envolvimento das partes interessadas nos diferentes
momentos do projeto.
Conceito
A área de conhecimento Partes Interessadas foi introduzida pela versão 5.0 do PMBOK, publicada
no início de 2013. Até a versão 4.0 do PMBOK, essa parte estava inclusa na área de conhecimento
Comunicações, que tratava da identificação e do gerenciamento das expectativas das partes interes-
sadas no projeto. A ideia por trás desse rearranjo do conteúdo das áreas de conhecimento é enfatizar
a importância de se controlar mais de perto o nível de envolvimento ou engajamento de cada parte
interessada durante o projeto. Em resumo, essa nova área de conhecimento abrange as seguintes
atividades e documentos (Tabela 13.1):
Tabela 13.1 Atividades e Documentos do Planejamento das Partes Interessadas

Atividades de planejamento das partes interessadas Documentos gerados
Continuar com a identificação e registro das partes interessadas Registro de Partes Interessadas
Elaborar o plano de gerenciamento com estratégias para Plano de Gerenciamento das Partes Interessadas
garantir o envolvimento das partes interessadas
A identificação das partes interessadas começa assim que o projeto é aprovado e continua durante
a fase de planejamento. O objetivo dessa identificação é registrar quem são as pessoas ou organizações
que irão influenciar ou serão influenciadas pelo projeto e qual o seu nível de importância.
Além disso, é importante que o gerente do projeto defina um plano para gerenciar as partes interes-
sadas. Para cada parte interessada, deverá haver uma atribuição clara de sua participação em decisões
e atividades relacionadas ao projeto. É responsabilidade do gerente de projeto controlar e reavaliar o
nível de envolvimento ou engajamento, removendo partes interessadas em pontos do projeto nos quais
sua participação ou seu envolvimento não se fizer mais necessário.
Na prática
Partes interessadas são pessoas ou organizações cujos interesses podem impactar ou influenciar o
projeto de forma negativa ou positiva. Muitas partes interessadas não estarão presentes no dia a dia
do projeto, porém poderão afetar o projeto de alguma forma, como, por exemplo: por meio de um veto
ou não autorização de algum recurso (pessoa, dinheiro, equipamento ou material) que era esperado
para o projeto.
169
Em muitos projetos, principalmente em empresas grandes com partes interessadas em diferentes

localidades e, muitas vezes, em empresas terceirizadas, o primeiro desafio do gerente de projeto é iden-
tificar quem deverá ser considerado parte interessada. Um critério popular entre gerentes de projetos
veteranos consiste em utilizar as questões abaixo para identificar partes interessadas relevantes a um
determinado projeto:
1. Essa pessoa ou organização será direta ou indiretamente afetada por esse projeto?
2. Essa pessoa ou organização está em uma posição de influência direta positiva ou negativa no projeto?
3. Essa pessoa ou organização afetará a liberação dos recursos necessários para a realização do projeto
(material ou equipamento, pessoal ou dinheiro)?
4. Essa pessoa terá habilidades ou capacidades que serão essenciais ao projeto?
5. Essa pessoa ou organização se beneficiará significativamente com o projeto?
6. Essa pessoa está em posição de oferecer resistência às mudanças que o projeto trará?
Se responder “sim” a uma ou mais das perguntas acima, a pessoa será considerada parte interessada,
devendo ser cadastrada e gerenciada no decorrer do projeto.
13.1 Registro das Partes Interessadas

O Registro de Partes interessadas é basicamente um cadastro de pessoas e organizações que terão
uma participação ativa no projeto. Esse Registro é de extrema importância para projetos grandes e com-
plexos, com equipes em diversas localidades, inclusive em países diferentes. É desenvolvido logo no
início do projeto e é normalmente atualizado no decorrer do projeto, conforme se fizer necessário. Para
projetos de médio e pequeno porte, o gerente do projeto precisa também desenvolver um registro de
suas partes interessadas para controlar as expectativas e influências de cada uma ao longo do projeto.
As informações no Registro de Partes Interessadas poderão variar no nível de detalhes, dependendo
das necessidades e complexidade de um projeto, como dito anteriormente. Um formato genérico e fácil
de utilizar é mostrado a seguir (Figura 13.1).
FIGURA 13.1 Modelo genérico de um Registro de Partes Interessadas.

Capítulo 13 • Partes Interessadas 171
Aplicação
A equipe do projeto de sustentabilidade para a rede de supermercados A – loja 1 começou a registrar as

partes interessadas do projeto logo após a aprovação do Termo de Abertura. A seguir o formato em que
o Registro das Partes Interessadas se encontrava no planejamento do projeto (Figura 13.2).
FIGURA 13.2 Registro de Partes interessadas do projeto sustentabilidade para a rede de supermercados A – loja 1.
FIGURA 13.2 (Cont.)
13.2 Plano de Gerenciamento de Partes Interessadas

Ter um bom plano de gerenciamento das partes interessadas é fundamental para garantir o envolvimen-
to ou engajamento de cada uma delas durante o projeto. A pior coisa que pode acontecer a um gerente de
projetos é não ter a ajuda, em especial com informações durante o planejamento do projeto, ou ser ignorado
por uma parte interessada crucial para aprovações de entregas-chave durante a execução do projeto.
A primeira etapa na elaboração de um plano de gerenciamento de partes interessadas é definir es-

tratégias para garantir a participação ativa ou o envolvimento efetivo dessas partes interessadas nas
diferentes fases do projeto. O objetivo principal dessas estratégias é garantir o apoio das partes in-
teressadas, principalmente aquelas de maior influência, e minimizar os impactos negativos de partes
interessadas que não apoiam o projeto.
As estratégias para gerenciar as partes interessadas se baseiam na avaliação do nível de compro-
metimento e envolvimento de cada parte interessada cadastrada no Registro de Partes Interessadas do
projeto. Não há uma fórmula universal para fazer essa avaliação que pode, em muitos casos, depender
da experiência do gerente de projeto na empresa e sua atuação em projetos similares.
Indicadores de envolvimento ou engajamento de partes interessadas no projeto
Uma forma genérica e simples de avaliar as partes interessadas é estimar qualitativamente em que
quadrante da matriz elas estão posicionadas, com base no seu desempenho no decorrer do projeto,
conforme ilustrado a seguir (Figura 13.3).
FIGURA 13.3 Indicadores de envolvimento ou engajamento de partes interessadas.
No eixo vertical, a influência seria avaliada em uma escala de um a cinco, sendo:

A = Alta (4-5) – parte interessada influencia todos os aspectos do projeto, principalmente no que se
refere às linhas de base.
M = Média (3) – parte interessada influencia alguns aspectos do projeto, pode afetar uma linha
de base.
B = Baixa (1-2) – parte interessada não influencia as linhas de base do projeto, mas participará em
atividades do projeto.
No eixo horizontal, a participação seria avaliada com base no planejamento do projeto para aquela
parte interessada específica e de acordo com as atividades do cronograma.
Para garantir o nível de envolvimento adequado de cada parte interessada, durante o monitoramento
e controle do projeto o gerente de projeto analisará o desempenho, considerando seu nível de influência
e participação, e classificará seu nível de envolvimento. Dependendo do resultado dessa análise, o
gerente de projeto deverá aplicar uma ou mais das estratégias descritas a seguir.
1. Alta influência com baixa participação. Esse indicador reflete partes interessadas com
alta influência que não estão participando das reuniões ou não estão realizando as
atividades designadas a elas. Pode ser também aquelas que não estejam demonstrando
interesse em participar do projeto de forma ativa, conforme o planejado e o necessário
para atingir os objetivos do projeto.
Estratégias: Nesse momento o melhor a fazer é marcar uma reunião ou encontro com essa parte
interessada para entender o porquê da sua não participação ou falta de interesse no projeto e, em
conjunto, encontrar formas de aumentar o nível de envolvimento. O gerente do projeto deve fazer o
possível para explicar a ela a sua importância dela no sucesso do projeto.
Há casos em que as partes interessadas não entendem a importância de sua participação, acredi-
tando que o gerente de projeto tenha condições de obter todas as informações e recursos que precisa
para as necessidades do projeto. Cabe, então, ao gerente de projeto esclarecer a função de cada um,
principalmente no que se refere a informações e a recursos necessários para um bom planejamento e
uma boa execução do projeto.
Outros casos podem refletir um levantamento errôneo ou incompleto das expectativas dessas partes
interessadas. O fato de elas acreditarem que suas necessidades e desejos não estejam sendo atendidos
pode levá-las a perder interesse no projeto ou não acreditar nos seus resultados. É importante rever as
expectativas no registro de partes interessadas para verificar se uma exigência considerada essencial
de alguma parte interessada não se transformou em requisito obrigatório do projeto ou se foi ignorada.
Se não for possível atender a uma expectativa considerada essencial por uma parte interessada de
alta influência, o gerente do projeto deve se esforçar ao máximo para explicar o porquê dessa decisão
à parte interessada, considerando os objetivos que se pretende atingir com o projeto e as restrições
(principalmente de custos) sob as quais o projeto está sendo gerido.
2. Alta influência com alta participação. Esse indicador reflete partes interessadas com alta
influência e participação, o que leva a um alto nível de envolvimento. Esse indicador
representa o mundo ideal em gerenciamento de projetos.
Estratégia: É importante que o gerente de projeto mantenha essa parte interessada com o alto
nível de envolvimento apresentado até então. O gerente de projeto deve manter essa parte interes-
sada informada sobre o andamento do projeto, convidá-la para reuniões de planejamento e tomada
de decisão e comunicar-se com ela na forma em que ela deseja ser comunicada (conforme explicado
no capítulo 10 Comunicações). O levantamento eficiente das expectativas dessas partes interessadas
ajuda o gerente do projeto a mantê-las satisfeitas com relação aos seus desejos e necessidades para
com o projeto.
3. Baixa influência com baixa participação. Esse indicador reflete partes interessadas com
baixo nível de influência e cuja participação no projeto está deixando a desejar.
Estratégia: Aqui a situação precisará ser analisada caso a caso. Por exemplo, se essa parte
interessada, apesar de não influenciar o projeto do ponto de vista das linhas de base, tiver uma par-
ticipação na execução de atividades do projeto, o gerente de projeto deverá, como sempre, primeiro
buscar os fatos para entender o problema e, depois, analisar a melhor solução. Pode ser o caso de
providenciar um treinamento para essa parte interessada, trocá-la por um recurso mais experiente,
aumentar a duração de alguma atividade, negociar melhorias nas condições do trabalho e assim por
diante. O importante é identificar a causa central e delinear um plano de ação para resolver o pro-
blema assim que for detectado.
4. Baixa influência com alta participação. Esse indicador reflete partes interessadas com baixo
nível de influência e alto nível de participação. Essas partes interessadas, na maioria das
vezes, são especialistas que serão utilizados como fontes de informações valiosas,
principalmente em áreas que requerem conhecimentos técnicos, por exemplo: área
financeira ou área de riscos.
Estratégia: É sempre bom ter essas partes interessadas como participantes de reuniões de planeja-
mento, monitoramento e controle para auxiliar o gerente de projeto no que for necessário para garantir
que o projeto esteja no rumo certo. Elas precisam se sentir à vontade para voluntariar informações e
participar das decisões em que possam contribuir de forma positiva e proativa.
5. Média influência com média participação. Esse indicador reflete normalmente stakeholders
em níveis gerenciais que participarão apenas em determinados pontos do projeto ou
profissionais que são chamados para executar atividades em determinadas entregas do
projeto. Muitas vezes, são terceirizados e sua influência se baseia em conhecimentos
técnicos ou áreas de especialização.
Estratégia: Esses stakeholders estão atuando no limite, ou seja, para o sucesso do projeto, eles
não podem diminuir sua participação ou acreditarem que não têm nenhuma influência no projeto. O
gerente do Projeto deve mantê-los atualizados das fases do projeto e incentivar a participação sempre
que necessário.
Monitorando e controlando o envolvimento das partes interessadas
Como mostrado na Figura 13.3, os quadrantes superiores deverão ter a maior atenção do gerente do
projeto, pois são essas partes que podem ter um impacto maior no projeto.
O gerente de projeto precisa estar atento ao fato de que algumas partes interessadas podem começar
o projeto motivadas e com um alto nível de envolvimento ou engajamento e, no decorrer do projeto, esse
nível pode abaixar consideravelmente. Por exemplo, no monitoramento e controle de um determinado
projeto, o gerente de projeto notou que o gerente de TI não aprovou uma entrega prevista para uma
determinada data e faltou na reunião de andamento daquela semana. Ele é uma parte interessada
com alta influência naquele projeto cuja expectativa de participação era alta também. A matriz de
gerenciamento de partes interessadas demonstraria o nível de envolvimento desse gerente de TI da
seguinte forma (Figura 13.4):
FIGURA 13.4 Exemplo de uma matriz de gerenciamento de partes interessadas.
Importante
No nível de participação, recomenda-se colocar o nível esperado, que normalmente é A ou alto

para todas as partes interessadas nos pontos combinados do projeto (conforme o cronograma), versus
o realizado, que foi medido em um determinado ponto do projeto (normalmente em reuniões de
andamento ou similar).
Dicas úteis
Muito do sucesso do gerente de projeto em lidar com partes interessadas dependerá de suas habi-
lidades de comunicação e relacionamento interpessoal. Algumas das iniciativas a seguir tendem a dar
bons resultados, principalmente em abordagens proativas que garantam o envolvimento das partes
interessadas1:
1. Entenda o ponto de vista das suas partes interessadas.
Independentemente do cargo da parte interessada, sejam esses em níveis abaixo ou acima
da organização realizadora do projeto, em organizações externas ao projeto ou, até mesmo, em outros
grupos de projetos da empresa, é importante conhecer o que a motiva ou não com relação ao projeto.
Nesse sentido, questões similares às listadas a seguir são úteis para o gerente de projeto conhecer
melhor suas partes interessadas:
a. Qual a visão ou impressão que essa parte interessada tem do projeto?
b. Como essa parte interessada se sente em relação aos objetivos do projeto?
c. Como essa parte interessada se sente em relação a você, gerente do projeto?
d. Como essa parte interessada pode influenciar outras que irão participar do projeto?
e. Qual a experiência que essa parte interessada tem com projetos similares ao seu?
f. Qual o histórico dessa parte interessada com projetos da sua área (por exemplo: relação
colaborativa – sempre apoia e participa com informações e atividades; combativa – discorda
de tudo e não quer fazer nada; reativa - sempre foge das reuniões de planejamento e pede
mudanças durante a execução, participativa durante o planejamento porém não participativa
na execução etc.)?
2. Envolva suas partes interessadas o quanto antes possível.
As respostas às questões acima permitirão uma leitura mais precisa de cada parte interessada
e suas expectativas. Por exemplo, aquelas com um histórico de resistência a projetos da sua área
e de constantes solicitações de mudança durante a execução precisarão ser envolvidas no projeto
desde o início. Muitas vezes, partes interessadas influenciam o projeto negativamente porque não
entendem um componente ou uma abordagem que foi definida no início do projeto e para a qual há
razões que essa parte interessada desconhece. Por exemplo, uma parte interessada pode estar com
expectativas irrealistas sobre o que pode ser feito no projeto por desconhecer restrições de tempo
e custo que foram impostas pelo patrocinador no Termo de Abertura do projeto. O alinhamento
do entendimento de todas as partes interessadas ficará mais fácil se seu envolvimento começar
o quanto antes, fazendo com que todos caminhem juntos no sentido de atingir os objetivos
do projeto.
3. Ouça atentamente o que as partes interessadas estão lhe dizendo.
Muitas vezes, quando ainda não somos experientes em gerenciamento de projetos, temos receio
de conflitos de opinião ou pontos de vista com relação ao projeto. Conflitos apresentam ótimas
oportunidades para entender o pensamento da parte interessada. Nessas ocasiões, é muito importante
ouvir atentamente o que a parte interessada está dizendo, seja na comunicação verbal, na escrita ou
na comunicação não verbal, como expressão facial, linguagem corporal ou gestos. Se houver alguma
indicação de resistência ou objeção, é importante dar a devida atenção para entender o ponto de vista
dessa parte interessada naquele momento e encontrar uma solução em comum para resolução do
problema o mais rápido possível.
1
Estratégias inspiradas no artigo intitulado Os seis princípios de envolvimento de parte interessada (tradução livre de The
6 principles of stakeholder engagement), de Sharma (2008).
4. Adote uma postura de colaboração mútua, não de coerção.

É importante que a parte interessada sinta-se como um membro da equipe, especialmente
se estiver representando uma organização externa ao projeto, por exemplo: outro departamento,
empresa terceirizada ou fornecedor de produtos ou serviços. Em muitos casos, usar coerção
como, por exemplo, ameaçar levar o assunto ao superior ou não trabalhar mais com um
prestador de serviços, não resolve o problema no curto prazo e, muitas vezes, só piora a situação.
É responsabilidade do gerente de projeto criar um ambiente de cooperação mútua entre todas
as partes interessadas do projeto.
O gerente do projeto deve se lembrar, também, que mesmo quando a influência de uma parte
interessada pode não ser muito alta a princípio, essa influência pode mudar no decorrer do projeto
devido a alguma circunstância especial. Por exemplo, um membro da equipe de apoio responsável por
uma entrega pequena pode ter que ajudar em outro componente de maior importância que está no
caminho crítico e que afeta diretamente a data de entrega do produto final do projeto. Dessa forma, é
importante que o gerente de projeto trate com respeito e valorize igualmente todas as partes interes-
sadas do seu projeto.
Aplicação
O Plano de Gerenciamento das Partes Interessadas encontra-se no Plano de Gerenciamento do

Projeto, item 6I.
A Matriz de Gerenciamento das Partes Interessadas do projeto foi desenvolvida da seguinte forma
(Figura 13.5).
FIGURA 13.5 Matriz de Gerenciamento das Partes Interessadas.

FIGURA 13.5 (Cont.)
Exercícios
Planejamento: Partes Interessadas

No início do projeto, Carlos Peixoto começou a desenvolver um registro das partes interessadas do
projeto e registrou suas expectativas e influências.
Material de apoio
Baixe o arquivo Registro de Partes Interessadas, na pasta Exercícios em Conteúdos extras, na página
1. Com base nas informações das partes interessadas que aparecem nas descrições dos exercícios
dos capítulos anteriores a esse, dê continuidade ao registro das partes interessadas do projeto
da reforma da loja de roupas femininas. Inclua possíveis expectativas e influências para cada
parte interessada com base nos cargos ou responsabilidades de cada uma com relação ao projeto.
Lembrete: Por ser uma atualização do documento, a versão do registro passará de 1.0 a 1.1
e você terá que documentar o motivo da atualização no registro de alterações do formulário.
2. No monitoramento e controle do projeto, uma parte interessada com alta influência não está
participando do projeto conforme o planejado. Que tipo de indicador apareceria na matriz
de gerenciamento das partes interessadas e qual a melhor estratégia para aumentar o nível de
envolvimento dessa parte interessada com relação ao projeto?
PA RT E
IV–
Realizando o projeto
Após o planejamento de todas as áreas de conhecimento, o projeto está pronto para ser realizado na
fase conhecida como execução. À medida que o projeto é executado, ele será monitorado e controlado
para garantir que o planejamento seja cumprido, principalmente no que se refere ao cumprimento das linhas
de base de custo, tempo e escopo. Após a conclusão, o gerente do projeto precisa providenciar o fechamento
formal de todas as atividades relativas ao projeto, tanto no aspecto administrativo como no operacional. Os
processos e procedimentos para a execução, o monitoramento e o controle, bem como o encerramento de
um projeto, serão descritos nos capítulos a seguir.
CAPÍTULO 14 Execução.....................................................................................................................183

CAPÍTULO 15 Monitoramento e Controle.......................................................................................199
CAPÍTULO 16 Encerramento.............................................................................................................215
14
Execução
• Entender como as atividades planejadas para as seguintes áreas de conhecimento são postas em prática na fase
de execução de um projeto: Integração, Qualidade, Recursos Humanos, Comunicações, Aquisições e Partes
Interessadas.
Conceito
A execução de um projeto consiste basicamente em colocar em prática tudo o que foi planejado.
Além de produzir as entregas do projeto propriamente ditas, cinco áreas de gerenciamento de projetos
entram em ação, conforme explicado a seguir (Tabela 14.1).
Tabela 14.1 Atividades da Execução de um Projeto

Áreas de conhecimento Atividades
Integração Manter as áreas e os recursos do projeto integrados.
Qualidade Realizar a garantia da qualidade.
Recursos Humanos Adquirir a equipe do projeto.
Desenvolver a equipe.
Gerenciar a equipe.
Comunicação Gerenciar as informações.
Partes interessadas Gerenciar as expectativas das partes interessadas.
Gerenciar as estratégias para manter um alto nível de engajamento
ou comprometimento das partes interessadas, conforme o necessário para
o sucesso do projeto.
Aquisições Realizar as aquisições e contratações.
Na área de integração, a execução significa colocar em prática todos os planos das áreas de co-
nhecimento de forma integrada (escopo, tempo, custos etc.). O trabalho do gerente de projeto nessa
integração é fundamental para que todas as áreas do projeto sejam um todo coeso para produzir os
resultados desejados.
A qualidade do projeto é planejada, executada e monitorada. Especificamente na execução do projeto,
a fase de qualidade é executada por vistorias ou auditorias para garantir que os padrões normais de
qualidade estipulados para o projeto estejam sendo seguidos.
Durante a execução de um projeto, cabe ao gerente de projeto conseguir os recursos humanos neces-
sários para realizar as atividades necessárias, conforme especificado no planejamento dos recursos
humanos. Porém, a obtenção dessa equipe é apenas um dos aspectos da gestão de recursos durante a
execução. O gerente de projeto deve gerenciar a equipe de forma a ajudá-la no que for necessário para
que o projeto seja bem-sucedido. Por exemplo, se um membro da equipe estiver com dificuldades téc-
nicas de realizar as atividades a ele alocadas, o gerente do projeto poderá providenciar um treinamento
adicional ou um suporte técnico para auxiliar esse recurso no que for necessário.
A área de comunicações é fundamental para o sucesso da execução de um projeto, especialmente
no que se refere ao gerenciamento das expectativas das partes interessadas. O gerente de projeto
deve manter as partes interessadas informadas sobre o andamento do projeto, conforme métodos de
comunicação e frequência definidos no planejamento das comunicações do projeto. Partes interessadas
183
de grande influência e impacto nos resultados do projeto devem ter prioridade sobre aqueles que só
pediram para ser informados ou que serão pouco influenciados pelo projeto. É importante, também,
que o gerente de projeto gerencie as estratégias de envolvimento ou engajamento das partes interes-
sadas no projeto, conforme previsto no planejamento.
No que se refere à área de aquisições, cabe ao gerente de projeto gerenciar o processo de compras
de serviços e produtos, dentro dos padrões e das normas de cada empresa ou organização, conforme
definido no Plano de Gerenciamento das Aquisições.
Na prática
14.1 Problemas comuns e soluções

Quando o planejamento do projeto é feito de forma eficaz e interativa com a participação ativa das
partes interessadas, a execução ocorre de forma tranquila e organizada, conforme descrito na parte
conceitual anterior.
Quando não é possível ter um planejamento eficaz e realista para o projeto, há mudanças cons-
tantes e retrabalhos durante a execução, comprometendo as linhas de base do projeto. Normalmente,
problemas na execução são resultados de um ou mais dos fatores descritos na Tabela 14.2.
Tabela 14.2 Problemas Comuns na Execução de Projetos com Soluções

Problema Descrição Solução
Não participação das partes Quando as partes interessadas Antes de o projeto começar, o gerente do projeto
interessadas não têm interesse em participar tem um papel de “evangelizador” do processo
do planejamento do projeto, de gerenciamento do projeto. Todos devem
principalmente na hora de fornecer entender como tudo funciona na metodologia
requisitos claros, específicos e de gerenciamento de projetos adotada na
quantificados, elas tendem a solicitar empresa, antes de o projeto começar. O
mudanças ou ajustes durante a engajamento das partes interessadas na
execução. Isso causa atrasos nos prazos metodologia de gerenciamento de projetos deve
e estouros no orçamento. ser um pré-requisito para o trabalho do gerente
de projetos. É por isso que gerenciamento de
projetos é top-down, ou seja, vem de cima para
baixo. A alta gerência da empresa deve dar
um apoio claro a essa metodologia de projetos
e incentivar todos a entendê-la e só depois
praticá-la.
Falta de apoio do alto escalão da Sem um apoio claro do nível Como dito no item anterior, sem um apoio
empresa estratégico da empresa, muitas de cima para baixo, a metodologia de
partes interessadas não percebem a gerenciamento de projetos de uma empresa não
importância de participar do projeto tem como ser bem-sucedida. O gerenciamento
o mais cedo possível ou de executar de projetos moderno requer um esforço
as atividades conforme planejado multidisciplinar de praticamente todos os setores
e designado. Em alguns casos, eles da empresa. Sem o apoio da alta gerência, o
podem até achar que é problema do gerente de projetos não tem como exigir ou
gerente do projeto que foi contratado esperar colaboração das partes interessadas com
só para fazer isso... relação ao projeto.
Capítulo 14 • Execução 185
Problema Tabela 14.2 Problemas Comuns na Execução de Projetos

Descrição Solução com Soluções (Cont.)
O gerente do projeto está em outro À medida que o mundo se torna É sempre recomendável ter uma reserva no
local, distante do lugar onde o globalizado e o Brasil investe em obras orçamento para viagens do gerente do projeto
projeto será executado de infraestrutura em todo território ao local das obras ou para onde o projeto será
nacional, pode haver casos em que o executado. Um planejamento realista precisa
projeto é planejado em um local para considerar todas as condições onde o projeto
ser executado em outro. É necessário será executado, mesmo quando essas condições
haver um bom alinhamento entre as não sejam as ideais. É melhor saber a realidade
necessidades de documentação do no planejamento e mitigar os problemas nos
projeto e a realidade das condições planos de ação aos riscos do que ser pego
locais onde o projeto será executado, de surpresa depois, durante a execução do
pois, do contrário, a documentação do projeto. As equipes locais devem acreditar no
planejamento será apenas proforma, planejamento para que os resultados desejados
sem utilização real como preparação para o projeto sejam obtidos.
para a execução bem-sucedida do
projeto.
Não familiarização da empresa com Quando a empresa é basicamente Como dito anteriormente, gerenciamento de
metodologias de gerenciamento de operacional (por exemplo, empresas de projetos requer uma abordagem top-down
projetos serviços logísticos ou transportadoras), (de cima para baixo) do nível estratégico da
trabalhar de acordo com uma empresa. Nesse nível estratégico, é necessário
metodologia de gerenciamento de que já tenha sido detectada uma necessidade
projetos não faz parte da cultura de organizar os trabalhos não operacionais em
organizacional. Quando há necessidade projetos gerenciados por um profissional que
de gerenciamento de projetos, as conhece a área de gerenciamento de projetos.
pessoas tendem a não entender a Os colaboradores devem ser informados que
mudança de paradigma e esperar que algumas necessidades operacionais serão tratadas
as atividades sejam predefinidas pelos como projetos, e assim eles devem receber um
superiores e que sejam sempre as treinamento sobre a metodologia de projetos
mesmas, como acontece no trabalho que será aplicada na empresa. É fundamental
operacional. que os colaboradores entendam a nova forma de
trabalhar e participar dos projetos, bem como a
importância de cada um para atingir os objetivos
dos projetos e, consequentemente, da empresa.
Situação “complicada” da empresa Em alguns casos, o gerente de projeto Esse cenário é um dos mais difíceis para o
no mercado terá que planejar um projeto sem o gerente de projeto e, até mesmo, para a alta
apoio dos recursos porque a empresa gerência. A única coisa que o gerente de
não está indo bem ou está prestes a projeto pode fazer é utilizar suas habilidades
ser comprada, ou qualquer outro fator em comunicação e negociação para obter a
organizacional que causa incertezas colaboração de todos para um foco no projeto,
quanto à estabilidade no emprego deixando de lado os outros problemas que
ou futuro da empresa. Se as partes acontecem na empresa naquele momento. Em
interessadas não estiverem motivadas momentos de muita tensão, iniciativas simples
a fornecer informações e participar do como oferecer pizzas e refrigerantes na reunião
planejamento do projeto, a execução de requisitos pode gerar um vínculo de amizade
estará fortemente comprometida. por parte das partes interessadas em relação
ao gerente de projeto. Isso pode ajudar a
aliviar a tensão e motivar as partes interessadas
a participarem do projeto; se não for para o
benefício da empresa, que seja como apoio ao
gerente de projeto.
(Continua)
Tabela 14.2 Problemas Comuns na Execução de Projetos com Soluções (Cont.)

Problema Descrição Solução
Falta de experiência do gerente do Mesmo os gerentes de projetos Quando a empresa já trabalha com alguma
projeto veteranos, quando começam a estrutura de gerenciamento de projetos, esse
trabalhar em uma empresa, enfrentam problema é geralmente menor e, muitas vezes,
dificuldades para planejarem e, até esperado. O gerente do projeto novato na
depois, executarem um projeto sem empresa recebe um projeto de prioridade menor,
retrabalhos ou mudanças. Há sempre que lhe permitirá errar e corrigir em tempo.
um período de adaptação. Esse Quando a empresa não tem uma estrutura
período é necessário, pois é comum o de gerenciamento de projetos, é importante
gerente do projeto estar se adaptando contar com o apoio do alto escalão no que for
aos assuntos relativos ao produto do necessário, durante o período de adaptação
projeto, do ponto de vista daquela (geralmente, por volta de 90 dias).
empresa, e à cultura organizacional.
Nesse período de adaptação é comum
que erros aconteçam, principalmente
na comunicação ou no gerenciamento
das expectativas das partes interessadas.
Isso tende a gerar suposições
errôneas durante o planejamento e,
consequentemente, retrabalho na
execução.
Aplicação
A execução do projeto sustentabilidade para a rede de supermercados A – Loja 1 foi realizado

conforme os itens a seguir.
14.2 Áreas de conhecimento na Execução

• Qualidade: A qualidade do trabalho como um todo era observada no dia a dia, considerando
o cumprimento dos processos e procedimentos estipulados no planejamento do projeto.
• Recursos Humanos: O patrocinador liberou os recursos internos conforme designações de
responsabilidades da matriz RACI e alocações do cronograma. O gerente do projeto gerenciou os
recursos conforme o planejamento do projeto.
• Comunicação: As informações foram distribuídas conforme Esquema das Comunicações.
• Partes Interessadas: O gerente de projeto gerenciou o envolvimento das partes interessadas utilizando
as ferramentas desenvolvidas no planejamento do projeto.
• Aquisições: Produtos foram adquiridos, conforme processos definidos no Plano de Gerenciamento
das Aquisições.
• Escopo: As entregas e os pacotes de trabalho seguiram a EAP, de acordo com as datas das respectivas
atividades no cronograma. A seguir, exemplos de como os componentes e subcomponentes do projeto
foram realizados:
Entregas e pacotes de trabalho da EAP do projeto sustentabilidade para a rede de supermercados
A – loja 1
Entrega: 1.2 Benchmarking
Pacote de trabalho: 1.2.1 Pesquisa Internet
O assunto sustentabilidade no varejo é tema recente no mundo. Entre junho de 2008 e setembro de
2009, o Centro de Excelência em Varejo (GVcev) da Fundação Getulio Vargas (FGV-EAESP) realizou um
fórum para o debate entre os principais interessados no assunto, a fim de criar um guia com as práticas
de sustentabilidade no varejo para funcionários e consumidores. Esse guia, denominado Fórum de
Varejo e Consumo Sustentável: experiências, debates e desafios, é atualmente um dos poucos materiais
disponíveis e amplamente divulgados no Brasil sobre o tema. Dessa forma, esse relatório considerou
esse guia a principal fonte de consulta.
De acordo com o Fórum de Varejo e Consumo Sustentável (2009), recentemente reconhece-se o fato
de que os padrões de consumo vêm se modernizando, possibilitados principalmente pelas atividades no
varejo. Isso gera um impacto significativo no meio ambiente, uma vez que o consumo mundial torna-se
maior a cada dia. Esse consumo resulta em dois principais aspectos negativos ao meio ambiente: 1)
exerce uma pressão sobre os recursos disponíveis no planeta e 2) cria um volume enorme de resíduos
despejados no ambiente.
Ainda de acordo com o Fórum de Varejo e Consumo Sustentável (2009), as mudanças nos padrões de
produção e consumo para formas mais sustentáveis têm sido uma preocupação de ordem mundial, e
o varejo desempenha uma importante tarefa na realização dessas mudanças, pois ele é o elo da cadeia
de produção entre fornecedores e consumidores. Dessa forma, uma pressão por mudanças vinda desse
setor tem um duplo efeito nos consumidores. Em primeiro lugar, há uma preocupação com a educação
dos consumidos no que se refere às práticas sustentáveis nesse setor. Em segundo lugar, há uma neces-
sidade de satisfazer as necessidades dos consumidores já educados em práticas sustentáveis, fornecendo
produtos que causem menos impactos ambientais e sociais.
Para se entender a importância do tema sustentabilidade, pode-se considerar que 5% dos brasileiros
já são consumidores conscientes, segundo pesquisas do Instituto Akatu. A tendência é que esse número
aumente, uma vez que 28% dos consumidores são considerados “envolvidos”, ou seja, estão pelo menos
tentando consumir de forma sustentável, e também outros 59% começam agora a se sensibilizar com
o tema.
O Fórum diz que esse processo de conscientização é uma oportunidade recente que agora começa
a ser explorada pelos varejistas, o que constitui oportunidades de entrada para o varejo sustentável em
três áreas:
◊ Operação e lojas sustentáveis

É possível iniciar o controle e gerenciamento de impactos socioambientais desde a construção até a
operação das lojas. Conforme o Fórum de Varejo e Consumo Sustentável (2009), embora os impactos
ambientais do setor varejista correspondam a uma taxa de apenas 5 a 10% dos impactos totais, é
importante que seja gerenciado para manter uma consistência e servir como exemplo para os outros
vínculos da cadeia de valor.
◊ Gerenciamento da cadeia produtiva
Por meio de incentivos, os fornecedores podem desenvolver produtos com diferenciais ambientais e
sociais, alocando esforços para tornar a cadeia produtiva mais sustentável. Assim é possível também
encorajar fornecedores locais, desenvolvendo a comunidade local, em detrimento das grandes
indústrias.
◊ Educação para os consumidores
O varejo é o lugar onde os consumidores podem ser incentivados a comprar produtos sustentáveis
e serem educados em relação ao correto descarte de materiais, entre outros aspectos da educação
ambiental. O varejo é peça fundamental para a mudança de comportamentos no consumo, pois é
o local que está em contato direto com o cliente.
O Fórum de Varejo e Consumo Sustentável (2009) concluiu que o setor varejista começa a perceber
que precisa assegurar sua participação no campo da sustentabilidade, mas ainda há o temor em com-
prometer seu desempenho econômico. Até agora, tudo indica que o consumidor deseja participar e
contribuir com a construção de um mundo melhor e mais consciente. O varejista que souber aproveitar
essa oportunidade certamente obterá apoio dos clientes e da sociedade.
Princípios de sustentabilidade no varejo

A sustentabilidade é um tema abrangente que aparece em todas as áreas do varejo, o que ocasiona
uma certa confusão em relação a algumas ideias. Um conceito muito bem aceito atualmente e
adotado no Fórum de Varejo e Consumo Sustentável (2009) é o criado pelo The Natural Steps (TNS),
organização internacional sem fins lucrativos, segundo o qual os princípios de sustentabilidade foram
desenvolvidos com o objetivo de representar limites do sistema natural da Terra. Esses princípios
foram desenvolvidos ao longo de 20 anos de pesquisa, envolvendo acadêmicos de alto nível na área
ambiental e natural, e é o mais adotado pelas empresas que abraçam a causa.
A ONG The Natural Steps apresenta três princípios que abrangem uma combinação do que é uni-
versalmente aceito nos campos de geologia, biologia, ecologia, física e química. São eles:
1. Na sociedade sustentável, a natureza não está submetida ao aumento de concentrações de recursos

extraídos da crosta terrestre:
Este princípio lida com o envenenamento do ambiente. Por bilhões de anos, a Terra se ajustou
em um processo lento de sedimentação que mudou muito a composição da vida, gerando
um equilíbrio perfeito que possibilitou a vida como a conhecemos. Ao retirarmos recursos do
ambiente e desregularmos essa composição química, há um alto risco de envenenamento, porém
muito difícil de se medir.
2. Na sociedade sustentável, a natureza não está submetida ao aumento de concentrações de material
transformado pela sociedade:
Assim como no primeiro princípio, a questão aqui é o envenenamento do ambiente. Porém,
aqui trata-se de elementos artificiais que sequer existem na composição química da vida.
Alguns desses elementos artificiais sequer decompõem-se no ambiente, e aqueles que o fazem
quase sempre deixam para trás compostos artificiais que elevam o risco de envenenamento.
É preciso evitar que esses materiais cheguem até o meio ambiente, o que ocasionaria enormes
prejuízos.
3. Na sociedade sustentável, a natureza não está submetida ao aumento da degradação dos meios
físicos:
Diferentemente dos dois primeiros princípios, esse último trata da destruição física do meio
ambiente. Estima-se um limite para que os ecossistemas essenciais à vida na Terra sobrevivam à
destruição causada por atividades da sociedade. Essa destruição física refere-se às estruturas dos
ciclos naturais, como rios, mares, montanhas e campos. Também trata da biodiversidade, da qual
somos dependentes. Alguns exemplos são os grandes cortes de madeira em áreas florestais, grandes
capturas de peixe etc.
Como é possível perceber, os princípios são declarados em forma negativa. Isso ocorre porque seria
inviável conceber princípios dizendo o que se espera que se faça quanto à sustentabilidade. Isso também
ocorre por conta dos objetivos pretendidos com esses princípios, ou seja, colocar limites e barreiras ao
desempenho das atividades do homem.
Uma pergunta que surge naturalmente ao se aprofundar o tema sustentabilidade é a questão da
dimensão econômica. Como ela fica nessa história toda? Responder a essa pergunta é mais fácil do que
se pensa... Diferentemente do que se pensava no passado, atitudes sustentáveis hoje deixaram de ser
um peso para a cadeia produtiva. Ser sustentável passou a ser uma ideia incorporada ao pensamento
estratégico das empresas.
Certificações ambientais
As certificações ambientais usuais para o setor do varejo não são aquelas já usualmente conhecidas
aplicadas às indústrias de transformação como um todo, como a ISO 14001 e as regulamentações da
CETESB, Companhia Ambiental do Estado de São Paulo, que já atua fortemente no sentido de minimizar
impactos ambientais por conta da transformação de bens.
Quando se fala em varejo, não se pensa nos seus consequentes impactos ambientais, visto que
por natureza ele é somente um intermediador de negócios entre a indústria e o consumidor final. As
práticas de ideias sustentáveis no varejo estão, na sua maioria, focadas em uma iniciativa de uma ONG
americana, a USGBC – United States Green Building Council, que desde 1993, quando foi fundada por
David Gottfried, se preocupa com os impactos da construção civil para o meio ambiente e prega formas
de construção sustentáveis.
Atualmente, o GBC encontra-se em 14 países, incluindo o Brasil, onde certifica construções feitas
de forma sustentável com o LEED (Leadership in Energy & Environmental Design), de acordo com os
critérios estabelecidos para a racionalização e máxima redução da utilização de recursos naturais, como
água e energia elétrica. O LEED é hoje a certificação sustentável mais conhecida e almejada no Brasil,
no que se refere à construção de prédios e infraestruturas sustentáveis.
Pacote de trabalho: 1.2.2 Pesquisa de campo
Nosso principal estudo benchmarking focou na loja “verde” do Pão de Açúcar, situada na cidade de
Indaiatuba, estado de São Paulo, onde após um investimento de 7,5 milhões de reais, foi montado o
primeiro supermercado “verde” da América Latina. O supermercado de Indaiatuba reúne iniciativas de
sustentabilidade de todo o Grupo Pão de Açúcar – e isso configura um diferencial da loja na região, ao
mesmo tempo em que serve de um piloto para outras lojas similares do grupo.
Nesse supermercado do Pão de Açúcar em Indaiatuba, desde o projeto inicial até seu funciona-
mento, houve uma preocupação com o meio ambiente. A construção da loja foi planejada com base
nos pré-requisitos exigidos pelo GBC – Green Building Council para a certificação LEED, que garante
que a infraestrutura é 80% sustentável.
Em visita à loja no dia 3 de março de 2010, pôde-se notar todas essas iniciativas, começando pelo
chão do estacionamento, onde há um sistema de concregrama, um concreto vazado que permite a
absorção mais rápida da água e alimenta os lençóis freáticos. Há também espaços diferenciados no es-
tacionamento para veículos com biocombustível, bem como espaços reservados para bicicletas. Ainda
no estacionamento, há estações de reciclagem (óleo de cozinha, plásticos, papel, vidro e metal), e vagas
reservadas para facilitar as entregas dos produtos recicláveis. Um paisagismo diferenciado em torno do
prédio utilizou plantas nativas da área e espécies típicas da região.
Para economia de energia, a iluminação do interior da loja é feita com um número bastante reduzido
de lâmpadas. Todas as lâmpadas são acompanhadas por uma calha refletora, que garante uma maior
eficiência na luminosidade. As telhas possuem uma capacidade refletiva e uma manta isotérmica,
fazendo com que o ar-condicionado seja mais eficiente e proporcione uma economia de até 10% de
energia, proporcionando o conforto térmico.
Considerando ainda a infraestrutura da loja, para evitar a eliminação de fluidos gasosos dos re-
frigeradores e congeladores que normalmente causam danos à camada de ozônio, foram adotados
aparelhos que expelem gases neutros, sem efeito no meio ambiente. Para uma maior economia da
água, foram usadas torneiras com sensores, o que pode reduzir até 40% do consumo de água da loja.
A água utilizada nos chuveiros dos colaboradores é aquecida por meio do reaproveitamento do calor
gerado pela casa das máquinas, economizando cerca de 48 mil kW/h por mês. O mobiliário da loja é
feito de madeira de reflorestamento certificada, com selo FSC, que garante uma extração sustentável
das florestas.
Os carrinhos utilizados para fazer as compras são todos feitos da reciclagem de garrafas PET. As
compras dos clientes podem ser colocadas em sacos de papel kraft certificado ou em caixas de papelão
que embalam as mercadorias da loja (e que antes eram descartadas) ou ainda em sacolas retornáveis
feitas de lona, utilizando-se também sacolas plásticas biodegradáveis. No ponto do caixa, há ainda um
novo conceito chamado de Caixa Verde: uma caixa em que os clientes podem descartar embalagens
dos produtos em vez de levá-las para casa.
Conforme o site oficial da rede, uma das principais iniciativas para fortalecer esse novo conceito
é a disposição de mais de 750 produtos considerados orgânicos, naturais e sustentáveis na loja, dos
quais 400 já são comercializados nas outras lojas da rede e 350 são exclusivos da loja de Indaiatuba.
A padaria faz pães com farinhas orgânicas; no açougue há carnes certificadas com garantias de que
os animais não foram alimentados com hormônios; as frutas, verduras e legumes orgânicos são
comercializados não apenas no formato embalado, mas também a granel, garantindo uma melhor
qualidade. Outra iniciativa adotada na loja de Indaiatuba foi a comercialização de produtos artesanais
locais, incentivando assim a economia da região.
Outro exemplo prático que a equipe não teve oportunidade de visitar é o Walmart do bairro do
Campinho no Rio de Janeiro. O Walmart classifica esse tipo de loja como “lojas ecoeficientes”. Essa
primeira loja ecoeficiente do Walmart foi inaugurada em 2008 e inclui cerca de 60 iniciativas de sus-
tentabilidade. Embora não tenha sido possível visitar a loja no Rio, a equipe assistiu ao vídeo disponível
no site da empresa (conforme endereço eletrônico nas Referências), que mostrou iniciativas similares
às do Pão de Açúcar.
Além dessas grandes redes que estão investindo em construção de lojas totalmente sustentáveis,
a equipe verificou que outras redes apresentam algumas iniciativas, como o Extra e o Carrefour, que
contam com estações de reciclagem do lixo e sacolas retornáveis.
Entrega: 1.3. Pesquisa junto aos clientes
Pacote de trabalho: 1.3.1 Elaboração do questionário
Para a elaboração do questionário, optamos por questões objetivas que pudessem ser facilmente
tabuladas em uma planilha MS Excel. Paulo elaborou as questões com base nas sugestões e ideias de
todas as partes interessadas. Decidimos focar em sete questões básicas para ter um perfil genérico dos
clientes da loja 1 da rede de supermercados A e descobrir o que esses clientes pensam com relação a
práticas de sustentabilidade que afetam diretamente o setor de varejo (Figura 14.1).
FIGURA 14.1 Questionário para coleta de informações.

Pacote de trabalho: 1.3.2 Aplicação do questionário

Paulo ficou encarregado de aplicar o questionário junto aos clientes. O questionário foi respondido
em forma de entrevista aos clientes da loja no dia da pesquisa. A aplicação levou oito horas, e foram
entrevistados 80 clientes.
Pacote de trabalho: 1.3.3 Tabulação dos dados
Os dados foram tabulados manualmente em uma planilha do MS Excel, conforme exemplo a seguir
(Figura 14.2).
FIGURA 14.2 Exemplo de tabulação dos dados.
Pacote de trabalho: 1.3.4 Elaboração do relatório

Com base nos dados coletados, a equipe de projeto elaborou o relatório a seguir.
Relatório do resultado da pesquisa com os clientes da rede A
Este é o relatório com o resultado da pesquisa e nossos comentários:
1. Qual sua idade?
• Até 21 anos – 11,25%
• De 22 a 29 – 33,75%
• De 30 a 44 – 30,00%
• De 45 a 60 – 20,00%
• Acima de 60 anos – 5%
A pesquisa demonstra que o varejo em questão (supermercado) atende atualmente todas as faixas
etárias, com ênfase à população adulta com idade entre 22 a 44 anos. Esse indicador apresenta-se como
ótima oportunidade para que a rede de supermercados A adote práticas sustentáveis, com projetos
educacionais elaborados para educar ambientalmente crianças e adolescentes.
2. Qual seu sexo?
• Masculino – 50,00%
• Feminino – 50,00%
Esse resultado mostra que, contrariamente à percepção popular, supermercados não são frequenta-
dos por uma maioria de mulheres. Hoje em dia, ambos os sexos compram produtos de supermercado em
um número igual. Dessa forma, ações de sustentabilidade terão um público-alvo sem distinção de sexo.
3. Com qual frequência você faz compras?
• Diária – 6,25%
• Semanal – 36,25%
• Quinzenal – 23,75%
• Mensal – 33,75%
A pesquisa apontou uma rotatividade de clientes que frequentam esse tipo de varejo.
4. Você costuma fazer reciclagem no seu cotidiano?
• Sim – 68,75%
• Não – 31,25%
Se sim, onde você pratica?
• Casa – 62,82%
• Trabalho – 29,49%
• Igreja – 6,41%
• Escola – 1,28%
O resultado dessa questão é um fator motivador para a implantação de práticas sustentáveis na rede A.
Os números indicam que grande parte dos clientes já incorporaram hábitos sustentáveis em sua rotina.
5. Como você considera a sua preocupação com práticas sustentáveis no seu dia a dia?
• Muito alta – 18,75%
• Alta – 53,75%
• Baixa – 23,75%
• Muito baixa – 3,75%
Outro fator fundamental em nossa análise: os resultados demonstram uma grande preocupação dos
clientes com sustentabilidade.
6. No momento da compra, você dá preferência para produtos sustentáveis?
• Sim – 42,50%
• Não – 57,50%
Esses números refletem que, no momento, ainda não é hábito entre os clientes demonstrar pre-
ferência por produtos “verdes” em supermercados. Uma possível causa pode ser a falta de oferta de
produtos sustentáveis, com a mesma variedade na qual produtos não sustentáveis são oferecidos nos
supermercados da rede A.
7. Você considera importante seu supermercado adotar práticas sustentáveis?
• Sim – 98,75%
• Não – 1,25%
O resultado dessa questão confirma a importância de se adotar práticas sustentáveis na rede A para
atender às expectativas dos clientes que, na sua grande maioria, consideram importante as práticas
sustentáveis no supermercado.
Conclusão
A loja 1 da rede de supermercados A atende a todas as faixas etárias, com uma alta rotatividade
de clientes. Mesmo considerando iniciativas simples, como a reciclagem de materiais, a pesquisa
demonstra que, seguindo uma tendência mundial, os clientes estão engajados e/ou preocupados com
a sustentabilidade do nosso planeta. O resultado da pesquisa, conforme demonstrado anteriormente,
se apresenta como um fator direcionador e motivador para a adoção de práticas sustentáveis na rede
de supermercados A, que assim pode atender às expectativas dos clientes atuais e atrair novos clientes
que dão preferência a estabelecimentos comerciais que incorporam práticas de sustentabilidade em
sua rotina operacional.
Entrega: 1.4 Proposta de implantação
Pacote de trabalho: 1.4.1 Levantamento de opções de sustentabilidade
Após análise das informações coletadas por meio do benchmarking e da pesquisa de campo, a equipe
elaborou a seguinte lista com ideias candidatas à implantação na rede A – loja 1:
• Caixa de papelão em substituição às sacolas plásticas no caixa.
• Produtos sustentáveis.
• Ponto de coleta de reciclagem.
• Sacola retornável.
• Sacola biodegradável.
• Aproveitamento do calor dos freezers.
• Cobertura com manta térmica.
• Energia solar.
• Telha transparente.
• Captação de água da chuva.

• Caixa verde (depositar embalagens).
• Carrinhos produzidos com matéria-prima oriunda de garrafas PET.
• Cartazes.
• Torneiras automáticas para evitar desperdício de água.
• Projetos educacionais com crianças da rede pública.
• Distribuição de sacolas retornáveis.
• Treinamento de funcionários.
• Utilização de materiais recicláveis nos setores administrativos.
• Visitas monitoradas às lojas da rede.
• Uso de combustíveis provenientes de fontes renováveis (etanol) na frota de veículos.
• Divulgação via site, revistas e jornais.
• Calhas receptoras nas lâmpadas.
• Parcerias com fornecedores com a cultura de sustentabilidade.
• Mural com antes e depois.
• Jornal ecológico divulgando as atividades desenvolvidas no mês.
• Tratamento do esgoto.
• Dia verde.
• Plantio de árvores.
• Slogan verde.
• Uniforme verde.
Pacote de trabalho: 1.4.2 Análise das opções de sustentabilidade
A primeira análise consistiu em passar todas as ideias por critérios básicos de seleção, em vista das
limitações dos requisitos da estrutura física da loja 1, do orçamento disponível e potencial de marketing
junto aos clientes da rede. Um exemplo de como essa análise foi realizada pode ser visto na figura
acima (Figura 14.3).
FIGURA 14.3 Exemplo de análise das opções de sustentabilidade.

FIGURA 14.3 (Cont.)
Em seguida, a equipe analisou cada opção aprovada na análise de viabilidade anterior usando o
método 5W2H, para priorizar os seguintes itens considerados viáveis:
What – O que será feito (etapas)
Where – Onde será feito (local)
Why – Por que será feito (justificativa)
How – Como será feito (método)
Who – Por quem será feito (responsabilidade)
When – Quando será feito (tempo)
How much – Quanto custará fazer (custo)
Exemplos dessas análises encontram-se nas figuras a seguir (Figuras 14.4 e 14.5):
FIGURA 14.4 Exemplo de análise de viabilidade, utilizando o método 5W2H.

FIGURA 14.4 (Cont.)
FIGURA 14.5 Exemplo de análise de viabilidade, utilizando o método 5W2H.
Pacote de trabalho: 1.4.3 Seleção das opções viáveis

Após as análises de cada ideia feitas no item anterior, e considerando também o orçamento deter-
minado para essa parte do projeto, as seguintes ações de sustentabilidade foram consideradas as mais
viáveis para o projeto:
1. Adaptação das instalações
a. Seção para produtos sustentáveis – construir prateleiras em uma área no supermercado voltada
somente para produtos com apelo sustentável.
b. Caixas de papelão – Fazer uso das embalagens dos produtos para acondicionamento das compras
dos clientes em vez de utilizar sacolas plásticas.
2. Instalação ou aquisição de novos itens

a. Estação de coleta de lixo reciclável – local onde os clientes jogariam lixo reciclável (garrafas, papel,
plástico etc.).
b. Sacolas retornáveis – encomendar sacolas retornáveis confeccionadas com material reciclado ou
pano, para eliminar o uso de sacolas plásticas.
c. Sacolas biodegradáveis – encomendar sacolas biodegradáveis para substituir o uso de sacolas
plásticas, para os clientes que não queiram caixa de papelão (gratuita) e não tenham sacola
retornável (que será vendida a um custo de R$ 10,00; o cliente deverá trazê-la a cada compra).
Será cobrado um valor de R$ 0,19 para cada sacolinha (vem com código de barra).
d. Caixas verdes – encomendar caixas para descartes de embalagens no ponto do caixa.
e. Mural com antes e depois – mural apresentando as mudanças ocorridas após a adoção das práticas
sustentáveis na loja 1.
3. Marketing
a. Cartazes ambientais – cartazes informativos, mostrando aos clientes práticas ambientais para
ajudar na conscientização ambiental.
b. Banners – com um slogan verde para a loja, chamando a atenção dos clientes para o fato de que
a rede de supermercados A está engajada em iniciativas de sustentabilidade.
c. Folhetos – folhetos com fotos e descrições das ações realizadas na loja 1.
d. Evento de plantio de mudas de árvores.
4. Treinamento em sustentabilidade
Preparar e ministrar um workshop mostrando as adaptações e as melhorias do supermercado e
a importância de entender e explicar as iniciativas de sustentabilidade aos clientes. O gerente do
projeto contatou, junto à prefeitura da cidade, um especialista na Secretaria de Educação que visita
organizações e ministra workshops sobre sustentabilidade.
1.4.4 Apresentação da proposta
As iniciativas anteriores foram apresentadas ao dono da rede de supermercados A. Foram aprovadas
todas as ideias, com exceção do evento do plantio das árvores, que ficou para outro momento, no
qual todas as lojas da rede estiverem engajadas em práticas de sustentabilidade.
1.5 Implantação
1.5.1 Infraestrutura
1.5.1.1 Instalação de novos itens
Os novos itens foram adquiridos pelo Departamento de Compras e instalados pelo Departamento de
Manutenção. A loja 1 passou a ter, então, um conjunto (kit) de coleta seletiva com cinco cestos (100L)
no estacionamento; quatro caixas verdes, instaladas próximo aos pontos de caixa normais; sacolas
retornáveis, colocadas nos caixas, e sacolas de plástico biodegradáveis.
1.5.1.2 Adaptação dos itens existentes
Prateleiras foram instaladas para display de produtos verdes, placas foram colocadas para sinalizar a
seção verde da loja, e um mural explica as iniciativas e como a população pode contribuir com elas. Um
espaço para caixas de papelão foi reservado para ficar à disposição dos clientes. Tomou-se o cuidado de
não utilizar caixas de produtos de limpeza ou outros produtos que pudessem contaminar os produtos
alimentícios com resíduos químicos.
1.5.1.3 Inspeção
Com base em uma lista de verificação (checklist) elaborada pelo supervisor da manutenção em
conjunto com o gerente do projeto, foi feita uma inspeção nos itens instalados e adaptados para cons-
tatar se tudo foi feito de forma correta, dentro dos princípios de sustentabilidade e sem causar danos
às outras instalações da loja.
1.5.2 Treinamento
1.5.2.1 Workshop aos colaboradores e gerentes
O treinamento foi realizado conforme o planejado, com um convidado da prefeitura da cidade.
Quinze colaboradores participaram do workshop com duração de uma hora, realizado na sala de
reuniões da loja 1.
1.5.2.2 Filmagem do treinamento

A filmagem do workshop foi feita por um profissional especializado da empresa Z. O vídeo foi editado,
formatado, gravado em DVD e entregue ao gerente de projeto para utilização na orientação de novos
funcionários, fornecedores e clientes.
1.6 Marketing
1.6.1 Definição do material
Para auxiliar na decisão sobre quais itens produzir, em vista da restrição de custo, o gerente do projeto
solicitou ao gerente de marketing que trabalhasse em conjunto com a empresa Z para, antes de mais
nada, elaborar um miniplano de marketing, com as melhores opções de promoção da iniciativa de
sustentabilidade da rede A. Esse miniplano considerou os requisitos levantados no planejamento e a
experiência da empresa Z com iniciativas similares no varejo. Foi elaborado um slogan verde para a rede
A, que fará parte de todos os materiais, e também pensou-se em uma aparência consistente para eles.
Foram incluídas fotos dos itens adaptados e instalados, e, no folheto, uma seção de “Você Sabia?” com
informações sobre os danos que materiais não recicláveis estão fazendo na natureza e o que cada um
pode fazer para melhorar esse cenário. Os itens confirmados para produção foram: cartazes, banners
e folhetos.
1.6.2 Produção
A produção do material foi feita por uma equipe especializada da empresa Z, responsável também
por tirar as fotos da loja e incorporá-las ao material.
1.6.3 Distribuição
Os cartazes foram colocados em pontos estratégicos da loja. Banners foram colocados na entrada
da loja e no estacionamento. A distribuição dos folhetos foi feita em todas as lojas da rede A em stands
colocados próximo ao setor de atendimento ao cliente na entrada da loja.
Exercício
Execução
O projeto da reforma da loja está em fase de execução.
1. Qual a importância do gerenciamento das áreas de comunicações e partes interessadas na Execução
de um projeto?
2. Com base na descrição dos problemas mais comuns que ocorrem durante a execução dos projetos
discutidos neste capítulo, determine quais tipos de problemas podem ocorrer na execução do projeto
da reforma da loja. Como Carlos Peixoto pode resolvê-los?
15
Monitoramento e Controle
• Entender e desenvolver métodos e ferramentas para monitorar e controlar as atividades das áreas de
conhecimento: integração, escopo, tempo, custo, qualidade, comunicação, riscos, aquisições e partes
interessadas para garantir que os objetivos do projeto sejam atingidos.
Conceito
O processo de monitoramento e controle do projeto verifica se o projeto está sendo de fato executado
conforme o planejado. A seguir, um resumo do que deve acontecer no monitoramento e controle de
um projeto, de acordo com a área de conhecimento (Tabela 15.1).
Tabela 15.1 Atividades e Documentos do Monitoramento e Controle de um Projeto

Áreas de conhecimento Monitoramento e controle Documentos
Integração Monitorar e controlar o trabalho Plano de Gerenciamento do Projeto
Realizar controle integrado de mudanças
Escopo Verificar escopo EAP e Dicionário da EAP
Controlar escopo
Tempo Controlar cronograma Cronograma
Custo Controlar custos Orçamento
Qualidade Realizar o controle da qualidade Listas de Verificação (Checklists) e
Matriz de Rastreabilidade de Requisitos
Comunicações Reportar desempenho Plano de Comunicação
Relatórios de Desempenho
Atas de Reuniões
Riscos Monitorar e controlar os riscos Análise de Risco
Aquisições Administrar os contratos Plano de Gerenciamento das Aquisições
Partes Interessadas Monitorar e controlar o nível de envolvimento Matriz de Gerenciamento das Partes
ou engajamento das partes interessadas Interessadas
no projeto
O monitoramento e controle de um projeto, como o nome já diz, controlam o projeto de forma a

permitir que medidas corretivas sejam tomadas o mais rápido possível após uma necessidade ter sido
detectada. A fase de monitoramento e controle consiste basicamente em coletar informações sobre
as diversas áreas do projeto para constatar se estão seguindo o planejado e produzindo os resultados
esperados nas áreas de conhecimento do projeto, conforme resumo na Tabela 15.1.
No monitoramento e controle, o gerente do projeto coleta e comunica informações sobre desempe-
nho de todas as áreas do projeto. Ele é responsável, também, por comparar o desempenho realizado
com o desempenho planejado, analisar as variâncias, avaliar tendências para melhorar os processos no
futuro, avaliar possíveis alternativas e recomendar medidas corretivas, conforme o necessário.
199
Na prática
A forma como o projeto será controlado e o trabalho da equipe será monitorado precisam ter um
planejamento devidamente comunicado às partes interessadas. O que será feito durante o monitora-
mento e controle do projeto deve ser comunicado às partes interessadas com antecedência, pois não
é uma boa prática surpreendê-las com convites para participarem de reuniões nas quais as partes não
sabem do propósito ou às quais comparecem sem estarem preparadas com as informações necessárias.
15.1 Metodologia de Controle e Ferramentas

Para que o gerente de projeto tenha um controle sobre o que está acontecendo, há certos procedimen-
tos comuns e simples que, quando realizados de forma consistente e ordenada por todos os envolvidos,
garantem o sucesso do projeto, conforme explicado a seguir, considerando cada área de conhecimento.
1. Integração
Todos os processos e procedimentos do projeto já foram descritos no Plano de Gerenciamento do
Projeto que inclui, também, o Processo de Gerenciamento de Mudanças. A integração de todos os
componentes previstos no plano deve ser monitorada de perto, mediante reuniões semanais ou com
outra frequência, conforme a necessidade do projeto.
A ideia do monitoramento e controle na integração é acompanhar de perto se tudo o que foi previs-
to no Plano de Gerenciamento do Projeto está acontecendo conforme o planejado. Caso não esteja,
o gerente do projeto deve fazer os ajustes necessários. Lembrando que, conforme descrito no Plano
de Gerenciamento do Projeto, nenhuma mudança na linha de base pode ser efetuada sem as devidas
aprovações.
2. Escopo
Para ser considerado bem-sucedido, o projeto não pode sair da linha de base. A linha de base do
escopo é formada pela Declaração de Escopo, a EAP e o Dicionário da EAP. O escopo do projeto deve
refletir o mapeamento dos componentes que constam na EAP, e as atividades relativas aos pacotes
de trabalho devem estar acontecendo conforme descrições do Dicionário da EAP.
3. Tempo
As atividades devem estar acontecendo conforme o previsto no cronograma, principalmente as
atividades no caminho crítico. O gerente do projeto pode fazer esse acompanhamento de várias formas,
junto aos membros da equipe do projeto na reunião semanal de andamento do projeto ou, até mesmo,
utilizando uma ferramenta eletrônica no servidor ou na internet (quando concluída uma atividade, ela
seria assinalada na ferramenta). Tudo dependerá de como os sistemas de apoio às equipes de gerencia-
mento dos projetos da empresa estão configurados.
O gerente do projeto pode fazer ajustes no cronograma, desde que seja nos casos em que esses ajustes
não afetem a linha de base de tempo do projeto. Outros ajustes deverão passar pelo processo formal de
gerenciamento de mudanças, conforme diretrizes do Plano de Gerenciamento do Projeto.
4. Custos
A forma como se realizará esse monitoramento e controle dependerá, em grande parte, da maneira
como os recursos e sistemas automatizados para controle de custos de projetos e operacionais da
empresa estão configurados. Para projetos de pequeno ou médio porte, o gerente do projeto pode
acompanhar os custos em uma planilha no MS Excel e monitorar o que está sendo gasto versus o que
foi planejado para aquele momento no projeto.
Capítulo 15 • Monitoramento e Controle 201
No controle dos custos, é importante observar que mesmo quando o orçamento está no azul, é
necessário analisar o custo versus o trabalho realizado. Nesse sentido, custos e tempo andam de mãos
dadas durante a execução de um projeto. Por exemplo, as atividades do cronograma podem estar em dia,
porém se o orçamento já estourou e ainda faltam 50% das atividades do projeto, o projeto não está em
dia. Da mesma forma, se ainda há dinheiro no orçamento, mas as atividades estão atrasadas, o projeto
também não está em dia, pois esse atraso vai custar dinheiro.
5. Qualidade
O controle da qualidade é feito por meio de inspeções periódicas com o objetivo de garantir que
estão sendo satisfeitos os padrões de qualidade, conforme o planejado. No monitoramento e controle
da qualidade, haverá a aceitação ou rejeição das entregas por meio de listas de verificação ou outras
ferramentas definidas no Plano de Gerenciamento da Qualidade. É importante que o gerente de projeto
documente oportunidades de melhorias no processo para projetos futuros também.
6. Comunicações
O monitoramento e controle da comunicação trata da coleta de informações relativas ao trabalho
em andamento, análise dessas informações e envio às partes interessadas. Os relatórios de desempenho
devem incluir informações relativas às linhas de base, ou seja, custo, tempo, escopo e qualidade, além
de serem customizados para a necessidade de informação das partes interessadas.
Em um nível iniciante em gerenciamento de projetos, o documento mais utilizado para relatar
informações de desempenho é o Relatório de Status ou Andamento do Projeto, conforme modelo
definido no planejamento das comunicações do projeto. Um modelo desse relatório pode ser utili-
zado também como ata de reunião, e enviado às partes interessadas após as reuniões de andamento
do projeto.
Muito do monitoramento e controle dos projetos é feito em reuniões. Reuniões são fundamentais
para que o gerente do projeto e sua equipe “sintam o pulso” do projeto e resolvam problemas no ato
ou antes que aconteçam.
É um erro comum – e grave – fazer reuniões apenas para “cumprir tabela”, ou seja, apenas por
formalidade. Reuniões são de extrema importância para manter a comunicação fluindo entre todos os
participantes do projeto.
Outro erro comum é não fazer atas de reuniões ou enviar atas dias depois da reunião. Uma solução
seria publicar as atas em uma intranet ou servidor do projeto, logo após a realização da reunião.
É importante também que os participantes da reunião recebam o convite para a reunião com a devida
antecedência e sejam informados da pauta que será abordada. Cabe ao gerente do projeto convidar
as partes interessadas que, de fato, tenham interesse em participar da reunião ou cuja participação é
fundamental naquele ponto do projeto.
Algumas regras gerais devem ser seguidas para garantir que as reuniões realizadas durante o moni-
toramento e controle de um projeto sejam produtivas a todos:
1. A frequência em que as reuniões de monitoramento do projeto devem acontecer e a indicação de
quem deve participar dessas reuniões devem ser planejadas na área de conhecimento Comunicações.
As partes interessadas devem estar cientes desse planejamento e concordar com o esquema proposto.
Conflitos devem ser resolvidos no planejamento das comunicações do projeto, e não durante o
monitoramento e controle da execução do projeto.
2. O gerente do projeto pode agendar todas as reuniões do projeto automaticamente no sistema de
e-mails da empresa. Se não houver um, o gerente do projeto pode desenvolver um processo ou
sistema manual de agendar as reuniões e verificar a disponibilidade das partes interessadas em
participar dessas reuniões.
3. A pauta da reunião deve ser enviada aos participantes com pelo menos 48 horas de antecedência.
Caso haja necessidade, o gerente do projeto pode solicitar que certas partes interessadas venham
preparadas para a reunião com as informações que serão necessárias em algum item da pauta.
4. É sempre uma boa ideia incluir o agendamento das reuniões no cronograma oficial do projeto, para
que os recursos que irão trabalhar no projeto se planejem e participem de todas as reuniões para as
quais estejam agendados.
Dicas
Aqui vão algumas dicas para evitar as armadilhas das reuniões malsucedidas:
1. NÃO utilizar as reuniões só para saber o que cada um está fazendo. As atividades de cada um já estão
definidas no cronograma. A reunião deve ser utilizada para resolver problemas ou imprevistos que
saem do que foi planejado e discutir assuntos do interesse de todos.
2. NÃO utilizar as reuniões para atualizar cronogramas, custos etc., ou realizar qualquer atividade
de atualização ou realização de documentação do gerenciamento do projeto. Os participantes da
reunião percebem quando o gerente do projeto utiliza o tempo da reunião para trabalhar em vez
de interagir com a equipe de projeto e resolver problemas. Trabalhos resultantes de discussões nas
reuniões são itens de ação que deverão ser realizados após a reunião.
3. NÃO ultrapassar o tempo alocado para a reunião. As partes interessadas de um projeto não gostam
de se sentir reféns de reuniões ou de gerentes de projetos que não conseguem gerenciar seu próprio
tempo!
4. NÃO deixar que os participantes fujam do tema – quando o assunto se referir a outro projeto ou
outra empresa, avise que o assunto será tratado em outra reunião ou pessoalmente com você após
a reunião.
5. NÃO deixar que os participantes levem notebooks nas reuniões. Se houver informação em documentos
que deverá ser apresentada durante essa reunião, o participante da reunião deverá enviar a você
com antecedência para sua visualização. De qualquer forma, reuniões de andamento não são
reuniões de apresentações técnicas. Talvez seja melhor tratar do assunto em outro momento
e local.
6. NÃO deixar que os participantes atendam telefones celulares durante a reunião. Peça a colaboração
de todos no cumprimento de algumas regras básicas de etiqueta no trabalho.
7. NÃO entrar em conflito com partes interessadas durante a reunião. Explique as regras de como as
reuniões serão realizadas no planejamento do projeto. Deixe claro a todos quais as regras do jogo
e por que será dessa forma. Explique que será do interesse de todos manterem a reunião objetiva e
focada na pauta para um melhor aproveitamento do tempo de todos.
8. NÃO acreditar que reuniões realizadas por meio de teleconferências ou webconferences sejam tão
eficientes quanto as presenciais. Recursos trabalhando em locais diferentes da reunião, sem um
contato visual, tendem a só prestar atenção quando o nome deles é chamado. Isso é contraprodutivo
e não faz sentido. Se não houver outra forma de esses recursos participarem da reunião pessoalmente,
tente começar com eles e os assuntos relacionados a eles. Reserve uma parte do orçamento
para viajar até o local onde o projeto está sendo realizado para reuniões face a face com esses
recursos. É fundamental que o projeto esteja totalmente integrado para que tenha sucesso. Uma
comunicação virtual muitas vezes dificulta ou, até mesmo, impossibilita essa integração do fluxo
de informação sobre o andamento do projeto.
9. NÃO verificar linha por linha do cronograma durante a reunião. Foque nos desvios ao cronograma,
ou seja, o que precisa ser abordado porque é um problema atual ou em potencial. Antes da
reunião, o gerente do projeto já deve ter mecanismos de verificar se tudo está correndo dentro
do tempo determinado no planejamento. A mesma coisa vale para os custos e as linhas do
orçamento.
10. NÃO chamar a atenção, criticar ou fazer gozações de recursos humanos presentes ou ausentes. Além
de não ser ético, isso afeta seu relacionamento com sua equipe. Se houver necessidade, converse
com o recurso – a sós – após a reunião terminar.
11. NÃO chegar atrasado ou sair mais cedo da reunião. O gerente do projeto deve sempre ser o primeiro
a chegar e o último a sair: o primeiro a chegar para verificar se tudo está pronto para o início da
reunião, e o último a sair para sanar dúvidas individuais de alguma parte interessada.
12. NÃO marcar reuniões de andamento do projeto que durem mais de uma hora. Embora as reuniões
de planejamento variem na duração e na frequência, é importante manter as reuniões de monitoramento
e controle curtas e objetivas, pois todos estão ocupados com a execução das tarefas do projeto.
Riscos
Os riscos devem ser monitorados semanalmente ou, até mesmo, diariamente, dependendo do pro-
jeto. Normalmente, na reunião semanal de andamento do projeto, há uma análise dos riscos para um
determinado ponto para verificar se houve alteração na avaliação de algum risco. Essa análise também
ativa um plano de resposta a um determinado risco, conforme o necessário. Caso haja mudanças que
não afetem as linhas de base do projeto, o gerente do projeto fica responsável pela atualização e ajustes
da documentação e dos planos de ação.
Aquisições
O monitoramento e controle das aquisições do projeto, assim como no planejamento e na execu-
ção, dependerão do tamanho do projeto e da estrutura organizacional da empresa. Para gerentes de
projeto iniciantes, é aconselhável trabalhar conjuntamente com outros departamentos da empresa,
como Jurídico, Compras, Contas a Pagar, Qualidade, Engenharia, Contabilidade, Financeiro e outros,
no monitoramento e controle das atividades de aquisições, que incluem:
• Certificar-se que ambas as partes do contrato estejam cumprindo as obrigações contratuais.
• Proteger os direitos legais da empresa.
• Manter um registo dos desempenhos de fornecedores e parceiros.
• Inspecionar e verificar as entregas do projeto.
• Gerenciar mudanças, conforme o necessário e autorizado.
• Acompanhar a realização dos pagamentos nas datas devidas.
Partes Interessadas
O monitoramento e controle das partes interessadas envolverão uma avaliação do nível de envolvi-
mento ou engajamento das partes interessadas naquele ponto específico do projeto que estiver sendo
avaliado. O gerente do projeto precisa saber se quem deveria participar do projeto o está fazendo no
nível de desempenho desejado.
Quando uma parte interessada estiver demonstrando uma redução no seu nível de envolvimento no
projeto, o gerente de projeto deverá aplicar uma das estratégias incluídas no plano de gerenciamento das
partes interessadas (conforme descrito no capítulo 13 Partes Interessadas), conforme o necessário.
Considerando as áreas de conhecimento do projeto de forma integrada, o gerente de projeto precisa
avaliar, também, se uma parte interessada pode ser liberada do projeto, em vista da conclusão das
atividades planejadas especificamente para ela.
Aplicação
O projeto sustentabilidade para a rede de supermercados A – loja 1 foi monitorado e controlado da

seguinte forma:
1. Reuniões.
Por ser um projeto em que todos trabalham muito próximos e com uma curta duração, com
atividades programadas em horas, as reuniões foram marcadas considerando o término das entre-
gas-chave. As reuniões aconteceram nas datas previstas no cronograma e serviram como um ponto
de encontro para a equipe sanar dúvidas quanto aos próximos passos, bem como discutir e resolver
eventuais problemas.
• 1a Reunião: Reunião de abertura do projeto, após aprovação do Termo de Abertura – 10.08.2011
• 2a Reunião: Reunião de kick-off (início dos trabalhos) do projeto, após aprovação do Plano do Projeto –
29.08.2011
• 3a Reunião: Reunião de andamento 1 do projeto, após aprovação da Proposta de Implantação –
20.09.2011
• 4a Reunião: Reunião de andamento 2 do projeto, após implantação da infraestrutura – 28.09.2011
• 5a Reunião: Reunião de andamento 3 do projeto, após realização do treinamento – 12.10.2011
• 6ª Reunião: Reunião de encerramento do projeto – 18.10.2011
2. Controle das áreas de conhecimento
• Escopo. Com a matriz de requisitos em mãos, o gerente do projeto confirmou, em cada reunião, se
o escopo do projeto estava, de fato, incorporando os requisitos aprovados e priorizados. Da mesma
forma, a linha de base foi monitorada de perto, de forma a garantir que as entregas e os pacotes
de trabalho estavam sendo feitos conforme o planejado. A matriz de requisitos era atualizada
à medida que a incorporação dos requisitos ao projeto era confirmada, conforme exemplo da
Figura 15.1.
FIGURA 15.1 Monitorando os requisitos.

FIGURA 15.1 (Cont.)
• Tempo. A realização das atividades foi monitorada pelo cronograma; quando uma atividade era
concluída, o gerente a marcava no cronograma como concluída – ou a porcentagem que já estava
concluída –, conforme exemplo de um snapshot do projeto no horário de almoço do dia 24.08.2011,
ilustrado na Figura 15.2.
FIGURA 15.2 Exemplo do controle das atividades no cronograma.
Ferramentas
1. No MS Project ou no OpenProj, para incluir a coluna de porcentagem do trabalho concluído no

cronograma, basta clicar o botão direito do mouse em cima da primeira coluna, escolher “Inserir
coluna, % concluída” em “Nome do campo”. Observe que, com base na porcentagem de conclusão
das atividades, o programa calcula automaticamente as porcentagens de conclusão dos pacotes de
trabalho e das respectivas entregas.
2. O MS Project e o OpenProj permitem comprimir e expandir os campos das atividades. No snapshot
anterior, por exemplo, as atividades do escopo e tempo foram concluídas e estão comprimidas (o sinal
de + indica compressão das atividades).
• Custo. À medida que os custos eram incorridos, o gerente do projeto lançava a despesa na planilha
dos custos do projeto, em uma coluna adicional de “Custos Incorridos” nas respectivas datas
(próximas às reuniões de andamento do projeto), conforme exemplo a seguir. Isso permitiu que
quantias menores, que não afetavam a linha de base, fossem ajustadas conforme o necessário
(Figura 15.3).
FIGURA 15.3 Exemplo da planilha de controle dos custos.
Ferramenta
No controle do orçamento, é sempre útil utilizar as fórmulas do MS Excel para ir automaticamente

descontando os valores incorridos dos valores planejados, à medida que os números são lançados.
• Qualidade. As listas de verificação ou checklists do projeto elaboradas no planejamento foram
preenchidas conforme o estipulado nos respectivos fluxogramas e, após o preenchimento, colocadas
na pasta de documentação do projeto no servidor, em formato PDF, conforme exemplo a seguir
(Figura 15.4).
FIGURA 15.4 Exemplo de Lista de Verificação (Checklist) preenchida.
• Comunicações. As informações sobre o projeto foram distribuídas conforme o Esquema das

Comunicações, com os documentos do projeto sendo colocados em formato PDF no servidor HJH,
e não enviados por e-mail. Devido à natureza das operações de um supermercado, o gerente de
projeto notou que foi uma boa estratégia evitar a utilização de e-mails para distribuir informações,
pois a maioria dos recursos circula na loja e trabalha diretamente com colaboradores e clientes; eles
não ficam sentados em uma mesa na frente do computador.
Os relatórios definidos no planejamento da comunicação foram emitidos conforme os exemplos
na Figura 15.5.
FIGURA 15.5 Exemplo de Relatório de Andamento preenchido.

FIGURA 15.5 (Cont.)
Exemplo de uma das solicitações de mudança na execução do projeto e como foi documentada
(Figuras 15.6 e 15.7).
FIGURA 15.6 Exemplo de Solicitação de Mudança preenchida.

FIGURA 15.7 Exemplo de Análise de Impactos de uma Solicitação de Mudança.
Após aprovação da mudança, o gerente do projeto comunicou a resolução por e-mail e telefone à
solicitante (Figura 15.8).
FIGURA 15.8 Exemplo de um Registro de Problemas.
• Riscos – A planilha de análise de riscos foi utilizada apenas como referência nas reuniões. Não
houve surpresas ou necessidade de acionar planos de ação. De qualquer forma, o gerente do projeto
apresentava cada risco e confirmava o status com os seguintes símbolos:
• Traço (–), caso o status do risco continuasse o mesmo.
• Seta para cima (↑), caso algum aspecto do risco (probabilidade, severidade etc.) aumentasse,
normalmente diante de uma maior incerteza de alguma atividade ainda por fazer.
• Seta para baixo (↓), caso algum aspecto de um risco mostrasse diminuição, normalmente diante
de atividades já realizadas que envolviam algum risco da matriz de riscos.
Vejamos um exemplo do controle de riscos da Reunião de andamento n° 3 de 12-10-2011 (Figura 15.9).
FIGURA 15.9 Monitorando os Riscos.
FIGURA 15.9 (Cont.)
FIGURA 15.9 (Cont.)
• Aquisições – As compras foram feitas segundo os processos internos do Departamento de Compras

e acompanhadas pelo gerente do projeto nas reuniões. A gerente de compras enviou e-mails ao
gerente de projeto avisando que a compra tinha sido feita e confirmando a data da entrega. Todos
os pagamentos foram feitos à vista; então, à medida que a confirmação da compra era feita e o
pagamento efetuado, o gerente do projeto dava baixa no respectivo item na planilha de custos.
• Partes Interessadas – Nas reuniões de andamento, a matriz de rastreabilidade das partes
interessadas mostrou resultados conforme figura a seguir para a reunião de andamento n° 3
(Figura 15.10).
FIGURA 15.10 Matriz de Gerenciamento das Partes Interessadas.

FIGURA 15.10 (Cont.)
Exercícios
Monitoramento e controle do projeto
O projeto está em plena execução quando Carlos recebe um telefonema de Ana Maria Costa dizendo
que o fornecedor de tintas ligou dizendo que a tinta escolhida está em falta e que a remessa nova só che-
gará dentro de duas semanas. Ana Maria está solicitando que haja um acréscimo de 5 dias no cronograma
Material de apoio
Baixe os arquivos Análise de impacto de mudança e Registro de problemas, na pasta Exercícios em
Conteúdos extras, na página web do livro (www.elsevier.com.br/martacamargo).
1. No formulário de análise de impacto de solicitação de mudança, faça uma análise de como a
solicitação de mudança no cronograma (acréscimo de 5 dias) afetaria as áreas de:
a. Escopo.
b. Tempo.
c. Qualidade.
d. Riscos.
2. Após a análise do impacto no exercício anterior, descreva o que Carlos deverá fazer, por exemplo:
mudar as datas no cronograma, esperar a nova remessa, trocar a cor, comprar de outro fornecedor
ou qualquer outra solução que for considerada a melhor para o projeto.
3. Registre o problema que ocorreu com esse fornecedor no registro de problemas, incluindo as
seguintes informações, conforme consta no formulário:
a. Número do problema: 01.
b. Descrição do problema.
c. Origem.
d. Resolução.
e. Responsável.
f. Data do registro.
g. Data da resolução.
16
Encerramento
• Planejar como as informações deverão ser registradas durante o projeto.
• Coletar informações para encerrar o projeto.
• Conduzir uma reunião de encerramento de um projeto.
• Elaborar relatórios de lições aprendidas para os projetos concluídos.
• Desenvolver itens de ação para futuros projetos.
16.1 Processo de Encerramento e Lições Aprendidas
Conceito
O encerramento se caracteriza pelo fechamento de todas as atividades relacionadas ao projeto. O

projeto não é considerado concluído quando seu escopo é terminado, mas sim quando seu processo
de encerramento é realizado, conforme explicado a seguir (Tabela 16.1).
Tabela 16.1 Atividades e Documentos do Encerramento

Área de conhecimento Atividades de encerramento Documentos gerados
Integração Realizar uma reunião de encerramento. Relatório de Lições
Elaborar um documento denominado Lições Aprendidas para relatar Aprendidas
o que deu certo e o que precisa ser melhorado.
Confirmar que o trabalho foi realizado conforme os requisitos definidos
para o projeto.
Concluir os relatórios de desempenho.
Encerrar contratos e pendências com fornecedores.
Arquivar toda a documentação do projeto.
Atualizar o banco de dados de Lições Aprendidas da empresa
(quando houver).
Liberar os recursos humanos que trabalharam no projeto.
Elaborar itens de ação para projetos futuros. Itens de Ação
O processo de encerramento é basicamente um fechamento administrativo do projeto, que irá

também deixar registros para projetos futuros. O encerramento exigirá do gerente do projeto uma
integração das várias áreas do projeto para garantir que tudo tenha sido concluído, sem pendências,
conforme as atividades listadas na Tabela 16.1.
215
Na prática
A capacidade de um gerente de projetos realizar um bom encerramento para o projeto está direta-
mente relacionada à sua capacidade de planejar previamente as atividades que servirão de fonte de
informações para o encerramento do projeto.
Como visto nos capítulos anteriores, uma documentação de acompanhamento detalhada do projeto
auxilia o gerente do projeto a rastrear causas de problemas que, muitas vezes, podem ter soluções simples.
Por exemplo, o fato de uma equipe de um determinado projeto sempre atrasar as entregas do respectivo
departamento pode ser simplesmente um problema de comunicação do cronograma. Como discutido
no capítulo sobre planejamento das comunicações, é essencial ao sucesso do projeto que o gerente
do projeto customize a forma como a informação é comunicada, dependendo da área e das preferências
das partes interessadas. As informações de datas em um cronograma detalhado no MS Project podem
ser excelentes ao escritório de projetos (PMO) ou outros departamentos, como TI; porém, para outros
departamentos, como produção ou financeiro, as informações contidas em um cronograma detalhado
no MS Project podem ser mais difíceis de serem entendidas e, portanto, executadas. Departamentos que
trabalham com números gostam de receber informações do projeto em planilhas do MS Excel.
Para projetos pequenos e menos complexos, o gerente de projeto pode coletar informações com base
nos documentos gerados no monitoramento e controle do projeto, como o Registro de Problemas (ou outro
controle relativo às solicitações e análises de impacto de mudanças), os Relatórios de Andamento, as Atas
de Reunião e outros registros pertinentes ao projeto. Esses documentos permitem ao gerente do projeto
fazer um levantamento do que foi bem-sucedido e do que precisa ser melhorado em futuros projetos. O que
precisa ser melhorado transforma-se em itens de ação com datas específicas, que devem ser resolvidos por
grupos designados. Esses grupos devem se comprometer a resolver os itens a eles designados ou negociar
soluções aos que podem ser resolvidos de imediato ou que serão resolvidos em um futuro próximo.
Para projetos mais longos (acima de seis meses) e complexos, envolvendo vários departamentos
da empresa e terceiros (fornecedores de serviços e produtos, por exemplo), o gerente do projeto pode
enviar um questionário a essas partes interessadas para coletar informações sobre o projeto do seu
ponto de vista. Nesse caso, o gerente do projeto deve padronizar o formulário do questionário e enviá-lo
a todas as partes interessadas tanto dentro como fora da empresa e, com base nessas informações,
gerar um relatório sobre o que foi bem-sucedido ou não no projeto, facilitando assim o levantamento
dos itens de ação para projetos futuros.
A lista de itens de ação para projetos futuros irá variar conforme as necessidades do gerente do projeto e
sua equipe, bem como da natureza do projeto. Por exemplo, gerar itens de ação e monitorar a resolução desses
itens é útil quando há uma continuidade no trabalho do projeto com as partes interessadas em questão.
A seguir, um exemplo de um questionário para levantamento das informações em preparação a uma
reunião de encerramento de um projeto:
1. O que foi bem-sucedido no projeto e o que não foi?
2. O que poderia ser feito de forma diferente?
3. Que surpresas ocorreram durante o projeto que afetaram o trabalho planejado?
4. Que circunstâncias do projeto não foram antecipadas?
5. Os objetivos do projeto foram atingidos? Se não foram, o que precisa ser mudado para que futuros
projetos alcancem os objetivos?
Em uma reunião de encerramento, o gerente do projeto levanta os problemas ocorridos e, por meio
de uma discussão voltada para itens de ação para o sucesso de futuros projetos, busca soluções para
eliminar as causas de problemas já ocorridos.
O resultado dessas discussões é documentado em um formulário chamado Lições Aprendidas que
inclui informações sobre o que deu certo e o que deu errado no projeto. O formato desse relatório de
Lições Aprendidas pode variar, porém a maioria deles inclui as informações a seguir (Figura 16.1):
Capítulo 16 • Encerramento 217
FIGURA 16.1 Formulário de Lições Aprendidas.
Dica
Outra forma de realizar a reunião de encerramento é levantar os pontos positivos e pontos negativos
do projeto ao vivo e com a colaboração de todas as partes interessadas no projeto. O gerente do projeto
funciona como facilitador e levanta as informações in loco. A seguir, uma sugestão para o roteiro dessa
reunião de encerramento:
Roteiro para reunião de encerramento1 – uma hora
Início – cinco minutos
• Revisão rápida do objetivo da reunião.
• Revisão das regras da reunião.
• Notebooks e celulares não serão permitidos durante a reunião.
• Críticas a processos ou procedimentos utilizados no projeto serão bem-vindas.
• Críticas a pessoas não serão permitidas.
1
Adaptado do roteiro publicado pelo Planning and Project Management Office da Carnegie Mellon University para reunião
de Lessons Learned.
• É importante que todos participem, mesmo com pontos de vistas diferentes.

• É importante manter uma atitude positiva para que a reunião agregue valor ao trabalho de todos.
Sucessos – 15 minutos (o facilitador da reunião escreve no quadro as respostas)
• O que foi bem-sucedido nas diferentes fases do projeto – ou seja, iniciação, planejamento, execução,
monitoramento e controle, encerramento?
• Como a equipe se saiu ao lidar com mudanças às linhas de base durante o projeto (se aplicável)?
• Como a comunicação ocorreu no projeto? O que a equipe do projeto fez que foi mais útil à comunicação
eficiente durante todo o projeto?
• Como a equipe do projeto se saiu ao gerenciar os riscos identificados no planejamento do projeto?
Oportunidades de melhorias – 15 minutos (o facilitador da reunião escreve no quadro as respostas)
• O que poderia ser melhorado no que se refere ao que aconteceu nas diferentes fases do projeto
(iniciação, planejamento, execução, monitoramento e controle, encerramento)?
• Como a equipe se saiu ao lidar com mudanças às linhas de base durante o projeto (se aplicável)?
O que poderia ser feito de forma diferente para responder às mudanças no projeto?
• Como a comunicação ocorreu no projeto? O que a equipe do projeto pode fazer para melhorar
a comunicação em projetos futuros?
• O que pode ser feito para ajudar a equipe a mitigar o impacto dos riscos ou reduzir a probabilidade de
o risco acontecer em projetos futuros?
Priorização – 15 minutos
• Quais seriam os cinco itens de maior importância no sucesso do projeto?
• Quais seriam os cinco itens de maior importância nas oportunidades de melhorias no projeto?
Fechamento – 5 minutos
• Quais os itens de ação para a resolução das cinco melhorias mais importantes que acabaram de ser
definidos?
• Quem será o responsável por cada item de ação?
• Quais os procedimentos para acompanhamento da resolução desses cinco itens de ação?
Com base nessa reunião, o Relatório de Lições Aprendidas é elaborado e enviado a todos para
aprovação. Depois da aprovação, o relatório é arquivado para servir como referência a futuros projetos
da empresa.
Outra dica
É sempre uma boa ideia realizar um evento para comemorar o encerramento do projeto. Principal-
mente quando os projetos envolveram momentos de tensão ou, no caso dos projetos de alta visibilidade
na empresa, causaram muita pressão nos membros da equipe, o gerente de projeto deve planejar uma
reserva no orçamento para um evento de fechamento. Esse evento pode ser um churrasco, um almoço
com feijoada, café da manhã completo ou até mesmo terminar a reunião de encerramento com pizza
para todos. Esses tipos de evento servem como um sinal de reconhecimento do esforço de todos e
fortalecem o espírito de equipe entre os participantes do projeto.
Aplicação
Para o projeto sustentabilidade para a rede de supermercados A – loja 1, o gerente do projeto pediu
às partes interessadas (por e-mail, telefone e pessoalmente) que pensassem nos três itens a seguir em
preparação à reunião de encerramento do projeto:
1. O que deu certo no projeto e por que você acha que deu certo?
2. O que não deu certo no projeto e por que você acha que isso aconteceu?
3. Quais as suas sugestões para futuros projetos semelhantes a esse?
A reunião de encerramento seguiu o roteiro de uma hora descrito na Dica, e o Gerente de Projeto foi
o facilitador da reunião e o responsável pela coleta de informações in loco.
Com base nas discussões durante a reunião, o gerente do projeto elaborou o Relatório de Lições
Aprendidas. Foram também levantados Itens de Ação para futuros projetos, conforme Figura 16.2 a seguir.
Após a reunião houve um evento de confraternização para a equipe do projeto oferecido pelo pa-
trocinador e dono da rede A – Sr. José S. – com a presença de todas as partes interessadas do projeto,
incluindo o pessoal da empresa Z, a empresa terceirizada responsável pelos componentes de marketing,
e do especialista em sustentabilidade da prefeitura, que ministrou o workshop aos colaboradores da
rede A (Figura 16.2).
FIGURA 16.2 Relatório de Lições Aprendidas e Itens de Ação – Projeto Sustentabilidade para Rede de Supermercados A – loja 1.
(continua)
FIGURA 16.2 (Cont.)

FIGURA 16.2 (Cont.)
(continua)
FIGURA 16.2 (Cont.)
Exercícios
Encerramento
Finalização do projeto da reforma da loja de roupas femininas: encerramento
O projeto da reforma da loja está concluído. No geral, o projeto foi bem-sucedido, pois executou-se
a maioria do que foi planejado sem problemas. Carlos Peixoto realizou uma reunião de encerramento
com sua equipe interna e os fornecedores de produtos e serviços, além de ter documentado os acon-
tecimentos para futuros projetos de reformas em suas outras lojas.
Material de apoio
Baixe o arquivo Lições Aprendidas, na pasta Exercícios em Conteúdos extras, na página web do
livro (www.elsevier.com.br/martacamargo).
Como o projeto da reforma da loja de artigos femininos foi uma simulação para a prática da docu-
mentação do gerenciamento de projetos, não é possível realizar um processo de encerramento com-
pleto, pois não foi feita a execução propriamente dita do projeto. Porém, é possível fazer uma reflexão
dos desafios que você encontrou no planejamento de cada área de conhecimento.
Utilizando o formulário de Lições aprendidas, faça uma reflexão sobre o seu desempenho no plane-
jamento do projeto considerando as seguintes informações:
1. O que deu certo (por exemplo: “a releitura do capítulo antes de realizar os exercícios facilitou
a elaboração das respostas.”).
2. Recomendação para futuros projetos com base no que deu certo neste (por exemplo: “sempre
procurar informações e ler as instruções com cuidado antes de realizar a tarefa do projeto”).
3. O que não deu certo (por exemplo: “fazer os exercícios sem ler com atenção as explicações
e os exemplos nos capítulos levou a retrabalhos e respostas incompletas ou incorretas”).
4. Recomendação para futuros projetos a fim de evitar o que não deu certo neste (por exemplo: “estar
sempre bem preparado para planejar um projeto”).
Faça o mesmo com relação a cada área de conhecimento do projeto:
1. Escopo.
2. Tempo.
3. Custos.
4. Qualidade.
5. Recursos Humanos.
6. Comunicações.
7. Riscos.
8. Aquisições.
A
Exemplo de Análise de Pré-projeto
— Estudo de viabilidade – Implantação de um
sistema de controle de versão de arquivos
no departamento de localização da empresa N
Introdução
Localização de software é o processo pelo qual o departamento internacional adapta o produto
desenvolvido no idioma inglês, voltado para o mercado norte-americano, para versões internacionais
voltadas a diferentes mercados estrangeiros, considerando tanto aspectos linguísticos como funcionais.
O departamento de localização da empresa N está configurado em cinco áreas distintas:
1. Terminologia: pesquisa e define os glossários para as traduções e padronizações dos termos
do software e da documentação do produto.
2. Gerenciamento de fornecedores: gerencia o trabalho terceirizado do processo de localização como um
todo.
3. Controle de qualidade: verifica a qualidade das versões internacionais do software por meio de casos
de testes e outras especificações, conforme o caso.
4. Engenharia de software: faz a parte técnica do processo de localização, envolvendo conversão
dos builds domésticos em builds internacionais, conversão de arquivos para vários formatos
(web, PDF, gráficos) e outras atividades. Na programação de software, um build é uma versão
de um programa. Via de regra, um build é uma versão pré-lançada e identificada por um número
sequencial, à medida que vão sendo produzidos até chegar no produto final (por exemplo, a primeira
versão de um software é o build 1, depois vem um build 2 com mais recursos, até se chegar a um
build 10 que será o build final e resultará na versão 1.0 do software pronto).
5. Gerenciamento de projetos: elabora os kits de localização com instruções sobre ferramentas, processos
específicos para cada produto, guias de estilo e especificações de testes para o pessoal interno e
externo da empresa. Essa área gerencia o processo inteiro de localização do produto, que envolve
partes dos trabalhos das outras áreas também.
O departamento de localização da empresa N lança as versões internacionais dos produtos na mesma
data que o produto nacional, conhecido como doméstico. Nesse modelo de sim-ship (ou lançamento
simultâneo do produto de software para diferentes idiomas e mercados ao mesmo tempo), o departa-
mento de localização começa a trabalhar enquanto a versão em inglês está ainda em desenvolvimento.
Nessas condições de trabalho simultâneo entre os dois departamentos (doméstico e internacional),
mudanças são constantes nos arquivos originais do doméstico, o que exige atualizações frequentes
nos arquivos-fonte. Como o software é produzido simultaneamente em inglês e em vários idiomas, o
processo de atualização dos arquivos em todos os idiomas, ao mesmo tempo, é um grande desafio aos
gerentes de projetos do departamento de localização.
O primeiro problema é que, para um determinado projeto, os arquivos originais provenientes da
equipe de desenvolvimento do doméstico podem consistir em aproximadamente 500 palavras, porém no
estágio da localização, o número se multiplica pelo número de idiomas aprovados para aquele projeto.
Por exemplo, para um produto de software localizado em oito idiomas, o total de arquivos chega a 4 mil.
Com uma média de três atualizações por lançamento (isso para produtos de pequeno a médio porte,
pois para produtos de grande porte, como o carro-chefe da empresa, esse número de atualizações pode
chegar a 20 ou mais), o número de arquivos que passa pelo departamento de localização pode chegar
a 12 mil, apenas para uma atualização no arquivo original em inglês.
225
O resultado do aumento no número de arquivos é que todos esses arquivos precisam ser monitorados
à medida que são trabalhados por diferentes fornecedores dos serviços de tradução e teste para que a
versão localizada tenha um build localizado que funcione. Durante todo o processo de desenvolvimento
de um software, os componentes do aplicativo são coletados e repetidamente compilados em builds
para serem testados, até se chegar ao produto final.
Outro fator a ser considerado é que os arquivos têm formatos diferentes (por exemplo, HMTL, XML,
Java, .txt, .doc etc.). Atualmente, todos esses arquivos são controlados e monitorados manualmente
pelos gerentes de projetos do departamento de localização.
O segundo problema se refere à falta de padronização para os ambientes de build. Não há um con-
trole sobre os arquivos que compõem cada build de software que é testado. Muitas vezes, partes do
software são produzidas em departamentos diferentes que têm formas diferentes de escrever o código,
fazer as entregas ao departamento de localização e criar builds de software. O resultado dessa falta de
padronização é a grande dificuldade encontrada pelo departamento de localização quando se trata
de documentar os diferentes processos e padrões e ainda explicar essas diferenças aos fornecedores e
contratados em diversas partes do mundo.
Para agravar ainda mais a situação, dentro do próprio departamento de localização há formas
diferentes de controlar os arquivos:
1. O grupo de testes de funcionalidade e o grupo de interface do software controlam os arquivos
utilizando listas com base no hand-off (processo de entrega formal) do código-fonte fornecido
pelo departamento de desenvolvimento de software doméstico. Essas listas não permitem que eles
saibam se o arquivo é totalmente novo ou apenas uma atualização. Todos os arquivos que vêm do
desenvolvimento de software são, portanto, considerados novos e enviados aos gerentes de projetos
para serem enviados aos fornecedores de serviços de localização.
2. O grupo de documentação do produto utiliza um sistema customizado para arquivos de ajuda e
documentação online que consiste basicamente em um arquivo de processador de textos com nomes
de arquivos que entraram e saíram, com datas e nomes das pessoas do grupo de documentação
doméstica que enviaram esses arquivos.
3. O grupo dos gerentes dos projetos de tradução criam tabelas ou planilhas com base nas informações
dos grupos 1 e 2. Muitas vezes, o gerente de um determinado projeto manualmente abre e verifica
cada arquivo para determinar se é algo novo ou apenas uma atualização para posteriormente enviar
as instruções aos fornecedores.
O processo anterior é propenso a erros, principalmente porque, para projetos grandes de mercados
internacionais com prazos extremamente agressivos, o gerente do projeto não tem tempo de verificar
cada arquivo e acaba enviando os arquivos que recebe do desenvolvimento do software doméstico
diretamente aos fornecedores de serviços de localização. Isso gera confusão e retrabalho.
O departamento de localização precisa de um sistema para controlar o hand-off dos arquivos das
equipes de desenvolvimento de software. Esse sistema precisa mostrar informações atualizadas sobre
os arquivos originais do doméstico e as respectivas atualizações. É necessário também que possa ser
compartilhado por vários departamentos para que constitua a forma oficial e padronizada de gerenciar
os arquivos que compõem cada versão localizada de todos os produtos de software da empresa.
Opções atuais de ferramentas de gerenciamento de arquivos

(especificamente para o departamento de localização da empresa)
De acordo com o estudo feito pela autora das ferramentas disponíveis no mercado que atendem essa
necessidade de padronização de hand-off de arquivos, foram descobertos dois produtos com potencial
de resolver o problema de controle de versão de arquivos:
1. Ferramenta A: ferramenta desenvolvida pela empresa C, opera no Windows e inclui uma interface
do usuário para todas as fases da produção dos arquivos, controle de versão, datas de sign-off
(processo de conclusão dos trabalhos) do desenvolvimento, datas de hand-off para localização, datas
Apêndice A • Exemplo de Análise de Pré-projeto 227
de hand-off para os fornecedores, atualizações, informações sobre autoria, status dos arquivos na

localização, arquivos utilizados para partes específicas no processo de localização e informações
sobre os arquivo originais necessários aos builds.
Vantagens: além de ter uma interface amigável, é mantido e atualizado pelos gerentes de projetos,
fica acessível a todos que forem inclusos como usuários e tem um custo zero ao departamento
de localização, pois foi desenvolvido por empresa parceira que gostaria de compartilhar ferramentas
conosco (ela forneceria a Ferramenta A em troca de nossa Ferramenta R para controle financeiro
dos projetos).
Desvantagens: o sistema requer que os gerentes de desenvolvimento entrem e mantenham
informações sobre marcos do projeto para que o departamento de localização possa manter suas
informações corretas e atualizadas. Atualmente, o departamento de desenvolvimento não usa essa
ferramenta e pode haver resistência contra a incorporação de uma ferramenta que não traz benefícios
diretos ao departamento e ainda aumenta a carga de trabalho da equipe de desenvolvimento (a fim
de alimentar o sistema especificamente para o departamento de localização).
2. Ferramenta B: é um sistema de gerenciamento de configuração de software que permite às equipes
de desenvolvimento um controle total sobre o código-fonte e as atividades de manutenção.
Gerencia objetivos que representam arquivos-fonte, documentos, casos de testes, programas
executáveis, bibliotecas e diretórios. Essa ferramenta também gerencia os relacionamentos entre
esses objetivos.
Vantagens: algumas equipes de desenvolvimento de software da empresa já estão utilizando essa
ferramenta. Os engenheiros de software e desenvolvedores consideram essa ferramenta eficiente,
pois ela cobre todas as fases do ciclo de desenvolvimento de um produto de software.
Desvantagens: especificamente para o departamento de localização, essa ferramenta inclui
informações que não se aplicam às necessidades internacionais. As funções principais da ferramenta
cobrem todas as fases de programação e escrita dos códigos-fonte, não o que acontece com os
arquivos após estarem concluídos no idioma inglês. Além disso, depois de testes com os gerentes
de projetos de localização, a interface não foi considerada amigável ou intuitiva, o que requer
documentação e treinamento específicos às equipes de localização, internas e externas (incluindo
toda a rede de fornecedores de serviços de localização em todos os países) para que a ferramenta
possa ser utilizada nos projetos internacionais.
Viabilidade técnica
A Ferramenta A pode ser instalada em um dos servidores do departamento de localização sem
afetar a produção dos projetos atuais. Considerando os recursos atuais da rede, não há necessidade
de nenhuma configuração especial ou aquisição de software ou outros produtos. O administrador
da rede do departamento confirmou que um servidor dedicado pode ser disponibilizado a todas
as equipes de projetos em questão de dias. Esse servidor poderia ser compartilhado por todas as
equipes dentro e fora do departamento, desde que o acesso seja solicitado e aprovado (via VPN
para equipes externas).
No que se refere aos requisitos de hardware, não é necessário adquirir novas máquinas ou outros
equipamentos, pois todos os computadores foram atualizados recentemente com o processador Intel
e a versão do Windows mais recente. Quanto aos requisitos de software, a Ferramenta A funciona como
um aplicativo qualquer, precisando apenas de uma instalação na máquina do usuário. Essa ferramenta
utiliza interface e terminologia próprias para a área de localização, facilitando a utilização dos novos
usuários. Não é necessário treinamento, pois a interface é intuitiva e amigável. Para a equipe de
desenvolvimento entrar com dados específicos sobre versões de arquivos e atualizações, há um menu
especial que foi considerado simples e fácil de utilizar por um desenvolvedor consultado durante a
realização deste estudo.
A Ferramenta B requer um servidor dedicado, juntamente com uma máquina UNIX rodando
uma engine de banco de dados. Senhas especiais teriam que ser configuradas a um número limitado
de usuários dentro do departamento de localização, devido às limitações de licença de uso
(apenas dois usuários por instalação). Seria necessário treinamento aos usuários do departamento de
localização, pois a interface e terminologia do produto refletem um ambiente de desenvolvimento
de sistemas e programação de código-fonte, não de localização.
Viabilidade operacional
A Ferramenta A foi projetada pela empresa C, cujos desenvolvedores vieram da nossa empresa. O
departamento de desenvolvimento da Ferramenta A é um antigo departamento da nossa empresa
que desenvolvia uma linha de produtos que foi vendida para a empresa C. Os menus são similares às
ferramentas que utilizamos nos nossos projetos atuais. A empresa C já testou a ferramenta em projetos
de localização e considerou-a um sucesso, pois reduziu em cerca de 20% o retrabalho dos gerentes de
projetos e agilizou em 50% o tempo para a elaboração das listas de arquivos que devem ser enviadas
aos fornecedores de serviços de localização em outros países.
A interface do usuário da Ferramenta B não é amigável para o pessoal do departamento de locali-
zação. Em um teste-piloto realizado com três gerentes de projetos, foi constatado que a Ferramenta
B inclui vários itens da interface do usuário que não se aplicam à área de localização. Alguns recursos
poderiam ser adaptados, mas a maioria deles se refere a ambientes específicos de desenvolvimento e
programação de software em inglês.
Viabilidade financeira
Antes de comparar os custos das duas ferramentas, é importante observar que qualquer fer-
ramenta adotada para controle dos arquivos trará vantagens ao departamento e à empresa. Isso
acontece pois o custo do retrabalho por parte dos fornecedores de serviços de localização tem
sido motivo de constantes atualizações no orçamento dos projetos, incorrendo em solicitações de
fundos extras ao sponsor.
Um exemplo desse problema foi o que aconteceu em um projeto recente com 100 mil palavras. Vinte
arquivos com 10 mil palavras cada foram enviados ao departamento de localização para tradução em
17 idiomas. Esses arquivos com as respectivas atualizações foram enviados sem um aviso de que eles já
haviam sido enviados antes – nesse caso, tratava-se apenas de uma atualização de parte do conteúdo
prévio de cada um deles. Sem esse aviso, foi feito o hand-off aos fornecedores de serviços de localização,
com os respectivos SOW's (Statements of Work ou declarações de trabalho) e ordens de compra com base
na premissa de que eram arquivos novos. Logicamente que os fornecedores de serviços de localização
não falaram, ou não perceberam, que esses novos arquivos eram novos apenas em parte, e acabamos
pagando a mesma tradução duas vezes.
A tabela a seguir indica como esse tipo de erro acarreta custos desnecessários e afeta o planejamento
do orçamento dos projetos de localização (Tabela A.1):
Tabela A.1 Custo de uma Atualização

Contagem Custo médio Custo total apenas Total de palavras Custo médio total Perda com a atualização
de palavras total de tradução da atualização consideradas – considerando
para a atualização por palavra novas os 17 idiomas
US$500 US$ 0,30 US$ 150,00 US$10.000 US$ 3.000 US$42.500
Como ilustrado na Tabela A.1, um erro no hand-off para a localização devido a problemas de controle
de versão de arquivos pode gerar perdas financeiras, pois são considerados como tradução nova no
número total de idiomas para o projeto. Esse exemplo ilustra um projeto pequeno: em projetos grandes
com mais de 1 milhão de palavras, a ocorrência de problemas de controle de versão de arquivos resulta
em perdas ainda maiores.
Os custos de aquisição para cada ferramenta encontram-se ilustrados na tabela a seguir (Tabela A.2):
Apêndice A • Exemplo de Análise de Pré-projeto 229
Tabela A.2 Custos das Ferramentas

Custo para licença para 20 usuários (gerente de projetos) Ferramenta A Ferramenta B
Compra 0 13.000
Instalação e configuração do software 500 2.000
Configuração de hardware (servidor) 500 10.000
Treinamento 0 5.000
Total US$1.000 US$30.000
Viabilidade legal
Com base em um acordo existente com a empresa C, resultante da venda de uma linha de produtos,
ambas as empresas podem trocar ferramentas internas sem incorrerem em custos. A única restrição
é que o código-fonte das ferramentas não pode ser compartilhado – apenas a ferramenta pronta.
Poderá ser necessária uma declaração por escrito do departamento de localização afirmando que não
será feita cópia da Ferramenta A a terceiros ou qualquer prática de engenharia reversa no produto ou
comercialização do mesmo sem autorização expressa da empresa C.
Para a Ferramenta B, o departamento de desenvolvimento já tem licenças de uso para produtos do
doméstico. Haverá necessidade de consulta junto ao departamento jurídico da empresa para verificar
se a utilização das licenças da ferramenta para a equipe do doméstico pode ser estendida a outros
departamentos que produzem versões internacionais do produto de software da empresa. Precisará ser
verificado também se o número de licenças disponível hoje é suficiente para todos os grupos.
Viabilidade do cronograma
É importante observar que qualquer aquisição deve ser realizada pelo departamento de compras
corporativas. Compras acima de US$ 5.000 estão condicionadas à aprovação do novo orçamento para
o próximo ano. Isso quer dizer que, se for escolhida a Ferramenta B, o departamento de localização
deverá esperar mais dois trimestres para solicitar a aquisição, pois o orçamento deste ano foi aprovado
no ano passado. Esse aspecto somado ao tempo necessário para configuração de software e hardware,
mais o treinamento da equipe, pode adiar a implantação da Ferramenta B para cerca de um ano a partir
da data de hoje.
Já no caso da Ferramenta A, a compra pode ser feita imediatamente, com uma implantação dentro
de duas semanas.
Recomendação
Com base nas viabilidades consideradas anteriormente, recomendamos a aquisição e implantação
da Ferramenta A, que atenderá às necessidades operacionais e técnicas do departamento de localização
sem impactar os cronogramas de produção ou financeiros. O departamento de desenvolvimento domés-
tico concordou com essa avaliação, e os baixos custos de implantação confirmam a viabilidade dessa
opção de ferramenta.
B
Perguntas Frequentes
1. Por que o gerenciamento de projetos foi introduzido em cursos de graduação e pós-graduação
nos últimos anos?
O gerenciamento de projetos se tornou uma questão estratégica para as empresas que precisam fazer
mais com menos, pois permite uma maximização dos recursos das empresas e organizações e agiliza o
tempo de entrada do produto ou serviço no mercado. Além disso, com a atual competitividade em nível
global, as empresas precisam trabalhar com indicadores de desempenho para um melhor controle de
seus processos internos (administrativos e produtivos). O gerenciamento de projetos oferece processos,
procedimentos e ferramentas para controlar e medir o trabalho de forma organizada e padronizada.
2. Qual a área de conhecimento mais difícil de gerenciar em um projeto real?
Todas as áreas apresentam níveis de dificuldade proporcionais aos ambientes técnicos, organizacio-
nais e culturais em que o projeto está sendo realizado. Normalmente, gerentes de projetos veteranos
concordam que a área de escopo é a mais difícil – não a mais complicada de gerenciar, mas de definir.
Isso é particularmente verdadeiro em projetos novos e inéditos em que pouco se sabe sobre os detalhes
do que de fato precisa ser feito no projeto. Como as outras áreas de conhecimento são planejadas em
cima do escopo, uma definição incorreta do escopo gera um “efeito dominó” que leva a retrabalhos e
estouros nos orçamentos.
3. O que é melhor para um projeto: ter um gerente de projetos técnico ou bom gestor?
O ideal é um equilíbrio das duas áreas: técnica e gestão. Não é muito eficaz um gerente extremamente
técnico que não mantém as áreas do projeto integradas, e, ao mesmo tempo, não vale muito ter um
ótimo gestor que não entende as particularidades das entregas e atividades envolvidas no projeto. O
mercado normalmente dá preferência aos profissionais da área técnica com formação em gerenciamento
de projetos. Isso acontece muito na área de tecnologia da informação, porém já é considerado padrão
em outras áreas também.
4. Como entrar para a profissão de gerente de projetos?
Se você tem interesse em ingressar ou já atua em posição júnior em gerenciamento de projeto, ou
se está estudando gerenciamento de projeto em um curso de graduação ou pós-graduação, existe uma
certificação do PMI para iniciantes denominada CAPM® – Certified Associate in Project Management.
O site do PMI Brasil fornece informações detalhadas sobre a certificação CAPM®.
Para conseguir uma posição em gerenciamento de projetos, se você trabalha em uma empresa que já
tem um PMO ou uma estrutura de gerenciamento de projetos, candidate-se sempre a uma posição nesse
departamento. Muitas vezes, temos que pagar para trabalhar e investir em uma carreira no longo prazo.
Outra dica é fazer trabalhos voluntários em organizações não governamentais (ONGs) e pedir para
gerenciar os projetos. Assim, você não só contribui com a sociedade como também adquire experiência e
vai acumulando horas em gerenciamento de projetos. Não se esqueça de pedir comprovantes a essas ins-
tituições confirmando sua atuação como gerente de projetos e incluindo o nome dos projetos que gerenciou.
O PMI também oferece cursos oficiais que oferecem PDU's, equivalentes a horas de gerenciamento
de projetos. Essas PDU's podem ser usadas depois para calcular quando você já pode prestar o exame
PMP®.
Outra dica para quem quer ingressar na área é sempre verificar anúncios de empregos em websites
nacionais especializados e ir acompanhando o perfil do profissional de projetos que as empresas estão
procurando. Primeiro, veja se você se encaixa nesse perfil. A profissão de gerente de projetos requer
uma combinação muito específica de habilidades. Além das certificações e experiência, é imprescindível
falar inglês, mesmo que a vaga seja em empresas nacionais.
231
A última dica, não só para quem está buscando oportunidades em gerenciamento de projetos, mas
para qualquer profissional, é ser flexível quanto ao local do trabalho. Em países como os Estados Unidos,
dificilmente o profissional consegue uma colocação profissional na mesma cidade onde nasceu, cresceu
e concluiu o ensino superior. O Brasil é um país que tem passado por um crescimento econômico
acelerado nos últimos anos, com outras regiões, além do Sudeste, em pleno desenvolvimento. Há muitas
oportunidades fora do eixo Sul-Sudeste que um iniciante em gerenciamento de projetos pode perseguir.
É importante estar aberto a mudanças em todos os sentidos para ter sucesso.
5. A empresa onde trabalho é tradicional e muito hierárquica. Os donos querem implantar uma
metodologia de gerenciamento de projetos, só que na hora de seguir o processo, ninguém quer
fazer nada. O que posso fazer nesse caso?
A primeira coisa é ter uma conversa séria com os donos da empresa para entender – exatamente
– o que querem de uma estrutura de gerenciamento de projetos. É necessário conhecer e entender as
expectativas das partes interessadas para decidir o que pode ser feito naquele contexto organizacional.
Você é o especialista na área de gerenciamento de projetos. Pode haver pontos na metodologia que
eles não estejam entendendo porque não é a área deles. Esse pode ser também um caso de resistência
a mudanças, o que requer habilidades específicas para mudar o paradigma das partes interessadas.
De qualquer forma, é necessário determinar se esses donos de fato querem implantar algum tipo de
organização ou estruturação em gerenciamento de projetos. No mundo de hoje, a empresa que quiser se
manter competitiva precisa ser mais ágil no trabalho e saber gerenciar de forma eficiente seus recursos.
Como profissional da área, cabe a você fazer um diagnóstico da situação para determinar se a situação
pode ser melhorada, desenvolvendo um entendimento maior sobre gerenciamento de projetos ou uma
customização maior da metodologia à cultura e aos processos da empresa.
6. Quais os melhores cursos, os melhores livros e as melhores ferramentas para gerenciar projetos?
Diversos livros, cursos e materiais na internet, disponíveis em bancas de jornais, livrarias etc. são
bons para consulta e entendimento de conceitos. Porém, por definição, projeto é um esforço temporário
único e exclusivo. Cada projeto tem seus próprios desafios que estão relacionados diretamente ao tipo
de produto, empresa, mercado e outras variáveis que são únicas para cada projeto. Não existe uma fonte
já pronta de informações que irá solucionar todos os problemas que um gerente de projetos enfrenta
nos seus projetos ou na sua empresa. É por isso que, para ser um bom gerente de projetos, o profissional
precisa ter um conjunto de habilidades muito específicas que permitem a ele se adaptar a qualquer
circunstância e achar soluções aos mais variados tipos de problemas que acontecem – e sempre irão
acontecer – no dia a dia da vida de um projeto.
Como dica pessoal da autora, há uma sequência básica na aquisição dos conhecimentos na área
de gerenciamento de projetos:
a. Domínio das áreas de conhecimento e processos do PMBOK.
b. Conhecimento de ferramentas informatizadas para elaborar EAPs, cronogramas e orçamentos,
para garantir o controle nas linhas de base do projeto.
c. Aperfeiçoamento na área de gestão de pessoas e comunicação. O gerente de um determinado
projeto pode ser impecável tecnicamente, porém se não souber trabalhar com as pessoas e se
comunicar extremamente bem com suas partes interessadas (nas formas oral e escrita, e tanto
pessoal como eletronicamente por e-mail, videoconferência ou teleconferência) não terá futuro
nessa área.
7. Agendo reuniões de planejamento, ninguém aparece. Faço cronogramas, ninguém segue as datas.
Na minha empresa, não há comprometimento. O que posso fazer nesse caso?
Gerenciamento de projetos é top-down, ou seja, o comprometimento com uma metodologia

de gerenciamento de projetos deve vir de cima. Deve haver uma comunicação clara do alto escalão
da empresa quanto à necessidade de se seguir a metodologia aprovada para os projetos da empresa.
Outra coisa a fazer é conversar com as partes interessadas e pedir a opinião sincera do porquê da falta
Apêndice B • Perguntas Frequentes 233
de colaboração. Talvez haja uma solução simples, talvez complexa – mas comunicar-se para entender
o que está acontecendo de fato é fundamental para a resolução do problema.
8. Acho a maior besteira esse negócio de documentar tudo no projeto. Gera um trabalho
desnecessário à equipe em geral. Passo mais tempo escrevendo a documentação do projeto que
o gerente de projetos da minha empresa pediu do que fazendo o meu trabalho. Será que uma
metodologia de projetos ajuda mesmo na eficiência ou só cria mais trabalho com toda essa
documentação?
A autora já se deparou com casos extremos de empresas grandes ou multinacionais com sistemas
sofisticados próprios de gerenciamento de projetos que geram ocorrências e relatórios diversas vezes
ao dia, forçando a equipe do projeto a preencher formulários no sistema a todo instante. Isso, de fato,
pode ser contraprodutivo e ocupar muito mais tempo para a documentação do que o necessário. A do-
cumentação do projeto deve ser feita, pois no mundo corporativo de hoje, o que não está documentado
não existe. É preciso que uma referência formal das informações-chave esteja disponível a todos que
trabalham no projeto para que haja consistência e um mínimo de organização no que deve ser feito.
O processo de documentação neste livro inclui tipos de documentos básicos e obrigatórios que não
engessam a equipe com constantes atividades relativas à documentação do projeto e são relativamente
fáceis de produzir e seguir no dia a dia. É responsabilidade do gerente do projeto usar o bom senso para
definir as necessidades de documentação de cada projeto, em vista de seu tamanho e complexidade e
das restrições de tempo da equipe.
9. Já tentamos implantar uma metodologia de projetos na nossa empresa seguindo o PMBOK, e
não funcionou. Quais as causas mais prováveis de isso ter acontecido?
Como explicado no capítulo 1, Breve História do Gerenciamento de Projetos, o que o PMBOK es-
tabelece como padrões em gerenciamento de projetos não reflete, necessariamente, um pensamento
novo ou revolucionário na maneira como gerenciar projetos. Desde a época da construção das Muralhas
da China e das Pirâmides de Gizé já havia processos semelhantes aos que temos hoje.
O PMBOK inclui diretrizes para as melhores práticas em gerenciamento de projeto que devem ser
adaptadas à realidade de cada empresa com uma metodologia de trabalho real e eficiente com projetos.
É mais fácil fazer um downsizing das diretrizes do PMBOK do que fazer um upgrade de uma metodologia
de projetos incompleta e deficiente.
Se a metodologia mencionada não funcionou, talvez seja o caso de a empresa procurar consultores
especializados na área para realizar um diagnóstico do PMO ou da estrutura de projetos que foi criada
na empresa para determinar qual a causa central dos problemas e como isso pode ser resolvido. Na
maioria dos casos, o problema não é o PMBOK; é uma combinação de fatores que vai desde um excesso
de requisitos de documentação para o produto do projeto até a resistência cultural dos colaboradores
da empresa ou falta de apoio do alto escalão. Pode ser até que a empresa seja caótica por si só – não
só para a realização de projetos como para a aplicação de métodos de controle de qualidade no seu
setor produtivo, nos controles de orçamentos em geral, e até mesmo no controle da agenda do diretor
comercial ou do diretor técnico – enfim, problemas estruturais da empresa como um todo. A solução
nesse caso é uma abordagem mais sistêmica com uma reengenharia nos processos e nos procedimentos
internos da empresa para que depois se possa chegar à customização da área de gerenciamento de
projetos naquela realidade organizacional.
10. Trabalho na área de tecnologia (telefonia, help desk, suporte etc.), e os projetos são de curtíssima
duração. Às vezes, o solicitante pede o projeto na sexta-feira para estar pronto na segunda-feira.
Sem falar que prestamos serviços para várias empresas que terceirizam para outras empresas.
É muito confuso e rápido. Não conseguimos documentar nada e tudo é para ontem. Como
posso, então, adotar uma metodologia de gerenciamento de projetos que dê certo nesse tipo de
ambiente tão caótico?
Em alguns setores, como a telefonia celular no Brasil, parece que está emergindo um novo conceito:
o “projetop”, uma mistura de projeto com operação ou trabalho operacional. Como o ciclo de vida do
produto está em uma curva ascendente, é comum que o ritmo seja rápido, com uma sensação de caos no
desenvolvimento de produtos e soluções. À medida que o produto amadurecer, será possível identificar
padrões de trabalhos e processos que irão atender – de forma padronizada – às necessidades dos clien-
tes. Chegará uma hora em que o resultado único e exclusivo não existirá mais. O que haverá será uma
variedade de opções de trabalho operacional, que irá se repetir no ciclo de vida do serviço ou produto
com algumas customizações. Hoje, a solução pode estar na análise do que é chamado de “projetop”,
na qual se procurará descobrir padrões repetitivos. Esses padrões indicarão que as operações talvez
precisem de processos e procedimentos operacionais (e não de uma metodologia de gerenciamento
de projetos) para funcionarem de forma mais organizada e controlada.
11. Qual a importância de uma certificação em gerenciamento de projetos?
Quem já esteve em situação de contratar um funcionário ou colaborador sabe da dificuldade de dis-
tinguir o profissional que agrega valor de um profissional que dará prejuízos à empresa. Não se pode mais
confiar apenas no currículo, pois a internet democratizou as informações e todos são muito parecidos.
Uma certificação em gerenciamento de projetos é uma validação segundo a qual o profissional tem o
conhecimento dos padrões e princípios do PMBOK para exercer a profissão na área de gerenciamento
de projetos. Uma certificação assegura também uma consistência no trabalho dos gerentes de projetos
da empresa, principalmente em caso de empresas multinacionais e de grande porte com operações
em diversas partes do mundo. Porém, de nada adianta a certificação se o profissional não souber
gerenciar um projeto na prática. Daí a importância de o profissional procurar formas de aprender e se
aperfeiçoar constantemente dentro dessa área. Segundo estudos realizados pelo PMI Brasil, as empresas
confirmaram que não exigem necessariamente uma certificação – porém, esse é um diferencial para
entrar e se manter na empresa.
Referências
AICHER, Peter J. Guide to the aqueducts of Ancient Rome. Bolchazy-Carducci Publishers: Wauconda, ILL, 1995.
CHIU, Y.C. An Introduction to the History of Project Management. From the Earliest Times to A. D. 1900. Eburon Academic
Publishers: The Netherlands, 2011.
DEPARTMENT of Defense Handbook – Work Breakdown Structure. 25 mar. 1993. Disponível em: <https://www.usgbc.
org/Docs/SBTM/sbt.pdf>. Acesso em: 23 out. 2010.
DUIKER, William J., & SPIELVOGEL, Jackson J. The Essential World History. 6. ed. Wadsworth Publishing: Boston, MA, 2007.
ESTUDO de Benchmarking em Gerenciamento de Projetos Brasil 2009 – Project Management Institute – Chapters Brasi-
leiros. Disponível em: http://pmi-rio.ning.com/page/benchmarking-1. Acesso em: 05 mar. 2011.
HAUGAN, Gregory T. Effective Work Breakdown Structures. Project Management Essential Library. Management Concepts
inc: Vienna, VA–USA, 2002.
ISO/IEC 27001:2005.Information technology — Security techniques — Information security management systems. Dis-
ponível em: <http://www.iso27001security.com/html/27001.htm>. Acesso em: 12 out. 2011.
KELLY, Cynthia C. Remembering the Manhattan Project. Perspective on the making of the atomic bomb and its legacy. World
Scientific Publishing Co. Pte. Ltd. Singapore: Cingapura, 2004.
KOZAK-HOLLAND, Mark The History of Project Management. Multi-media Publications Inc: Ottawa, Canada, 2011.
LESSONS LEARNED PURPOSE AND AGENDA. Planning and Project Management Office da Carnegie Mellon University.
Disponível em: <http://www.cmu.edu/computing/ppmo/project-management/life-cycle/closing/lessons/index.
html>. Acesso em: 13 out 2011.
MULCAHY, Rita. PMP® Exam Prep: Rita's Course in a Book for Passing the PMP® Exam. RMC Publications, Inc. Sixth
Edition. RMC Publications Inc.: USA, 2009.
NASA-APOLLO Program Management. Preparado pelo Apollo Program Office. National Aeronautics and Space Adminis-
tration. US Department of Comerce. Volume I. Dezembro de 1967. Disponível em: <http://ntrs.nasa.gov/archive/
nasa/casi.ntrs.nasa.gov/19700076195_1970076195.pdf>. Acesso em: 21 dez. 2011.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 4ª Edição.
ed. [S.l.]: PROJECT MANAGEMENT INSTITUTE, 2009.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 5ª Edição.
ed. [S.l.]: PROJECT MANAGEMENT INSTITUTE, 2013.
PROJECT Budget Template for IT Software Projects. 2010 Version (v1.01). Axia Consulting Ltd. Disponível em: www.
axia-consulting.co.uk. Acesso em 21 dez. 2011.
PROJETOS web: Planejamento. Estrutura Analítica do Projeto (EAP) – Work Breakdown Structure (WBS). Disponível em:
http://www.avellareduarte.com.br/projeto/planejamento/planejamento5/planejamento5.htm#ixzz1mwbo. Acesso
em: 15 nov. 2011.
ROADMAP para o Projeto de Implantação do Escritório de Processos. Elo Group, 2008. Disponível em:<http://www.elo-
group.com.br/download/Artigo_Roadmap%20para%20Implantacao%20de%20um%20Escritorio%20de%20Processos.
pdf>. Acesso em: 25 ago. 2011.
SIDAOUI, Rogério Curiosidades históricas. São Paulo: IBRASA, 2004.
SHARMA, Raj. The 6 principles of stakeholder management. Supply Chain Management Review. Outubro, 2008. Disponível
em: http://www.censeoconsulting.com/media/pnc/2/media.12.pdf. Acesso em: 23 dez. 2012.
STRETTON, Alan. A Short History of Modern Project Management. PM World Today, vol. IX, n˚ X. Outubro, 2007. Disponível
em: <http://www.pmforum.org/library/second-edition/2007/PDFs/Stretton-10-07.pdf>. Acesso em: 15 jun. 2011.
SUSTAINABLE building technical manual: green building practices for Ddesign, construction, and operations. 1996. US
Green Building Council. Disponível em: http://www.usgbc.org/DisplayPage.aspx?CMSPageID=212. Acesso em: 19
jan. 2012.
VERZUH, Eric The fast forward MBA in project management. 3. ed. Hoboken, New Jersey–USA: John Wiley & Sons, Inc., 2008.
WALKER, Derek & DART, Christopher J. Frontinus. A Project Manager From the Roman Empire. Project Management
Journal, vol. 42, Ns. 5, 4–16. Disponível em: http://onlinelibrary.wiley.com. Acesso em: 05 jul. 2011.
WEAVER, Patrick. A Brief History of Scheduling. PM Forum. Abril, 2006. Disponível em: http://www.pmforum.org/library/
papers/2006/A_Brief_History_of_Scheduling.pdf. Acesso em: 22 jan. 2011.
Referências das pesquisas do projeto de implantação de práticas de sustentabilidade à rede A.
AGENDA SUSTENTÁVEL. A sustentabilidade na prática. artigos, responsabilidade social, empresas parceiras e cases em
destaque. Disponível em: http://www.agendasustentavel.com.br. Acesso em: 19 abr. 2010.
Agenda sustentável. O futuro a gente faz agora. Pão de Açúcar: primeiro supermercado com selo LEED. Disponível em:
http://planetasustentavel.abril.com.br/noticia/desenvolvimento/conteudo_282198.shtml. Acesso em: 10 mar. 2010.
FÓRUM DE VAREJO E CONSUMO SUSTENTÁVEL: EXPERIÊNCIAS, DEBATES E DESAFIOS. Coordenação: Juracy Parente,
Jacques Gelman, Roberta Cardoso. Redação, Edição e Revisão: Luiz Macedo, Maria Furlan da Silva Telles e Roberta
235
Cardoso. São Paulo: FGV, 2009. Disponível em: <http://www.varejosustentavel.com.br/painel/dbarquivos/dbanexos/

publicaoforumbp.pdf>. Acesso em: 03 mar. 2010.
GBC BRASIL. Construindo um Brasil sustentável. histórico, missão e visão, metodologia aplicada e certificação LEED. Dis-
ponível em: http://www.gbcbrasil.org.br. Acesso em: 19 abr.2010.
PÃO DE AÇÚCAR, Lugar de gente feliz. Blog com artigos, informações sobre as lojas verdes do grupo e dicas de sus-
tentabilidade. Disponível em: http://www.paodeacucarverde.com.br. Acesso em: 10 mar.2010.
WALMART – Brasil, Lojas ecoeficientes. Disponível em http://www.walmartbrasil.com.br/sustentabilidade/programas-de
-sustentabilidade/lojas-ecoeficientes. Acesso em: 20 nov. 2010.
Índice
A fixos, 111
Aceitar, 153 indiretos, 111
Activities, 21 orçamentos, 111
Adaptação de itens existentes, 96 variáveis, 111
Alinhamento com as estratégias da empresa, 25
Alta influência D
com alta participação, 174 Declaração de Escopo, 49
com baixa participação, 173 Definição
Análise das opções de sustentabilidade, 96 das entregas e pacotes de trabalho, 72
Aplicação do questionário, 95 do material, 96
Apresentação Deliverables, 20
da proposta, 96 Distribuição, 97
final, 72 Documentação
Aquisições, 95, 163 de requisitos, 58
plano de gerenciamento, 164 documentação de requisitos, 59
áreas de conhecimento na execução, 186 matriz de rastreabilidade de requisitos, 59
Arquivamento do projeto, 97 plano de gerenciamento de requisitos, 59
Assumption, 20 do gerenciamento das mudanças, 148
Atividades, 21 Documentos iniciais, 94
E
B EAP
Baixa influência mista, 83
com alta participação, 174 para produtos com ciclo de vida, 83
com baixa participação, 174 para serviços, 81
Basílica de Santa Sofia, 6 para um resultado, 83
Benchmarking de práticas sustentáveis, 95 Educação para os consumidores, 187
Bottom-up, 71, 111 Elaboração
Brainstorming, 72 do questionário, 95
do relatório, 96
C Encerramento, 97, 215
Certificações ambientais, 188 lições aprendidas, 215
Checklists, 126 processo, 215
Cliente, 17 Engajamento de partes interessadas no projeto, 173
Colaboração mútua, 177 Entregas, 20
Coliseu, 5 Entregáveis, 20
Comunicações, 145 Envolvidos no Projeto, 20
esquema das, 146 Escopo, 18, 49
relatórios e registros de informações, 146 declaração, 49
Comunicações, 95 documentação de requisitos, 58
Consenso, 72 documentação de requisitos, 59
Constraint, 22 matriz de rastreabilidade de requisitos, 59
Controle, 95, 199 plano de gerenciamento de requisitos, 59
Critical Path Method, 10 estrutura analítica do projeto, 68
Cronograma, 99 dicionário, 90
Custos, 94, 111 estratégias para criação, 71
diretos, 111 níveis, 70
estimativas, 111 tipos de, 77
237
238 Índice
Escopo, 94 Instalação de novos itens, 96

do produto, 18 Integração, 37
do projeto, 18 plano de gerenciamento do projeto, 38
Esquema das comunicações, 146
Estimativas, 111 L
Estrutura Levantamento de opções de sustentabilidade, 96
analítica do projeto, 68 Lições aprendidas, 215
dicionário, 90 Linha de base, 19
estratégias para criação, 71 Listas de verificação, 126
níveis, 70
tipos de, 77 M
analítica dos riscos, 152 Marketing, 96
organizacional, 18 Matriz de análise qualitativa dos riscos, 152
Evitar, 153 Matriz RACI, 140
Execução, 183 Média influência com média participação, 175
áreas de conhecimento, 186 Membros da equipe do projeto, 20
problemas comuns e soluções, 184 Método
5W2H, 194
F do caminho crítico, 10
Fechamento dos contratos, 97 Metodologia de controle e ferramentas, 200
Filmagem do treinamento, 96 Mitigar, 153
Fluxogramas, 124 Monitoramento e controle, 199
ferramentas, 200
G metodologia, 200
Gerenciamento partes interessadas, 175
da cadeia produtiva, 187 Muralha da China, 3
de projetos
breve história do, 3 N
obras históricas, 3 Necessidades
princípios básicos, 17 do negócio, 25
atividades, 21 organizacionais, 25
cliente, 17
entregas, 20 O
escopo, 18 Objetivo, 17
estrutura organizacional, 18 Operação e lojas sustentáveis, 187
linha de base, 19 Orçamentos, 111
objetivo, 17 Organização
pacotes de trabalho, 21 executora, 20
parte interessada, 20 por afinidades, 72
patrocinador, 20
premissa, 20 P
projeto, 17 Pacote de trabalho, 21, 189
recursos, 21 Padronização da documentação, 94
requisitos, 23 Paramétrica, 111
restrição tripla, 22 Parte Interessada, 20, 169
restrição, 22 plano de gerenciamento, 171
tarefas, 21 registro, 170
Parthenon, 5
I Patrocinador, 20
Império Romano, 3 PERT, 10
Implantação, 96 PERT-CPM, 10
Indicadores de envolvimento, 173 Pesquisa
Informações, registros de, 146 de campo, 95, 189
Infraestrutura, 96 junto aos clientes, 95
Iniciação, 27 Pirâmides de Gizé, 6
Inspeção, 96 Plano
Índice 239
de gerenciamento Restrição Tripla, 22

das aquisições, 164 Reunião
de partes interessadas, 171 de encerramento, 97
do projeto, integração, 38 de status, 95
do projeto, 94 Riscos, 95, 151
Ponto de vista, 176 estrutura analítica, 152
Pré-projeto, 25 matriz de análise qualitativa, 152
Premissa, 20 Risk Breakdown Structure, 152
Princípios de sustentabilidade no varejo, 188 Roma, 4
Problemas comuns, execução, 184
Processo de encerramento, 215 S
Produção, 96 Seleção das opções, 96
Program Evaluation and Review Technique, 10 SMART, 18
Programa Apollo, 9 Soluções, execução, 184
Project Charter, 27, 32 Sponsor, 20
Project Management Professional (PMP®), 13 Stakeholders, 20
Projeto, 17, 25 Suposição, 20
iniciação, 27
pré-projeto, 25
T
Proposta de implantação, 96
Tabulação dos dados, 96
Tarefas, 21
Q
Tasks, 21
Qualidade, 123
Tempo, 94, 99
fluxogramas, 124
cronograma, 99
listas de verificação, checklists, 126
de abertura, 27, 32, 94
Qualidade, 94
Top-down, 71, 111
Transferir, 153
R
Treinamento, 96
Recursos, 21
Triple Constraint, 22
Recursos humanos, 95, 139
Matriz RACI, 140
Registro V
das partes interessadas, 170 Viabilidade
de problemas, 95, 149 do cronograma, 229
de informações, 146 financeira, 228
Relatório(s), 146 legal, 229
de andamento do projeto, 148 operacional, 228
de lições aprendidas, 97 técnica, 227
de status, 95
Requirements, 23 W
Requisitos, 23 Work Breakdown Structure (WBS), 11, 68
Resources, 21 Work Packages, 21
Restrição, 22 Workshop para os colaboradores e gerentes, 96

Gerenciamento de Projetos Fundamentos e Pratica Integrada - 1 Edição - Marta Rocha Camargo - 2014 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerenciamento de Projetos Fundamentos e Pratica Integrada - 1 Edição - Marta Rocha Camargo - 2014 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Gerenciamento

Copidesque: Lucas de Souza Cartaxo

Elsevier Editora Ltda.

Serviço de Atendimento ao Cliente

CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO

Camargo, Marta Rocha

1. Administração de projetos. 2. Empreendimentos. 3. Planejamento estratégico.

13-03453 CDD: 658.404

Do que este livro trata (escopo incluído)

Como este livro está estruturado?

6. I mportante: Observações importantes com relação a uma determinada parte do concei-

FIGURA A.1 Modelo de documento padrão.

Recursos de apoio na web

CAPÍTULO 1 Breve História do Gerenciamento de Projetos............................................................03

1.1 Obras Históricas

FIGURA 1.1 Muralha da China. © Margaretwallace | Dreamstime.com.

FIGURA 1.2 Aqueduto romano em Segóvia, Espanha. © Mariusz Prusaczyk | Dreamstime.com.

FIGURA 1.3 Mapa de trecho das estradas romanas. © Joanne Zh | Dreamstime.com.

FIGURA 1.4 Exemplo de estradas romanas. © Witr | Dreamstime.com.

FIGURA 1.5 Parthenon em Atenas, Grécia. © Vassilis | Dreamstime.com.

FIGURA 1.6 Coliseu em Roma, na Itália. © Vladimir Sazonov | Dreamstime.com.

FIGURA 1.7 Basílica de Santa Sofia em Istambul, Turquia. © Jackmalipan | Dreamstime.com.

FIGURA 1.8 Pirâmides de Gizé, Egito. © Witr | Dreamstime.com.

1.2 Século XIX

FIGURA 1.10 Exemplo de um gráfico de Gantt. Fonte: Modelos de Cronograma do MS Project.

Outro aspecto importante da história do gerenciamento de projetos ainda no século XX é o inves-

FIGURA 1.11 Pesquisas nucleares no projeto Manhattan. © Witold Krasowski | Dreamstime.com.

FIGURA 1.12 Missões Apollo. © Philcold | Dreamstime.com.

FIGURA 1.13 Exemplo de um PERT simples.

FIGURA 1.14 PERT-CPM mostrando o caminho crítico (caminho mais longo).

Tabela 1.3 Áreas de Conhecimento do PMBOK

Tabela 1.4 Processos do PMBOK

1.4 Século XXI

CAPÍTULO 2 Princípios Básicos em Gerenciamento de Projetos......................................................17

Os objetivos são fundamentais para comunicar claramente as expectativas de resultados, planejar

2.1.5 Estrutura Organizacional

2.1.6 Linha de Base (Baseline)

2.1.7 Premissa ou Suposição (Assumption)

2.1.8 Parte Interessada (Stakeholders ou os Envolvidos no Projeto)

2.1.9 Patrocinador (Sponsor)

2.1.10 Entregas (Deliverables ou Entregáveis)

São exemplos de entregas:

2.1.11 Pacotes de Trabalho (Work Packages)

FIGURA 2.1 Exemplo de pacote de trabalho.

2.1.12 Atividades ou Tarefas (Activities, Tasks)

2.1.13 Recursos (Resources)

FIGURA 2.2 Exemplo de atividades.

2.1.14 Restrição (Constraint)

2.1.15 Restrição Tripla (Triple Constraint)

FIGURA 2.3 Elementos da restrição tripla.

2.1.16 Requisitos (Requirements)

1. Faça a correspondência do conceito com o respectivo significado.

a. Objetivo ( ) Fornece os recursos financeiros ao projeto.

2. Para os exemplos seguintes, indique o conceito ao qual se referem as frases:

FIGURA 3.1 Exemplo de pré-projeto.

FIGURA 3.1 (cont.)

Tabela 3.1 Atividades da Iniciação

FIGURA 3.2 Modelo genérico de um Termo de Abertura.

FIGURA 3.3 (Cont.)

Além da elaboração e da aprovação do Termo de Abertura, para o projeto de implantação de práticas

FIGURA 3.4 Termo de Abertura do projeto sustentabilidade para a rede de supermercados A.

FIGURA 3.4 (Cont.)

Não é aconselhável detalhar o Termo de Abertura com descrições de entregas ou atividades

6. I mportante: Observações importantes com relação a uma determinada parte do concei-