Marta Rocha Camargo Gerenciamento de Projetos Fundamentos e Pratica Integrada

Gerenciamento
de Projetos
Gerenciamento
de Projetos
Fundamentos e Prtica 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 autorizao prvia por escrito da editora, poder ser reproduzida ou
transmitida sejam quais forem os meios empregados: eletrnicos, mecnicos, fotogrficos, gravao
ou quaisquer outros.
Copidesque: Lucas de Souza Cartaxo

Reviso: Bruna Baldini
Editorao Eletrnica: 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 So Paulo SP
Servio 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 tcnica foram empregados na edio desta obra. No entanto, podem ocorrer
erros de digitao, impresso ou dvida conceitual. Em qualquer das hipteses, solicitamos a
comunicao ao nosso Servio de Atendimento ao Cliente, para que possamos esclarecer ou
encaminhar a questo. Nem a editora nem o autor assumem qualquer responsabilidade por
eventuais danos ou perdas a pessoas ou bens, originados do uso desta publicao.
CIP-BRASIL. CATALOGAO NA PUBLICAO

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

Gerenciamento de projetos: fundamentos e prtica integrada / Marta Rocha
Camargo. - 1. ed. - Rio de Janeiro : Elsevier, 2014.
28cm
ISBN 978-85-352-6366-4
1. Administrao de projetos. 2. Empreendimentos. 3. Planejamento estratgico.

I. Project Management Institute. II. Ttulo.
13-03453 CDD: 658.404

CDU: 65.012.3
Sobre o Autor
Marta Rocha Camargo Project Management Professional (PMP), ttulo obtido em 2010 pelo Project
Management Institute (PMI), e ph.D. em Administrao de Empresas Aplicada Tomada de Deciso, com es-
pecializao em Liderana e Mudanas Organizacionais pela Walden University, Minnesota, Estados Unidos
(2006), revalidado no Brasil pela Universidade de So Paulo como doutorado em Administrao de Empresas
em 2009. tambm mestre em Administrao de Empresas, com especializao em Gesto de Sistemas
de Informao 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 experincia profissional inclui 12 anos como gerente de projetos na rea de localizao e interna-
cionalizao de produtos de software em multinacionais de grande porte como WordPerfect, 3COM, Novell
e Adobe Systems, onde gerenciou centenas de projetos de pequeno, mdio e grande porte para cerca de
20 mercados internacionais em todos os continentes.
Lecionou a disciplina Gesto de Projetos nos cursos de Tecnologia da Informao e Administrao de
Empresas da Faculdade Prudente de Moraes em Itu (So Paulo) entre 2007 e 2010, onde coordenou a Agncia
de Projetos da instituio, gerenciando cerca de 40 projetos de concluso de curso cujos temas abrangeram
solues a problemas reais em empresas da regio, projetos de tecnologia da informao e melhorias da
infraestrutura de organizaes sem fins lucrativos.
Atualmente, professora da disciplina de Gesto de Projetos no MBA em Gesto Empresarial e no MBA
em Gesto Estratgica da Tecnologia da Informao, e tambm da disciplina de Gerenciamento de Escopo
no MBA em Gerenciamento de Projetos da Rede FGV Management em todo o Brasil, desde 2008. Orienta
tambm Projetos de Concluso de Curso do MBA em Gerenciamento de Projetos, tendo sido responsvel,
at 2013, por cerca de 50 projetos em diferentes reas, dentre as quais destacam-se as engenharias civil e
mecnica, a bancria, a tecnolgica e os novos negcios.
Agradecimentos
Agradeo aos profissionais de gerenciamento de projetos com quem trabalhei na rea de localizao e
internacionalizao de produtos de software, pois eles me ensinaram muito, principalmente no que se refere
comunicao das necessidades e informaes de projetos complexos para equipes de diversas nacionalidades
e formaes profissionais.
Tambm agradeo aos meus clientes de consultoria, que me oferecem oportunidades de aplicar e
customizar prticas de gerenciamento de projetos nos mais variados ambientes organizacionais e culturais.
Deixo agradecimentos especiais a todos os meus alunos pelo incentivo e pela motivao para que eu
colocasse minha experincia em um material prtico e integrado e com exemplos, muitos exemplos! Espero
ter alcanado esse objetivo, e que este livro sirva como um guia para ajud-los com sugestes de prticas,
ferramentas, ideias e dicas para utilizao no dia a dia.
Tambm agradeo a contribuio dos seguintes colaboradores:
Equipe de projeto composta por Ivan Scaravelli (lder do projeto), Elias Libnio, Joo Benedetti e Paulo
Campos, que realizou um projeto de implantao de prticas de sustentabilidade a uma rede de super-
mercados na cidade de Itu (So Paulo), o qual serviu como inspirao para o projeto aplicado deste livro.
Equipe de projeto composta por Eliana Sassagima (lder do projeto), Cristiano Sandrin, Renato Csar
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 referncias e indicao da utilizao 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 auxlio no desenvol-
vimento deste livro.
Apresentao
Nos dias de hoje, cada vez mais comum encontrar profissionais de reas diferentes como engenheiros,
arquitetos, analistas de sistemas, programadores, contadores, mdicos, veterinrios, advogados, entre outros
atuando como lderes de projetos ou membros de uma equipe de projeto. Muitas vezes, esses profissionais
recebem um treinamento genrico, baseado primariamente em material terico que, por vezes, tende a
confundir mais do que esclarecer.
H casos tambm de gerentes de projetos recm-formados em cursos de Gerenciamento de Projetos em
escolas de graduao ou ps-graduao que conhecem a teoria, mas no conseguem entender como tudo
aquilo se traduz na prtica da empresa onde trabalham. Muitos desses profissionais acreditam que h uma
distncia 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 organizao onde atuam impe a eles.
H ainda casos de gerentes de projetos veteranos que so profundos conhecedores de conceitos e ferra-
mentas sofisticadas, mas tm dificuldades em fazer com que a equipe do projeto execute corretamente as
tarefas que foram planejadas. Esses profissionais veteranos criam documentao de projeto que ningum l
ou segue, acarretando atrasos e retrabalhos nos projetos.
Este livro vem ao encontro dessa demanda por um material prtico e real para a realizao de projetos,
dentro de uma abordagem amigvel, fcil de entender e aplicar, voltada a um pblico e contexto empresarial
e organizacional multidisciplinar.
Objetivo
O objetivo deste livro apresentar, de forma prtica 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 esto iniciando na rea de projetos. Profissionais experientes tambm podero
se beneficiar com inmeros exemplos de documentao de projetos e dicas valiosas de como formular e
comunicar as informaes de um projeto a todos os envolvidos.
A quem se destina
Alunos de graduao, ps-graduao e profissionais de qualquer rea que queiram ou precisem aprender
processos e tcnicas para gerenciar projetos.
Do que este livro trata (escopo includo)

Faz parte do escopo deste livro uma cobertura dos principais conceitos das reas de conhecimento do PMBOK:
Integrao
Escopo
Tempo
Custos
Qualidade
Recursos Humanos
Comunicaes
Riscos
Aquisies
Partes Interessadas
Por meio de exemplos prticos e aplicaes dos conceitos, cada captulo oferecer sugestes sobre o que
fazer em cada rea de conhecimento, com ideias para elaborao de documentos e utilizao de ferramentas
especficas quando necessrio.
Do que este livro no trata (escopo excludo)
No faz parte do escopo deste livro:
Contedo especfico ou exerccios de preparao ao exame de certificao para o Project Management
Professional (PMP).
Detalhamento de todos os captulos e processos do PMBOK: o contedo aqui apresentado foi adaptado
de forma a cobrir os itens mais importantes de cada captulo do PMBOK e incorpor-los em uma
metodologia de trabalho fcil de entender e utilizar, considerando o dia a dia de um gerente de projetos
iniciante.
Explicaes detalhadas ou passo a passo para a utilizao das ferramentas sugeridas em alguns captulos:
como so ferramentas comuns e populares a profissionais que trabalham com projetos, parte-se do pres-
suposto de que o leitor ter condies de baixar as ferramentas das fontes livres sugeridas nos captulos e
utilizar o software por si s ou fazer buscas na internet (ou outras fontes) para obter material informativo
sobre os recursos das ferramentas.
Organizao do contedo
O contedo dos captulos baseia-se nos princpios do Project Management Book of Knowledge (PMBOK) do
Project Management Institute (PMI), porm no segue risca sua lgica. No PMBOK, iniciao, planejamento,
execuo, monitoramento e controle e encerramento so tratados como processos, no como fases de um
projeto. Fases de um projeto pertencem a ciclos de vida especficos para cada setor ou indstria.
Para fins de aprendizado a um nvel iniciante, a proposta deste material facilitar o entendimento
colocando o projeto em uma linha de tempo lgica. Todo projeto tem um comeo, planejado, executado,
monitorado e controlado e, depois, encerrado. Dessa forma, cada captulo segue uma linha de raciocnio
fcil de acompanhar para a realizao de um projeto simples por um gerente de projeto iniciante na rea de
gerenciamento de projetos.
Obviamente que essa sequncia lgica 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 organizao.
Como este livro est estruturado?

A parte I, Introduo ao Gerenciamento do Projeto, um apanhado geral com base na literatura existente
sobre o assunto. interessante observar que o gerenciamento de projetos no algo que surgiu nos tempos
modernos, mas tem sua origem em grandes projetos que fazem parte da histria da humanidade. O que se
aprende com a histria que, at mesmo em projetos considerados impossveis para determinada poca,
princpios de uma boa gesto dos recursos (financeiros, humanos, materiais etc.) garantiram o sucesso e
seus resultados podem ser vistos at os dias de hoje.
O segundo captulo na parte II, Princpios Bsicos em Gerenciamento de Projetos, aborda princpios que
so normalmente colocados em glossrios ou anexos a um livro-referncia. Porm, importante que esses
princpios sejam entendidos antes que o leitor passe para a forma de gerenciar projetos, que ser vista nos
captulos posteriores, para evitar confuses no entendimento das diferentes reas de conhecimento. O
captulo seguinte, Nascimento de um Projeto, trata das fases de pr-projeto e iniciao de um projeto.
J a parte III, Planejando o Projeto, aborda todas as reas de conhecimento do PMBOK. Em cada captulo,
planeja-se o projeto a partir de documentao e ferramentas especficas.
A parte IV, Realizando o Projeto, trata dos aspectos relacionados execuo do projeto. Nela, o projeto
que foi iniciado e planejado nos captulos anteriores ser executado, monitorado e controlado e encerrado.
Importante! H uma repetio proposital de determinadas informaes nos documentos de gerencia-
mento de projeto. Isso se d, porque certos documentos podem ser enviados para diferentes pessoas ou
grupos trabalhando nos projetos. Alm disso, uma informao definida no incio do projeto pode ser neces-
sria para o entendimento de uma tarefa no decorrer ou no final do projeto. Essa repetio comum nas
documentaes do projeto e, muitas vezes, esperada para nfase e confirmao de entendimento por todos
os envolvidos no projeto.
Conveno tipogrfica
O contedo dos captulos ser dividido em sees que seguiro uma conveno grfica para fcil consulta
e referncia:
1. C
onceito: Para cada rea de conhecimento do PMBOK, foram extrados os pontos mais
importantes e essenciais ao gerenciamento de um projeto de nvel iniciante. Nessa parte
do captulo, o conceito explicado sob o ponto de vista do PMBOK, de uma forma sim-
plificada e objetiva.
2. N
a prtica: Essa seo cobrir exemplos de como o conceito pode ser utilizado na vida
real.
3. A
plicao: Essa seo uma espcie de um projeto-estudo de caso que ser realizado no
decorrer deste livro. Assim, um projeto de implantao de prticas de sustentabilidade em
um supermercado ser iniciado, planejado, executado, monitorado e controlado e, depois,
encerrado.
Ateno! Os exemplos prticos e aplicados servem apenas para ilustrar o contedo apresentado. Como
todo projeto nico e exclusivo, no recomendvel utilizar esse material (pelo menos no na forma
em que se encontra nas sees) em projetos reais sem que se faa uma anlise e uma adaptao para as
necessidades especficas de cada projeto e de cada empresa ou organizao.
4. F
erramentas: Quando houver ferramentas especficas para a realizao das tarefas mais
comuns em uma determinada rea, haver explicaes sobre as ferramentas e os recursos
mais utilizados naquela rea.
5. D
icas teis: Nos casos em que a prtica for muito abrangente, haver dicas teis com
base nas experincias de gerentes de projeto veteranos. Essas dicas abrangero desde
ferramentas at tcnicas ou atalhos para que o projeto seja feito de forma eficiente e
eficaz.
6. I mportante: Observaes importantes com relao a uma determinada parte do concei-

to ou prtica que estiver sendo explicada.
7. E
xerccios: Ao final de cada captulo, haver exerccios para praticar o que foi aprendido.
Esses exerccios iro gerar a documentao para um projeto de reforma de uma loja de
roupas femininas.
8. M
aterial de apoio: Esse smbolo indicar a necessidade de baixar um material especfico
para realizao do exerccio na pgina do livro no site da Editora - www.elsevier.com.br/
martacamargo.
Conveno da documentao de projeto nos exemplos
Para uma consistncia no tipo de informao e garantia da exatido do contedo dos documentos de
gerenciamento de projetos, importante estabelecer uma padronizao, conforme mostrado a seguir:
FIGURA A.1 Modelo de documento padro.
Recursos de apoio na web

Modelos de documentos originais para gerenciamento de projetos mencionados nos captulos.
Modelos de formulrios especficos para a realizao dos exerccios no final de cada captulo.
Videoclipes com demonstraes das ferramentas de software mencionadas nos captulos.
Documentos originais e completos do Plano de Gerenciamento do Projeto (Plano de Gerenciamento da
Integrao) e seus anexos, conforme projeto aplicado deste livro.
Exemplos adicionais de documentos de planejamento de projetos.
Exemplos adicionais de anlises estratgicas de pr-projeto.
Respostas aos exerccios do final de cada captulo (acesso restrito ao professor)
Apresentaes em PowerPoint de cada captulo (acesso restrito ao professor).
PA RT E
I
Introduo ao Gerenciamento
de Projetos
Muitas pessoas acreditam que o gerenciamento de projetos surgiu no sculo XIX ou no sculo XX, com o
surgimento da disciplina de Administrao. Apesar de ter se tornado popular no sculo XX, o gerenciamento
deprojetos est presente na forma de trabalhar do homem h muito tempo, como ser descrito a seguir.
CAPTULO 1 Breve Histria do Gerenciamento de Projetos............................................................03

1
Breve Histria do Gerenciamento de Projetos
OBJETIVOS DE APRENDIZAGEM
Aps o estudo deste captulo, voc ser capaz de:
Entender a evoluo do gerenciamento de projetos.
Saber como o gerenciamento de projetos foi aplicado em obras histricas da humanidade.
Conhecer as tendncias atuais em gerenciamento de projetos.
1.1 Obras Histricas

O gerenciamento de projetos realmente algo que veio com o surgimento da disciplina de Adminis-
trao de Empresas nos meados do sculo XIX? Ou ser que seus conceitos podem ser encontrados em
marcos histricos da construo civil, como a Muralha da China?
O projeto da Muralha da China levou 1.588 anos para ser concludo e atingiu uma extenso de
2.300 quilmetros de distncia. Acredita-se que milhes de trabalhadores na sua maioria, escravos
que trabalhavam at a exausto , foram utilizados em todos esses anos de construo. O material e as
tcnicas de construo variavam medida que os tempos evoluam e novas tecnologias de construo
eram introduzidas (SIDAOUI,2004) (Figura1.1).
FIGURA 1.1 Muralha da China. Margaretwallace | Dreamstime.com.
E quanto aos grandes projetos de infraestrutura, como os aquedutos e as estradas, construdos pelo
Imprio Romano (24 a.C.476 d.C.) nos territrios conquistados? Aquedutos eram canais que corriam
nosubsolo ou na superfcie e levavam a gua das fontes at as cidades romanas. Durante a poca do
Imprio Romano, esses canais de gua eram construdos de forma precisa para manter uma leve in-
clinao 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 90km de extenso (AICHER,1995). Muitos desses aquedutos podem ainda ser vistos em vrios
pontos da Europa, conforme o exemplo na Figura1.2.
3
4 Gerenciamento de projetos
FIGURA 1.2 Aqueduto romano em Segvia, Espanha. Mariusz Prusaczyk | Dreamstime.com.
J o famoso ditado todos os caminhos levam a Roma no fora de expresso: a engenharia romana
utilizada nos projetos de construo de estradas era to sofisticada que, de fato, todo o sistema rodo-
virio (uma parte desse sistema mostrada na Figura1.3) de aproximadamente 150 mil quilmetros
foi construdo para levar produtos, servios, pessoas e animais das diversas partes do Imprio 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 to resistentes que sobrevivem at os dias de hoje, como pode ser visto na
Figura1.4.
FIGURA 1.4 Exemplo de estradas romanas. Witr | Dreamstime.com.

Captulo 1 Breve Histria do Gerenciamento de Projetos 5
Para projetos to grandes e complexos, deve ter havido alguma organizao dos recursos humanos,
financeiros e naturais, bem como um tempo predeterminado para entrega da obra, em vista das neces-
sidades polticas e econmicas dos lderes da poca.
Segundo Walker e Dart (2011), o estudo das grandes obras da Antiguidade, principalmente no
Imprio Romano, demonstra que havia prticas 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 diferena
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 execuo desses processos, que
se transformou com o avano nas tecnologias de produo: foram introduzidas novas ferramentas
para o planejamento, monitoramento e controle de projetos. Tambm houve uma evoluo nas
necessidades do homem em relao ao seu trabalho: passou-se de uma obrigao ou questo de
honra nos tempos do Imprio Romano para uma forma de escolha e realizao 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 auxlio de profissionais das reas de
engenharia, histria e arquitetura para analisar grandes obras da construo civil, como:
o Parthenon, na Grcia (447438 a.C.), cuja construo teve como principal objetivo gerar trabalho
para a populao grega e estimular a economia da poca. Completado em nove anos, foi um marco
na arquitetura, copiado at os dias de hoje (Figura1.5);
FIGURA 1.5 Parthenon em Atenas, Grcia. Vassilis | Dreamstime.com.
o Coliseu, construdo em um perodo de dez anos e localizado em Roma (6979 d.C.), na Itlia, noqual
se utilizou vrios tipos de matrias-primas consideradas revolucionrias para a poca (o concreto,
por exemplo) e mo de obra especializada, composta por soldados romanos, escravos, engenheiros
e empreiteiros (Figura1.6);
FIGURA 1.6 Coliseu em Roma, na Itlia. Vladimir Sazonov | Dreamstime.com.
a Baslica de Santa Sofia (532537 d.C.), construda em Constantinopla (rea que atualmente
corresponde a Istambul, na Turquia) em uma rea de terremotos foi concluda em cinco anos.
Construda com materiais flexveis e executada a partir de projeto inteligente, a Baslica j sobreviveu
a inmeros terremotos e seu projeto copiado em outras partes do mundo, especialmente nos pases
muulmanos (Figura1.7);
FIGURA 1.7 Baslica de Santa Sofia em Istambul, Turquia. Jackmalipan | Dreamstime.com.
e as Pirmides de Giz (25502530 a.C.), no Egito; a criao das bases das pirmides apresentou muitos
desafios tcnicos pois deveriam estar exatamente no mesmo nvel para a construo dascmaras
fnebres (Figura1.8).
FIGURA 1.8 Pirmides de Giz, Egito. Witr | Dreamstime.com.

Considerando as Pirmides de Giz, Kozak-Holland (2011) fez um paralelo entre as aes da poca
e as reas de conhecimento atuais de gerenciamento de projetos, conforme resumo apresentado na
Tabela1.1 a seguir.
Tabela 1.1 Construo das Pirmides de Giz e reas de Gerenciamento de Projetos
rea de conhecimento Aplicao no Projeto das Pirmides de Giz
Escopo Havia uma Estrutura Analtica do Projeto que serviu como base ao planejamento do escopo
e tempo.
Preparao do local
Terraplenagem
Colocao de base slida
Determinao do sentido norte
Criao de blocos de pedra calcria
em quadrados perfeitos
Construo
Criao de um porto e canal no Rio Nilo
Criao da vila dos trabalhadores
Construo de rampas
Operaes de pedreiras
Transporte da pedra acabada
Realizao 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 concluso do projeto antes de o Fara morrer ou,
aproximadamente, vinte anos.
A equipe do projeto calculou 10 anos para a extrao do granito para o teto da cmara
funerria do rei. No dcimo ano do projeto, a pirmide deveria apresentar uma altura de
45,72 metros e estar pronta para a construo da cmara fnebre.
Qualidade A preciso nas medidas foi fundamental para o sucesso do projeto.
Cada lado tem 230 metros de comprimento, em um alinhamento quase perfeito
de15milmetros. As dimenses da pirmide so bastante precisas, e o local da obra
foiigualado em termos de centmetros sobre uma base de 5,3 hectares.
Recursos Humanos A fora de trabalho no era apenas escrava. A grande maioria era de fazendeiros que
recebiam salrios e benefcios. Registros da poca mostram que bfalos e carneiros eram
enviados ao local da obra para alimentar os operrios e mant-los motivados. Havia incentivos
tambm no abatimento de impostos para quem trabalhasse na construo da pirmide.
Comunicaes A organizao da comunicao seguia uma hierarquia estilo militar, de cima para baixo,
feita, na sua grande parte, oralmente. Havia servio de mensageiros que levavam e traziam
informaes sobre o projeto em papiros e mantinham o fluxo de informao entre as partes
interessadas em diversos pontos da regio.
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
desequilbrio dos operrios. Os blocos maiores eram colocados por meio de rampas que davam
acesso direto ao posicionamento na pirmide. Buscava-se manter a ocorrncia de acidentes no
nvel mais baixo possvel, para no afetar o moral e a produtividade dos operrios.
Aquisies Havia uma rede de fornecedores de materiais dentro e fora da regio da obra, bem como um
sistema para transporte, recebimento e pagamento do material fornecido no local da obra.
Alm 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 histria sob a perspectiva do moderno gerenciamento de projetos e descobriram
vrias similaridades no gerenciamento do tempo, dos custos e das pessoas semelhanas que confirmam,
acima de tudo, a necessidade de algum tipo de organizao formal dos recursos para a concluso dos
projetos.
medida que o homem evoluiu e suas necessidades ficaram mais sofisticadas, o nmero de projetos
necessrios para acompanhar essa evoluo e reduzir o tempo de entrega desses projetos aumentou.
Os trs ltimos sculos, particularmente, trouxeram grandes avanos nas prticas de gerenciamento
de projetos e no papel do gerente de projetos, conforme explicado a seguir.
1.2 Sculo XIX

O sculo XIX foi marcado por obras governamentais de infraestrutura de grande porte nos Estados
Unidos, as quais ofereciam um nvel cada vez maior de complexidade devido escala dos projetos.
Projetos de construo 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 operrios, sem falar na
fabricao e montagem de quantidades exorbitantes (para a poca) de material de construo para as
obras (KOZAK-HOLLAND,2011). Nenhum mtodo formal de gerenciamento das tarefas e dos recursos
foi desenvolvido nessa poca, porm as empresas comearam a perceber que era necessrio estabelecer
uma maior organizao e um maior controle do trabalho e dos trabalhadores para que as obras fossem
terminadas dentro do tempo e do custo esperados (Figura1.9).
FIGURA 1.9 Construo das ferrovias no sculo XIX. Georgios Kollidas | Dreamstime.com.
1.3 Sculo XX
Os primeiros registros de ferramentas especficas para gerenciamento de projetos surgem no incio
do sculo XX na figura de Henry Gantt, que desenvolveu as primeiras tcnicas de planejamento e con-
trole de um projeto.
Seguindo os passos das teorias de administrao cientfica de Frederick Taylor, Gantt comeou a observar
o trabalho dos operrios na construo de navios da marinha norte-americana na poca da Primeira Guerra
Mundial para identificar atividades e as duraes dessas atividades. Durante esses estudos, Gantt desenvolveu
um mtodo de utilizar grficos com barras de tarefas e marcadores de pontos importantes do projeto, deli-
neando a sequncia e a durao de todas as tarefas no processo da produo (CHIU,2010). Esses grficos ou
diagramas de Gantt se tornaram uma ferramenta valiosa para os gerentes da poca, pois assim conseguiam
ter uma viso melhor da durao do trabalho e da utilizao dos recursos para executar esse trabalho. Eles
auxiliavam, tambm, na comparao entre trabalho planejado e trabalho realizado (Figura1.10).
FIGURA 1.10 Exemplo de um grfico de Gantt. Fonte: Modelos de Cronograma do MS Project.

Outro aspecto importante da histria do gerenciamento de projetos ainda no sculo XX o inves-

timento do governo norte-americano em projetos de energia atmica 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 produo de bombas atmicas, envolvendo cerca de 125 mil trabalhadores a
um custo de aproximadamente dois bilhes de dlares (KELLY,2004) (Figura1.11).
FIGURA 1.11 Pesquisas nucleares no projeto Manhattan. Witold Krasowski | Dreamstime.com.
Alm de projetos associados a armas nucleares, os anos 1950 foram marcados tambm pelos grandes
projetos de conquista espacial, com o incio da operao da NASA (National Aeronautics and Space
Administration Administrao Nacional da Aeronutica e do Espao, em portugus) em 1958.
Ainda disponvel na internet (o endereo eletrnico encontra-se nas Referncias ao final deste livro),
o manual do gerenciamento do programa Apollo (NASA-Apollo Program Management), de 1967, detalha
todas as informaes do programa, com vrios elementos do moderno gerenciamento de projetos, como
diviso em fases, estrutura analtica, realizao em uma estrutura matricial, linhas de base, requisitos,
riscos, aquisies etc. (Figura1.12).
FIGURA 1.12 Misses Apollo. Philcold | Dreamstime.com.
Como esses projetos eram extremamente complexos na sua logstica e dispendiosos nos seus gastos,
o congresso do governo norte-americano comeou a exigir uma organizao e documentao para
definir o trabalho e, principalmente, justificar e comprovar os gastos e as despesas (VERZUH,2008).
Comearam a surgir, ento, modelos matemticos para demonstrar informaes 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 mssil do submarino nuclear Polaris (trabalho em
conjunto com a Lockheed Corporation). A ideia era trabalhar com um mtodo quantitativo e probabils-
tico para estimar as duraes das atividades, em situaes nas quais essas duraes eram incertas. Em
linhas gerais, o PERT apresentava uma ilustrao grfica de um projeto como um diagrama de rede
formado por ns numerados (que podiam ser crculos ou retngulos) representando eventos ou marcos
do projeto conectados por meio de vetores (STRETTON,2007). A direo das setas nas linhas indicava
a sequncia das tarefas, como pode ser visto na Figura1.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 mtodo do
caminho crtico, desenvolvido em conjunto pela DuPont Corporation e a Remington Rand Corporation
para projetos de manuteno de plantas industriais. Diante de um nmero muito grande de projetos,
as empresas procuravam formas de reduzir o tempo de concluso 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 concluso e decidir se alocar mais recursos a essas partes traria benefcios, como a reduo dos
prazos de entrega (WEAVER,2006). A Figura1.14 ilustra (caminho em negrito) o caminho crtico para
um projeto a exemplo do PERT.
FIGURA 1.14 PERT-CPM mostrando o caminho crtico (caminho mais longo).
O mtodo do caminho crtico concebido naquela poca basicamente o mesmo que continua sendo
utilizado nos dias de hoje. Conhecido agora como PERT-CPM, o mtodo do caminho crtico permite
definir a sequncia das atividades para que o projeto seja concludo dentro do prazo estipulado. o
caminho mais longo das atividades que compem o projeto, desde o incio at o fim, e determina a data
de concluso ou entrega final do projeto. Se uma das atividades que se encontra no caminho crtico
no for concluda no tempo determinado, isso significa que o projeto ter um atraso. por isso que
importante entender a sequncia das atividades no caminho crtico, pois um atraso em uma atividade
crtica afeta o prazo final do projeto. Um aspecto interessante do PERT-CPM evidenciar o fato de que,
quando o projeto est atrasado, no adianta alocar recursos para tarefas fora do caminho crtico, pois
elas no afetam as datas finais. As tarefas do caminho crtico sempre tero 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 inclua um grfico com os
principais componentes do projeto Polaris, que viria a se chamar Work Breakdown Structure (WBS),
conforme exemplo na Tabela1.2 a seguir.
Tabela 1.2 Subsistemas do Projeto Polaris
Subsistemas do Programa de Mssil Balstico da Frota
Mssil Corpo de reentrada
Guia
Revestimento balstico
Propulso
Controle de voo
Disparador
Navegao
Controle de disparo
Navios
Comunicaes 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 descrio de uma WBS, similar forma em que feita hoje, conforme
ilustrado na Figura1.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 construo civil, blica e aeroespa-
cial. Nesse perodo, a disciplina de Gerenciamento de Projetos passou a ser reconhecida e conduzida por
um profissional denominado gerente de projetos. Comearam a aparecer instituies dedicadas a essa
rea com o objetivo de reunir profissionais com interesses similares e compartilhar prticas comuns.
Uma das primeiras instituies a padronizar os processos de gerenciamento de projetos foi o Project
Management Institute (PMI). O PMI uma instituio sem fins lucrativos, fundada em 1969 por cinco
voluntrios na cidade de Filadlfia, estado da Pensilvnia, nos Estados Unidos.
medida que os negcios evoluam e o mercado se tornava cada vez mais competitivo, principal-
mente a partir dos anos 1980, as empresas comearam a perceber que precisavam encontrar formas
de trabalho mais eficientes e utilizar seus recursos ao mximo 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 servios ao mercado, as empresas comearam a compartilhar uma estrutura orga-
nizacional com base em projetos gerenciados pelo seu gerente de projetos, que organizava o trabalho
e assegurava a integrao e a comunicao do fluxo de trabalho entre profissionais e funes diferentes.
Dentro dessa nova viso organizacional multidisciplinar, tornou-se necessrio padronizar as prticas
de gerenciamento de projetos.
Em 1987, os conceitos e os processos de gerenciamento de projetos praticados por diversas ins-
tituies 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 bsica para entender o gerenciamento de projetos e o ambiente
no qual o projeto ocorre. O PMBOK oferece tambm uma viso geral da maneira como os diversos
processos de gesto interagem durante a realizao de projetos.
A segunda verso do PMBOK foi publicada em 1996, a terceira em 2000 e a quarta em 2008. Em 2013,
o PMI lanou a 5 edio do manual, com a criao de uma nova rea de conhecimento: Partes Interes-
sadas. Atualmente o PMBOK est disponvel em 10 idiomas: alemo, rabe, chins, coreano, espanhol,
francs, italiano, japons, portugus e russo.
Empresas no mundo todo vm adotando os processos e as reas de conhecimento do PMBOK para
garantir uma consistncia nas formas de gerenciar seus projetos, principalmente quando se trata de
empresas grandes ou multinacionais com operaes em vrios pases.
O guia est organizado por reas de conhecimento (ver Tabela1.3) e processos de gerenciamento de
projetos (ver Tabela1.4). Cada rea de conhecimento se refere a um aspecto a ser considerado e tratado
pela gerncia de projetos.
Tabela 1.3 reas de Conhecimento do PMBOK

rea de Conhecimento Descrio
Integrao Permite que os diversos elementos do projeto sejam coordenados de forma eficiente euniforme.
Escopo Assegura que o trabalho necessrio, e apenas o necessrio, 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 concludo dentro do oramento aprovado.
Qualidade Garante que o projeto satisfaa necessidades ou requisitos para os quais foi idealizado.
Recursos Humanos Torna a utilizao dos recursos humanos mais eficiente durante a realizao do projeto. Define
os papis e as responsabilidades quem vai fazer o que no projeto.
Comunicaes Registra e administra a coleta, a disseminao e o armazenamento das informaes do projeto.
Riscos Identifica, analisa e responde aos riscos do projeto.
Aquisies Obtm bens e servios externos ou terceirizados, bem como cuida da administrao de
fornecedores, provedores, licitaes e contratos.
Partes Interessadas1 Prev uma identificao e um registro abrangentes das partes interessadas. Prev, tambm, o
gerenciamento e o monitoramento das inter-relaes das partes interessadas de forma a garantir o
nvel de envolvimento ou engajamento adequado de cada uma em diferentes pontos do projeto.
1
A rea de conhecimento Partes Interessadas foi introduzida no incio de 2013, na 5 edio do PMBOK.
Tabela 1.4 Processos do PMBOK

Processo Descrio
Iniciao Processo que trata principalmente da obteno da autorizao do projeto
ou, em um projeto com vrias fases, de uma fase do projeto. o processo
necessrio para a documentao das necessidades de negcios relacionados
aoprojeto.
Planejamento Processo que permite a coleta de informaes de muitas fontes para desenvolver
os planos de gerenciamento para cada rea de conhecimento do projeto.
Execuo Processo em que o trabalho definido no plano de gerenciamento do projeto
realizado.
Monitoramento e Controle Processo que observa a execuo do projeto para resolver problemas medida
que ocorrerem, alinhando tambm a execuo ao planejamento e controlando-o
para que apenas mudanas aprovadas sejam implantadas.
Encerramento Nesse processo, as atividades do projeto so formalmente encerradas.
O PMI oferece uma certificao chamada Project Management Professional (PMP), concedida
a quem consegue demonstrar, avaliado por uma prova, a experincia efetiva em gerenciamento de
projetos, com pleno conhecimento dos conceitos e das abordagens de projetos descritos no PMBOK.
A primeira certificao PMP foi estabelecida em 1984.
Alm da certificao PMP, os padres PMI de gerenciamento de projetos incluem os PMOs ou
Project Management Offices, escritrios de gerenciamento de projetos que so basicamente locais
fsicos dentro das empresas onde profissionais especializados e credenciados nos processos do PMBOK
orientam e do suporte a outros gerentes, equipes e partes interessadas dos projetos. Um PMO funciona
como um centro de operaes e informaes para acompanhamento do projeto e da resoluo 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 documentao etc., ou arcando coma
responsabilidade pelos resultados do projeto.
H vrios centros de informao do PMI em cidades de todo o mundo. Chamados de captulos
(do ingls chapters), esses centros fornecem informaes sobre certificaes e eventos. No Brasil,
h 13captulos nos seguintes estados: Amazonas, Bahia, Cear, Distrito Federal, Esprito Santo,
Gois, Minas Gerais, Paran, Pernambuco, Rio de Janeiro, Rio Grande do Sul, Santa Catarina e
So Paulo.
O site do PMI no Brasil http://www.pmi.org.br. Nesse endereo eletrnico podero ser encon-
tradas informaes sobre sites regionais, cursos, eventos e materiais relativos a gerenciamento de
projetos.
1.4 Sculo XXI

No Brasil e no mundo, o PMI se tornou o padro em gerenciamento de projetos. Cursos de graduao
e ps-graduao incluram programas especficos para gerenciamento de projetos cujos mdulos se
baseiam nos conceitos do PMBOK.
Vagas para contrataes no setor de engenharia (todas as reas), tecnologia da informao, suporte
tcnico e outras, geralmente incluem exigncias de conhecimentos ou certificaes em gerenciamento
de projetos. Mesmo quando o cargo de gerente de projetos no o pretendido, as empresas esperam que
os colaboradores conheam a forma de trabalhar voltada para projetos, a qual segue uma metodologia
consistente de trabalho.
Independentemente do cargo ou da posio na empresa, o profissional impreterivelmen-
te atuar ou como gerente, coordenador ou lder de projetos, ou como membro da equipe de um
projeto.
Exerccios
1. Dentre todas as grandes obras citadas neste captulo, qual delas voc consideraria o maior desafio
se fosse o gerente de projetos? Justifique sua resposta.
2. Qual a diferena entre as prticas de gerenciamento de projetos de 2 mil anos atrs e as atuais?
3. Que participao teve a NASA na histria 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
Comeando 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 especfica degerenciamento
de projetos segundo o PMBOK.
Antes de mais nada, importante entender determinados termos-chave1 que fazem parte das descries de
atividades e documentos envolvidos no gerenciamento de qualquer projeto. Aps entender esses termos-chave,
o gerente de projetos estar pronto para dar incio a um projeto, conforme os processos eprocedimentos
explicados a seguir.
CAPTULO 2 Princpios Bsicos em Gerenciamento de Projetos......................................................17

CAPTULO 3 Nascimento de um Projeto............................................................................................25
1
O original em ingls de alguns termos ficar entre parnteses, pois muitos iniciantes trabalham em empresas globais (ou que
prestam servios para empresas globais) nas quais se utilizam alguns dos termos em ingls e outros em portugus.
2
Princpios Bsicos em Gerenciamento
de Projetos
Entender conceitos importantes relacionados ao gerenciamento de projetos.
Conhecer a aplicao dos conceitos do gerenciamento de projetos por meio de exemplos prticos.
Utilizar esse embasamento conceitual como preparao ao entendimento dos prximos captulos.
2.1Introduo
Este captulo ir explicar os conceitos que sero repetidamente utilizados nas descries e prticas
de cada rea de gerenciamento de projeto. O objetivo que isso sirva como uma referncia desses
conceitos para facilitar o entendimento do contedo descrito e aplicado no decorrer dos vrios captulos
que formam este livro.
2.1.1Projeto
Projeto um esforo temporrio (com comeo, meio e fim) empreendido para criar um resultado
exclusivo. Projetos existem em todos os nveis organizacionais e devem ser gerenciados de uma forma
consistente e eficiente, independentemente do seu tamanho. Os princpios contidos no PMBOK (que
sero discutidos e demonstrados no decorrer deste livro) pressupem projetos complexos e de grande
porte, como o desenvolvimento de um novo produto ou servio, o desenvolvimento de um novo modelo
de veculo, a construo de um prdio ou uma casa, uma campanha publicitria ou de marketing, uma
campanha de vacinao ou a realizao de um concurso nacional.
Nas mesmas empresas que desenvolvem esses projetos de grande porte poder haver projetos de
pequeno porte, que devero ser gerenciados seguindo princpios similares para que toda a organizao
de projetos da empresa trabalhe de forma consistente.
So exemplos de projetos de pequeno porte: o desenvolvimento de um programa de treinamento,
a criao de um website, o desenvolvimento de uma nova estratgia de vendas ou a elaborao de um
sistema de avaliao da qualidade dos servios prestados aos clientes de um restaurante.
2.1.2Cliente
H dois tipos de clientes de projetos: interno e externo. Cliente interno um representante de
uma diviso, departamento ou unidade internos organizao que est realizando o projeto. Esse
cliente ser o receptor de produtos, resultados ou servios oriundos de um projeto. Cliente externo
uma pessoa ou organizao externa que compra os produtos, resultados ou servios oriundos de
um projeto.
A diferena bsica entre os dois tipos de clientes que os clientes internos so pessoas conectadas
com a empresa, enquanto os clientes externos no fazem parte da organizao que est realizando
oprojeto. As necessidades e os requisitos de ambos os tipos de clientes devem ser satisfeitos para
que oprojeto tenha sucesso.
2.1.3Objetivo
Objetivo o porqu ou a razo de se fazer um projeto. No uma lista das atividades ou tarefas de
um projeto; uma explicao do motivo de se fazer o projeto em vista das necessidades da organizao.
17
Os objetivos so fundamentais para comunicar claramente as expectativas de resultados, planejar

estratgias, medir o desempenho e conseguir o resultado desejado. Hoje em dia, as empresas ou
organizaes no podem desperdiar tempo e dinheiro com projetos que no lhe tragam benefcios
mensurveis ou que no lhe agreguem valor.
Um objetivo deve ser SMART, que em ingls significa inteligente ou esperto. SMART um acrnimo
para:
S (Specific) o objetivo deve ser especfico na definio clara e inequvoca do resultado desejado.
M (Measurable) o objetivo deve ser mensurvel, ou seja, medido e avaliado com nmeros.
A (Achievable) o objetivo deve ser alcanvel, ou seja, deve estar dentro da realidade da empresa
ou da organizao.
R (Relevant) o objetivo deve ser relevante, alinhado com a viso da empresa da ou organizao,
pois deve estar de acordo com seus objetivos estratgicos.
T (Time-Framed) o objetivo deve estar dentro de um limite de tempo ou prazo especfico, deforma
a permitir que os resultados sejam verificados e confirmados.
Exemplo: O objetivo de investir na produo e lanamento de um determinado novo produto
aumentar as vendas da empresa na regio Sudeste em 20%, dentro do segmento de produtos infantis,
em um prazo de um ano aps o lanamento da primeira linha.
2.1.4Escopo
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 iniciao,
h informaes 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 excluses especficas) so estipulados em um
documento chamado Declarao de Escopo.
Aps esses limites serem aprovados pelas partes interessadas, o escopo detalhado, considerando-se
fases, subprojetos, entregas e pacotes de trabalho na Estrutura Analtica do Projeto (EAP). O Dicionrio
da EAP descreve os pacotes de trabalho e fecha o ciclo de definio no escopo do projeto. O escopo
dever ser monitorado durante a execuo do projeto para que no saia da linha de base (veja neste
captulo, mais adiante, a definio de linha de base).
H tambm o escopo do produto, que no 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 caractersticas, recursos, especificaes, funcionalidades e requisitos que devero estar in-
corporados no resultado, produto ou servio 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 operaes 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, so criados os itens no escopo do projeto:
Escopo do projeto: O escopo do projeto contempla a concepo, o desenvolvimento, os testes, opiloto
em um departamento da empresa e a homologao de uma verso 2.5 do software X.
2.1.5 Estrutura Organizacional

A funo do gerente do projeto varia de acordo com a estrutura organizacional em que os projetos
so realizados. A estrutura organizacional define o nvel de autoridade e autonomia que o gerente de
projetos ter para administrar os recursos do seu projeto. H trs estruturas organizacionais bsicas
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 adquam, em grande parte, natureza do produto do
projeto. ATabela2.1 resume cada estrutura, com as respectivas vantagens e desvantagens.
Captulo 2 Princpios Bsicos em Gerenciamento de Projetos 19
Tabela 2.1 Resumo das Diferentes Estruturas Organizacionais, com Suas Vantagens e Desvantagens
Estrutura Definio 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 organizaes em que as execuo de processos e projetos, porm o
funcionais da empresa, como diferentes sees esto gerente funcional centraliza a tomada de deciso.
vendas, suporte tcnico, geograficamente prximas 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 informao. pequeno nmero de bens e/ou
servios.
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
decises 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 aps a concluso
projeto. No h departamentos controle completo, e todos do projeto em uma estrutura projetizada, h a
ou reas funcionais. Os os membros da equipe se ausncia de metas de longo prazo ou garantia
membros da equipe so reportam diretamente a ele. H de emprego aos colaboradores, que se sentem,
permanentes ou contratados uma melhor comunicao, pois tambm, sem teto, ou seja, quando o projeto
como recursos temporrios todos esto trabalhando com acaba, eles no tm para onde ir, pois no
para trabalharem no projeto dedicao exclusiva ao projeto pertencem a reas funcionais. Se no houver
em perodo integral at sua e se reportam a apenas uma novos projetos, eles perdem o emprego.
concluso. 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 utilizao eficiente das partes, esse tipo de estrutura pode levar a
projetizada. Cada membro dos recursos. Quando h problemas se no for bem administrado. Uma
da equipe tem dois chefes: o projetos compatveis com as boa comunicao 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, so chamados para participar; gerente do projeto no se relacionarem bem, os
o poder estar mais com o do contrrio, continuam seus membros da equipe podero ficar no meio de
gerente de projeto. Se a matriz trabalhos nas respectivas reas conflitos, causando confuso e retrabalho. H
for fraca, o poder estar mais funcionais. tambm um problema de saber qual a prioridade
com o gerente funcional. se o projeto ou se o trabalho funcional e
quem resolve a situao 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 trs 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 concludo pelo projeto. Entregas (ou deliverables) no inclusas
na linha de base do escopo no sero realizadas.
Portanto, a linha de base do escopo inclui:
Declarao de Escopo aprovada pelas partes interessadas;
Estrutura Analtica do Projeto;
Dicionrio 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 necessrio para
produzir as entregas definidas para o projeto. Atividades que no contribuem especificamente para as en-
tregas definidas no escopo do projeto no podem fazer parte do seu cronograma e, portanto, no podem
ser executadas.
Embora a linha de base de custos esteja normalmente associada ao valor do oramento final do
projeto, Mulcahy (2009) e a nova verso do PMBOK (5 Edio) esclarecem que essa linha de base , na
verdade, formada pelo valor do oramento total do projeto menos as reservas gerenciais (consulte o
captulo7, Custos). Dessa forma, a linha de base de custos inclui os custos relativos a todas as atividades
do projeto mais as reservas de contingncia (custos conhecidos) associadas aos riscos, porm sem as
reservas gerenciais (custos desconhecidos).
H tambm a linha de base da qualidade, vinculada a padres especficos de qualidade para deter-
minados projetos, como os padres de Total Quality Management TQM ou o ISO 9000.
2.1.7 Premissa ou Suposio (Assumption)

Premissa aquilo tido como certo no projeto. Normalmente, as premissas so itens que o gerente
deprojetos d como certo e acordado para dar incio ao projeto.
Nesse caso, o gerente do projeto manifesta suas premissas s partes interessadas do projeto para
obter uma validao s suas suposies iniciais ou uma modificao nas suposies que forem falsas.
Suposies ou premissas podem mudar durante o projeto e precisam ser monitoradas, pois podem
representar um risco sua consecuo.
Exemplos de premissas:
Os recursos que iro trabalhar no projeto so: a, b, c e d.
A equipe de projeto ser a mesma at o trmino do projeto.
O oramento do projeto j foi aprovado.
O projeto contar com o apoio da diretoria do departamento at a sua concluso.
2.1.8 Parte Interessada (Stakeholders ou os Envolvidos no Projeto)

Partes interessadas so todas as pessoas ou organizaes que possuem um envolvimento direto ou
indireto no projeto e que podem afet-lo positivamente ou negativamente. O PMBOK utiliza a traduo
partes interessadas, porm em organizaes que trabalham com projetos comum manter o termo em
ingls: stakeholders.
Exemplos de partes interessadas ou stakeholders de um projeto:
Cliente: a pessoa ou organizao que ir utilizar o produto do projeto.
Organizao executora: a empresa cujos funcionrios esto diretamente envolvidos na execuo
do trabalho do projeto.
Membros da equipe do projeto: a equipe que est executando o projeto.
Outros: proprietrios e provedores de fundos, fornecedores e contratados, membros da equipe e seus
familiares, agncias governamentais e meios de comunicao e cidados comuns, alm dasociedade
em geral.
2.1.9 Patrocinador (Sponsor)

Pessoa, grupo ou organizao que fornece os recursos financeiros para a execuo de um projeto.
So exemplos de patrocinadores:
Diretor financeiro.
Banco ou qualquer agente financiador.
Dono da empresa.
2.1.10 Entregas (Deliverables ou Entregveis)

Qualquer documento, produto ou resultado tangveis e verificveis produzidos para terminar um
processo, fase ou projeto.
So exemplos de entregas:
Plano do projeto
Cronograma
Programa (software)
Prottipo
Piloto
Apostila
2.1.11 Pacotes de Trabalho (Work Packages)

So as unidades de trabalho que sero necessrias para compor a entrega. So os ltimos itens na
hierarquia da Estrutura Analtica do Projeto.
Por exemplo a (Figura2.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 so melhor descritas utilizando-se verbos de ao. As atividades fazem
parte do gerenciamento de tempo de um projeto e so detalhadas no cronograma. So exemplos de
atividades para os pacotes de trabalho do item anterior (Figura2.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 tambm recursos fsicos, como
equipamentos ou materiais, e recursos financeiros, como fundos ou oramento.
Exemplos:
Engenheiro de software
Assistente financeiro
Gerente do produto
Analistas
Programadores
FIGURA 2.2 Exemplo de atividades.
2.1.14 Restrio (Constraint)

Restrio todo e qualquer fator limitante execuo do projeto. basicamente um estado, qualidade
ou sentido que impe restrio a uma determinada ao ou inatividade; algo que afetar o desempe-
nho do projeto ou de um processo. Normalmente, as restries crticas do projeto refletem os fatores
da restrio tripla.
Exemplos:
O oramento desse projeto no dever ultrapassar R$ 500.000,00.
Este projeto dever estar encerrado at o final do segundo bimestre deste ano, no sendo permitida,
em hiptese alguma, prorrogao desse prazo.
2.1.15 Restrio Tripla (Triple Constraint)

A restrio tripla (conhecida tambm como triple constraint) descreve o equilbrio entre o escopo,
ocusto e o tempo de um projeto.
A qualidade foi adicionada depois da criao desse tringulo, subentendendo-se que se encaixa
dentro do escopo. Em todo o projeto, importante que o trmino 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 especificaes mnimas (qualidade) para serem teis organizao (Figura2.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 esto solicitando mudanas. Se a
solicitao de mudana incorrer em aumento do escopo, ento pelo menos um dos outros vrtices do
tringulo tambm sofrer mudanas. Por exemplo, se for solicitado que se aumente o escopo da localiz
o de um software para incluir um novo idioma, ser necessrio gastar mais dinheiro para alocar mais
recursos ou gastar mais tempo para terminar o projeto com mais trabalho. Dessa forma, a mudana
em uma das restries forar a mudana de pelo menos uma ou mais das outras restries. Uma das
FIGURA 2.3 Elementos da restrio tripla.
responsabilidades mais importantes do gerente de projetos determinar o impacto que cada mudana
solicitada pelas partes interessadas ter no tringulo e, consequentemente, no projeto (isso ser dis-
cutido com mais detalhes no captulo4 Integrao).
2.1.16 Requisitos (Requirements)

H dois tipos de requisitos: do produto e do projeto. Requisito do produto uma condio ou
capacidade que deve ser obedecida por um sistema, produto, servio, resultado ou componente para
satisfazer um contrato, um padro, uma especificao ou outros documentos formais. A seguir, um
exemplo de requisitos relativos a um produto:
O produto dever ser testado de acordo com os padres ACDE-830 de 30 de janeiro de 2011.
O software dever gerar relatrios financeiros de hora em hora.
As cores que devero ser produzidas para esse produto so verde, amarela e azul.
O dimetro da pea principal no poder ultrapassar 60 centmetros.
O sistema X dever funcionar nas configuraes 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 especfica, detalhada, quantificada (sempre que pos-
svel) e formalmente documentada com relao ao gerenciamento do projeto. A seguir, exemplos de
requisitos do projeto:
O gerente funcional da rea tcnica 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 ms de
antecedncia do incio 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 exign-
ciasou necessidades com relao ao produto do projeto durante a execuo, acarretando atrasos e
estouros de oramentos. Isso ser explicado com mais detalhes no captulo5 Escopo.
Exerccios
1. Faa a correspondncia do conceito com o respectivo significado.
a. Objetivo ( ) Fornece os recursos financeiros ao projeto.

b. Entrega ( ) So as tarefas que os recursos do projeto devero executar.
c. Pacote de trabalho ( ) So os produtos ou resultados do projeto.
d. Projeto ( ) Deve ser especfico, mensurvel, relevante, realizvel e estar em conformidade a um
prazo determinado.
e. Atividades ( ) So itens de trabalho que compem as entregas.
f. Patrocinador ( ) um esforo temporrio com comeo, meio e fim.
2. Para os exemplos seguintes, indique o conceito ao qual se referem as frases:

a. A data de concluso do projeto no 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 realizao desse projeto, o gerente do projeto poder contar com o suporte da alta
direo da empresa at a concluso do projeto.
Conceito: ____________________________________________________________________________
d. O projeto contempla concepo, desenvolvimento, prottipo e testes do software MRC.
Conceito: ____________________________________________________________________________
e. O projeto no contempla a produo em massa do software MRC.
Conceito: ____________________________________________________________________________
f. Faro parte e participaro das reunies do projeto as seguintes pessoas: gerente de produo,
gerente de marketing, assistente financeiro e supervisor da manuteno.
Conceito: ____________________________________________________________________________
g. Realizaro 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 decises 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 trabalharo no projeto.
Conceito: ____________________________________________________________________________
3
Nascimento de um Projeto
Entender a origem dos projetos em empresas e organizaes.
Coletar informaes necessrias para obter a autorizao para iniciar um novo projeto.
Desenvolver a documentao necessria para iniciar um projeto o Termo de Abertura.
3.1Pr-projeto
Conceito
Antes de falar sobre o incio de um projeto, importante entender qual a sua origem. H uma
fase anterior ao incio do projeto chamada pr-projeto. Nessa fase, h um estudo ou uma avaliao
de ideias que so transformadas em propostas de projeto. Normalmente, uma proposta para a
realizao de um projeto pode ser criada em atendimento a um ou mais dos itens (seguidos de
exemplos) a seguir:
Necessidades do negcio: o projeto ir atender a uma demanda do mercado, necessidades especficas
de algum cliente, avanos tecnolgicos, requisitos legais ou novas regulamentaes governamentais.
Alinhamento com as estratgias da empresa: o projeto necessrio para atingir alguma meta
estratgica da empresa, pela qual ela deseja se tornar lder em um determinado segmento demercado
ou simplesmente se manter competitiva.
Necessidades organizacionais: o projeto necessrio para implantar uma melhoria dos sistemas
internos ou ser a soluo de um problema que est afetando a produtividade da empresa.
Na prtica
O tipo de documentao elaborado nas propostas de pr-projeto ir variar, dependendo da empresa

ou organizao e do tipo de produto ou servio com que trabalha. Por exemplo, para um projeto in-
terno, a fase de pr-projeto pode ser constituda por um estudo de viabilidade no qual o departamento
solicitante indica o que ser necessrio no projeto para que se alcance uma melhoria interna que trar
benefcios empresa. Estudos de viabilidade tambm so teis para analisar a possibilidade de lanar
um novo produto no mercado. Outra forma de escolher projetos so as anlises estratgicas do mercado,
acompanhadas de estudos de viabilidade financeira para o produto do projeto no mercado desejado.
Exemplos dessas anlises na fase de pr-projeto encontram-se no Apndice A e na pasta de contedos
extras, na pgina web do livro (www.elsevier.com.br/martacamargo).
Os projetos tambm podem ser mais simples, como um projeto de implantao de prticas 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 seo Aplicao de cada
captulo.
Aplicao
A rede de supermercados A atende a clientes da classe B e C em uma cidade do interior do estado de So

Paulo. A rede possui sete lojas na cidade e tem tambm participao em outros supermercados pequenos
com outras bandeiras em cidades da regio. O primeiro supermercado comeou a funcionar naquela cidade
em 1984, como uma pequena mercearia. Estima-se que agora a rede esteja atendendo a um tero da popu-
lao da cidade cerca de 50 mil pessoas. Em 2010, a rede contava com aproximadamente 300 funcionrios.
A ascenso da classe C no Brasil trouxe novas exigncias desse mercado consumidor, tambm
preocupado em manter uma atitude sustentvel em relao ao meio ambiente; essa necessidade vem
ao encontro da tendncia nas redes de supermercado em adotar prticas de sustentabilidade (por
exemplo, estaes de reciclagem de lixo, no utilizao de sacolas plsticas, reutilizao de caixas de
papelo 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 prticas de sustentabilidade a uma das lojas
para, depois, implantar em todas as lojas da rede. Para obter aprovao do dono da rede (sr. Jos S.),
esse gerente elaborou a proposta exibida na Figura3.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 iniciao do projeto, conforme explicado a seguir.
FIGURA 3.1 Exemplo de pr-projeto.

Captulo 3 Nascimento de um Projeto 27
FIGURA 3.1 (cont.)
3.2Iniciao
Conceito
A fase de iniciao de um projeto se caracteriza pela sua abertura e faz parte da rea de conhecimento
de integrao.
A iniciao comea a partir do momento em que o projeto selecionado pela empresa por conta de
alguma necessidade (interna, estratgica ou de mercado). Seja qual for a necessidade da empresa que
culminou na aprovao do projeto, deve haver um plano de negcios (motivao focada no negcio
da empresa ou organizao) que justifique o investimento no projeto e deixe claro quais os benefcios
para a empresa e seus clientes, sejam eles internos ou externos.
A iniciao se caracteriza basicamente pela criao de um documento chamado Termo de Abertura
ou Project Charter. Esse documento de extrema importncia, pois autoriza formalmente o incio dos
trabalhos em um determinado projeto.
O Termo de Abertura registra, tambm, as primeiras informaes 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 no tem fundos dis-
ponveis para o projeto, e sem dinheiro especificamente alocado nenhum projeto tem condies de
ser concludo ou sequer existir.
Um resumo das atividades da iniciao e seus documentos, conforme exemplos neste captulo, pode
ser visto na Tabela3.1.
Tabela 3.1 Atividades da Iniciao

rea Atividades Documentos
Iniciao Selecionar o gerente do projeto Termo de Abertura
Determinar a autoridade do gerente do projeto
Identificar as principais partes interessadas
Determinar objetivos mensurveis
Obter aprovao do patrocinador (sponsor)
Alm das atividades especficas listadas anteriormente, o gerente do projeto coleta informaes his-
tricas de projetos anteriores que podero auxili-lo como referncia nas decises do projeto. Mesmo
quando a empresa no possui uma metodologia padronizada para a documentao e o arquivamento dos
projetos, sempre h histricos de projetos em documentos diversos, como oramentos, e-mails, relatrios
de conformidade etc. Esse material referente a projetos anteriores pode conter informaes 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 informaes conforme as neces-
sidades ou os padres da empresa. A Figura3.2 apresenta um modelo genrico de um Termo de Abertura,
com uma explicao do tipo de informao necessria em cada campo.
FIGURA 3.2 Modelo genrico de um Termo de Abertura.

Na prtica
O PMBOK sugere que o Termo de Abertura seja criado por uma organizao externa quela
dogerente do projeto, ou seja, nas empresas que possuem um escritrio de projetos ou algum outro
departamento responsvel pela avaliao de projetos candidatos ou qualquer outra anlise na fasede
pr-projeto.
Em muitas empresas que no contam com um departamento voltado para essa finalidade, o prprio
gerente do projeto quem levanta as primeiras informaes para a elaborao de um Termo de Abertura
e para trabalhar com o patrocinador, a fim de confirmar essas informaes preliminares e obter uma apro-
vao formal, confirmando ainda que a empresa disponibilizar fundos para a realizao desse projeto.
recomendvel, inclusive, que o Termo de Abertura seja impresso e uma assinatura desse pa-
trocinador seja obtida para uma validao total da autorizao do projeto, conforme informaes
preliminares constantes desse Termo. A Figura3.3 apresenta um exemplo preenchido de Termo de
Abertura, conforme veremos a seguir.
FIGURA 3.3 Exemplo de Termo de Abertura preenchido soluo para gesto do Imposto sobre Servios (ISS).
FIGURA 3.3 (Cont.)
Aplicao
Alm da elaborao e da aprovao do Termo de Abertura, para o projeto de implantao de prticas

de sustentabilidade rede de supermercados A, o gerente do projeto, em conjunto com o dono da rede,
decidiu padronizar os formulrios de documentao de projeto, conforme aqueles que sero utilizados
em todas as sees Aplicao deste livro, de acordo com a Figura3.4 a seguir
FIGURA 3.4 Termo de Abertura do projeto sustentabilidade para a rede de supermercados A.

FIGURA 3.4 (Cont.)
Importante
No aconselhvel detalhar o Termo de Abertura com descries de entregas ou atividades

especficas ou estimativas de custo detalhadas. Esse documento apenas uma autorizao para
realizar o projeto, e de preferncia, por um patrocinador que no faz parte do escritrio de projetos.
Durante o planejamento do projeto, muitos itens que podem ser considerados como certos no incio
do projeto podem se tornar inviveis. Portanto, no se pode engessar o projeto no Termo de Aber-
tura estabelecendo entregas, custos ou prazos sem ter certo nvel de confiana de que podero ser
realizados.
Exerccios Iniciao: Termo de Abertura
A partir de agora, voc far um projeto conforme as instrues dadas ao longo dos captulos. Quando
aplicvel, haver uma indicao 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 vrias lojas no centro da cidade e em dois shopping centers na regio. Nos
ltimos seis meses, Carlos observou que houve uma reduo 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 trs de sua loja. Essa loja concorrente est chamando muito a ateno 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 pblico 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 poupana para
melhorias nas lojas, caso houvesse necessidade.
Nesse momento, Carlos parte do pressuposto que ter condies de gerenciar esse projeto, anteci-
pando que esse oramento ser suficiente e que, de fato, o problema de reduo de faturamento est
diretamente relacionado infraestrutura da loja e ao atendimento do pessoal de vendas em comparao
concorrncia 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 rpido possvel. A operao da loja dever continuar normalmente apesar
da reforma, limitando o trabalho do pessoal da obra para o perodo noturno somente. O oramento
de R$ 20.000,00 em custos variveis e diretamente relacionados ao trabalho do projeto no poder ser
ultrapassado, pois Carlos no dispe 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 trs meses aps a inaugurao 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 Exerccios em Contedos extras, na pgina web do livro
(www.elsevier.com.br/martacamargo).
1. Faa o Termo de Abertura contendo as seguintes informaes:

a. Ttulo e descrio do projeto.
b. Gerente do projeto designado e nvel de autoridade no projeto.
c. Motivao 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 informaes
de cada rea de conhecimento em gerenciamento de projetos so 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).
CAPTULO 4 Integrao....................................................................................................................37
CAPTULO 5 Escopo........................................................................................................................... 49
CAPTULO 6 Tempo...........................................................................................................................99
CAPTULO 7 Custos..........................................................................................................................111
CAPTULO 8 Qualidade...................................................................................................................123
CAPTULO 9 Recursos Humanos.....................................................................................................139
CAPTULO 10 Comunicaes.............................................................................................................145
CAPTULO 11 Riscos...........................................................................................................................151
CAPTULO 12 Aquisies...................................................................................................................163
CAPTULO 13 Partes Interessadas.....................................................................................................169
Tabela III.1 Atividades de Planejamento de um Projeto

rea Atividades Documentos
Integrao Apresentar a estratgia para a realizao 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 Documentao de Requisitos
Definir entregas e pacotes de trabalho Estrutura Analtica do Projeto (EAP)
Descrever os pacotes de trabalho e definir critrios Dicionrio da EAP
de aceitao desses pacotes
Tempo Definir atividades Cronograma Planilha
Sequenciar atividades Cronograma Gantt
Estimar durao das atividades Cronograma de Marcos
Alocar recursos s atividades
Custo Estimar custos Estimativa de Custos
Determinar oramento Oramento do projeto
Qualidade Estabelecer procedimentos e ferramentas para gerenciar Fluxogramas
e controlar a qualidade Listas de Verificao ou Checklists
Recursos Humanos Definir necessidades associadas aos recursos humanos Matriz RACI
Atribuir papis e responsabilidades aos recursos
Comunicaes Elaborar um esquema para as comunicaes entre as Esquema das Comunicaes
partes interessadas durante o projeto
Riscos Planejar o gerenciamento dos riscos Anlise Qualitativa de Riscos
Identificar os riscos
Realizar anlise qualitativa dos riscos
Realizar anlise quantitativa dos riscos
Planejar as respostas aos riscos
Aquisies Definir procedimentos para aquisies e contrataes Plano de Gerenciamento das Aquisies
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 nvel de envolvimento de cada parte interessada
em pontos diferentes no projeto
importante observar que as reas de conhecimento do planejamento no ocorrem necessariamente na

sequncia mostrada na tabela anterior.
Normalmente, h uma sequncia intuitiva formada por EscopoTempoCusto e, depois, as outras reas.
Porm, medida que as reas so planejadas, pode ser necessrio voltar e replanejar algum item que j havia
sido definido anteriormente. Alm de ser necessria uma total integrao entre asreas deconhecimento
(conforme explicado a seguir), elas so interativas. Por exemplo: aps 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 alocao 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, aps
toda essa interao e uma total integrao das reas, aslinhas de base estejam slidas e reflitam uma realidade
atingvel, conforme estipulado no objetivo do projeto.
Esse processo basicamente o foco das exigncias de documentao de um projeto, conforme proposta
do PMBOK; por isso, os captulos a seguir abordaro, mais detalhadamente, o planejamento decada rea
de conhecimento de um projeto.
4
Integrao
Integrar as reas de conhecimento de um projeto com um plano de gerenciamento do projeto.
Conceito
Uma das funes principais do gerente de projeto integrar as diferentes reas de conhecimento do
projeto. A integrao consiste na coordenao 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 integrao 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 informaes
sobre todas as reas de conhecimento e estabelecer como essas informaes sero gerenciadas at o
encerramento do projeto.
Outro componente da integrao fundamental ao sucesso de qualquer projeto o gerenciamento
das mudanas, que devem ser controladas e analisadas em relao ao impacto que tero em todas as
reas do projeto, no apenas na rea em que est sendo solicitada. Por exemplo, uma solicitao de
mudana no prazo pode afetar o custo e a qualidade do projeto.
O gerente de projeto deve estabelecer um processo formal para solicitao e aprovao de mudanas,
bem como uma definio dos limites de aprovao. Normalmente, mudanas que no afetam as linhas
de base podem ser avaliadas e aprovadas (ou no) pelo gerente de projeto. Mudanas 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 mudanas solicitadas, em funo do impacto das mudanas nas reas-chave do
projeto (geralmente so as reas escopo, custo, tempo e qualidade).
Na prtica
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 pginas.
Considerando um nvel iniciante em gerenciamento de projetos, o importante documentar os
aspectos bsicos de como o projeto ser gerenciado. Em vez de estabelecer planos separados e com-
plicados considerando tambm que o projeto de um gerente de projetos iniciante ser menos com-
plexoe ter uma durao menor , bem como subplanos separados, o plano de gerenciamento do
projetodescrito neste livro inclur sees que cobriro 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 itlico explica o tipo de informao que deve ser inserido
em cada campo (Figura4.1).
37
FIGURA 4.1 Modelo genrico de Plano de Gerenciamento de Projeto.

Captulo 4 Integrao 39
FIGURA 4.1 (Cont.)

Aplicao
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 prximos captulos, bem como os respectivos anexos (Figura4.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.)

Exerccios
Planejamento: Integrao
1. Qual a funo do gerente de projeto na integrao do projeto?
2. Que tipos de informao devem fazer parte do Plano de Gerenciamento do Projeto e por qu?
3. Por que o gerenciamento de mudanas faz parte da integrao de um projeto?
5
Escopo
Definir e documentar o que ser feito e o que no ser feito em um projeto por meio de uma Declarao
de Escopo.
Descobrir e documentar desejos, necessidades e exigncias das partes interessadas no projeto, com a
documentao de requisitos.
Detalhar o trabalho que ser realizado no projeto mediante o desenvolvimento de Estruturas Analticas
de Projeto (EAP) e de seu respectivo Dicionrio.
Conceito
Escopo o que o projeto se prope a fazer para garantir que todo o trabalho, e somente esse traba-
lho, seja realizado no projeto. O planejamento do escopo de grande importncia ao projeto, pois a
partir dele que as outras reas de conhecimento sero planejadas. O planejamento do escopo envolve
atividades e documentos que sero explicados a seguir (ver Tabela5.1).
O plano de gerenciamento do escopo deve incluir o planejamento das estratgias para gerenciar
o escopo do projeto com informaes sobre formulrios especficos que sero utilizados para regis-
trar as informaes 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 dicionrio.
Tabela 5.1 Atividades e Documentos de Planejamento do Escopo

Atividades para planejar o escopo Documentos gerados
Planejar estratgias para gerenciar o escopo Plano de Gerenciamento do Escopo
Definir limites do escopo Declarao do Escopo
Definir requisitos do projeto Documentao dos Requisitos
Definir entregas principais Estrutura Analtica do Projeto (EAP)
Definir os pacotes de trabalho Dicionrio da EAP
5.1 Declarao de Escopo

No incio da fase de planejamento, importante definir os limites do escopo, ou seja, o que ser in-
cludo ou no no projeto. A Declarao de Escopo do projeto a primeira tentativa de determinar esses
limites do escopo, principalmente o que deve ser feito, em linhas gerais, para alcanar os objetivos do
projeto. A Declarao de Escopo desenvolvida com base em informaes fornecidas pelo patrocinador
e outras partes interessadas de maior influncia no projeto.
A finalidade da Declarao de Escopo garantir que o gerente do projeto e as partes interessadas
tenham um entendimento similar ou opinies semelhantes sobre o escopo do projeto antes do incio
do planejamento, estipulando limites ao escopo do projeto (isto , estabelecendo o que far parte do
escopo e o que no far parte do escopo).
A Declarao de Escopo varia em formato e contedo, e as declaraes mais comuns normalmente
incluem as seguintes informaes (Figura5.1):
49
FIGURA 5.1 Modelo genrico da Declarao de Escopo.

Captulo 5 Escopo 51
Na prtica
O escopo de um projeto definido de forma progressiva, medida que as informaes sobre o pro-
duto do projeto vo aparecendo no processo de planejamento. Esse processo de definio do escopo se
torna mais fcil quando h um histrico de projetos semelhantes na empresa, bastando apenas verificar
o que j foi feito e aproveitar as informaes coletadas anteriormente para o projeto atual. Quando o
projeto indito ou diferente dos que foram realizados anteriormente na empresa, ou em casos em
que no h um histrico para se verificar registros sobre como projetos anteriores foram realizados,
a equipe do projeto tem mais dificuldades para levantar as informaes 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 mudanas posteriores.
A seguir, um exemplo de uma Declarao de Escopo de um projeto, com base no modelo fornecido
anteriormente (Figura5.2).
FIGURA 5.2 Exemplo de Declarao de Escopo.

FIGURA 5.2 (Cont.)

Captulo 5 Escopo 53
FIGURA 5.2 (Cont.)

FIGURA 5.2 (Cont.)
Aplicao
Declarao de Escopo para o projeto de sustentabilidade para a rede de supermercados A loja 1

(Figura5.3).
Captulo 5 Escopo 55
FIGURA 5.3 Declarao de Escopo do projeto de sustentabilidade rede de supermercados A loja 1.

FIGURA 5.3 (Cont.)

Captulo 5 Escopo 57
FIGURA 5.3 (Cont.)
Exerccio
Planejamento Escopo: Declarao de Escopo

Continuao do projeto reforma da loja de roupas femininas
Aps elaborar o Termo de Abertura do projeto, Carlos Peixoto j tem uma ideia geral do que ser
necessrio fazer para concluir o projeto de forma bem-sucedida. Trs grandes componentes de trabalho
devero ser realizados: estrutura da loja, treinamento dos colaboradores e promoo das melhorias. O
oramento reservado para o projeto no 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 organizao interna da loja e de todas as aquisies
de produtos e servios.
Silvio Rocha, o engenheiro responsvel 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 responsvel por todo o marketing e promoo da loja depois
da reforma.
O trabalho comear no dia 1o de maro e dever estar concludo em 30 dias teis no mximo. Carlos
gostaria que os principais eventos do projeto ocorressem da seguinte maneira:
A concluso do planejamento deve se dar at o terceiro dia aps a assinatura do Termo de Abertura.
O mestre de obras dever estar contratado at o quinto dia do projeto.
Todos os novos produtos e servios j devero estar disponveis at o stimo dia do projeto.
A execuo da obra dever estar concluda at o vigsimo quinto dia do projeto.
A verificao do trabalho dever estar concluda at o vigsimo stimo dia do projeto.
O treinamento do pessoal dever estar concludo at o vigsimo nono dia do projeto.
No trigsimo primeiro dia, o projeto dever estar encerrado.
Material de apoio
Baixe o arquivo Declarao de Escopo, da pasta Exerccios em Contedos extras, na pgina web do
livro (www.elsevier.com.br/martacamargo).
1. Elabore a Declarao de Escopo para o projeto da reforma da loja, com as seguintes informaes:
a. Ttulo e descrio do projeto.
b. Patrocinador (sponsor).
c. Gerente do projeto e autoridade.
d. Equipe.
e. Objetivos.
f. Justificativa.
g. Fatores de sucesso.
h. Restries.
i. Premissas.
j. Excluses especficas.
k. Entregas principais (escopo includo).
l. Oramento previsto.
m. Marcos principais (principais acontecimentos do projeto).
n. Critrios de aceitao do projeto.
5.2 Documentao de Requisitos
Conceito
Requisitos so condies ou capacidades que devem ser obedecidas por um sistema, produto,
servio, resultado ou componente para satisfazer um contrato, um padro, uma especificao 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 possvel) e
documentada.
A criao de trs documentos est prevista para cobrir as necessidades de uma documentao ade-
quada dos requisitos e o posterior rastreamento da incorporao dos requisitos aprovados no projeto.
Cada um desses documentos explicado a seguir.
Captulo 5 Escopo 59
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 sero gerenciados durante todo o projeto, considerando:
1. Mtodos de levantamento e coleta dos requisitos.
2. Definio das categorias que sero estabelecidas para os requisitos.
3. Esquema de priorizao das categorais de requisitos.
4. Procedimento para rastrear a incluso dos requisitos aprovados no projeto.
5. Procedimento para mudanas nos requisitos.
6. Verificao do cumprimento dos requisitos.
5.2.2 Documentao de Requisitos

Um formato bsico e genrico para o incio da documentao dos requisitos uma tabela com o
nome da parte interessada que est solicitando o requisito, uma descrio detalhada do requisito, a
categoria ou o tipo de requisito e uma classificao da prioridade desse requisito, conforme ilustrado
no Figura5.4 a seguir.
FIGURA 5.4 Incio do Documento de Requisitos.
Essa tabela de requisitos se transforma em uma matriz de rastreabilidade de requisitos quando

se insere informaes de situao ou status do requisito, ou seja, informaes sobre como e em que
momento o requisito foi incorporado no projeto ou se no foi incorporado devido a algum critrio
predefinido de priorizao dos requisitos, conforme ilustrado mais adiante neste captulo.
5.2.3 Matriz de Rastreabilidade de Requisitos

Uma matriz de rastreabilidade de requisitos usada para controlar os vrios atributos de requisitos
ao longo do ciclo de vida do projeto. Essa matriz praticamente a mesma que foi utilizada para os
levantamentos dos requisitos, porm 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 necessrio durante o projeto (Figura5.5).
FIGURA 5.5 Exemplo de Matriz de Rastreabilidade de Requisitos.
Na prtica
Um dos grandes motivos de mudanas depois que um projeto se inicia a incluso, modificao ou
excluso de requisitos. Dessa forma, a habilidade de o gerente conseguir coletar e documentar todos os
requisitos do projeto antes da execuo do mesmo diminui a probabilidade de mudanas, que custam
tempo e dinheiro.
O gerente do projeto deve fazer o possvel para entender as necessidades e as exigncias em relao ao
gerenciamento do projeto e, principalmente, aquelas relacionadas ao produto do projeto. H requisitos
relativos ao gerenciamento do projeto, porm o grande desafio levantar os requisitos que o produto do
projeto dever ter. O que dificulta esse processo de coleta de exigncias e necessidades com relao ao
produto do projeto que muitas partes interessadas no sabem expressar necessidades e exigncias de
suas reas. Por exemplo, em uma entrevista ao gerente financeiro para levantar requisitos para um sis-
tema de controle de oramentos automatizado, esse gerente tender a focar nos aspectos financeiros do
sistema e no na interface do usurio ou aspectos mais tcnicos relacionados tecnologia da informao.
O resultado, como muitos gerentes de projetos da rea de TI podero confirmar, o desenvolvimento de
um sistema que, ao ser testado na rea solicitante, no atende s necessidades das partes interessadas,
gerando uma necessidade de adaptaes e mudanas.
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 exigncias que se transformaro 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 solues ou possibilidades para resolues de problemas. O mapa mental
Captulo 5 Escopo 61
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 implantao de um refeitrio em uma empresa precisa saber quais
as exigncias ou necessidades das principais partes interessadas daquela empresa. Para o gerente do
projeto, necessrio saber logo no incio do planejamento quais as expectativas e necessidades des-
sas partes interessadas em relao s principais reas do projeto, a fim de que o escopo seja definido
e j considere essas necessidades. Se isso no for feito logo no incio do planejamento, o escopo ser
definido de forma incompleta ou incorreta, acarretando necessidades de mudanas no decorrer da
execuo do projeto.
Aps consultar a diretoria da empresa, o gerente do projeto descobre que as principais partes
interessadas que iro contribuir com informaes sobre requisitos para esse projeto so os gerentes
das seguintes reas: Recursos Humanos, Contabilidade, Nutrio, Refeitrio, Jurdico e Tecnologia da
Informao. Com essa informao em mos, o gerente do projeto comea a desenhar o mapa mental e
prepar-lo para entrevistas com as partes interessadas; nessa fase, ele tambm faz o levantamento dos
requisitos, colocando no centro o objetivo central, e representando como ramificaes desse objetivo
central as reas que iro gerar os requisitos (Figura5.6).
FIGURA 5.6 Exemplo do incio de um mapa mental para coleta de requisitos.
Na prxima 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 refeitrio no
pode operar se as seguintes condies no forem cumpridas:
1. Apenas funcionrios designados como gerentes de menu pelo gerente do refeitrio podem criar,
modificar ou deletar menus.
2. Funcionrios temporrios ou prestadores de servios devero pagar as refeies vista e em espcie
apenas no caixa da tesouraria, que fornecer um recibo que dever ser entregue ao gerente do
refeitrio.
3. Apenas funcionrios com carteira registrada podem se cadastrar para obterem desconto do valor
das refeies em folha de pagamento.
Em um mapa mental, essas condies seriam consideradas requisitos, conforme ilustrado a seguir
(Figura5.7):
FIGURA 5.7 Exemplo da coleta de requisitos com um mapa mental.
Assim tambm para as demais reas, conforme ilustrado na Figura5.8.

FIGURA 5.8 Exemplo dos requisitos de partes interessadas coletados com um mapa mental.
Captulo 5 Escopo 63
Ferramentas
Existem softwares livres na internet que auxiliam o gerente do projeto nessa coleta de requisitos
junto s partes interessadas. O mapa mental desta seo Na Prtica, por exemplo, foi feito com uma
ferramenta chamada FreeMind, um software livre cujo download gratuito na internet (requer verso
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 seo Aplicao, a seguir. Como os links para download
dessas ferramentas podem mudar, melhor realizar uma pesquisa rpida na internet para saber onde
essas ferramentas se encontram neste momento.
Dica
Para projetos pequenos ou de mdio porte, o gerente de projetos pode convocar todos para uma
reunio de requisitos. Utilizando um projetor (datashow), ele pode colocar o software em uma tela
branca e comear um processo de levantamento dos requisitos por parte interessada. As necessidades
e exigncias de cada parte interessada seriam colocadas em um mapa mental para fcil visualizao
de todos e para discusso imediata de conflitos ou maior detalhamento de algum requisito. Para ser
considerado, o requisito deve ser especfico e incluir quantificaes ou especificaes. Por exemplo,
no seria aceito o requisito: Opo de prato de baixa caloria, pois vago. Baixa caloria pode significar
coisas diferentes para pessoas diferentes. O requisito certo incluiria um dado especfico, e poderia
ser, nesse caso: uma opo de prato de baixa caloria com um mximo de 500 calorias e um mnimo de
300 calorias.
Importante
importante que o gerente do projeto esclarea 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 vrias vezes durante o planejamento para garantir que todos os
requisitos importantes sejam analisados e includos no projeto, conforme o caso.
Aps esse levantamento preliminar dos requisitos do projeto, o gerente de projeto deve lanar
esses requisitos em uma matriz de rastreamento dos requisitos, conforme exemplo mostrado a seguir
(Figura5.9):
FIGURA 5.9 Exemplo de Documentao de Requisitos aps mapa mental.
Aplicao
Os documentos de requisitos produzidos para o projeto de sustentabilidade rede de supermercados

A loja 1 encontram-se listados a seguir (Figura5.10).
O Plano de Gerenciamento de Escopo encontra-se no Plano de Gerenciamento do Projeto, item 6A.
FIGURA 5.10 Exemplo de Documentao de Requisitos.

Captulo 5 Escopo 65
FIGURA 5.10 (Cont.)

FIGURA 5.10 (Cont.)

Captulo 5 Escopo 67
FIGURA 5.10 (Cont.)
Exerccios
Planejamento Escopo: Documentao dos requisitos

Continuao 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 exigncias) das
partes interessadas do projeto com relao ao produto ou resultado final do projeto. Para isso, Carlos
marca uma reunio 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 Exerccios em

Contedos extras, na pgina 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 possveis exigncias da rea de compras
ou de marketing em relao a um projeto de reforma.
2. No formulrio Matriz de Rastreabilidade de Requisitos, classifique os requisitos conforme as
categorias e as prioridades que constam no fim do formulrio.
5.3 Estrutura Analtica do Projeto (EAP) ou Work Breakdown

Structure (WBS)
Conceito
Estrutura Analtica do Projeto (EAP) uma expresso traduzida do ingls Work Breakdown Structure
(WBS). Todo o trabalho do projeto deve estar representado de alguma forma na EAP e, caso no seja,
no 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 Declarao de Escopo.
A EAP permite que o gerente do projeto produza estimativas de custo, prazo e recursos com
uma viso total do projeto, e pode ter o formato de uma lista itemizada ou de um grfico similar
ao de um organograma. Como o grande valor da EAP est em auxiliar as partes interessadas do
projeto a desenvolver uma viso clara do produto final do projeto e dos componentes que iro
produzi-lo, as partes interessadas preferem que a EAP esteja em formato similar a um organogra-
ma sempre que possvel. Os exemplos deste captulo apresentaro as EAPs apenas em seu formato
grfico.
Em linhas gerais, a EAP decompe o trabalho em partes menores cuja soma totalizar o todo do
projeto. A decomposio se inicia com uma diviso 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 nvel mais baixo na EAP ou seja, o ltimo
nvel que aparece na EAP.
Na prtica
Dois gerentes de projeto em uma mesma empresa, com a mesma experincia e o mesmo conheci-
mento sobre o produto do projeto, podem fazer EAPs diferentes do mesmo projeto, porm perfeitamente
corretas.
Para a empresa que j trabalha com uma metodologia baseada nos princpios do PMBOK,
provvel que haja uma padronizao para a elaborao 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
Captulo 5 Escopo 69
componentes que precisam ser includos, ou ainda componentes ultrapassados que precisam ser
retirados da EAP.
Dica
Muitos iniciantes em gerenciamento de projetos tm dificuldades em produzir EAPs reais para o

projeto que esto gerenciando por no entenderem corretamente o conceito de decomposio do
trabalho em unidades menores. A traduo para o portugus da palavra breakdown, ou seja, o termo
analtica, talvez seja a culpada por certa confuso com relao ao que deve ser feito. Por trs de uma
EAP, no h uma anlise no sentido literal da palavra, mas sim um desmembramento do trabalho em
unidades menores que formaro o todo.
Para ilustrar essa ideia de desmembramento do todo em partes menores, veja a Figura5.11. O projeto
seria representado pelo animal, enquanto que o breakdown ou desmembramento de seus componentes
seriam as partes que compem esse animal.
FIGURA 5.11 Exemplo de breakdown ou desmembramento das partes.
Importante
O propsito da EAP mostrar os componentes do trabalho que precisaro ser feitos de acordo com
o projeto, NO as aes envolvidas nesse trabalho. As aes do projeto so refletidas nas atividades ou
tarefas que fazem parte do gerenciamento de tempo de um projeto, conforme descrito em Planejando
o Tempo.
5.3.1 Nveis de uma EAP

A forma de uma EAP variar muito, dependendo da natureza do projeto. Geralmente, a EAP dividida
nos seguintes nveis:
Nvel 1: O produto final do projeto. Tem apenas um nvel e representa o escopo total do projeto.
Numerado como 1.0 na EAP.
Nvel 2: Esse nvel reflete o breakdown ou a quebra das categorias maiores do trabalho que ser feito
no projeto. Inclui normalmente os componentes bsicos que iro formar o projeto. Numerados
como 1.1, 1.2, 1.3 e assim por diante na EAP, podem ser fases, componentes, localizaes geogrficas,
entregas maiores etc.
Nvel 3: Esse nvel reflete os subcomponentes dos componentes maiores refletidos no nvel 2. Devem
ser especficos e refletir as partes do que est espeficado no nvel 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 nveis acima.
Nvel 4: Esse nvel reflete o trabalho que ser necessrio para compor o que est representado no
nvel 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 so pacotes de trabalho das entregas constantes em um nvel acima.
Normalmente, a EAP vai no mximo at o nvel 4, abrindo-se depois em atividades no cronograma
(Figura5.12).
FIGURA 5.12 Estrutura genrica de uma EAP.

Captulo 5 Escopo 71
5.3.2 Estratgias para Criao de uma EAP

H vrias 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 estratgias mais comuns para sua elaborao so:
1. Top-down (de cima para baixo). Consiste em uma decomposio e hierarquizao do trabalho de
cima para baixo. Geralmente envolve ciclos de vida ou fases predefinidas ou uma elaborao 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 padro, os itens do primeiro nvel da EAP
sero geralmente padronizados, conforme ilustrado a seguir (Figura5.13).
FIGURA 5.13 Exemplo 1 do nvel 2 de uma EAP top-down.
Poderamos considerar o caso de uma empresa organizadora de eventos como outro exemplo
de uma estratgia top-down para a criao de uma EAP. Todo o evento segue o mesmo ritual
de trabalho, com basicamente os mesmos componentes ou categorias de trabalho de nvel 1,
conforme ilustrado a seguir (Figura5.14).
FIGURA 5.14 Exemplo 2 do nvel 2 de uma EAP top-down.
2. Bottom-up (de baixo para cima). Consiste em uma decomposio e hierarquizao do trabalho de
baixo para cima. Geralmente envolve projetos para produtos ou servios nunca antes feitos, com uma
equipe de projeto nova, ou produtos customizados aos requisitos do cliente. Nesse caso, o processo
de elaborao 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 reunio de
brainstorming em que as partes interessadas do projeto so convidadas a participar com ideias do
trabalho que precisa ser desenvolvido no projeto. Esse processo de elaborao de uma EAP gera uma
srie de ideias que so organizadas em uma folha de flipchart. Gradativamente, os itens do nvel 2 vo
aparecendo, e a EAP vai se estruturando.
Considere-se, por exemplo, um projeto que trata da organizao e da realizao de um banquete

em homenagem ao presidente de uma empresa. Ningum na equipe do projeto tem experincia com
esse tipo de evento e isso nunca foi feito na empresa. Um dos colaboradores da empresa foi convidado
para ser o lder 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 reunio de brainstorming e a
criao 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 preferncias individuais.
importante que o lder do projeto atue como facilitador da sesso 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 discusso 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 so escritos em post-its e colocados em uma folha de flipchart afixada a
uma parede. importante que todos vejam os itens aprovados e um possvel escopo sendo formado
gradativamente.
Terceiro passo: Organizao 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 semelhanas
entre os itens. Para isso, todos os itens que forem mveis so agrupados em um ponto, e todos
os itens que se referirem infraestrutura so agrupados em outro ponto, e assim por diante.
Itens redundantes ou muito granulares (que no representam trabalhos ou entregas) so
descartados.
Quarto passo: Definio das entregas e pacotes de trabalho. Aos poucos, o grupo percebe que os
itens do nvel 2da EAP e seus subcomponentes esto sendo formados, e agora possvel dar nomes
aos grupos de itens com a mesma afinidade. Por exemplo, itens relativos s adaptaes ao local
ou equipamento de som e imagem so classificados como pertencentes a um componente maior
chamado Instalaes, que se tornar a entrega principal para esses itens que, por consequncia,
se tornaram pacotes de trabalho dessa entrega na EAP (ou subcomponentes de um componente
maior).
ltimo passo: Apresentao final. Agora, s organizar os resultados em um formato grfico de
uma EAP (com uma numerao hierrquica), conforme a Figura5.15, que mostra a EAP em formato
grfico.
Dica
Para o processo descrito anteriormente, no necessrio cobrir as entregas e pacotes de trabalho do

gerenciamento do projeto, pois j esto padronizadas. Porm, na apresentao final importante que
essa rea seja representada, conforme metodologia de gerenciamento de projetos adotada pela empresa.
Captulo 5 Escopo 73
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 lder 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 (Figura5.16).
FIGURA 5.16 Brainstorming com mapa mental realizado com a ferramenta XMind.
Captulo 5 Escopo 75
Em seguida, o lder do projeto e a equipe eliminariam redundncias ou itens que no refletem itens
de trabalho associados a uma EAP e agrupariam os itens em comum, conforme o exemplo seguinte,
que considera uma das entregas (Figura5.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 no se encaixassem a um nvel de EAP (por exemplo, vinho do Porto ou prato vegetariano
seriam eliminados, bem como itens granulares que no se referem a pacotes de trabalho, como sacos de
lixo), definindo-se os nomes das entregas principais. Os itens so agrupados e renomeados (conforme
o caso) gradativamente pela equipe at que as entregas e os pacotes de trabalho fiquem definidos.
Dica
Aps 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 prpria ferramenta XMind, escolhendo-se, no menu Estrutura, o formato de organograma
(Figura5.18).
FIGURA 5.18 EAP do projeto banquete em homenagem ao presidente de uma empresa feita com o XMind.
Captulo 5 Escopo 77
Importante
Os exemplos da EAP neste livro seguem uma determinada padronizao; assim, na primeira coluna
coloca-se toda a documentao de gerenciamento de projetos, e na ltima coluna consta o processo de
encerramento do projeto. Essa padronizao no obrigatria. A EAP deve incluir entregas ou delivera-
bles referentes documentao do projeto, porm o formato padro contido aqui apenas uma forma
ou uma sugesto de como fazer isso. Fica a critrio do gerente de projeto encontrar a melhor forma
de representar a documentao 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 criao, considerando o tipo de projeto que ser realizado. Nesse
sentido, Haugan (2002) sugere que possvel ter tipos distintos de EAP que seguiriam uma lgica para
a organizao das entregas e dos pacotes de trabalho. A seguir, listamos alguns exemplos de como essa
abordagem para a criao de EAPs poderia ser colocada em prtica. Nesse ponto importante lembrar
novamente que tudo isso apenas uma sugesto. Cada projeto tem suas prprias necessidades e pode,
at mesmo, envolver uma combinao de dois ou mais tipos.
EAP para produtos: geralmente essa EAP organizada de acordo com uma estrutura fsica natural
do produto final que est sendo desenvolvido no projeto, conforme ilustrado a seguir (Figura5.19).
FIGURA 5.19 EAP para um projeto de construo de aeronave. Fonte: Adaptado do Work Breakdown Structure do Department of Defense Handbook,
MIL-HDBK-88, 1998.
Captulo 5 Escopo 79
Em projetos envolvendo produtos, pode-se fazer uma EAP para o escopo total do projeto e criar EAPs
secundrias para cada componente importante e distinto do projeto. Por exemplo, para a EAP anterior,
pode ser que haja um departamento especfico (ou at mesmo uma empresa contratada) para o item
1.5 Dados, que abriria a EAP em itens adicionais, conforme ilustrado a seguir (Figura5.20).
FIGURA 5.20 EAP secundria.
A seguir, outro exemplo de EAP para produto (Figura5.21):

FIGURA 5.21 EAP para um projeto de desenvolvimento de um sistema.
Captulo 5 Escopo 81
EAP para servios: esse tipo de EAP normalmente reflete as entregas estruturadas do projeto. O
trabalho dividido em uma ordem lgica das reas de trabalho envolvidas para produzir o servio. Para
a organizao de um congresso, por exemplo, a EAP teria os seguintes itens (Figura5.22):
FIGURA 5.22 EAP para um projeto de organizao e realizao de um congresso.
Outro exemplo: A empresa da EAP anterior tambm realiza Formaturas, dentro de um formato
padro que permite customizaes, conforme solicitao dos clientes (Figura5.23).
FIGURA 5.23 EAP para um projeto de organizao e realizao de uma formatura.
Captulo 5 Escopo 83
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 tcnicos, 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 (Figura5.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 no
formam um produto propriamente dito, mas normalmente produzem uma srie de produtos que levar
ao resultado desejado. Poderia ser, por exemplo, o caso de um projeto para adequao de uma empresa a
uma legislao especfica ou a um padro uma certificao ISO, conforme ilustrado a seguir (Figura5.25).
EAP mista: esse tipo de EAP tem um pouco de todos os tipos mencionados anteriormente. Envolve
um produto final, mas inclui tambm trabalho relativo a servios e resultados em uma determinada
sequncia que poderia ser um ciclo de vida. O exemplo a seguir ilustra uma possvel EAP para um projeto
de uma construo de um prdio sustentvel (Figura5.26).
FIGURA 5.25 EAP para um projeto de certificao na ISO 27001. Fonte: Baseado na Norma ISO 27001.
Captulo 5 Escopo 85
FIGURA 5.26 EAP para um projeto de construo de um prdio sustentvel.
Dicas
A EAP a definio das entregas e dos pacotes de trabalho do projeto. Deve refletir o que o cliente
final do projeto ir receber quando o projeto for concludo. No uma lista de atividades ou tarefas
necessrias para completar o projeto; isso faz parte do cronograma.
A EAP uma ferramenta til para que todas as partes interessadas tenham uma visualizao
rpida e de fcil entendimento quanto ao escopo total do projeto. No pode ser utilizada como
a nica documentao do projeto ou substituir um cronograma colocando-se datas diretamente
nas entregas ou nos pacotes de trabalho isso no faz sentido. Os recursos que trabalham nos
projetos precisam saber exatamente o que tero que fazer para concluir os pacotes de trabalho
ecomporem as entregas pelas quais so responsveis. Esse fazer refletido por atividades ou
tarefas que reflitam aes especficas que o recurso ou os recursos tero que realizar durante o
projeto.
Depois que a linha de base do escopo for definida, no ser possvel alterar a EAP sem que haja uma
aprovao formal de um grupo de partes interessadas que fazem parte de algum tipo de comit de
controle de mudanas do projeto. Durante o planejamento, o gerente do projeto pode definir uma
data-limite em que mudanas ou adaptaes EAP possam ser feitas antes que a linha de base do
escopo seja congelada.
A EAP no reflete o sequenciamento das entregas no tempo. Embora geralmente a EAP siga uma
lgica que pode ser sequencial aos acontecimentos do projeto, isso no um pr-requisito para sua
elaborao ou aceitao. O sequenciamento do projeto no tempo feito no planejamento do tempo,
refletido no cronograma do projeto, como ser visto na prxima seo deste captulo.
H uma regra geral de que a realizao de um pacote de trabalho no pode ter mais do que
oitenta horas ou menos do que oito horas. Para os iniciantes, essa determinao pode ser difcil
de entender, pois o cronograma ainda no foi realizado para determinar a durao das atividades
que comporo cada pacote de trabalho. De qualquer forma, essa uma regra geral intuitiva
que pode ser considerada, em alguns casos, como uma referncia para saber quando parar no
desmembramento das entregas em pacotes de trabalho.
Captulo 5 Escopo 87
Aplicao
A EAP para o projeto de sustentabilidade para a rede de supermercados A loja 1 ficou assim definida
(Figura5.27):
FIGURA 5.27 Estrutura Analtica do Projeto EAP.

Ferramentas
EAPs em formato grfico podem ser feitas com o recurso Organograma no menu do SmartArt do
MS Word, MS Excel ou MS PowerPoint. H tambm o software WBS ChartPro da empresa Critical
Tools, que custa US$ 199,00 e considerado o mais completo, com recursos avanados de visualizao
e incluso de vrios tipos de informaes na EAP. As EAPs deste captulo foram elaboradas, na sua
maioria, com o WBS Chart Pro.
A ferramenta de download gratuito XMind tambm pode ser utilizada para elaborar EAPs, porm o
programa ainda no numera o produto do projeto (o item 1.0 do produto ou resultado do projeto) e no
segue a numerao hierrquica recomendada (1.0, 1.1, 1.2 etc.). Para projetos simples e pequenos, uma
EAP elaborada no XMind (escolhendo-se a opo Organograma no menu Estrutura e Numerao
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 (Figuras5.28 e5.29).
FIGURA 5.28 Exemplo de EAP com o WBSChart Pro. Fonte: Adaptado (com permisso) de Projetos para Web Planejamento
(www.avellareduarte.com.br).
Captulo 5 Escopo 89
FIGURA 5.29 Exemplo de EAP com o Xmind. Fonte: Adaptado (com permisso) de Projetos para Web Planejamento (www.avellareduarte.com.br).
5.3.4 Dicionrio da Estrutura Analtica do Projeto (EAP)
Conceito
O Dicionrio da EAP uma espcie de glossrio que inclui definies de cada pacote de trabalho da
EAP. Essa descrio importante por vrios 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 tcnico que no 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 orientao para a elaborao das atividades do projeto no cronograma.
Na prtica
O nvel de detalhamento do Dicionrio da EAP depende da complexidade do trabalho e do tipo de

projeto. A seguir, um formato de EAP comumente utilizado (Figura5.30):
FIGURA 5.30 Formulrio para Dicionrio de EAP.

Captulo 5 Escopo 91
Para EAPs de produtos, a descrio do pacote pode incluir uma descrio de um componente fsico,
e no do trabalho propriamente dito para fazer esse componente. Como tudo relacionado a projetos,
depende de cada caso. Para EAPs de servios e resultados, mais comum ter uma descrio do trabalho
propriamente dito, com atividades especficas que devero ser realizadas pelos membros da equipe
para concluir cada pacote.
Importante
Um dicionrio de EAP no pode existir sem um nmero de identificao. Aps realizar uma EAP,
todo o trabalho do projeto dever ser acompanhado de um nmero, conforme aparece na EAP. Sem
esse nmero, o trabalho ser considerado como no aprovado. Apenas o trabalho com um nmero de
identificao da EAP considerado aprovado e ser executado no projeto.
A seguir, um exemplo do dicionrio dos pacotes de trabalho de uma EAP da entrega Convite do
projeto Formatura exemplo mostrado anteriormente (Figura5.31).
FIGURA 5.31 Exemplo de Dicionrio da EAP.

Captulo 5 Escopo 93
Dicas
Dependendo do projeto, o Dicionrio da EAP consumir muitas horas de trabalho do gerente do

projeto e dos membros da sua equipe. Porm, uma vez realizado, o contedo poder ser reaproveitado
para outros projetos que tiverem pacotes de trabalho semelhantes. Isso verdadeiro especialmente
para os componentes do gerenciamento do projeto, que sero padronizados e se repetiro em todos
os projetos.
Se o dicionrio estiver descrevendo componentes tcnicos de um produto, pode ser necessrio
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.
Aplicao
A seguir, o Dicionrio da EAP do projeto de sustentabilidade rede de supermercados A loja 1

(Figura5.32):
FIGURA 5.32 Dicionrio da EAP do projeto de sustentabilidade para a rede de supermercados A loja 1.
Captulo 5 Escopo 95
FIGURA 5.32 (Cont.)

FIGURA 5.32 (Cont.)

Captulo 5 Escopo 97
FIGURA 5.32 (Cont.)
Dicas
A criao de um dicionrio de EAP simples, porm esse processo precisa da colaborao de todas as
reas envolvidas no projeto. O gerente de projeto pode solicitar a colaborao de cada rea na elaborao
do Dicionrio da EAP e tambm explicar aos colaboradores das reas envolvidas no projeto que, ao
colaborarem com a elaborao do Dicionrio da EAP por meio de descries com atividades especficas,
nas quais so especializados, o cronograma elaborado no gerenciamento de tempo, realizado com base
nesse dicionrio, ser mais completo e real para a rea de cada um.
Exerccios
Planejamento Escopo: Estrutura Analtica do Projeto (EAP) e respectivo Dicionrio

Carlos Peixoto est pronto para detalhar o que dever ser feito no projeto. Aps reunio com os
colaboradores e fornecedores, as entregas e os pacotes de trabalho do projeto so definidos como:
1. Gerenciamento do projeto: todos os documentos padro sero produzidos.
2. A obra propriamente dita, que envolver um trabalho de anlise da estrutura atual, definio de
novo layout, definio de mobilirio e acessrios, reforma interna, reforma externa, montagens e
instalaes.
3. O treinamento dado aos colaboradores, que em primeiro lugar deve considerar a definio do
contedo que ser ministrado, e depois a elaborao do material do treinamento, bem como a
preparao do local onde o treinamento ir acontecer.
4. Dever ser realizada tambm uma promoo da iniciativa da loja com o novo visual da estrutura e da
equipe de vendas. Para isso, primeiro ser necessrio haver uma definio do material promocional
que dever ser elaborado, e em seguida uma preparao do material, bem como sua reproduo e
distribuio a clientes atuais e em potencial.
5. Por ltimo, o encerramento, com os componentes padro.
Material de apoio
Baixe os arquivos EAP e Dicionrio da EAP, na pasta Exerccios em Contedos extras, na pgina web
do livro (www.elsevier.com.br/martacamargo).
1. Complete a Estrutura Analtica 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 aparea em formato grfico (estilo organograma), conforme exemplos deste
captulo.
2. Elabore o Dicionrio da EAP para os pacotes de trabalho considerando apenas a entrega Treinamento
dos colaboradores, no formulrio Dicionrio da EAP, incluindo os seguintes itens:
a. Nmero do pacote de trabalho.
b. Nome do pacote de trabalho.
c. Descrio (crie descries com base em aes comuns a esse tipo de trabalho).
d. Critrios de aceitao (crie critrios de aceitao com base em prticas comuns a esse tipo
de projeto).
6
Tempo
Dividir o tempo do projeto em atividades com duraes e recursos especficos por meio da elaborao
de um cronograma para o projeto.
Conceito
O planejamento do tempo de um projeto define o tempo que ser necessrio para realizar o projeto
e alcanar seus objetivos. As atividades e os documentos gerados no planejamento do tempo sero
explicados a seguir (Tabela6.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 duraes para as atividades.
A forma como essas atividades sero desenvolvidas pelo gerente do projeto e equipe deve ser docu-
mentada em um plano de gerenciamento de tempo. Esse plano poder incluir, por exemplo, informaes
sobre as ferramentas que sero utilizadas para desenvolver o cronograma, a maneira como os gerentes
funcionais sero comunicados das necessidades de recursos para o projeto, como os recursos sero
alocados, como as duraes sero calculadas e assim por diante.
6.1Cronograma
O cronograma define as atividades que sero feitas no projeto com base em uma decomposio dos
pacotes de trabalho da EAP. Em primeiro lugar, identificam-se as atividades ou tarefas que devero ser
executados durante o projeto. Depois, h um sequenciamento dessas atividades por meio da identifi-
cao e do estabelecimento de relacionamentos lgicos entre elas (o que precisa vir antes, o que vem
depois etc.). Aps identificar as atividades e sequenci-las, necessrio determinar o tipo e a quantidade
de recursos (pessoas, equipamentos e materiais) necessrios para a realizao do projeto, bem como
estabelecer quando cada recurso dever estar disponvel.
O processo de desenvolvimento do cronograma determina as datas iniciais e finais para a execuo
de cada atividade do projeto, e interativo e contnuo durante todo o projeto.
As duraes das atividades podem ser determinadas de vrias formas:
1. Dados histricos de projetos similares.
2. Opinio especializada de profissionais da rea.
99
3. Estimativas anlogas, que utilizam uma durao de uma atividade anterior semelhante.
4. Estimativas paramtricas, que utilizam uma relao estatstica entre os dados histricos e outras
variveis (por exemplo: metros quadrados em construo, linhas de cdigo no desenvolvimento de
software, horas/funcionrio etc.) para calcular a durao padro para aquela atividade.
5. Estimativas de trs pontos, na qual a durao da atividade pode ser construda usando uma mdia
de trs duraes, conforme a equao a seguir:
(O + 4 M + P )
Dur. Atividade =
6
Observao: O seria o tempo mais otimista, M, o mais provvel, e P, o pessimista.

A estimativa de trs pontos utilizada em casos em que no se tem nenhuma referncia para a
durao de uma atividade. Matematicamente falando, a utilizao da frmula mostrada anteriormente
garante uma maior probabilidade de acerto.
No desenvolvimento do cronograma importante determinar o caminho crtico do projeto. Caminho
crtico 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 crtico. Ele indica quais atividades necessitam de maior
monitoramento (menor folga). A maioria das ferramentas e softwares que fazem cronogramas calcula
o caminho crtico de um projeto automaticamente.
Na prtica
Embora a necessria 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 criao
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 questo de simplesmente abrir os pacotes de trabalho da EAP em atividades, sequenci-las em
uma ordem lgica dentro dos componentes do projeto, designar a durao para cada atividade e os
responsveis pela execuo dessas atividades.
Assim como o gerente do projeto trabalha como um facilitador para a formao da EAP, ele deve
trabalhar com os recursos de cada rea para determinar as atividades, suas duraes e os responsveis
por cada uma. Um projeto dificilmente ter sucesso se o gerente de projeto tomar sozinho a iniciativa
de criar atividades, impor duraes e delegar responsabilidades aos membros da equipe. Por mais que
o gerente de projeto conhea a rea que est gerenciando, sempre recomendvel trabalhar com os
especialistas de cada rea para estipular atividades, duraes e responsveis. importante tambm
envolver o pessoal da linha de frente, principalmente na definio das atividades e suas duraes, pois
so eles que iro executar o trabalho.
As formas de estimar o tempo para executar as atividades variaro dependendo do projeto. Uma
estimativa anloga ser usada quando o projeto for similar a um projeto anterior. Uma estimativa para-
mtrica 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 Dicionrio da EAP um grande auxlio na definio das atividades, pois a descrio de um pacote
de trabalho inclui atividades que precisaro ser executadas. Vejamos o exemplo de um projeto visto
anteriormente (Figura6.1).
Captulo 6 Tempo 101
FIGURA 6.1 Exemplo de descrio de pacote de trabalho.
Com base na descrio do trabalho para o item Design, possvel definir as seguintes atividades:
1. Entrevistar representante da turma.
2. Obter preferncias.
3. Alocar designer.
4. Elaborar design.
5. Submeter diferentes testes de design para aprovao.
6. Aprovar design.
Aps defini-las, o gerente do projeto coloca as atividades em uma sequncia lgica, incluindo suas
duraes, conforme explicado anteriormente. Quando o projeto no tem uma referncia da durao,
o gerente do projeto poder utilizar as estimativas de trs pontos, conforme explicado neste captulo.
Definidas as duraes de todas as atividades, o gerente do projeto monta o cronograma. Para o grupo
de atividades mencionadas, o cronograma seria o seguinte (Figura6.2):
FIGURA 6.2 Exemplo de atividades no cronograma.
Ferramenta
Cronogramas so normalmente feitos com softwares especficos. Os mais comuns so o Microsoft

Project ou MS Project e o software livre OpenProj (download gratuito na internet). A interface do usurio
e a funcionalidade do OpenProj so similares quelas do MS Project.
Dica
O nvel de detalhamento das atividades no cronograma depender do contexto do projeto. Por

exemplo, para uma equipe interna experiente, que j trabalhou inmeras vezes no mesmo tipo de
projeto com atividades semelhantes, no h necessidade de detalhar todo o trabalho passo a passo.
Para componentes do projeto cujas atividades sero 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 interpretao do que deve ser feito, bem como problemas de
percepo do tempo de durao das atividades ou tarefas do projeto.
Importante
A durao das atividades no pode ser calculada sozinha. necessrio considerar a durao em
relao aos recursos que iro fazer a atividade. Por exemplo, uma atividade precisa de 24 horas, porm
o recurso s trabalhar quatro horas por dia nessa atividade; assim, a atividade ou tarefa no precisar
de trs dias (recurso trabalhando o dia todo no projeto), mas de seis (recurso trabalhando em meio
perodo todo dia). necessrio ficar atento forma como a ferramenta de elaborao de cronograma
est configurada. Por exemplo, no MS Project possvel definir duraes em horas, dias, semanas, meses
ou at mesmo minutos. J o OpenProj (software gratuito) s permite em dias.
Aplicao
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 trs formatos no MS Project:
1. Formato planilha, para auxiliar o gerente do projeto no controle do tempo e dos recursos
(Figura6.3).
2. Formato grfico de Gantt, para que os recursos tenham uma visualizao rpida (normalmente no
arquivo eletrnico) dos picos de trabalho e do sequenciamento do projeto como um todo. A seguir
um exemplo de uma das sequncias de atividades do cronograma com apresentao em formato
de grfico de Gantt (Figura6.4).
3. Formato de cronograma de marcos, para que o dono da rede e os gerentes tenham uma visualizao
rpida dos pontos mais importantes do projeto (Figura6.5).
Captulo 6 Tempo 103
FIGURA 6.3 Cronograma do projeto de sustentabilidade rede de supermercados A loja 1 Formato planilha.
(continua)
FIGURA 6.3 (Cont.)

Captulo 6 Tempo 105
FIGURA 6.3 (Cont.)

(continua)
FIGURA 6.3 (Cont.)

Captulo 6 Tempo 107
FIGURA 6.4 Cronograma do projeto de sustentabilidade para a rede de supermercados A loja 1 Formato grfico 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 so apenas visualizaes 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 visualizao do leitor nas pginas
deste livro. Essa tcnica de converso do arquivo do MS Project em planilha do MS Excel til,
tambm, 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 Pgina da web.
b. O assistente para exportao ser iniciado.
c. Escolha Usar mapa existente.
d. Clique em Exportar para HTML usando modelo padro.
e. Clique em todos os botes Avanar e conclua.
f. Encontre o arquivo salvo.
g. Mude a extenso 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, tambm no MS Project, escolhido no menu Projeto, Filtro
para: e Etapas. necessrio configurar os marcos no cronograma para que o filtro possa
gerar essa visualizao (clique duas vezes na atividade, escolha Avanado, selecione Marcar
tarefa como etapa e, depois, coloque zero (0) na coluna Durao da atividade na planilha do
cronograma.
Ferramentas
(H vdeo clipes com demonstraes do abaixo na pasta de contedos extras na pgina do livro na
internet www.elsevier.com.br/martacamargo)
No MS Project, o cabealho com informaes sobre o projeto pode ser inserido no menu Exibir,
em Cabealho; aparecer apenas quando o arquivo for impresso no papel ou estiver em formato
PDF.
No MS Project, possvel modificar a escala do tempo clicando com o boto direito do mouse na
barra de tempo e configurando a visualizao (por ms, semana, hora etc.).
Pode-se tambm configurar as informaes que aparecem nas barras do grfico de Gantt, clicando
com o boto direito do mouse no grfico e escolhendo Assistente do Grfico de Gantt.
No MS Project, para saber o caminho crtico do projeto, basta clicar com o boto direito do mouse no
grfico de Gantt, escolher Assistente de Grfico de Gantt e assinalar Caminho Crtico. O caminho
crtico para o projeto aparecer em vermelho.
O cronograma completo pode ficar disponvel no formato eletrnico, o que permite aumentar o
tamanho do contedo para uma melhor visualizao 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.
Captulo 6 Tempo 109
Importante
Os projetos que comearem direto com um cronograma, sem um Termo de Abertura, Declarao
de Escopo, documentao de requisitos e, principalmente, sem uma EAP e seu respectivo Dicionrio,
estaro condenados ao fracasso. A importncia de se fazer essa documentao antes do crono-
grama no simplesmente uma questo de cumprir um padro 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 participao das partes interessadas no fornecimento de
informaes-chave ao projeto. Sem essa participao e sem essa viso 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 atualizaes e retraba-
lhos. necessrio ter um cronograma real para o gerente do projeto e, principalmente, para quem
ir executar as atividades contidas nele.
Exerccios
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 Exerccios em Contedos extras, na pgina
web do livro (www.elsevier.com.br/martacamargo). Voc poder fazer o exerccio com o MS Excel, MS
Project ou OpenProj. H vdeos demonstrativos para as operaes bsicas com o MS Project e o OpenProj.
1. Aps 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
Dicionrio da EAP contm descries dos pacotes de trabalho que geram atividades. Ateno!
Voc precisar das descries dos pacotes de trabalho do Dicionrio da EAP que elaborou no
captulo anterior para fazer este exerccio.
b. Inclua uma data de incio e uma de fim para cada atividade.
c. Insira a durao de cada atividade.
d. Aloque um recurso (quem ir fazer) para cada atividade.
7
Custos
Definir estratgias e realizar levantamentos de custos dos projetos para a elaborao de oramentos.
Conceito
O planejamento dos custos de um projeto calcula o dinheiro que precisar ser gasto para fazer o
projeto e alcanar os objetivos propostos. O planejamento dos custos envolve as atividades e os docu-
mentos descritos a seguir (Tabela7.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 oramento do projeto Oramento
O plano de gerenciamento de custo ir incluir informaes sobre as estratgias para clculo dos
custos e quais os tipos de custos considerados no oramento do projeto.
7.1 Estimativas de Custos e Oramentos

H vrias formas de elaborar estimativas de custo em projetos. As mais comuns so:
Top-down ou de cima para baixo (com base em projetos anteriores custos mais genricos).
Bottom-up ou de baixo para cima (por componente, pacote de trabalho ou atividade custos mais
detalhados).
Paramtrica, na qual se utiliza a relao estatstica entre os dados histricos e outras variveis
(por exemplo: metros quadrados em construo, linhas de cdigo no desenvolvimento desoftware)
para calcular a estimativa.
Os tipos de custos geralmente considerados nas estimativas de projetos so:
Custos diretos: custos diretamente relacionados ao trabalho especfico do projeto, como custos de
mo de obra contratada especificamente para o projeto, passagens areas da equipe que trabalhar
exclusivamente no projeto ou equipamentos comprados para a realizao do projeto.
Custos indiretos: custos indiretamente relacionados ao trabalho do projeto, por exemplo: despesas
de luz, gua ou Internet.
Custos fixos: custos que no esto conectados diretamente ao projeto, como aluguel do prdio onde
a empresa opera, salrios e benefcios.
Custos variveis: custos que variam conforme o trabalho executado especificamente para oprojeto,
como hora/funcionrio de trabalhadores temporrios contratados para realizar testes emum
componente do projeto ou aluguel mensal de instalaes alocadas especificamente paraaexecuo
de alguma parte do projeto.
111
O oramento considera o custo das atividades e dos recursos que o projeto utilizar, bem como as
reservas de contingncia e as reservas gerenciais.
As reservas de contingncia cobrem os custos dos riscos conhecidos que apareceram na anlise rea-
lizada no planejamento de riscos do projeto. Quanto maior o ndice de risco geral do projeto resultante
na anlise de riscos, maior dever ser essa porcentagem para cobrir contingncias.
As reservas gerenciais referem-se aos custos dos imprevistos. uma reserva alocada para cobrir etapas
que podem dar errado no projeto e que no foram identificadas como riscos pela equipe. Normalmente,
em projetos inditos com variveis 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 contingncia. O oramento total do projeto formado pelos custos da linha de base mais as reservas
gerenciais, conforme ilustrado a seguir (Figura7.1).
FIGURA 7.1 Custos que compem um oramento. Fonte: Adaptado de Mulcahy, R. PMP Exam Prep, p. 238, 2009.
Na prtica
A maneira como os custos sero 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 oramento do projeto. Se o gerente do
projeto receber um valor fixo para o oramento do projeto, o planejamento do escopo e das outras reas de
conhecimento do projeto girar em torno desse valor. O valor servir como a restrio-me de todas as
decises do projeto. Se o projeto no tiver um valor predeterminado, ou se o valor puder ser negociado,
o gerenciamento dos custos do projeto englobar quatro etapas bsicas, conforme veremos a seguir:
Captulo 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 referncia para
saber o limite mximo dos custos que o projeto pode alcanar. O nvel de confiana nessa estimativa
inicial deve ser baixo, e ela no poder ser utilizada como base para decises sobre as atividades ou
sobre o escopo do projeto. Em algumas empresas, esse valor inicial decidido pelo patrocinador do
projeto apenas como referncia para aprovao do projeto.
2a Etapa: Desenvolver um oramento detalhado e com uma ordem de grandeza de 10% a +15%,
resultado da anlise dos custos de todas as atividades do projeto e obteno da aprovao formal
do valor. Esse valor ser utilizado como linha de base e tambm para medir o sucesso do projeto.
3a Etapa: Refinar o oramento enquanto o trabalho executado e os custos incorridos no decorrer
do projeto. No final dessa etapa, os nmeros devero ficar na faixa de 5 a 10% acima ou abaixo do
valor orado para o projeto.
4a Etapa: Monitorar e controlar o oramento no decorrer da execuo das atividades do projeto.
importante que o gerente de projeto fique atento a certas situaes que podem causar alteraes no
oramento:
a. Se os recursos alocados para executar certas atividades demonstrarem menos experincia do que
o esperado, isso pode causar atrasos ou necessidade de treinamento adicional.
b. Os preos de mercadorias ou servios podem aumentar em relao ao seu oramento inicial.
c. Alguns recursos alocados no planejamento talvez no estejam mais disponveis na execuo. 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 no h como retirar o pessoal que j est l.
d. O cliente pode solicitar mudanas ao escopo original acordado no planejamento.
Uma boa prtica 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 tcnico do que est sendo orado. Alm do conheci-
mento tcnico, quando participa das estimativas a equipe compartilha a responsabilidade pelo cumprimento
do oramento do projeto. O gerente de projeto continua com a responsabilidade de facilitar o processo de
levantamento das informaes de custos com base em ferramentas e tcnicas especficas (listadas a seguir);
porm, quando os nmeros vm de quem conhece o trabalho, o oramento fica mais real a todos.
Para se chegar a estimativas mais reais, o ideal combinar tcnicas diferentes, conforme o que est sendo es-
timado ou orado. Por exemplo, para estimar horas/funcionrio, interessante utilizar dados paramtricos. 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, possvel utilizar dados
anlogos pesquisando a documentao desses projetos. Nesse aspecto, espera-se que a empresa tenha um
mnimo de organizao para arquivar oramentos 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 durao
das tarefas juntamente com os recursos necessrios para execuo de cada uma dessas tarefas. Dessa
forma, agora no planejamento dos custos do projeto, o gerente de projetos tem condies de fazer um
levantamento mais preciso para saber quanto todas essas atividades e recursos custaro.
H vrias formas de calcular os custos de um projeto. Muitas empresas ou organizaes tm processos
especficos no departamento financeiro ou comercial que determinam sistemas informatizados ou formu-
lrios especficos para estimativas e oramentos. Focando sempre o gerenciamento de projetos em nvel
iniciante e as formas mais prticas e fceis de trabalhar com projetos, sero propostas aqui duas categorias
para dividir os custos de um projeto: custos relativos mo de obra e custos no relativos mo de obra.
Custos relativos mo de obra so as horas/funcionrio necessrias para a execuo de cada atividade
e podem ser:
1. Custos externos, quando o projeto requer recursos humanos de fora da organizao do projeto
ou a contratao de consultores ou temporrios. Esses custos precisam obrigatoriamente
serestimados, orados e acordados com os devidos fornecedores na fase de planejamento
paragarantir certo nvel de estabilidade ao projeto. Para a maioria dos projetos, h fornecedores
dispostos a darem oramentos ou, quando isso no for possvel, h sempre fontes na internet com
horas/funcionrio padro (ou faixa salarial) para engenheiros, programadores, contadores e outros
profissionais para o clculo dos custos com mo 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 dopagamento, faz
parte do custo fixo da empresa e receber o salrio de qualquer forma. Porm, recomenda-se sempre
incluir os custos de hora/funcionrio internos, pois necessrio ter um controle sobre quanto o projeto
ir custar. No uma questo de quem vai pagar essas horas/funcionrio quesero utilizadas no projeto,
mas preciso ter uma viso do custo total e real do projeto.
Dica
Cada empresa tem um jeito prprio de tratar custos internos dos projetos. Algumas empresas utilizam
um valor interno para cada cargo, outras utilizam o valor mdio do salrio 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 no considera
custos internos para fins de oramentos ou estimativas de custos dos projetos, a melhor sada incluir
uma coluna no oramento para custos no incrementais, indicando que o valor daquele recurso no vir
necessariamente do oramento do projeto (que normalmente inclui apenas os custos diretos e variveis),
mas faz parte do custo do projeto como um todo, que deve ser previsto, monitorado e controlado.
Custos no relacionados mo de obra, como o nome j diz, referem-se a todo e qualquer custo que
no esteja diretamente relacionado a salrios (e respectivos benefcios) ou valores horas/funcionrio.
Normalmente, para fins de clculo de custos no relacionados mo de obra, os seguintes itens so
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 instalaes ou maquinrios.
7. Transporte.
8. Refeies.
A seguir, um exemplo de um oramento genrico para um projeto de tecnologia da informao.
Trata-se de um exemplo de uma empresa hipottica trabalhando em uma estrutura organizacional
projetizada em que todos os recursos humanos so considerados terceirizados para fins de oramento
do projeto. Os valores no oramento so apenas para fins ilustrativos, no so valores reais.
Importante
Os exemplos de oramentos aqui colocados no refletem o custo do produto ou servio do projeto

ao cliente, mas sim os custos de se fazer o projeto em si. O custo ao cliente envolve uma poltica de pre-
cificao de servios e produtos de cada empresa, o que no faz parte do escopo deste livro (Figura7.2).
FIGURA 7.2 Exemplo de oramento para um projeto de TI. Fonte: Adaptado (com permisso) do Project Budget Template da Axia
Consulting (www.axia-consulting.co.uk).
(continua)
FIGURA 7.2 (Cont.)
Aplicao
O Plano de Gerenciamento de Custos para esse projeto encontra-se no Plano de Gerenciamento do
Projeto, item 6C.
O oramento para o projeto de sustentabilidade rede de supermercados A loja 1 teve trs 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 reviso aps planejamento dos riscos (Figura7.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 anlise de componentes especficos 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 oramento
do projeto e, depois, discriminados em uma planilha detalhada para monitoramento e controle do
projeto, conforme ilustrado a seguir. Aps a anlise dos riscos (conforme demonstrado no captulo11
Riscos), as porcentagens das reservas foram confirmadas e mantidas (Figura7.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 variveis. O valor da hora/funcionrio foi calculado com base na mdia do salrio
do recurso por hora, dividindo o salrio mensal pelo nmero de horas trabalhadas em um ms (Figura7.5).
FIGURA 7.5 Oramento com todos os custos do projeto de sustentabilidade rede de supermercados A loja 1.
Ferramenta
No MS Project possvel colocar o valor da hora/funcionrio de cada recurso que trabalhar no

projeto na Planilha de Recursos. Aps a concluso do cronograma, o programa calcula automatica-
mente o total de horas/funcionrio, com base nas alocaes das atividades para os recursos humanos
do projeto. Para uma visualizao do valor total, calculado pela multiplicao do total de horas que o
recurso trabalhar no projeto pelo valor hora/funcionrio do recurso, s clicar em Uso dos Recursos,
conforme mostrado a seguir (Figura7.6).
FIGURA 7.6 Custos dos recursos como aparecem no MS Project.
Observao: Andr (Z) custo zero, pois o recurso da empresa Z, responsvel pelo marketing (custo
do recurso embutido nos custos das entregas de marketing da empresa terceirizada).
Dicas
H vrias formas de minimizar os problemas relativos s estimativas de custos e oramentos. A seguir,

algumas sugestes com base nas melhores prticas de gerentes de projetos experientes, similares s
propostas por Verzuh (2008):
No 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 incio do projeto, o gerente de
projeto pode fornecer uma estimativa com uma porcentagem de erro de 50% ou +100%, isso
muito perigoso em organizaes em que no h um processo oficial com base no PMBOK
ou, at mesmo, quando o solicitante dessa estimativa inicial um gerente de alto escalo
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 situao se agrava quando ele envia por
e-mail uma estimativa de custos e avisa que apenas preliminar. Esse e-mail ento encaminhado a
outras pessoas, e isso aumenta a probabilidade de que uma delas acredite que aquela a estimativa slida
e no preliminar (apesar de estar escrito no e-mail, muitos no leem as mensagens corretamente e agem
em funo de informaes que entenderam errado). Diante dessas situaes, a melhor sada explicar
que ainda no possvel fornecer estimativas decustos naquele momento do projeto e sugerir uma data
em que essa informao ser apresentada formalmente, com dados mais especficos para validar os
nmeros.
Fazer o possvel para no fornecer valores sem ter visto as especificaes ou os requisitos do projeto
em primeiro lugar. Por exemplo, para projetos de construo civil necessrio ver, no mnimo, a
blueprint da obra. Em projetos que envolvam algum tipo de maquinrio ou tecnologia, necessrio
ter um prvio 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 anlise que
envolve custos precisa ter algo concreto a partir do qual os clculos e as pesquisas de preos sero
feitos.
As estimativas devem refletir a realidade dos custos. Colocar um dinheirinho extra para
emergncias no uma boa prtica, a no ser que isso seja fundamentado. Reservas financeiras
so includas no oramento com base em anlises especficas 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 eficincia 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.
Exerccios
Planejamento Custos: oramento

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 servios e obteve as
seguintes estimativas de custos:
Araras R$ 500,00
Prateleiras R$ 500,00
Balces R$ 1.000,00
Vitrine R$ 500,00
Fachada R$ 1.000,00
Iluminao externa R$ 500,00
Material de construo R$ 2.000,00
Tintas e acessrios 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
Alm desses custos dos fornecedores de produtos e servios, Ana Maria fez uma lista dos custos que
sero cobertos pela folha de pagamento da empresa ou pelo oramento operacional existente:
Salrio da faxineira R$ 300,00

Salrio da gerente da loja R$ 1.500,00
gua e luz R$ 150,00
Produtos de limpeza R$ 100,00
Material de escritrio R$ 100,00
Carlos Peixoto analisou todos esses itens e pediu a Ana Maria para elaborar um oramento do projeto
organizando os custos em duas categorias: fixos e variveis.
Material de apoio
Baixe o arquivo Oramento, na pasta Exerccios em Contedos extras, na pgina web do livro (www.
elsevier.com.br/martacamargo).
1. Faa o oramento do projeto conforme a solicitao de Carlos Peixoto, incluindo inicialmente os
custos fixos e variveis relativos mo de obra e no relativos mo de obra.
2. Inclua agora uma reserva de contingncia de 10% e uma reserva gerencial de 5% no subtotal, e depois
recalcule o valor final do oramento do projeto.
3. Qual o valor orado para o projeto? Esse valor est de acordo com a restrio de custos expressa no
incio do projeto (no ultrapassar R$ 20.000,00 em custos variveis)?
4. Que valor ser considerado como linha de base do projeto?
8
Qualidade
Definir e documentar procedimentos de verificao da qualidade dos projetos por meio de fluxogramas
e listas deverificao (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 inspeo total dos produtos, aps sua
concluso. Esse conceito evoluiu. Atualmente, o foco da qualidade est voltado para o planejamento,
possibilitando a preveno da ocorrncia de falhas. A qualidade deve ser planejada e no somente ins-
pecionada, pois o custo da preveno de erros sempre menor do que o custo da correo dos erros.
O planejamento da qualidade envolve, normalmente, trs atividades de grande importncia ao
projeto e respectiva documentao, conforme explicado a seguir (Tabela8.1).
Tabela 8.1 Atividades e Documentos do Planejamento da Qualidade

Atividades para planejar a qualidade Documentos gerados
Identificar os padres de qualidade relevantes ao produto ou produtos do projeto Plano de Gerenciamento da Qualidade
ecomo satisfaz-los. Fluxogramas
Definir as atividades que sero realizadas no decorrer do projeto para garantir Listas de Verificao ou Checklists
queosrequisitos predefinidos sejam atendidos.
Escolher as ferramentas que sero utilizadas para monitorar e controlar a qualidade
durante todo o projeto.
Para a primeira atividade descrita na Tabela8.1, uma boa prtica para iniciantes em gerenciamento
de projetos fazer um benchmarking, ou seja, pesquisar e descobrir as prticas de sucesso que ou-
tros gerentes de projetos fizeram em projetos semelhantes (dentro ou fora da empresa). A tcnica de
benchmarking permite estabelecer padres realsticos 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 Tabela8.1 deve contar com formas eficientes de realizar a garantia
da qualidade. A garantia da qualidade acontece durante todo o projeto e voltada preveno 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 realizao das entregas do projeto que verificaro
se os requisitos esto sendo cumpridos conforme o planejado.
As ferramentas de qualidade da terceira atividade iro variar, dependendo do produto ou servio
do projeto. O PMBOK prev uma srie de ferramentas para planejamento, execuo, monitoramento
e controle da qualidade, como grficos de Pareto, diagramas de causa e efeito, histogramas, grficos
de disperso, fluxogramas e listas de verificao ou checklists. A seo a seguir abordar duas dessas
ferramentas: fluxogramas e listas de verificao ou checklists.
123
Na prtica
Os padres de qualidade de um projeto dependero da rea ou do setor em que o projeto estar sendo
realizado e do produto do projeto. Considerando um nvel iniciante em gerenciamento de projetos, este
captulo mostrar duas ferramentas bsicas que podem ser utilizadas em qualquer tipo de projeto e em
diversos pontos do projeto. Essas ferramentas so os fluxogramas e as listas de verificao ou checklists.
8.1Fluxogramas
O formato de um fluxograma pode variar, porm a ideia sempre a mesma: visualizar a sequncia
do trabalho ou dos processos para atingir um fim especfico.
A elaborao ou o desenho de um fluxograma genrico segue algumas regras bsicas:
1. Determinados smbolos ou formas geomtricas representam os processos no fluxograma.
2. Os smbolos devem ter tamanhos e formas uniformes, alm de guardar a devida proporo 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 srie de formatos geogrficos ou smbolos para fluxogramas. Para um fluxograma bsico,
os smbolos seguintes so os mais usados:
Terminal Representa o incio e o fim do processo.
Processo Representa qualquer ao para criar, transformar, conferir ou analisar.
Deciso Indica um ponto do processo que apresenta aes condicionais.
Documento Representa qualquer documento criado ou transformado no fluxo

doprocesso.
Linhas de fluxo Representam o sentido do fluxo da informao.
Dados sequenciais Representam a continuidade do fluxo no processo.
Exemplo: Uma empresa no tinha um estoque informatizado, e os pedidos ao estoque ocorriam

da seguinte forma: o estoquista, ao receber uma solicitao de pea, verificava na listagem do estoque
sua disponibilidade. Caso estivesse disponvel, a pea era entregue ao solicitante e, em seguida, era
dada a baixa no estoque. Caso a pea no estivesse disponvel, verificava-se o prazo de entrega junto
aos fornecedores de peas. Informava-se o tempo necessrio ao solicitante. Caso ele ainda desejasse
a pea, o pedido ao fornecedor era efetuado imediatamente. Aguardava-se a chegada da pea e a sua
entrada no estoque. Em seguida, a pea era entregue ao solicitante e era dada a baixa no estoque.
Considera-se, neste exemplo, que o fornecedor sempre tinha a pea solicitada disponvel para entrega.
Captulo 8 Qualidade 125
O fluxograma para o processo de solicitao da pea, conforme essa descrio, seria o seguinte
(Figura8.1):
FIGURA 8.1 Exemplo de um fluxograma.

8.2 Listas de Verificao ou Checklists

Uma das ferramentas mais utilizadas em processos de verificao em projetos a lista de verificao
ou checklist. Listas de verificao ou checklists so ferramentas muito teis para monitorar e controlar
tarefas ou resultados de um projeto. Essas listas variam no formato e no contedo do que ser verificado.
A Figura8.2 ilustra um formato genrico que ser utilizado nos exemplos a seguir.
FIGURA 8.2 Formato genrico de uma lista de verificao (checklist).
Exemplo: No exemplo anterior do fluxograma para as peas, existe um ponto em que ser neces-
srioverificar a qualidade da pea antes de entreg-la ao solicitante. Nesse caso, uma lista de verificao
poderia ser elaborada (Figura8.3):
FIGURA 8.3 Exemplo de uma lista de verificao (checklist).

No exemplo atual, o fluxograma incluiria um comentrio fazendo referncia a essa lista de verificao
(Figura8.4):
FIGURA 8.4 Exemplo de fluxograma com lista de verificao (checklist).
Outro exemplo: Voc est abrindo uma empresa para produzir e vender sabonetes artesanais. Como
ir contratar outras pessoas para ajudar na produo, voc desenvolveu um processo mediante um
fluxograma e incluiu pontos de verificao para a equipe de produo verificar a qualidade do produto
que est sendo produzido (Figuras8.5 e8.6).
FIGURA 8.5 Exemplo de fluxograma projeto de produo de sabonetes.

FIGURA 8.6 Lista de verificao (checklist) para fluxograma do projeto de produo de sabonetes.
Ferramentas
Para fazer fluxogramas, a melhor ferramenta o software MS Visio. s escolher a opo Fluxograma
Bsico, clicar na forma, arrastar e soltar.
Para fazer checklists ou listas de verificao, o MS Word e o MS Excel contm o recurso Desenvolvedor
para criar listas de verificao com interatividade. H tutoriais da Microsoft na internet com metdos
passo a passo para ativar o recurso Desenvolvedor e utilizar os recursos para desenvolver listas de
verificao.
Aplicao
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 verificao do projeto
sustentabilidade para a rede de supermercados A loja 1 (Figuras8.7 a8.13).
FIGURA 8.7 Fluxograma com listas de verificao (checklists) para o projeto sustentabilidade para a rede de supermercados A loja 1.
FIGURA 8.8 Lista de verificao (checklist) para o projeto sustentabilidade para a rede de supermercados A loja 1.
FIGURA 8.9 Lista de verificao (checklist) para o projeto sustentabilidade para a rede de supermercados A loja 1.
FIGURA 8.9 (Cont.)

FIGURA 8.10 Fluxograma para processo de aquisio projeto Sustentabilidade para a Rede de Supermercados da Rede A loja 1.
FIGURA 8.11 Checklist para fluxograma do processo de aquisio projeto Sustentabilidade para a Rede de Supermercados
daRede A loja 1.
daRede A loja 1.
daRede A loja 1.
Exerccios
Planejamento: Qualidade
Para o processo do treinamento, Carlos Peixoto elaborou o fluxograma (Figura8.14), que aparece
na prxima pgina.
Material de apoio
Baixe os arquivos Listas de verificao T-01 e T-02, na pasta Exerccios em Contedos extras, na pgina
web do livro (www.elsevier.com.br/martacamargo).
1. Elabore duas listas de verificao para serem utilizadas na verificao dos pontos de deciso do
fluxograma anterior. Cada lista de verificao dever ter um mnimo de 10 (dez) itens.
a. A primeira lista (T-01) dever incluir itens necessrios para aprovar o material que foi elaborado
para o treinamento, considerando questes como: o material est claro para o pblico-alvo? H
erros gramaticais? O texto est diagramado de forma profissional?
b. A segunda lista (T-02) dever incluir itens necessrios aprovao da qualidade de reproduo
do material considerando questes como: as cpias esto legveis? As ilustraes podem ser vistas
claramente? H espaos para as anotaes dos participantes?
FIGURA 8.14 Fluxograma para etapas do treinamento.

9
Recursos Humanos
Desenvolver matrizes RACI para documentar papis e responsabilidades das partes interessadas
de um projeto.
Conceito
Em gerenciamento de projetos, os Recursos Humanos consistem basicamente na gesto das pessoas

que iro 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 (Tabela9.1):
Tabela 9.1 Atividades e Documentos para Planejamento dos Recursos Humanos
Atividades para planejar os Recursos Humanos Documentos gerados
Identificar as habilidades necessrias para que os recursos participem doprojeto,
adquirir os recursos necessrios execuo bem-sucedida do projeto, documentar Plano de Gerenciamento de Recursos Humanos
a hierarquia do projeto, identificar e documentar papis eresponsabilidades. Matriz RACI
Providenciar treinamento e desenvolvimento das habilidades do pessoal doprojeto.
Acompanhar o desempenho da equipe, dar feedback, resolver conflitos
egerenciar mudanas.
O planejamento dos Recursos Humanos requer o desenvolvimento de um plano de Recursos Humanos

para identificar e documentar funes, responsabilidades e relaes hierrquicas do projeto. Em todo
projeto, importante que haja uma definio clara da responsabilidade de cada indivduo, bem como os
limites de cada um para a resoluo de conflitos ou problemas e as tomadas de decises durante o projeto.
O gerente de projeto responsvel pelo planejamento dos recursos propriamente ditos, pois ele
determina quantas pessoas so necessrias 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 seleo e o treina-
mento dos recursos que iro 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 necessrio ao
projeto dentro do tempo e custo alocados.
As atividades relacionadas ao treinamento e ao desenvolvimento dos recursos envolvero 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 prtica
Para a maioria dos projetos, o planejamento de Recursos Humanos em projetos consistir ba-
sicamente na definio de que tipo de recursos o projeto ir precisar, bem como os papis e as
139
responsabilidades especficas para as necessidades daquele projeto. Pode ser que o gerente de projeto
identifique tambm necessidades de contrataes adicionais ou treinamentos para determinados
membros da equipe.
Tambm faz parte do papel do gerente de projeto identificar como e quando os membros da equipe
comearo a participar do projeto, de que reas da empresa esses membros viro, quais gerentes
funcionais precisaro aprovar a liberao desse pessoal para trabalho no projeto, qual treinamento
esse pessoal poder precisar e, por fim, como os membros da equipe sero liberados dos trabalhos do
projeto quando de sua concluso. Tudo isso documentado no Plano de Gerenciamento de Recursos
Humanos e variar muito, dependendo do tipo do projeto e dos recursos disponveis em cada empresa
ou organizao.
9.1 Matriz RACI

Independentemente de como os Recursos Humanos sero planejados e gerenciados, ser necessrio
especificar papis e responsabilidades especficos para cada projeto. Uma ferramenta muito til para
documentar papis e responsabilidades em projetos a matriz RACI, um acrnimo (em ingls) para:
R=RESPONSIBLE ou responsvel pela execuo do trabalho envolvido na entrega, pacote de
trabalho, processo ou atividade, ou seja, responsvel por assegurar que o trabalho seja realizado.
Refere-se ao executor de determinadas partes do trabalho.
A=ACCOUNTABLE ou responsvel pela aprovao 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 informaes para completar o
trabalho. Refere-se ao consultor para a realizao de determinados componentes do trabalho do
projeto.
I=INFORMED ou informado sobre o status do trabalho em questo. So aqueles recursos que s
precisam ser copiados nos e-mails ou relatrios em determinados pontos do projeto.
A matriz RACI til para definir a participao dos membros da equipe nos diferentes papis neces-
srios para concluir o trabalho do projeto de forma bem-sucedida. A RACI evidencia a necessidade da
participao de todos, e no apenas daqueles envolvidos diretamente na execuo 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 Figura9.1 ilustra o formato genrico de uma matriz RACI.
FIGURA 9.1 Formulrio genrico da matriz RACI.

Captulo 9 Recursos Humanos 141
A matriz RACI pode ser utilizada para cada atividade do projeto, porm, para projetos de grande
porte, pode ser invivel. Um projeto grande pode ter centenas ou milhares de atividades e a res-
ponsabilidade pela concluso de cada atividade , normalmente, alocada a indivduos na coluna
Recursos de um cronograma genrico (feito, por exemplo, com o MS Project ou OpenProj). As res-
ponsabilidades em uma RACI so geralmente atribudas para entregas, processos ou componentes
maiores do projeto.
Essa matriz pode tambm ser utilizada para fazer um levantamento das necessidades de contrataes,
principalmente quando houver um excesso de R's para um papel funcional, significando que haver
necessidade de reforos para a realizao do trabalho envolvido naquele papel.
Importante
Na elaborao da matriz RACI, importante considerar o seguinte:

As designaes devem ser atribudas a uma funo ou a um papel funcional, no ao nome de uma
pessoa especfica. A alocao 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.
recomendvel ter apenas um A por item da matriz (processo, entrega etc.), ou seja, no 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 nvel de
desempenho desejado.
Se ningum assumir um R (Executor), o item no ser realizado e isso no pode acontecer. Todo
item na matriz RACI precisa de pelo menos um R.
Os nveis de R (Executor) e A (Aprovador) devem estar prximos do nvel de conhecimento e de ao,
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 aprovao ou no do que est sendo designado.
A autoridade direta, ou seja, quando um papel funcional recebe um A, esse papel diretamente
responsvel pela aprovao, e no precisa da obteno da aprovao de outra fonte.
Deve-se tentar minimizar o nmero de C's e I's considerando apenas o necessrio. Quem no precisar
ser consultado ou informado, no precisa participar daquele item do trabalho. No se recomenda
colocar C ou I s para ter algo designado a um papel funcional. Se no fizer parte daquela rea de
trabalho, s deixar em branco na matriz RACI.
Todo C deve participar ANTES da deciso ou ao. sempre bom verificar se quem est recebendo
um C precisa mesmo participar daquele item e ter disponibilidade para essa participao no tempo
alocado, a fim de que assim no se trave o trabalho.
A matriz no precisa ter todos os campos preenchidos apenas o necessrio para realizar o projeto.
No necessrio preencher um determinado papel com C's ou I's s para no deixar vazio.
A matriz feita em equipe com as partes envolvidas e pode ser modificada ou adaptada no decorrer
do projeto, conforme o necessrio.
Depois de pronta, a matriz RACI deve ser aprovada pelos papis funcionais para os quais esto sendo
designadas responsabilidades.
Veja um exemplo de matriz RACI na Figura9.2.
FIGURA 9.2 Exemplo de uma matriz RACI. Fonte: Adaptado (com permisso) de Roadmap para o Projeto de Implantao do Escritrio
de Processos, 2008 (www.elogroup.com.br).
Aplicao
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 mdio porte, a hierarquia dos recursos do projeto refletiu praticamente a hierarquia
da empresa. Um organograma considerando a organizao dos recursos foi colocado no Plano de
Gerenciamento do Projeto para confirmar apenas como todos se encaixavam no projeto. No houve
necessidade de treinamentos adicionais ou contrataes.
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 elaborao de uma matriz RACI con-
firmando os papis e as responsabilidades de cada um, como na figura a seguir (Figura9.3):
Captulo 9 Recursos Humanos 143
FIGURA 9.3 Matriz RACI do projeto de sustentabilidade para a rede de supermercados A loja 1.
Exerccios
Planejamento: Recursos Humanos

Para deixar claro quais sero as responsabilidades de cada um no projeto, Carlos decide utilizar uma
matriz RACI.
Material de apoio
Baixe o arquivo Matriz RACI, na pasta Exerccios em Contedos extras, na pgina 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 documentao do projeto.
b. Seleo e pagamento dos fornecedores.

c. Treinamento dos colaboradores.
d. Reformas na estrutura interna.
e. Reformas na estrutura externa.
f. Entrega e instalao das prateleiras e das araras.
g. Entrega e montagem das vitrines.
h. Entrega e montagem dos mveis.
i. Recebimento e verificao dos produtos comprados.
j. Decorao das vitrines.
k. Arrumao das prateleiras com produtos e mercadorias.
l. Promoo e divulgao da loja reformada.
E considerando os papis 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
Comunicaes
Elaborar um Esquema das Comunicaes para padronizar o fluxo de informaes durante a realizao do projeto.
Conceito
O planejamento das comunicaes ter que definir estratgias e processos para a comunicao das
informaes do projeto a todas as partes interessadas. H duas atividades bsicas de comunicaes em
qualquer projeto, apresentadas na tabela a seguir (Tabela10.1).
Tabela 10.1 Atividades e Documentos para o Planejamento das Comunicaes

Atividades para planejar as comunicaes Documentos gerados
Definir como o fluxo de informaes ser realizado durante o projeto. Esquema das Comunicaes
Definir formas de coletar informaes, elaborar relatrios e distribuir Relatrio de Andamento
informaes sobre o desempenho do projeto. Registro de Problemas
Na prtica
O gerente de projeto deve elaborar um documento para registrar os meios e as formas de comuni-
cao especficas para o projeto.
A eficincia desse documento depende, em grande parte, da habilidade do gerente de projeto em
j ter feito, desde o incio do projeto, um levantamento correto das partes interessadas e respectivas
influncias no projeto. Muitos dos problemas que surgem no decorrer do projeto so devidos falta da
informao que nunca chegou pessoa que deveria ter recebido essa comunicao referente a algum
aspecto do projeto. Em empresas de grande porte com atividades globais, h ainda o agravante de a
comunicao estar sendo feita em ingls em pases que falam outro idioma, o que adiciona obstculos
a uma comunicao eficiente.
No h uma frmula perfeita de se resolver todos os problemas de comunicao de um projeto.
Contudo, obrigao de qualquer gerente de projetos primeiro fazer o possvel para descobrir quem
de fato precisa ser comunicado do que e quando e, depois, entregar a informao da forma como essa
parte interessada quer e entende. No adianta, por exemplo, enviar um cronograma detalhado no MS
Project a um supervisor da fbrica que no est acostumado com essa ferramenta. Muitas vezes, um
cronograma em formato de grfico de barras simples no MS Excel a soluo.
A documentao do projeto fundamental para a comunicao eficiente a todos os envolvidos.
Porm, o formato em que essa documentao apresentada no necessariamente o que o gerente do
projeto prefere (em funo de uma determinada ferramenta, por exemplo) ou quer, mas o que melhor
para o entendimento das partes interessadas.
145
10.1 Esquema das Comunicaes

Todo projeto precisa de um documento em que fiquem registrados os nomes das partes interessadas
e suas preferncias quanto ao mtodo e a frequncia em que querem receber informaes do projeto.
Esse documento pode ter vrios formatos e contedos. O modelo que ser utilizado a seguir receber o
nome de Esquema das Comunicaes do Projeto e conter informaes sobre formas de recebimento
das informaes, quem receber essas informaes, quando e em que formato, bem como as premissas
e restries relacionadas especificamente s comunicaes do projeto (Figura10.1).
No planejamento da rea de conhecimento Comunicaes, devem ser elaborados tambm rela-
trios e documentos que iro conter informaes para monitoramento e controle do projeto. Esses
documentos sero explicados e ilustrados na prxima seo.
FIGURA 10.1 Formulrio genrico para o Esquema das Comunicaes.
Aplicao
O Plano de Gerenciamento das Comunicaes encontra-se no Plano de Gerenciamento do Projeto,

item 6F.
O Esquema das Comunicaes para o projeto sustentabilidade para a rede de supermercados A loja1
encontra-se a seguir (Figura10.2).
FIGURA 10.2 Esquema das Comunicaes para o projeto sustentabilidade para a rede de supermercados A loja 1.
Captulo 10 Comunicaes 147
FIGURA 10.2 (Cont.)

FIGURA 10.2 (Cont.)
10.2 Relatrios e Registros de Informaes

Conforme mencionado anteriormente, sero necessrios alguns documentos de apoio comuni-
cao do projeto. Esses documentos so concebidos na fase de planejamento, porm so preenchidos
durante o monitoramento e controle do projeto. Esses documentos so:
1. Relatrio de Andamento do Projeto. Incluir informaes sobre o que est acontecendo a em
determinados pontos do projeto. Esse relatrio ser elaborado conforme as datas no cronograma
ecolocado em formato PDF na pasta SustentaA, no servidor HJH (Figura10.3).
FIGURA 10.3 Formulrio para Relatrio de Status ou Relatrio de Andamento do Projeto.
2. Documentao do Gerenciamento das Mudanas. Quando houver necessidade de alguma

mudananoprojeto, o solicitante dever enviar um formulrio por e-mail ao gerente de projeto,
que ir analisar a solicitao e analisar o impacto. Se no afetar a linha de base, o prprio gerente
Captulo 10 Comunicaes 149
doprojeto poder aprovar ou no a mudana. Se afetar a linha de base, a solicitao dever

seranalisada por um comit formado pelo sr. Jos S. (proprietrio da rede e patrocinador do
projeto),por Ivan S. (gerente do projeto) e o gerente da rea que ser afetada pela mudana (por
exemplo, sr. Ernesto S., se as mudanas forem relacionadas s instalaes, ou sr. Vicente A., se
forem relacionadas ao marketing, e assim por diante). A situao final da mudana ser registrada
no Registro de Problemas para uma rpida visualizao do que foi mudado no projeto e para ser
utilizada no processo de lies aprendidas do projeto (Figuras10.4 e10.5).
3. Registro de Problemas. Quando houver um problema durante o projeto que leve a um risco ou
queserefira a algum aspecto no planejado no projeto, o gerente de projeto dever lan-lo
noRegistrode Problemas. Toda solicitao de mudana durante a execuo do projeto ser
considerada problema e lanada no registro. Esse Registro de Problemas ser uma fonte
importantedeinformaes durante a elaborao do Relatrio de Lies Aprendidas, no processo
de encerramento do projeto (Figura10.6).
FIGURA 10.4 Formulrio para Solicitaes de Mudanas.
FIGURA 10.5 Formulrio para Anlise de Impacto das Solicitaes de Mudanas.

FIGURA 10.5 (Cont.)
FIGURA 10.6 Formulrio para Registro de Problemas.
Exerccios
Planejamento: Comunicaes
Para confirmar como a comunicao do projeto ocorrer entre os diversos participantes, Carlos
decide utilizar o formulrio Esquema das Comunicaes.
Material de apoio
Baixe o arquivo Esquema das Comunicaes, na pasta Exerccios em Contedos extras, na pgina
Simule as possveis necessidades de comunicao no projeto da reforma da loja e elabore um
esquema de comunicao para os membros da equipe do projeto, considerando o tipo, a durao
eas pessoas que trabalharo no projeto. Esse esquema dever conter as seguintes informaes:
a. Tipo de comunicao.
b. Pblico-alvo.
c. Mtodo.
d. Frequncia.
e. Formato.
f. Remetente.
11
Riscos
Identificar, analisar e avaliar qualitativamente os riscos do projeto, considerando a elaborao de planos
de ao e reservas financeiras para contingncias.
Conceito
Riscos so circunstncias ou acontecimentos inesperados ou incertos que, quando ocorrem, afetam

o projeto de alguma forma. Os riscos que exigem maior ateno so aqueles que tendem a afetar as
linhas de base do projeto, pois impactam diretamente a consecuo de seus objetivos. As atividades
normalmente realizadas no planejamento dos riscos so descritas a seguir (Tabela11.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 Anlise dos Riscos
Analisar os riscos
Elaborar as respostas aos riscos identificados
Deve haver um plano que inclua informaes especficas de como a equipe ir identificar os riscos,
analis-los de forma qualitativa e quantitativa (dependendo do projeto), desenvolver planos de ao
em resposta a eles e a definir a maneira como sero monitorados e controlados.
H basicamente duas abordagens anlise dos riscos:
1. Qualitativa: A anlise qualitativa de risco uma anlise subjetiva em que os riscos so analisados
considerando suas implicaes ao cumprimento dos objetivos do projeto. Essa anlise 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 anlise quantitativa de risco conta com nmeros rgidos. Cada risco recebe uma nota,
e no uma avaliao baixa, mdia e alta. A anlise quantitativa de riscos no necessria para todos
os projetos e pode ser pulada para se passar direto para o planejamento de respostas a riscos. As
tcnicas mais comuns utilizadas em anlises quantitativas de riscos so: anlise de valor monetrio,
rvore de deciso e simulao de Monte Carlo. Devido sua complexidade, esse tipo de abordagem
quantitativa no ser discutido neste livro.
Os riscos a um projeto podem ser divididos em categorias como:
1. Externos: Itens regulatrios, ambientais, governamentais, fornecedores, condies do mercado ou
concorrncia.
2. Internos: Tempo, custo, mudanas no escopo, inexperincia, planejamento inadequado, pessoas,
pessoal, materiais, equipamentos, rea contratual ou jurdica.
3. Tcnicos: Aspectos relacionados tecnologia, especificaes tcnicas, requisitos do produto.
151
Na prtica
Neste material voltado para gerentes de projetos iniciantes, a prtica e a aplicao 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 sugesto. H inmeras formas
de realizar esses tipos de anlises, e esta apenas uma delas.
11.1 Estrutura Analtica dos Riscos EAR (Risk Breakdown

Structure RBS)
A anlise qualitativa dos riscos de um projeto pode comear com uma identificao das categorias
principais dos riscos especficos para aquele projeto.
Por um processo semelhante criao da Estrutura Analtica do Projeto (EAP), as categorias e sub-
categorias dos riscos especficos para o projeto podem ser hierarquizadas em uma Estrutura Analtica
dos Riscos EAR (Risk Breakdown Structure RBS, em ingls), para uma posterior identificao dos
riscos especficos dentro de cada subcategoria (Figura11.1).
O formato grfico das categorias e subcategorias dos riscos facilita a visualizao dos tipos de riscos
que podem acontecer no projeto e da maneira como eles esto relacionados entre si.
FIGURA 11.1 Exemplo de Estrutura Analtica de Riscos (EAR).
11.1.1 Matriz de Anlise Qualitativa dos Riscos

A partir das categorias e subcategorias de riscos definidas na EAR, o gerente do projeto e as partes
interessadas se renem para identificar os riscos especficos do projeto. Isso pode ser realizado por meio
de uma reunio de brainstorming para identificao livre de todo risco possvel e imaginvel para, em
seguida, agrupar os riscos considerados relevantes para uma anlise mais detalhada. Nessa primeira
anlise qualitativa, a equipe do projeto classifica o risco considerando os seguintes itens:
Captulo 11 Riscos 153
1. Impacto de cada risco no projeto ou a maneira como o risco afeta os elementos da tripla restrio
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 estratgias que tm como objetivo diminuir um possvel efeito prejudicial do
risco aos objetivos do projeto.
Em anlises qualitativas de riscos, as seguintes respostas so consideradas padro:
1. Evitar: Eliminar a ameaa acabando com a causa. Por exemplo: um item do escopo do projeto pode
contaminar um riacho que passa perto da fbrica. Evitar o risco significa remover esse item do escopo
do projeto.
2. Mitigar: Reduzir a probabilidade ou o impacto de uma ameaa, 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 agncia de empregos com a qual a empresa trabalha no conseguir suprir o nmero
de recursos necessrios. Nesse caso, mitigar significa solicitar os recursos a mais duas agncias, para
aumentar a probabilidade de conseguir os recursos no tempo necessrio.
3. Transferir: Tornar outra parte responsvel pelo risco com a aquisio de seguros, terceirizao do
trabalho etc. Por exemplo: algumas atividades do projeto de engenharia civil sero 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 ao vivel, ou ento os riscos so
considerados de pouca probabilidade e baixo impacto, ou ambos. No h muito a fazer, por exemplo,
quando h riscos de mudanas na legislao ou regulamentao governamental que afetam um
determinado item do projeto.
H vrias 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 (Figura11.2):
FIGURA 11.2 Formulrio genrico para Anlise de Riscos de um projeto.
Como preencher o formulrio de anlise de riscos:

No do risco: Nmero identificador que pode ser sequencial para cada risco identificado.
Categorias: So 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 oramento 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 duraes e datas, como problemas de disponibilidade de
recursos nas datas predeterminadas, erros nas estimativas de duraes das atividades e atrasos.
Tcnico Qualquer item que esteja diretamente relacionado aos aspectos tcnicos do projeto, como
complexidade tcnica, tecnologias novas e integrao da tecnologia nova com as existentes na
empresa.
Gesto Itens relacionados habilidade em gerenciamento de projetos ou gesto da empresa como
um todo, em especial quanto ao comprometimento de todos para a realizao bem-sucedida do
projeto.
Comunicao Itens relacionados ao entendimento dos requisitos e ao controle do fluxo de

informao durante o projeto.
Operacional Itens relacionados a problemas relacionados a treinamento inadequado ou
disponibilidade de recursos.
Poltico Itens relativos a rgos pblicos, governo, legislao ou leis.
Mercado Itens relativos a instabilidades do mercado, estratgias dos concorrentes e mudanas no
ambiente externo da empresa.
Fornecedor Itens relativos ao cumprimento de contratos e entrega de produtos ou servios pelos
fornecedores, conforme necessrio para a realizao do projeto.
Tecnolgico Itens relacionados a mudanas na tecnologia ou introduo de uma nova tecnologia.
Infraestrutura Itens relacionados s instalaes onde o projeto ir acontecer, condies da rea de
trabalho, suporte tcnico ao equipamento utilizado no projeto.
Probabilidade Significa a chance de o risco acontecer. Na anlise qualitativa, geralmente h

uma escala de 1 a 5:
1 Muito improvvel.
2 De certa forma improvvel.
3 Chance de 50% de ocorrer.
4 Altamente provvel.
5 Quase certeza.
Severidade Significa a gravidade do risco, se ele acontecer. Pode ser expresso tambm 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.
Nvel de controle Expressa o nvel de controle sobre o risco da equipe do projeto. Pode ser ex-
presso tambm em uma escala de 1 a 5:
1 Evitvel por meio de aes de mitigao do risco.

2 Altamente controlvel pela organizao ou aes do projeto.
3 Moderadamente controlvel pela organizao ou aes do
projeto.
4 Altamente incontrolvel pela organizao ou aes do projeto.
5 Totalmente incontrolvel pela organizao ou aes do projeto.
Significncia Obtida pela soma de probabilidade, severidade e nvel de controle sobre os riscos:
3-5 Baixa - pouco impacto ao projeto.

6-10 Mdia - impacta algumas reas do projeto.
Acima de 10 Alta - impacta os objetivos e os resultados do projeto.
Estratgias para gerenciar o risco Aes padronizadas que so acionadas dependendo da condio
imposta pelo risco. Essas aes so: aceitar, evitar, mitigar e transferir, conforme explicado anterior-
mente.
A seguir, um exemplo de anlise de riscos para um projeto de desenvolvimento de uma soluo
de software para integrao de outros sistemas em uma determinada empresa com atuao nacional
(Figura11.3).
FIGURA 11.3 Exemplo de uma Anlise de Riscos para um projeto de TI.
FIGURA 11.3 (Cont.)
Aplicao
O Plano de Gerenciamento de Riscos encontra-se no Plano de Gerenciamento do Projeto, item 6G.

Para a anlise de riscos para o projeto sustentabilidade rede de supermercados A. Loja 1, a equipe
realizou a Estrutura Analtica dos Riscos (EAR) do projeto, conforme ilustrado na Figura11.4:
FIGURA 11.4 Estrutura Analtica 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 (Figura11.5).
Aps essa anlise de risco, considerando a mdia da significncia (que foi 8,6) e seguindo a mesma
classificao para significncia (descrita anteriormente na seo Na Prtica), verifica-se que a equipe
classificou qualitativamente o projeto atribuindo-lhe um risco geral mdio, e decidiu manter a reserva
de contingncia de 4% dos custos para os riscos conhecidos e a reserva gerencial de 5% para riscos no
previstos, ou seja, aqueles que a equipe no identificou, mas que podem acontecer no projeto (assim
como em qualquer projeto). Essa porcentagem seria maior se a anlise qualitativa dos riscos do projeto
indicasse riscos com alto impacto e alta severidade que a equipe do projeto no tivesse condies de
controlar ou mitigar.
FIGURA 11.5 Anlise de riscos para o projeto de sustentabilidade para a rede de supermercados A loja 1.
FIGURA 11.5 (Cont.)

FIGURA 11.5 (Cont.)
Exerccios
Planejamento: Riscos
Carlos Peixoto est preocupado com relao a alguns aspectos do projeto. Como ele no tem ex-
perincia com reformas, Carlos no sabe se haver problemas no decorrer do projeto, para os quais no
estar preparado. Ele gostaria de fazer um levantamento de tudo o que pode dar errado para ter uma
soluo j planejada, no caso de um evento inesperado ocorrer. As reas que mais preocupam Carlos
encontram-se representadas a seguir pelas questes e se:
1. E se o dinheiro no for suficiente?
2. E se suas habilidades como gerente de projeto no derem conta do recado?
3. E se a gerente da loja contratar os fornecedores errados?
4. E se os fornecedores no fizerem as entregas em dia?
5. E se o pessoal da loja no gostar do treinamento?
6. E se o pessoal da obra no aparecer nos dias programados no cronograma?
7. E se os pedreiros no trabalharem com qualidade?
8. E se a instalao de novos aparelhos e equipamentos causar um curto-circuito no prdio?
9. E se o prazo de 30 dias teis no for suficiente para concluir todas as atividades do projeto?
10. E se as prateleiras compradas no couberem na rea reservada para elas?
11. E se a promoo e a divulgao da loja no tiverem os efeitos desejados no mercado?
12. E se o investimento no obtiver o retorno esperado?
13. E se a prefeitura no autorizar a reforma?
Com base nesses receios, Carlos elaborou a Estrutura Analtica de Riscos (EAR) (Figura11.6):
FIGURA 11.6 Estrutura Analtica de Riscos (EAR).
Material de apoio
Baixe o arquivo Anlise de riscos, na pasta Exerccios em Contedos extras, na pgina web do livro
(www.elsevier.com.br/martacamargo).
1. D continuidade anlise de riscos com base nas categorias de riscos da Estrutura Analtica de Riscos
(EAR) anterior e nos receios de Carlos Peixoto refletidos nas questes e se. Voc poder identificar
riscos adicionais e incluir na anlise. Essa anlise dever incluir:
a. Categoria do risco (conforme especificado na EAR do projeto que voc elaborou no exerccio
anterior).
b. Descrio do risco.
c. Probabilidade.
d. Severidade.
e. Nvel de controle.
f. Significncia.
g. Estratgia para gerenciar o risco.
h. Plano de ao.
2. Como voc classificaria o risco geral do projeto: alto, mdio ou baixo? Justifique sua resposta com
base no resultado da anlise de riscos do exerccio anterior.
12
Aquisies
Entender e gerenciar o processo de aquisies de bens e servios do projeto por meio de um plano formal de
aquisies.
Conceito
Aquisies , provavelmente, uma palavra estranha para quem no est acostumado com os termos
de gerenciamento de projetos com base nos princpios do PMBOK. O termo em ingls procurement,
que designa o processo de adquirir mercadorias, trabalhos e servios de terceiros. O processo envolve
um ciclo completo desde a identificao das necessidades antes das contrataes at o fechamento
do contrato. As atividades normalmente realizadas no planejamento das aquisies do projeto sero
descritas a seguir (Tabela12.1).
Tabela 12.1 Atividades e Documento do Planejamento das Aquisies

Atividades para planejar as aquisies Documentos gerados
Decidir se as aquisies sero feitas internamente ou compradas
de fornecedores externos empresa.
Criar critrios de seleo de fornecedores e prestadores de servios,
Plano de Gerenciamento das Aquisies
selecionar fornecedores.
Definir o tipo de contrato para o projeto, bem como seus termos
e condies.
Como pode ser observado na Tabela12.1, a rea de aquisies complexa e envolve toda e qualquer
ao envolvida em compras, aquisies e contrataes para o projeto. O planejamento das aquisies
envolver a elaborao de um Plano de Aquisies em que todas as atividades da Tabela12.1 sero
detalhadas, conforme as necessidades do projeto e as prticas internas da empresa ou organizao.
Uma das aes mais importantes nas decises durante o planejamento das aquisies definir o
tipo de contrato que deve ser fechado com parceiros e fornecedores. O PMBOK prev trs tipos bsicos
de contratos:
1. Preo fixo ou contratos de preo fechado para contratos com um preo total fixo para um produto
bem definido.
2. Contratos de custos reembolsveis para contratos que envolvam o pagamento (reembolso) ao
vendedor pelos custos reais.
3. Contratos de preo unitrio, 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 servios ou vendedor
doproduto. O valor total do contrato uma funo das quantidades necessrias para concluir o
trabalho previsto no projeto.
163
Dentro de cada um desses tipos bsicos de contratos, h ainda subdivises 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, Jurdico e outros em
todos os aspectos relacionados s aquisies 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 Aquisies
Na prtica
Como mencionado anteriormente, a rea de aquisies de um projeto pode ser bastante complexa,
principalmente se o projeto envolver vrios fornecedores de produtos e servios. No se espera que
um gerente de projetos iniciante domine todos os aspectos relativos s aquisies, 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 condies de gerenciar o processo das
aquisies e definir o que precisa ser feito para poder acionar os recursos cabveis a cada situao que pode
ocorrer durante as aquisies de produtos ou servios, dependendo do tipo de projeto que estiver gerenciando.
O Plano de Gerenciamento das Aquisies dever definir claramente os papis e as responsabilidades
da equipe do projeto no que se refere aos produtos ou servios que sero adquiridos. O gerente do
projeto precisa identificar quem ter participao na gesto de fornecedores e terceiros e como sero
divididas as responsabilidades de forma a no sobrecarregar desnecessariamente sua equipe com essas
tarefas. necessrio que todos ajudem na gesto de fornecedores e terceiros, porque ser necessrio
o conhecimento tcnico de reas diferentes. Portanto, o papel do gerente do projeto fundamental
na definio da relao entre os membros da equipe do projeto, do departamento de compras, do
departamento jurdico e de outras reas que sero chamadas para auxiliar na gesto 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 relaes com os outros departa-
mentos da empresa, ser necessrio decidir o que dever ser fornecido por terceiros e quais as condies
desse fornecimento. Nesse caso, deve-se considerar as seguintes questes:
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 condies de ser fornecido na data estipulada no
cronograma?
3. Quais os itens que precisaro ter fornecedores externos ou ser realizados por terceiros?
4. Que tipos de fornecedores so os mais indicados para fornecer o que o projeto precisa?
5. Quem aprovar as aquisies?
O gerente do projeto, em conjunto com o departamento jurdico ou de compras da empresa (ou
outro departamento, conforme o caso), dever ento decidir que tipo de contrato dever ser utilizado,
dependendo do item que ser adquirido de fornecedores ou terceiros.
O prximo passo decidir como os assuntos relativos a fornecedores, terceiros e respectivos
contratos sero 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 responsvel pela deciso final. Normalmente, quando se trata de contratos de
grande porte, importante ter um processo de licitao formal para a escolha da empresa contratada.
Captulo 12 Aquisies 165
Aquisies 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 so, normalmente, definidos pelos
processos internos de cada empresa ou estipulados no plano de aquisies para cada projeto.
Aplicao
O Plano de Gerenciamento do Projeto (item 6.8) inclui as estratgias gerais que foram seguidas para
elaborar o seguinte Plano de Gerenciamento das Aquisies (Figura12.1):
FIGURA 12.1 Plano de Gerenciamento das Aquisies.

FIGURA 12.1 (Cont.)
Exerccios
Planejamento: Aquisies
Ana Maria Costa entrou em contato com trs fornecedores para os novos balces da loja e des-
cobriu que cada um tem pontos positivos e negativos. Em uma reunio com Carlos Peixoto, ela explica
a situao da seguinte forma:
Captulo 12 Aquisies 167
1. Fornecedor A
Custo na mdia do mercado.
Itens fornecidos de boa qualidade.
Reputao de no 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 reputao entre os clientes.
3. Fornecedor C
Custo 5% abaixo da mdia do mercado.
Itens fornecidos de qualidade varivel, pois trabalha com vrios fabricantes e sempre fecha
comomais barato, sem preocupao com a qualidade.
Entrega mais ou menos em dia; no consistente.
Reputao varia entre os clientes alguns deram referncias positivas, outros no.
Material de apoio
Baixe o arquivo Avaliao de fornecedor, na pasta Exerccios em Contedos extras, na pgina web
do livro (www.elsevier.com.br/martacamargo).
1. Avalie cada fornecedor com base nos critrios de avaliao do formulrio.
2. Qual fornecedor o melhor para o projeto da reforma da loja? Justifique sua resposta com base na
sua avaliao de cada fornecedor em funo das necessidades do projeto.
13
Partes Interessadas
Documentar e classificar a importncia de cada parte interessada, conforme a influncia de cada uma no projeto.
Definir estratgias para gerenciar e monitorar o envolvimento das partes interessadas nos diferentes
momentos doprojeto.
Conceito
A rea de conhecimento Partes Interessadas foi introduzida pela verso 5.0 do PMBOK, publicada
no incio de 2013. At a verso 4.0 do PMBOK, essa parte estava inclusa na rea de conhecimento
Comunicaes, que tratava da identificao e do gerenciamento das expectativas das partes interes-
sadas no projeto. A ideia por trs desse rearranjo do contedo das reas de conhecimento enfatizar
a importncia de se controlar mais de perto o nvel de envolvimento ou engajamento de cada parte
interessada durante o projeto. Em resumo, essa nova rea de conhecimento abrange as seguintes
atividades e documentos (Tabela13.1):
Tabela 13.1 Atividades e Documentos do Planejamento das Partes Interessadas

Atividades de planejamento das partes interessadas Documentos gerados
Continuar com a identificao e registro das partes interessadas Registro de Partes Interessadas
Elaborar o plano de gerenciamento com estratgias para Plano de Gerenciamento das Partes Interessadas
garantir o envolvimento das partes interessadas
A identificao das partes interessadas comea assim que o projeto aprovado e continua durante
a fase de planejamento. O objetivo dessa identificao registrar quem so as pessoas ou organizaes
que iro influenciar ou sero influenciadas pelo projeto e qual o seu nvel de importncia.
Alm disso, importante que o gerente do projeto defina um plano para gerenciar as partes interes-
sadas. Para cada parte interessada, dever haver uma atribuio clara de sua participao em decises
e atividades relacionadas ao projeto. responsabilidade do gerente de projeto controlar e reavaliar o
nvel de envolvimento ou engajamento, removendo partes interessadas em pontos do projeto nos quais
sua participao ou seu envolvimento no se fizer mais necessrio.
Na prtica
Partes interessadas so pessoas ou organizaes cujos interesses podem impactar ou influenciar o
projeto de forma negativa ou positiva. Muitas partes interessadas no estaro presentes no dia a dia
doprojeto, porm podero afetar o projeto de alguma forma, como, por exemplo: por meio de um veto
ou no autorizao 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 critrio popular entre gerentes de projetos
veteranos consiste em utilizar as questes abaixo para identificar partes interessadas relevantes a um
determinado projeto:
1. Essa pessoa ou organizao ser direta ou indiretamente afetada por esse projeto?
2. Essa pessoa ou organizao est em uma posio de influncia direta positiva ou negativa no projeto?
3. Essa pessoa ou organizao afetar a liberao dos recursos necessrios para a realizao do projeto
(material ou equipamento, pessoal ou dinheiro)?
4. Essa pessoa ter habilidades ou capacidades que sero essenciais ao projeto?
5. Essa pessoa ou organizao se beneficiar significativamente com o projeto?
6. Essa pessoa est em posio de oferecer resistncia s mudanas 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 organizaes que tero
uma participao ativa no projeto. Esse Registro de extrema importncia para projetos grandes e com-
plexos, com equipes em diversas localidades, inclusive em pases diferentes. desenvolvido logo no
incio do projeto e normalmente atualizado no decorrer do projeto, conforme se fizer necessrio. Para
projetos de mdio e pequeno porte, o gerente do projeto precisa tambm desenvolver um registro de
suas partes interessadas para controlar as expectativas e influncias de cada uma ao longo do projeto.
As informaes no Registro de Partes Interessadas podero variar no nvel de detalhes, dependendo
das necessidades e complexidade de um projeto, como dito anteriormente. Um formato genrico e fcil
de utilizar mostrado a seguir (Figura13.1).
FIGURA 13.1 Modelo genrico de um Registro de Partes Interessadas.

Captulo 13 Partes Interessadas 171
Aplicao
A equipe do projeto de sustentabilidade para a rede de supermercados A loja 1 comeou a registraras

partes interessadas do projeto logo aps a aprovao do Termo de Abertura. A seguir o formato em que
o Registro das Partes Interessadas se encontrava no planejamento do projeto (Figura13.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 no ter a ajuda, em especial com informaes durante o planejamento do projeto, ou ser ignorado
por uma parte interessada crucial para aprovaes de entregas-chave durante a execuo do projeto.
A primeira etapa na elaborao de um plano de gerenciamento de partes interessadas definir es-

tratgias para garantir a participao ativa ou o envolvimento efetivo dessas partes interessadas nas
diferentes fases do projeto. O objetivo principal dessas estratgias garantir o apoio das partesin-
teressadas, principalmente aquelas de maior influncia, e minimizar os impactos negativos de partes
interessadas que no apoiam o projeto.
As estratgias para gerenciar as partes interessadas se baseiam na avaliao do nvel de compro-
metimento e envolvimento de cada parte interessada cadastrada no Registro de Partes Interessadas do
projeto. No h uma frmula universal para fazer essa avaliao que pode, em muitos casos, depender
da experincia do gerente de projeto na empresa e sua atuao em projetos similares.
Indicadores de envolvimento ou engajamento de partes interessadas no projeto
Uma forma genrica e simples de avaliar as partes interessadas estimar qualitativamente em que
quadrante da matriz elas esto posicionadas, com base no seu desempenho no decorrer do projeto,
conforme ilustrado a seguir (Figura13.3).
FIGURA 13.3 Indicadores de envolvimento ou engajamento de partes interessadas.
No eixo vertical, a influncia 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=Mdia (3) parte interessada influencia alguns aspectos do projeto, pode afetar uma linha
de base.
B=Baixa (1-2) parte interessada no influencia as linhas de base do projeto, mas participar em
atividades do projeto.
No eixo horizontal, a participao seria avaliada com base no planejamento do projeto para aquela
parte interessada especfica e de acordo com as atividades do cronograma.
Para garantir o nvel de envolvimento adequado de cada parte interessada, durante o monitoramento
e controle do projeto o gerente de projeto analisar o desempenho, considerando seu nvel de influncia
e participao, e classificar seu nvel de envolvimento. Dependendo do resultado dessa anlise, o
gerente de projeto dever aplicar uma ou mais das estratgias descritas a seguir.
1. Alta influncia com baixa participao. Esse indicador reflete partes interessadas com
alta influncia que no esto participando das reunies ou no esto realizando as
atividades designadas a elas. Pode ser tambm aquelas que no estejam demonstrando
interesse em participar do projeto de forma ativa, conforme o planejado e o necessrio
para atingir os objetivos do projeto.
Estratgias: Nesse momento o melhor a fazer marcar uma reunio ou encontro com essa parte
interessada para entender o porqu da sua no participao ou falta de interesse no projeto e, em
conjunto, encontrar formas de aumentar o nvel de envolvimento. O gerente do projeto deve fazer o
possvel para explicar a ela a sua importncia dela no sucesso do projeto.
H casos em que as partes interessadas no entendem a importncia de sua participao, acredi-
tando que o gerente de projeto tenha condies de obter todas as informaes e recursos que precisa
para as necessidades do projeto. Cabe, ento, ao gerente de projeto esclarecer a funo de cada um,
principalmente no que se refere a informaes e a recursos necessrios para um bom planejamento e
uma boa execuo do projeto.
Outros casos podem refletir um levantamento errneo ou incompleto das expectativas dessas partes
interessadas. O fato de elas acreditarem que suas necessidades e desejos no estejam sendo atendidos
pode lev-las a perder interesse no projeto ou no acreditar nos seus resultados. importante rever as
expectativas no registro de partes interessadas para verificar se uma exigncia considerada essencial
de alguma parte interessada no se transformou em requisito obrigatrio do projeto ou se foi ignorada.
Se no for possvel atender a uma expectativa considerada essencial por uma parte interessada de
alta influncia, o gerente do projeto deve se esforar ao mximo para explicar o porqu dessa deciso
parte interessada, considerando os objetivos que se pretende atingir com o projeto e as restries
(principalmente de custos) sob as quais o projeto est sendo gerido.
2. Alta influncia com alta participao. Esse indicador reflete partes interessadas comalta
influncia e participao, o que leva a um alto nvel de envolvimento. Esse indicador
representa o mundo ideal em gerenciamento de projetos.
Estratgia: importante que o gerente de projeto mantenha essa parte interessada com o alto
nvel de envolvimento apresentado at ento. O gerente de projeto deve manter essa parte interes-
sada informada sobre o andamento do projeto, convid-la para reunies de planejamento e tomada
de deciso e comunicar-se com ela na forma em que ela deseja ser comunicada (conforme explicado
no captulo10 Comunicaes). O levantamento eficiente das expectativas dessas partes interessadas
ajuda o gerente do projeto a mant-las satisfeitas com relao aos seus desejos e necessidades para
com o projeto.
3. Baixa influncia com baixa participao. Esse indicador reflete partes interessadas com
baixo nvel de influncia e cuja participao no projeto est deixando a desejar.
Estratgia: Aqui a situao precisar ser analisada caso a caso. Por exemplo, se essa parte
interessada, apesar de no influenciar o projeto do ponto de vista das linhas de base, tiver uma par-
ticipao na execuo de atividades do projeto, o gerente de projeto dever, como sempre, primeiro
buscar os fatos para entender o problema e, depois, analisar a melhor soluo. Pode ser o caso de
providenciar um treinamento para essa parte interessada, troc-la por um recurso mais experiente,
aumentar a durao de alguma atividade, negociar melhorias nas condies do trabalho e assim por
diante. O importante identificar a causa central e delinear um plano de ao para resolver o pro-
blema assim que for detectado.
4. Baixa influncia com alta participao. Esse indicador reflete partes interessadas combaixo
nvel de influncia e alto nvel de participao. Essas partes interessadas, namaioria das
vezes, so especialistas que sero utilizados como fontes de informaes valiosas,
principalmente em reas que requerem conhecimentos tcnicos, por exemplo: rea
financeira ou rea de riscos.
Estratgia: sempre bom ter essas partes interessadas como participantes de reunies de planeja-
mento, monitoramento e controle para auxiliar o gerente de projeto no que for necessrio para garantir
que o projeto esteja no rumo certo. Elas precisam se sentir vontade para voluntariar informaes e
participar das decises em que possam contribuir de forma positiva e proativa.
5. Mdia influncia com mdia participao. Esse indicador reflete normalmente stakeholders
em nveis gerenciais que participaro apenas em determinados pontos do projeto ou
profissionais que so chamados para executar atividades em determinadas entregas do
projeto. Muitas vezes, so terceirizados e sua influncia se baseia em conhecimentos
tcnicos ou reas de especializao.
Estratgia: Esses stakeholders esto atuando no limite, ou seja, para o sucesso do projeto, eles
no podem diminuir sua participao ou acreditarem que no tm nenhuma influncia no projeto. O
gerente do Projeto deve mant-los atualizados das fases do projeto e incentivar a participao sempre
que necessrio.
Monitorando e controlando o envolvimento das partes interessadas
Como mostrado na Figura13.3, os quadrantes superiores devero ter a maior ateno do gerente do
projeto, pois so 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 comear
o projeto motivadas e com um alto nvel de envolvimento ou engajamento e, no decorrer do projeto, esse
nvel pode abaixar consideravelmente. Por exemplo, no monitoramento e controle de um determinado
projeto, o gerente de projeto notou que o gerente de TI no aprovou uma entrega prevista para uma
determinada data e faltou na reunio de andamento daquela semana. Ele uma parte interessada
com alta influncia naquele projeto cuja expectativa de participao era alta tambm. A matriz de
gerenciamento de partes interessadas demonstraria o nvel de envolvimento desse gerente de TI da
seguinte forma (Figura13.4):
FIGURA 13.4 Exemplo de uma matriz de gerenciamento de partes interessadas.
Importante
No nvel de participao, recomenda-se colocar o nvel 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 reunies de
andamento ou similar).
Dicas teis
Muito do sucesso do gerente de projeto em lidar com partes interessadas depender de suas habi-
lidades de comunicao 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 nveis abaixo ou acima
daorganizao realizadora do projeto, em organizaes externas ao projeto ou, at mesmo, emoutros
grupos de projetos da empresa, importante conhecer o que a motiva ou no comrelao ao projeto.
Nesse sentido, questes similares s listadas a seguir so teis para o gerente de projeto conhecer
melhor suas partes interessadas:
a. Qual a viso ou impresso que essa parte interessada tem do projeto?
b. Como essa parte interessada se sente em relao aos objetivos do projeto?
c. Como essa parte interessada se sente em relao a voc, gerente do projeto?
d. Como essa parte interessada pode influenciar outras que iro participar do projeto?
e. Qual a experincia que essa parte interessada tem com projetos similares ao seu?
f. Qual o histrico dessa parte interessada com projetos da sua rea (por exemplo: relao
colaborativa sempre apoia e participa com informaes e atividades; combativa discorda
de tudo e no quer fazer nada; reativa - sempre foge das reunies de planejamento e pede
mudanas durante a execuo, participativa durante o planejamento porm no participativa
na execuoetc.)?
2. Envolva suas partes interessadas o quanto antes possvel.
As respostas s questes acima permitiro uma leitura mais precisa de cada parte interessada
esuas expectativas. Por exemplo, aquelas com um histrico de resistncia a projetos da sua rea
e de constantes solicitaes de mudana durante a execuo precisaro ser envolvidas no projeto
desde o incio. Muitas vezes, partes interessadas influenciam o projeto negativamente porque no
entendem um componente ou uma abordagem que foi definida no incio do projeto e para a qual h
razes 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 restries 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 fcil se seu envolvimento comear
o quanto antes, fazendo com que todos caminhem juntos no sentido de atingir os objetivos
do projeto.
3. Oua atentamente o que as partes interessadas esto lhe dizendo.
Muitas vezes, quando ainda no somos experientes em gerenciamento de projetos, temos receio
de conflitos de opinio ou pontos de vista com relao ao projeto. Conflitos apresentam timas
oportunidades para entender o pensamento da parte interessada. Nessas ocasies, muito importante
ouvir atentamente o que a parte interessada est dizendo, seja na comunicao verbal, na escrita ou
na comunicao no verbal, como expresso facial, linguagem corporal ou gestos. Se houver alguma
indicao de resistncia ou objeo, importante dar a devida ateno para entender o ponto de vista
dessa parte interessada naquele momento e encontrar uma soluo em comum para resoluo do
problema o mais rpido possvel.
1
Estratgias inspiradas no artigo intitulado Os seis princpios de envolvimento de parte interessada (traduo livre de The
6principles of stakeholder engagement), de Sharma (2008).
4. Adote uma postura de colaborao mtua, no de coero.

importante que a parte interessada sinta-se como um membro da equipe, especialmente
se estiver representando uma organizao externa ao projeto, por exemplo: outro departamento,
empresa terceirizada ou fornecedor de produtos ou servios. Em muitos casos, usar coero
como, por exemplo, ameaar levar o assunto ao superior ou no trabalhar mais com um
prestador de servios, no resolve o problema no curto prazo e, muitas vezes, s piora a situao.
responsabilidade do gerente de projeto criar um ambiente de cooperao mtua entre todas
as partes interessadas do projeto.
O gerente do projeto deve se lembrar, tambm, que mesmo quando a influncia de uma parte
interessada pode no ser muito alta a princpio, essa influncia pode mudar no decorrer do projeto
devido a alguma circunstncia especial. Por exemplo, um membro da equipe de apoio responsvel por
uma entrega pequena pode ter que ajudar em outro componente de maior importncia que est no
caminho crtico 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.
Aplicao
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
(Figura13.5).
FIGURA 13.5 Matriz de Gerenciamento das Partes Interessadas.

FIGURA 13.5 (Cont.)
Exerccios
Planejamento: Partes Interessadas

No incio do projeto, Carlos Peixoto comeou a desenvolver um registro das partes interessadas do
projeto e registrou suas expectativas e influncias.
Material de apoio
Baixe o arquivo Registro de Partes Interessadas, na pasta Exerccios em Contedos extras, na pgina
1. Com base nas informaes das partes interessadas que aparecem nas descries dos exerccios
dos captulos anteriores a esse, d continuidade ao registro das partes interessadas do projeto
da reforma da loja de roupas femininas. Inclua possveis expectativas e influncias para cada
parte interessada com base nos cargos ou responsabilidades de cada uma com relao ao projeto.
Lembrete: Por ser uma atualizao do documento, a verso do registro passar de 1.0 a 1.1
e voc ter que documentar o motivo da atualizao no registro de alteraes do formulrio.
2. No monitoramento e controle do projeto, uma parte interessada com alta influncia no est
participando do projeto conforme o planejado. Que tipo de indicador apareceria na matriz
de gerenciamento das partes interessadas e qual a melhor estratgia para aumentar o nvel de
envolvimento dessa parte interessada com relao ao projeto?
PA RT E
IV
Realizando o projeto
Aps o planejamento de todas as reas de conhecimento, o projeto est pronto para ser realizado na
fase conhecida como execuo. medida que o projeto executado, ele ser monitorado e controlado
para garantir que o planejamento seja cumprido, principalmente no que se refere ao cumprimento daslinhas
de base de custo, tempo e escopo. Aps a concluso, o gerente do projeto precisa providenciar ofechamento
formal de todas as atividades relativas ao projeto, tanto no aspecto administrativo comonooperacional. Os
processos e procedimentos para a execuo, o monitoramento e o controle, bemcomo o encerramento de
um projeto, sero descritos nos captulos a seguir.
CAPTULO 14 Execuo.....................................................................................................................183
CAPTULO 15 Monitoramento e Controle.......................................................................................199
CAPTULO 16 Encerramento.............................................................................................................215
14
Execuo
Entender como as atividades planejadas para as seguintes reas de conhecimento so postas em prtica na fase
de execuo de um projeto: Integrao, Qualidade, Recursos Humanos, Comunicaes, Aquisies e Partes
Interessadas.
Conceito
A execuo de um projeto consiste basicamente em colocar em prtica tudo o que foi planejado.
Alm de produzir as entregas do projeto propriamente ditas, cinco reas de gerenciamento de projetos
entram em ao, conforme explicado a seguir (Tabela14.1).
Tabela 14.1 Atividades da Execuo de um Projeto

reas de conhecimento Atividades
Integrao 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.
Comunicao Gerenciar as informaes.
Partes interessadas Gerenciar as expectativas das partes interessadas.
Gerenciar as estratgias para manter um alto nvel de engajamento
ou comprometimento das partes interessadas, conforme o necessrio para
o sucesso do projeto.
Aquisies Realizar as aquisies e contrataes.
Na rea de integrao, a execuo significa colocar em prtica todos os planos das reas de co-
nhecimento de forma integrada (escopo, tempo, custos etc.). O trabalho do gerente de projeto nessa
integrao 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 execuo do projeto,
a fase de qualidade executada por vistorias ou auditorias para garantir que os padres normais de
qualidade estipulados para o projeto estejam sendo seguidos.
Durante a execuo de um projeto, cabe ao gerente de projeto conseguir os recursos humanos neces-
srios para realizar as atividades necessrias, conforme especificado no planejamento dos recursos
humanos. Porm, a obteno dessa equipe apenas um dos aspectos da gesto de recursos durante a
execuo. O gerente de projeto deve gerenciar a equipe de forma a ajud-la no que for necessrio para
que o projeto seja bem-sucedido. Por exemplo, se um membro da equipe estiver com dificuldades tc-
nicas de realizar as atividades a ele alocadas, o gerente do projeto poder providenciar um treinamento
adicional ou um suporte tcnico para auxiliar esse recurso no que for necessrio.
A rea de comunicaes fundamental para o sucesso da execuo de um projeto, especialmente
no que se refere ao gerenciamento das expectativas das partes interessadas. O gerente de projeto
devemanter as partes interessadas informadas sobre o andamento do projeto, conforme mtodos de
comunicao e frequncia definidos no planejamento das comunicaes do projeto. Partes interessadas
183
de grande influncia e impacto nos resultados do projeto devem ter prioridade sobre aqueles que s
pediram para ser informados ou que sero pouco influenciados pelo projeto. importante, tambm,
que o gerente de projeto gerencie as estratgias de envolvimento ou engajamento das partes interes-
sadas no projeto, conforme previsto no planejamento.
No que se refere rea de aquisies, cabe ao gerente de projeto gerenciar o processo de compras
de servios e produtos, dentro dos padres e das normas de cada empresa ou organizao, conforme
definido no Plano de Gerenciamento das Aquisies.
Na prtica
14.1 Problemas comuns e solues

Quando o planejamento do projeto feito de forma eficaz e interativa com a participao ativa das
partes interessadas, a execuo ocorre de forma tranquila e organizada, conforme descrito na parte
conceitual anterior.
Quando no possvel ter um planejamento eficaz e realista para o projeto, h mudanas cons-
tantes e retrabalhos durante a execuo, comprometendo as linhas de base do projeto. Normalmente,
problemas na execuo so resultados de um ou mais dos fatores descritos na Tabela14.2.
Tabela 14.2 Problemas Comuns na Execuo de Projetos com Solues

Problema Descrio Soluo
No participao das partes Quando as partes interessadas Antes de o projeto comear, o gerente do projeto
interessadas no tm 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, especficos e de gerenciamento de projetos adotada na
quantificados, elas tendem a solicitar empresa, antes de o projeto comear. O
mudanas ou ajustes durante a engajamento das partes interessadas na
execuo. Isso causa atrasos nos prazos metodologia de gerenciamento de projetos deve
e estouros no oramento. 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 gerncia 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 escalo da Sem um apoio claro do nvel Como dito no item anterior, sem um apoio
empresa estratgico da empresa, muitas de cima para baixo, a metodologia de
partes interessadas no percebem a gerenciamento de projetos de uma empresa no
importncia de participar do projeto tem como ser bem-sucedida. O gerenciamento
o mais cedo possvel ou de executar de projetos moderno requer um esforo
as atividades conforme planejado multidisciplinar de praticamente todos os setores
e designado. Em alguns casos, eles da empresa. Sem o apoio da alta gerncia, o
podem at achar que problema do gerente de projetos no tem como exigir ou
gerente do projeto que foi contratado esperar colaborao das partes interessadas com
s para fazer isso... relao ao projeto.
Captulo 14 Execuo 185
Problema Tabela 14.2 Problemas Comuns na Execuo de Projetos

Descrio Soluo com Solues (Cont.)
O gerente do projeto est em outro medida que o mundo se torna sempre recomendvel ter uma reserva no
local, distante do lugar onde o globalizado e o Brasil investe em obras oramento para viagens do gerente do projeto
projeto ser executado de infraestrutura em todo territrio 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 condies onde o projeto
ser executado em outro. necessrio ser executado, mesmo quando essas condies
haver um bom alinhamento entre as no sejam as ideais. melhor saber a realidade
necessidades de documentao do no planejamento e mitigar os problemas nos
projeto e a realidade das condies planos de ao aos riscos do que ser pego
locais onde o projeto ser executado, de surpresa depois, durante a execuo do
pois, do contrrio, a documentao do projeto. As equipes locais devem acreditar no
planejamento ser apenas proforma, planejamento para que os resultados desejados
sem utilizao real como preparao para o projeto sejam obtidos.
para a execuo bem-sucedida do
projeto.
No familiarizao 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 servios logsticos ou transportadoras), (de cima para baixo) do nvel estratgico da
trabalhar de acordo com uma empresa. Nesse nvel estratgico, necessrio
metodologia de gerenciamento de que j tenha sido detectada uma necessidade
projetos no faz parte da cultura de organizar os trabalhos no 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 no entender a Os colaboradores devem ser informados que
mudana de paradigma e esperar que algumas necessidades operacionais sero 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
importncia de cada um para atingir os objetivos
dos projetos e, consequentemente, da empresa.
Situao complicada da empresa Em alguns casos, o gerente de projeto Esse cenrio um dos mais difceis 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 gerncia. A nica coisa que o gerente de
no est indo bem ou est prestes a projeto pode fazer utilizar suas habilidades
ser comprada, ou qualquer outro fator em comunicao e negociao para obter a
organizacional que causa incertezas colaborao 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 no estiverem motivadas momentos de muita tenso, iniciativas simples
a fornecer informaes e participar do como oferecer pizzas e refrigerantes na reunio
planejamento do projeto, a execuo de requisitos pode gerar um vnculo de amizade
estar fortemente comprometida. por parte das partes interessadas em relao
ao gerente de projeto. Isso pode ajudar a
aliviar a tenso e motivar as partes interessadas
a participarem do projeto; se no for para o
benefcio da empresa, que seja como apoio ao
gerente de projeto.
(Continua)
Tabela 14.2 Problemas Comuns na Execuo de Projetos com Solues (Cont.)

Problema Descrio Soluo
Falta de experincia do gerente do Mesmo os gerentes de projetos Quando a empresa j trabalha com alguma
projeto veteranos, quando comeam 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 mudanas. H sempre que lhe permitir errar e corrigir em tempo.
um perodo de adaptao. Esse Quando a empresa no tem uma estrutura
perodo necessrio, pois comum o de gerenciamento de projetos, importante
gerente do projeto estar se adaptando contar com o apoio do alto escalo no que for
aos assuntos relativos ao produto do necessrio, durante o perodo de adaptao
projeto, do ponto de vista daquela (geralmente, por volta de 90 dias).
empresa, e cultura organizacional.
Nesse perodo de adaptao comum
que erros aconteam, principalmente
nacomunicao ou no gerenciamento
das expectativas das partesinteressadas.
Isso tende a gerar suposies
errneas durante o planejamento e,
consequentemente, retrabalho na
execuo.
Aplicao
A execuo do projeto sustentabilidade para a rede de supermercados A Loja 1 foi realizado

conforme os itens a seguir.
14.2 reas de conhecimento na Execuo

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 designaes de
responsabilidades da matriz RACI e alocaes do cronograma. O gerente do projeto gerenciou os
recursos conforme o planejamento do projeto.
Comunicao: As informaes foram distribudas conforme Esquema das Comunicaes.
Partes Interessadas: O gerente de projeto gerenciou o envolvimento das partes interessadas utilizando
as ferramentas desenvolvidas no planejamento do projeto.
Aquisies: Produtos foram adquiridos, conforme processos definidos no Plano de Gerenciamento
das Aquisies.
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 doprojeto
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 Excelncia em Varejo (GVcev) da Fundao Getulio Vargas (FGV-EAESP) realizou um
frum para o debate entre os principais interessados no assunto, a fim de criar um guia com as prticas
de sustentabilidade no varejo para funcionrios e consumidores. Esse guia, denominado Frum de
Varejo e Consumo Sustentvel: experincias, debates e desafios, atualmente um dos poucos materiais
disponveis e amplamente divulgados no Brasil sobre o tema. Dessa forma, esse relatrio considerou
esse guia a principal fonte de consulta.
De acordo com o Frum de Varejo e Consumo Sustentvel (2009), recentemente reconhece-se o fato
de que os padres de consumo vm 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 presso sobre os recursos disponveis no planeta e 2) cria um volume enorme de resduos
despejados no ambiente.
Ainda de acordo com o Frum de Varejo e Consumo Sustentvel (2009), as mudanas nos padres de
produo e consumo para formas mais sustentveis tm sido uma preocupao de ordem mundial, e
o varejo desempenha uma importante tarefa na realizao dessas mudanas, pois ele o elo da cadeia
de produo entre fornecedores e consumidores. Dessa forma, uma presso por mudanas vinda desse
setor tem um duplo efeito nos consumidores. Em primeiro lugar, h uma preocupao com a educao
dos consumidos no que se refere s prticas sustentveis nesse setor. Em segundo lugar, h uma neces-
sidade de satisfazer as necessidades dos consumidores j educados em prticas sustentveis, fornecendo
produtos que causem menos impactos ambientais e sociais.
Para se entender a importncia do tema sustentabilidade, pode-se considerar que 5% dos brasileiros
j so consumidores conscientes, segundo pesquisas do Instituto Akatu. A tendncia que esse nmero
aumente, uma vez que 28% dos consumidores so considerados envolvidos, ou seja, esto pelo menos
tentando consumir de forma sustentvel, e tambm outros 59% comeam agora a se sensibilizar com
o tema.
O Frum diz que esse processo de conscientizao uma oportunidade recente que agora comea
a ser explorada pelos varejistas, o que constitui oportunidades de entrada para o varejo sustentvel em
trs reas:
Operao e lojas sustentveis

possvel iniciar o controle e gerenciamento de impactos socioambientais desde a construo at a
operao das lojas. Conforme o Frum de Varejo e Consumo Sustentvel (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 consistncia e servir como exemplo para os outros
vnculos da cadeia de valor.
Gerenciamento da cadeia produtiva
Por meio de incentivos, os fornecedores podem desenvolver produtos com diferenciais ambientais e
sociais, alocando esforos para tornar a cadeia produtiva mais sustentvel. Assim possvel tambm
encorajar fornecedores locais, desenvolvendo a comunidade local, em detrimento das grandes
indstrias.
Educao para os consumidores
O varejo o lugar onde os consumidores podem ser incentivados a comprar produtos sustentveis
e serem educados em relao ao correto descarte de materiais, entre outros aspectos da educao
ambiental. O varejo pea fundamental para a mudana de comportamentos no consumo, pois
o local que est em contato direto com o cliente.
O Frum de Varejo e Consumo Sustentvel (2009) concluiu que o setor varejista comea a perceber
que precisa assegurar sua participao no campo da sustentabilidade, mas ainda h o temor em com-
prometer seu desempenho econmico. At agora, tudo indica que o consumidor deseja participar e
contribuir com a construo de um mundo melhor e mais consciente. O varejista que souber aproveitar
essa oportunidade certamente obter apoio dos clientes e da sociedade.
Princpios de sustentabilidade no varejo

A sustentabilidade um tema abrangente que aparece em todas as reas do varejo, o que ocasiona
uma certa confuso em relao a algumas ideias. Um conceito muito bem aceito atualmente e
adotado no Frum de Varejo e Consumo Sustentvel (2009) o criado pelo The Natural Steps (TNS),
organizao internacional sem fins lucrativos, segundo o qual os princpios de sustentabilidade foram
desenvolvidos com o objetivo de representar limites do sistema natural da Terra. Esses princpios
foram desenvolvidos ao longo de 20 anos de pesquisa, envolvendo acadmicos de alto nvel na rea
ambiental e natural, e o mais adotado pelas empresas que abraam a causa.
A ONG The Natural Steps apresenta trs princpios que abrangem uma combinao do que uni-
versalmente aceito nos campos de geologia, biologia, ecologia, fsica e qumica. So eles:
1. Na sociedade sustentvel, a natureza no est submetida ao aumento de concentraes de recursos

extrados da crosta terrestre:
Este princpio lida com o envenenamento do ambiente. Por bilhes de anos, a Terraseajustou
em um processo lento de sedimentao que mudou muito a composio da vida, gerando
um equilbrio perfeito que possibilitou a vida como a conhecemos. Ao retirarmos recursos do
ambiente e desregularmos essa composio qumica, h um alto risco de envenenamento, porm
muito difcil de se medir.
2. Na sociedade sustentvel, a natureza no est submetida ao aumento de concentraes dematerial
transformado pela sociedade:
Assim como no primeiro princpio, a questo aqui o envenenamento do ambiente. Porm,
aqui trata-se de elementos artificiais que sequer existem na composio qumica da vida.
Alguns desses elementos artificiais sequer decompem-se no ambiente, e aqueles que o fazem
quase sempre deixam para trs compostos artificiais que elevam o risco de envenenamento.
preciso evitar que esses materiais cheguem at o meio ambiente, o que ocasionaria enormes
prejuzos.
3. Na sociedade sustentvel, a natureza no est submetida ao aumento da degradao dos meios
fsicos:
Diferentemente dos dois primeiros princpios, esse ltimo trata da destruio fsica do meio
ambiente. Estima-se um limite para que os ecossistemas essenciais vida na Terra sobrevivam
destruio causada por atividades da sociedade. Essa destruio fsica refere-se s estruturas dos
ciclos naturais, como rios, mares, montanhas e campos. Tambm trata da biodiversidade, da qual
somos dependentes. Alguns exemplos so os grandes cortes de madeira em reas florestais, grandes
capturas de peixe etc.
Como possvel perceber, os princpios so declarados em forma negativa. Isso ocorre porque seria
invivel conceber princpios dizendo o que se espera que se faa quanto sustentabilidade. Isso tambm
ocorre por conta dos objetivos pretendidos com esses princpios, ou seja, colocar limites e barreiras ao
desempenho das atividades do homem.
Uma pergunta que surge naturalmente ao se aprofundar o tema sustentabilidade a questo da
dimenso econmica. Como ela fica nessa histria toda? Responder a essa pergunta mais fcil do que
se pensa... Diferentemente do que se pensava no passado, atitudes sustentveis hoje deixaram de ser
um peso para a cadeia produtiva. Ser sustentvel passou a ser uma ideia incorporada ao pensamento
estratgico das empresas.
Certificaes ambientais
As certificaes ambientais usuais para o setor do varejo no so aquelas j usualmente conhecidas
aplicadas s indstrias de transformao como um todo, como a ISO 14001 e as regulamentaes da
CETESB, Companhia Ambiental do Estado de So Paulo, que j atua fortemente no sentido de minimizar
impactos ambientais por conta da transformao de bens.
Quando se fala em varejo, no se pensa nos seus consequentes impactos ambientais, visto que
por natureza ele somente um intermediador de negcios entre a indstria e o consumidor final. As
prticas de ideias sustentveis no varejo esto, 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 construo civil para o meio ambiente e prega formas
de construo sustentveis.
Atualmente, o GBC encontra-se em 14 pases, incluindo o Brasil, onde certifica construes feitas
de forma sustentvel com o LEED (Leadership in Energy & Environmental Design), de acordo com os
critrios estabelecidos para a racionalizao e mxima reduo da utilizao de recursos naturais, como
gua e energia eltrica. O LEED hoje a certificao sustentvel mais conhecida e almejada no Brasil,
no que se refere construo de prdios e infraestruturas sustentveis.
Pacote de trabalho: 1.2.2 Pesquisa de campo
Nosso principal estudo benchmarking focou na loja verde do Po de Acar, situada na cidade de
Indaiatuba, estado de So Paulo, onde aps um investimento de 7,5 milhes de reais, foi montado o
primeiro supermercado verde da Amrica Latina. O supermercado de Indaiatuba rene iniciativas de
sustentabilidade de todo o Grupo Po de Acar e isso configura um diferencial da loja na regio, ao
mesmo tempo em que serve de um piloto para outras lojas similares do grupo.
Nesse supermercado do Po de Acar em Indaiatuba, desde o projeto inicial at seu funciona-
mento, houve uma preocupao com o meio ambiente. A construo da loja foi planejada com base
nos pr-requisitos exigidos pelo GBC Green Building Council para a certificao LEED, que garante
que a infraestrutura 80% sustentvel.
Em visita loja no dia 3 de maro de 2010, pde-se notar todas essas iniciativas, comeando pelo
cho do estacionamento, onde h um sistema de concregrama, um concreto vazado que permite a
absoro mais rpida da gua e alimenta os lenis freticos. H tambm espaos diferenciados no es-
tacionamento para veculos com biocombustvel, bem como espaos reservados para bicicletas. Ainda
no estacionamento, h estaes de reciclagem (leo de cozinha, plsticos, papel, vidro e metal), e vagas
reservadas para facilitar as entregas dos produtos reciclveis. Um paisagismo diferenciado em torno do
prdio utilizou plantas nativas da rea e espcies tpicas da regio.
Para economia de energia, a iluminao do interior da loja feita com um nmero bastante reduzido
de lmpadas. Todas as lmpadas so acompanhadas por uma calha refletora, que garante uma maior
eficincia na luminosidade. As telhas possuem uma capacidade refletiva e uma manta isotrmica,
fazendo com que o ar-condicionado seja mais eficiente e proporcione uma economia de at 10% de
energia, proporcionando o conforto trmico.
Considerando ainda a infraestrutura da loja, para evitar a eliminao de fluidos gasosos dos re-
frigeradores e congeladores que normalmente causam danos camada de oznio, 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 mquinas, economizando cerca de 48 mil kW/h por ms. O mobilirio da loja
feito de madeira de reflorestamento certificada, com selo FSC, que garanteuma extrao sustentvel
das florestas.
Os carrinhos utilizados para fazer as compras so todos feitos da reciclagem de garrafas PET. As
compras dos clientes podem ser colocadas em sacos de papel kraft certificado ou em caixas de papelo
que embalam as mercadorias da loja (e que antes eram descartadas) ou ainda em sacolas retornveis
feitas de lona, utilizando-se tambm sacolas plsticas biodegradveis. 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 disposio de mais de 750 produtos considerados orgnicos, naturais e sustentveis na loja, dos
quais 400 j so comercializados nas outras lojas da rede e 350 so exclusivos da loja de Indaiatuba.
A padaria faz pes com farinhas orgnicas; no aougue h carnes certificadas com garantias de que
os animais no foram alimentados com hormnios; as frutas, verduras e legumes orgnicos so
comercializados no apenas no formato embalado, mas tambm a granel, garantindo uma melhor
qualidade. Outra iniciativa adotada na loja de Indaiatuba foi a comercializao de produtos artesanais
locais, incentivando assim a economia da regio.
Outro exemplo prtico que a equipe no 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 no tenha sido possvel visitar a loja no Rio, a equipe assistiu ao vdeo disponvel
no site da empresa (conforme endereo eletrnico nas Referncias), que mostrou iniciativas similares
s do Po de Acar.
Alm dessas grandes redes que esto investindo em construo de lojas totalmente sustentveis,
a equipe verificou que outras redes apresentam algumas iniciativas, como o Extra e o Carrefour, que
contam com estaes de reciclagem do lixo e sacolas retornveis.
Entrega: 1.3. Pesquisa junto aos clientes
Pacote de trabalho: 1.3.1 Elaborao do questionrio
Para a elaborao do questionrio, optamos por questes objetivas que pudessem ser facilmente
tabuladas em uma planilha MS Excel. Paulo elaborou as questes com base nas sugestes e ideias de
todas as partes interessadas. Decidimos focar em sete questes bsicas para ter um perfil genrico dos
clientes da loja 1da rede de supermercados A e descobrir o que esses clientes pensam com relao a
prticas de sustentabilidade que afetam diretamente o setor de varejo (Figura14.1).
FIGURA 14.1 Questionrio para coleta de informaes.

Pacote de trabalho: 1.3.2 Aplicao do questionrio

Paulo ficou encarregado de aplicar o questionrio junto aos clientes. O questionrio foi respondido
em forma de entrevista aos clientes da loja no dia da pesquisa. A aplicao levou oito horas, e foram
entrevistados 80 clientes.
Pacote de trabalho: 1.3.3 Tabulao dos dados
Os dados foram tabulados manualmente em uma planilha do MS Excel, conforme exemplo a seguir
(Figura14.2).
FIGURA 14.2 Exemplo de tabulao dos dados.
Pacote de trabalho: 1.3.4 Elaborao do relatrio

Com base nos dados coletados, a equipe de projeto elaborou o relatrio a seguir.
Relatrio do resultado da pesquisa com os clientes da rede A
Este o relatrio com o resultado da pesquisa e nossos comentrios:
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 questo (supermercado) atende atualmente todas as faixas
etrias, com nfase populao adulta com idade entre 22 a 44 anos. Esse indicador apresenta-se como
tima oportunidade para que a rede de supermercados A adote prticas sustentveis, com projetos
educacionais elaborados para educar ambientalmente crianas e adolescentes.
2. Qual seu sexo?
Masculino 50,00%
Feminino 50,00%
Esse resultado mostra que, contrariamente percepo popular, supermercados no so frequenta-
dos por uma maioria de mulheres. Hoje em dia, ambos os sexos compram produtos de supermercado em
um nmero igual. Dessa forma, aes de sustentabilidade tero um pblico-alvo sem distino de sexo.
3. Com qual frequncia voc faz compras?
Diria 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%
No 31,25%
Se sim, onde voc pratica?
Casa 62,82%
Trabalho 29,49%
Igreja 6,41%
Escola 1,28%
O resultado dessa questo um fator motivador para a implantao de prticas sustentveis na rede A.
Os nmeros indicam que grande parte dos clientes j incorporaram hbitos sustentveis em sua rotina.
5. Como voc considera a sua preocupao com prticas sustentveis no seu dia a dia?
Muito alta 18,75%
Alta 53,75%
Baixa 23,75%
Muito baixa 3,75%
Outro fator fundamental em nossa anlise: os resultados demonstram uma grande preocupao dos
clientes com sustentabilidade.
6. No momento da compra, voc d preferncia para produtos sustentveis?
Sim 42,50%
No 57,50%
Esses nmeros refletem que, no momento, ainda no hbito entre os clientes demonstrar pre-
ferncia por produtos verdes em supermercados. Uma possvel causa pode ser a falta de oferta de
produtos sustentveis, com a mesma variedade na qual produtos no sustentveis so oferecidos nos
supermercados da rede A.
7. Voc considera importante seu supermercado adotar prticas sustentveis?
Sim 98,75%
No 1,25%
O resultado dessa questo confirma a importncia de se adotar prticas sustentveis na rede A para
atender s expectativas dos clientes que, na sua grande maioria, consideram importante as prticas
sustentveis no supermercado.
Concluso
A loja 1da rede de supermercados A atende a todas as faixas etrias, com uma alta rotatividade
de clientes. Mesmo considerando iniciativas simples, como a reciclagem de materiais, a pesquisa
demonstra que, seguindo uma tendncia mundial, os clientes esto 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 adoo de prticas sustentveis na rede
de supermercados A, que assim pode atender s expectativas dos clientes atuais e atrair novos clientes
que do preferncia a estabelecimentos comerciais que incorporam prticas de sustentabilidade em
sua rotina operacional.
Entrega: 1.4 Proposta de implantao
Pacote de trabalho: 1.4.1 Levantamento de opes de sustentabilidade
Aps anlise das informaes coletadas por meio do benchmarking e da pesquisa de campo, a equipe
elaborou a seguinte lista com ideias candidatas implantao na rede A loja 1:
Caixa de papelo em substituio s sacolas plsticas no caixa.
Produtos sustentveis.
Ponto de coleta de reciclagem.
Sacola retornvel.
Sacola biodegradvel.
Aproveitamento do calor dos freezers.
Cobertura com manta trmica.
Energia solar.
Telha transparente.
Captao de gua da chuva.

Caixa verde (depositar embalagens).
Carrinhos produzidos com matria-prima oriunda de garrafas PET.
Cartazes.
Torneiras automticas para evitar desperdcio de gua.
Projetos educacionais com crianas da rede pblica.
Distribuio de sacolas retornveis.
Treinamento de funcionrios.
Utilizao de materiais reciclveis nos setores administrativos.
Visitas monitoradas s lojas da rede.
Uso de combustveis provenientes de fontes renovveis (etanol) na frota de veculos.
Divulgao via site, revistas e jornais.
Calhas receptoras nas lmpadas.
Parcerias com fornecedores com a cultura de sustentabilidade.
Mural com antes e depois.
Jornal ecolgico divulgando as atividades desenvolvidas no ms.
Tratamento do esgoto.
Dia verde.
Plantio de rvores.
Slogan verde.
Uniforme verde.
Pacote de trabalho: 1.4.2 Anlise das opes de sustentabilidade
A primeira anlise consistiu em passar todas as ideias por critrios bsicos de seleo, em vista das
limitaes dos requisitos da estrutura fsica da loja 1, do oramento disponvel e potencial de marketing
junto aos clientes da rede. Um exemplo de como essa anlise foi realizada pode ser visto na figura
acima (Figura14.3).
FIGURA 14.3 Exemplo de anlise das opes de sustentabilidade.

FIGURA 14.3 (Cont.)
Em seguida, a equipe analisou cada opo aprovada na anlise de viabilidade anterior usando o
mtodo 5W2H, para priorizar os seguintes itens considerados viveis:
What O que ser feito (etapas)
Where Onde ser feito (local)
Why Por que ser feito (justificativa)
How Como ser feito (mtodo)
Who Por quem ser feito (responsabilidade)
When Quando ser feito (tempo)
How much Quanto custar fazer (custo)
Exemplos dessas anlises encontram-se nas figuras a seguir (Figuras14.4 e14.5):
FIGURA 14.4 Exemplo de anlise de viabilidade, utilizando o mtodo 5W2H.

FIGURA 14.4 (Cont.)
FIGURA 14.5 Exemplo de anlise de viabilidade, utilizando o mtodo 5W2H.
Pacote de trabalho: 1.4.3 Seleo das opes viveis

Aps as anlises de cada ideia feitas no item anterior, e considerando tambm o oramento deter-
minado para essa parte do projeto, as seguintes aes de sustentabilidade foram consideradas as mais
viveis para o projeto:
1. Adaptao das instalaes
a. Seo para produtos sustentveis construir prateleiras em uma rea no supermercado voltada
somente para produtos com apelo sustentvel.
b. Caixas de papelo Fazer uso das embalagens dos produtos para acondicionamento das compras
dos clientes em vez de utilizar sacolas plsticas.
2. Instalao ou aquisio de novos itens

a. Estao de coleta de lixo reciclvel local onde os clientes jogariam lixo reciclvel (garrafas, papel,
plstico etc.).
b. Sacolas retornveis encomendar sacolas retornveis confeccionadas com material reciclado ou
pano, para eliminar o uso de sacolas plsticas.
c. Sacolas biodegradveis encomendar sacolas biodegradveis para substituir o uso de sacolas
plsticas, para os clientes que no queiram caixa de papelo (gratuita) e no tenham sacola
retornvel (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 cdigo de barra).
d. Caixas verdes encomendar caixas para descartes de embalagens no ponto do caixa.
e. Mural com antes e depois mural apresentando as mudanas ocorridas aps a adoo das prticas
sustentveis na loja 1.
3. Marketing
a. Cartazes ambientais cartazes informativos, mostrando aos clientes prticas ambientais para
ajudar na conscientizao ambiental.
b. Banners com um slogan verde para a loja, chamando a ateno dos clientes para o fato de que
a rede de supermercados A est engajada em iniciativas de sustentabilidade.
c. Folhetos folhetos com fotos e descries das aes realizadas na loja 1.
d. Evento de plantio de mudas de rvores.
4. Treinamento em sustentabilidade
Preparar e ministrar um workshop mostrando as adaptaes e as melhorias do supermercado e
a importncia de entender e explicar as iniciativas de sustentabilidade aos clientes. O gerente do
projeto contatou, junto prefeitura da cidade, um especialista na Secretaria de Educao que visita
organizaes e ministra workshops sobre sustentabilidade.
1.4.4 Apresentao da proposta
As iniciativas anteriores foram apresentadas ao dono da rede de supermercados A. Foram aprovadas
todas as ideias, com exceo do evento do plantio das rvores, que ficou para outro momento, no
qual todas as lojas da rede estiverem engajadas em prticas de sustentabilidade.
1.5 Implantao
1.5.1 Infraestrutura
1.5.1.1 Instalao de novos itens
Os novos itens foram adquiridos pelo Departamento de Compras e instalados pelo Departamento de
Manuteno. A loja 1 passou a ter, ento, um conjunto (kit) de coleta seletiva com cinco cestos (100L)
no estacionamento; quatro caixas verdes, instaladas prximo aos pontos de caixa normais; sacolas
retornveis, colocadas nos caixas, e sacolas de plstico biodegradveis.
1.5.1.2 Adaptao dos itens existentes
Prateleiras foram instaladas para display de produtos verdes, placas foram colocadas para sinalizar a
seo verde da loja, e um mural explica as iniciativas e como a populao pode contribuir com elas. Um
espao para caixas de papelo foi reservado para ficar disposio dos clientes. Tomou-se o cuidado de
no utilizar caixas de produtos de limpeza ou outros produtos que pudessem contaminar os produtos
alimentcios com resduos qumicos.
1.5.1.3 Inspeo
Com base em uma lista de verificao (checklist) elaborada pelo supervisor da manuteno em
conjunto com o gerente do projeto, foi feita uma inspeo nos itens instalados e adaptados para cons-
tatar se tudo foi feito de forma correta, dentro dos princpios de sustentabilidade e sem causar danos
s outras instalaes 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 durao de uma hora, realizado na sala de
reunies da loja 1.
1.5.2.2 Filmagem do treinamento

A filmagem do workshop foi feita por um profissional especializado da empresa Z. O vdeo foi editado,
formatado, gravado em DVD e entregue ao gerente de projeto para utilizao na orientao de novos
funcionrios, fornecedores e clientes.
1.6 Marketing
1.6.1 Definio do material
Para auxiliar na deciso sobre quais itens produzir, em vista da restrio 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 opes de promoo da iniciativa de
sustentabilidade da rede A. Esse miniplano considerou os requisitos levantados no planejamento e a
experincia 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 tambm pensou-se em uma aparncia consistente para eles.
Foram includas fotos dos itens adaptados e instalados, e, no folheto, uma seo de Voc Sabia? com
informaes sobre os danos que materiais no reciclveis esto fazendo na natureza e o que cada um
pode fazer para melhorar esse cenrio. Os itens confirmados para produo foram: cartazes, banners
e folhetos.
1.6.2 Produo
A produo do material foi feita por uma equipe especializada da empresa Z, responsvel tambm
por tirar as fotos da loja e incorpor-las ao material.
1.6.3 Distribuio
Os cartazes foram colocados em pontos estratgicos da loja. Banners foram colocados na entrada
da loja e no estacionamento. A distribuio dos folhetos foi feita em todas as lojas da rede A em stands
colocados prximo ao setor de atendimento ao cliente na entrada da loja.
Exerccio
Execuo
O projeto da reforma da loja est em fase de execuo.
1. Qual a importncia do gerenciamento das reas de comunicaes e partes interessadas na Execuo
de um projeto?
2. Com base na descrio dos problemas mais comuns que ocorrem durante a execuo dos projetos
discutidos neste captulo, determine quais tipos de problemas podem ocorrer na execuo do projeto
da reforma da loja. Como Carlos Peixoto pode resolv-los?
15
Monitoramento e Controle
Entender e desenvolver mtodos e ferramentas para monitorar e controlar as atividades das reas de
conhecimento: integrao, escopo, tempo, custo, qualidade, comunicao, riscos, aquisies 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 (Tabela15.1).
Tabela 15.1 Atividades e Documentos do Monitoramento e Controle de um Projeto

reas de conhecimento Monitoramento e controle Documentos
Integrao Monitorar e controlar o trabalho Plano de Gerenciamento do Projeto
Realizar controle integrado de mudanas
Escopo Verificar escopo EAP e Dicionrio da EAP
Controlar escopo
Tempo Controlar cronograma Cronograma
Custo Controlar custos Oramento
Qualidade Realizar o controle da qualidade Listas de Verificao (Checklists) e
Matriz de Rastreabilidade de Requisitos
Comunicaes Reportar desempenho Plano de Comunicao
Relatrios de Desempenho
Atas de Reunies
Riscos Monitorar e controlar os riscos Anlise de Risco
Aquisies Administrar os contratos Plano de Gerenciamento das Aquisies
Partes Interessadas Monitorar e controlar o nvel 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 rpido possvel aps uma necessidade ter sido
detectada. A fase de monitoramento e controle consiste basicamente em coletar informaes sobre
as diversas reas do projeto para constatar se esto seguindo o planejado e produzindo os resultados
esperados nas reas de conhecimento do projeto, conforme resumo na Tabela15.1.
No monitoramento e controle, o gerente do projeto coleta e comunica informaes sobre desempe-
nho de todas as reas do projeto. Ele responsvel, tambm, por comparar o desempenho realizado
com o desempenho planejado, analisar as varincias, avaliar tendncias para melhorar os processos no
futuro, avaliar possveis alternativas e recomendar medidas corretivas, conforme o necessrio.
199
Na prtica
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 antecedncia, pois no
uma boa prtica surpreend-las com convites para participarem de reunies nas quais as partes no
sabem do propsito ou s quais comparecem sem estarem preparadas com as informaes necessrias.
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. Integrao
Todos os processos e procedimentos do projeto j foram descritos no Plano de Gerenciamento do
Projeto que inclui, tambm, o Processo de Gerenciamento de Mudanas. A integrao de todos os
componentes previstos no plano deve ser monitorada de perto, mediante reunies semanais ou com
outra frequncia, conforme a necessidade do projeto.
A ideia do monitoramento e controle na integrao acompanhar de perto se tudo o que foi previs-
to no Plano de Gerenciamento do Projeto est acontecendo conforme o planejado. Caso no esteja,
o gerente do projeto deve fazer os ajustes necessrios. Lembrando que, conforme descrito no Plano
de Gerenciamento do Projeto, nenhuma mudana na linha de base pode ser efetuada sem as devidas
aprovaes.
2. Escopo
Para ser considerado bem-sucedido, o projeto no pode sair da linha de base. A linha de base do
escopo formada pela Declarao de Escopo, a EAP e o Dicionrio da EAP. O escopo do projeto deve
refletir o mapeamento dos componentes que constam na EAP, e as atividades relativas aos pacotes
detrabalho devem estar acontecendo conforme descries do Dicionrio da EAP.
3. Tempo
As atividades devem estar acontecendo conforme o previsto no cronograma, principalmente as
atividades no caminho crtico. O gerente do projeto pode fazer esse acompanhamento de vrias formas,
junto aos membros da equipe do projeto na reunio semanal de andamento do projeto ou, at mesmo,
utilizando uma ferramenta eletrnica no servidor ou na internet (quando concluda uma atividade, ela
seria assinalada na ferramenta). Tudo depender de como os sistemas de apoio s equipes degerencia-
mento dos projetos da empresa esto configurados.
O gerente do projeto pode fazer ajustes no cronograma, desde que seja nos casos em que esses ajustes
no afetem a linha de base de tempo do projeto. Outros ajustes devero passar pelo processo formal de
gerenciamento de mudanas, 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 esto configurados. Para projetos de pequeno ou mdio 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.
Captulo 15 Monitoramento e Controle 201
No controle dos custos, importante observar que mesmo quando o oramento est no azul,
necessrio analisar o custo versus o trabalho realizado. Nesse sentido, custos e tempo andam de mos
dadas durante a execuo de um projeto. Por exemplo, as atividades do cronograma podem estar em dia,
porm se o oramento j estourou e ainda faltam 50% das atividades do projeto, o projeto no est em
dia. Da mesma forma, se ainda h dinheiro no oramento, mas as atividades esto atrasadas, o projeto
tambm no est em dia, pois esse atraso vai custar dinheiro.
5. Qualidade
O controle da qualidade feito por meio de inspees peridicas com o objetivo de garantir que
esto sendo satisfeitos os padres de qualidade, conforme o planejado. No monitoramento e controle
da qualidade, haver a aceitao ou rejeio das entregas por meio de listas de verificao 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 tambm.
6. Comunicaes
O monitoramento e controle da comunicao trata da coleta de informaes relativas ao trabalho
em andamento, anlise dessas informaes e envio s partes interessadas. Os relatrios de desempenho
devem incluir informaes relativas s linhas de base, ou seja, custo, tempo, escopo e qualidade, alm
de serem customizados para a necessidade de informao das partes interessadas.
Em um nvel iniciante em gerenciamento de projetos, o documento mais utilizado para relatar
informaes de desempenho o Relatrio de Status ou Andamento do Projeto, conforme modelo
definido no planejamento das comunicaes do projeto. Um modelo desse relatrio pode ser utili-
zado tambm como ata de reunio, e enviado s partes interessadas aps as reunies de andamento
doprojeto.
Muito do monitoramento e controle dos projetos feito em reunies. Reunies so fundamentais
para que o gerente do projeto e sua equipe sintam o pulso do projeto e resolvam problemas no ato
ou antes que aconteam.
um erro comum e grave fazer reunies apenas para cumprir tabela, ou seja, apenas por
formalidade. Reunies so de extrema importncia para manter a comunicao fluindo entre todos os
participantes do projeto.
Outro erro comum no fazer atas de reunies ou enviar atas dias depois da reunio. Uma soluo
seria publicar as atas em uma intranet ou servidor do projeto, logo aps a realizao da reunio.
importante tambm que os participantes da reunio recebam o convite para a reunio com a devida
antecedncia 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 reunio ou cuja participao
fundamental naquele ponto do projeto.
Algumas regras gerais devem ser seguidas para garantir que as reunies realizadas durante o moni-
toramento e controle de um projeto sejam produtivas a todos:
1. A frequncia em que as reunies de monitoramento do projeto devem acontecer e a indicao de
quem deve participar dessas reunies devem ser planejadas na rea de conhecimento Comunicaes.
As partes interessadas devem estar cientes desse planejamento e concordar com o esquema proposto.
Conflitos devem ser resolvidos no planejamento das comunicaes do projeto, e no durante o
monitoramento e controle da execuo do projeto.
2. O gerente do projeto pode agendar todas as reunies do projeto automaticamente no sistema de
e-mails da empresa. Se no houver um, o gerente do projeto pode desenvolver um processo ou
sistema manual de agendar as reunies e verificar a disponibilidade das partes interessadas em
participar dessas reunies.
3. A pauta da reunio deve ser enviada aos participantes com pelo menos 48 horas de antecedncia.
Caso haja necessidade, o gerente do projeto pode solicitar que certas partes interessadas venham
preparadas para a reunio com as informaes que sero necessrias em algum item da pauta.
4. sempre uma boa ideia incluir o agendamento das reunies no cronograma oficial do projeto, para
que os recursos que iro trabalhar no projeto se planejem e participem de todas as reunies para as
quais estejam agendados.
Dicas
Aqui vo algumas dicas para evitar as armadilhas das reunies malsucedidas:

1. NO utilizar as reunies s para saber o que cada um est fazendo. As atividades de cada um j esto
definidas no cronograma. A reunio deve ser utilizada para resolver problemas ou imprevistos que
saem do que foi planejado e discutir assuntos do interesse de todos.
2. NO utilizar as reunies para atualizar cronogramas, custos etc., ou realizar qualquer atividade
de atualizao ou realizao de documentao do gerenciamento do projeto. Os participantes da
reunio percebem quando o gerente do projeto utiliza o tempo da reunio para trabalhar em vez
de interagir com a equipe de projeto e resolver problemas. Trabalhos resultantes de discusses nas
reunies so itens de ao que devero ser realizados aps a reunio.
3. NO ultrapassar o tempo alocado para a reunio. As partes interessadas de um projeto no gostam
de se sentir refns de reunies ou de gerentes de projetos que no conseguem gerenciar seu prprio
tempo!
4. NO 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 reunio ou pessoalmente com voc aps
a reunio.
5. NO deixar que os participantes levem notebooks nas reunies. Se houver informao em documentos
que dever ser apresentada durante essa reunio, o participante da reunio dever enviar a voc
com antecedncia para sua visualizao. De qualquer forma, reunies de andamentono so
reunies de apresentaes tcnicas. Talvez seja melhor tratar do assunto em outro momento
e local.
6. NO deixar que os participantes atendam telefones celulares durante a reunio. Pea a colaborao
de todos no cumprimento de algumas regras bsicas de etiqueta no trabalho.
7. NO entrar em conflito com partes interessadas durante a reunio. Explique as regras de como as
reunies sero 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 reunio objetiva e
focada na pauta para um melhor aproveitamento do tempo de todos.
8. NO acreditar que reunies realizadas por meio de teleconferncias ou webconferences sejam to
eficientes quanto as presenciais. Recursos trabalhando em locais diferentes da reunio, sem um
contato visual, tendem a s prestar ateno quando o nome deles chamado. Isso contraprodutivo
e no faz sentido. Se no houver outra forma de esses recursos participarem da reunio pessoalmente,
tente comear com eles e os assuntos relacionados a eles. Reserve uma parte do oramento
para viajar at o local onde o projeto est sendo realizado para reunies face a face com esses
recursos. fundamental que o projeto esteja totalmente integrado para que tenha sucesso. Uma
comunicaovirtual muitas vezes dificulta ou, at mesmo, impossibilita essa integrao do fluxo
de informao sobre o andamento do projeto.
9. NO verificar linha por linha do cronograma durante a reunio. Foque nos desvios ao cronograma,
ou seja, o que precisa ser abordado porque um problema atual ou em potencial. Antes da
reunio, 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
oramento.
10. NO chamar a ateno, criticar ou fazer gozaes de recursos humanos presentes ou ausentes. Alm
de no ser tico, isso afeta seu relacionamento com sua equipe. Se houver necessidade, converse
com o recurso a ss aps a reunio terminar.
11. NO chegar atrasado ou sair mais cedo da reunio. 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 incio da
reunio, e o ltimo a sair para sanar dvidas individuais de alguma parte interessada.
12. NO marcar reunies de andamento do projeto que durem mais de uma hora. Embora as reunies
deplanejamento variem na durao e na frequncia, importante manter as reunies de monitoramento
e controle curtas e objetivas, pois todos esto ocupados com a execuo das tarefas do projeto.
Riscos
Os riscos devem ser monitorados semanalmente ou, at mesmo, diariamente, dependendo do pro-
jeto. Normalmente, na reunio semanal de andamento do projeto, h uma anlise dos riscos para um
determinado ponto para verificar se houve alterao na avaliao de algum risco. Essa anlise tambm
ativa um plano de resposta a um determinado risco, conforme o necessrio. Caso haja mudanas que
no afetem as linhas de base do projeto, o gerente do projeto fica responsvel pela atualizao e ajustes
da documentao e dos planos de ao.
Aquisies
O monitoramento e controle das aquisies do projeto, assim como no planejamento e na execu-
o, dependero do tamanho do projeto e da estrutura organizacional da empresa. Para gerentes de
projeto iniciantes, aconselhvel trabalhar conjuntamente com outros departamentos da empresa,
como Jurdico, Compras, Contas a Pagar, Qualidade, Engenharia, Contabilidade, Financeiro e outros,
nomonitoramento e controle das atividades de aquisies, que incluem:
Certificar-se que ambas as partes do contrato estejam cumprindo as obrigaes contratuais.
Proteger os direitos legais da empresa.
Manter um registo dos desempenhos de fornecedores e parceiros.
Inspecionar e verificar as entregas do projeto.
Gerenciar mudanas, conforme o necessrio e autorizado.
Acompanhar a realizao dos pagamentos nas datas devidas.
Partes Interessadas
O monitoramento e controle das partes interessadas envolvero uma avaliao do nvel de envolvi-
mento ou engajamento das partes interessadas naquele ponto especfico do projeto que estiver sendo
avaliado. O gerente do projeto precisa saber se quem deveria participar do projeto o est fazendo no
nvel de desempenho desejado.
Quando uma parte interessada estiver demonstrando uma reduo no seu nvel de envolvimento no
projeto, o gerente de projeto dever aplicar uma das estratgias includas no plano de gerenciamento das
partes interessadas (conforme descrito no captulo13 Partes Interessadas), conforme o necessrio.
Considerando as reas de conhecimento do projeto de forma integrada, o gerente de projeto precisa
avaliar, tambm, se uma parte interessada pode ser liberada do projeto, em vista da concluso das
atividades planejadas especificamente para ela.
Aplicao
O projeto sustentabilidade para a rede de supermercados A loja 1 foi monitorado e controlado da

seguinte forma:
1. Reunies.
Por ser um projeto em que todos trabalham muito prximos e com uma curta durao, com
atividades programadas em horas, as reunies foram marcadas considerando o trmino das entre-
gas-chave. As reunies aconteceram nas datas previstas no cronograma e serviram como um ponto
de encontro para a equipe sanar dvidas quanto aos prximos passos, bem como discutir e resolver
eventuais problemas.
1a Reunio: Reunio de abertura do projeto, aps aprovao do Termo de Abertura 10.08.2011
2a Reunio: Reunio de kick-off (incio dos trabalhos) do projeto, aps aprovao do Plano do Projeto
29.08.2011
3a Reunio: Reunio de andamento 1 do projeto, aps aprovao da Proposta de Implantao
20.09.2011
4a Reunio: Reunio de andamento 2 do projeto, aps implantao da infraestrutura 28.09.2011
5a Reunio: Reunio de andamento 3 do projeto, aps realizao do treinamento 12.10.2011
6 Reunio: Reunio de encerramento do projeto 18.10.2011
2. Controle das reas de conhecimento
Escopo. Com a matriz de requisitos em mos, o gerente do projeto confirmou, em cada reunio, 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 incorporao dos requisitos ao projeto era confirmada, conforme exemplo da
Figura15.1.
FIGURA 15.1 Monitorando os requisitos.

FIGURA 15.1 (Cont.)
Tempo. A realizao das atividades foi monitorada pelo cronograma; quando uma atividade era
concluda, o gerente a marcava no cronograma como concluda ou a porcentagem que j estava
concluda , conforme exemplo de um snapshot do projeto no horrio de almoo do dia 24.08.2011,
ilustrado na Figura15.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 concludo no

cronograma, basta clicar o boto direito do mouse em cima da primeira coluna, escolher Inserir
coluna, % concluda em Nome do campo. Observe que, com base na porcentagem de concluso
das atividades, o programa calcula automaticamente as porcentagens de concluso 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 concludas e esto comprimidas (osinal
de+indica compresso das atividades).
Custo. medida que os custos eram incorridos, o gerente do projeto lanava a despesa na planilha
dos custos do projeto, em uma coluna adicional de Custos Incorridos nas respectivas datas
(prximas s reunies de andamento do projeto), conforme exemplo a seguir. Isso permitiu que
quantias menores, que no afetavam a linha de base, fossem ajustadas conforme o necessrio
(Figura15.3).
FIGURA 15.3 Exemplo da planilha de controle dos custos.
Ferramenta
No controle do oramento, sempre til utilizar as frmulas do MS Excel para ir automaticamente

descontando os valores incorridos dos valores planejados, medida que os nmeros so lanados.
Qualidade. As listas de verificao ou checklists do projeto elaboradas no planejamento foram
preenchidas conforme o estipulado nos respectivos fluxogramas e, aps o preenchimento, colocadas
na pasta de documentao do projeto no servidor, em formato PDF, conforme exemplo a seguir
(Figura15.4).
FIGURA 15.4 Exemplo de Lista de Verificao (Checklist) preenchida.
Comunicaes. As informaes sobre o projeto foram distribudas conforme o Esquema das

Comunicaes, com os documentos do projeto sendo colocados em formato PDF no servidor HJH,
e no enviados por e-mail. Devido natureza das operaes de um supermercado, o gerente de
projeto notou que foi uma boa estratgia evitar a utilizao de e-mails para distribuir informaes,
pois a maioria dos recursos circula na loja e trabalha diretamente com colaboradores e clientes; eles
no ficam sentados em uma mesa na frente do computador.
Os relatrios definidos no planejamento da comunicao foram emitidos conforme os exemplos
na Figura15.5.
FIGURA 15.5 Exemplo de Relatrio de Andamento preenchido.

FIGURA 15.5 (Cont.)
Exemplo de uma das solicitaes de mudana na execuo do projeto e como foi documentada
(Figuras15.6 e15.7).
FIGURA 15.6 Exemplo de Solicitao de Mudana preenchida.

FIGURA 15.7 Exemplo de Anlise de Impactos de uma Solicitao de Mudana.
Aps aprovao da mudana, o gerente do projeto comunicou a resoluo por e-mail e telefone
solicitante (Figura15.8).
FIGURA 15.8 Exemplo de um Registro de Problemas.
Riscos A planilha de anlise de riscos foi utilizada apenas como referncia nas reunies. No
houve surpresas ou necessidade de acionar planos de ao. De qualquer forma, o gerente do projeto
apresentava cada risco e confirmava o status com os seguintes smbolos:
Trao (), 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 diminuio, normalmente diante
de atividades j realizadas que envolviam algum risco da matriz de riscos.
Vejamos um exemplo do controle de riscos da Reunio de andamento n 3 de 12-10-2011 (Figura15.9).
FIGURA 15.9 Monitorando os Riscos.
FIGURA 15.9 (Cont.)
FIGURA 15.9 (Cont.)
Aquisies As compras foram feitas segundo os processos internos do Departamento de Compras

e acompanhadas pelo gerente do projeto nas reunies. 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; ento, medida que a confirmao da compra era feita e o
pagamento efetuado, o gerente do projeto dava baixa no respectivo item na planilha de custos.
Partes Interessadas Nas reunies de andamento, a matriz de rastreabilidade das partes
interessadas mostrou resultados conforme figura a seguir para a reunio de andamento n 3
(Figura15.10).
FIGURA 15.10 Matriz de Gerenciamento das Partes Interessadas.

FIGURA 15.10 (Cont.)
Exerccios
Monitoramento e controle do projeto
O projeto est em plena execuo 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 acrscimo de 5 dias nocronograma
Material de apoio
Baixe os arquivos Anlise de impacto de mudana e Registro de problemas, na pasta Exerccios em
Contedos extras, na pgina web do livro (www.elsevier.com.br/martacamargo).
1. No formulrio de anlise de impacto de solicitao de mudana, faa uma anlise de como a
solicitao de mudana no cronograma (acrscimo de 5 dias) afetaria as reas de:
a. Escopo.
b. Tempo.
c. Qualidade.
d. Riscos.
2. Aps a anlise do impacto no exerccio 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 soluo que for considerada a melhor para o projeto.
3. Registre o problema que ocorreu com esse fornecedor no registro de problemas, incluindo as
seguintes informaes, conforme consta no formulrio:
a. Nmero do problema: 01.
b. Descrio do problema.
c. Origem.
d. Resoluo.
e. Responsvel.
f. Data do registro.
g. Data da resoluo.
16
Encerramento
Planejar como as informaes devero ser registradas durante o projeto.
Coletar informaes para encerrar o projeto.
Conduzir uma reunio de encerramento de um projeto.
Elaborar relatrios de lies aprendidas para os projetos concludos.
Desenvolver itens de ao para futuros projetos.
16.1 Processo de Encerramento e Lies Aprendidas
Conceito
O encerramento se caracteriza pelo fechamento de todas as atividades relacionadas ao projeto. O

projeto no considerado concludo quando seu escopo terminado, mas sim quando seu processo
de encerramento realizado, conforme explicado a seguir (Tabela16.1).
Tabela 16.1 Atividades e Documentos do Encerramento

rea de conhecimento Atividades de encerramento Documentos gerados
Integrao Realizar uma reunio de encerramento. Relatrio de Lies
Elaborar um documento denominado Lies Aprendidas para relatar Aprendidas
oque deu certo e o que precisa ser melhorado.
Confirmar que o trabalho foi realizado conforme os requisitos definidos
para oprojeto.
Concluir os relatrios de desempenho.
Encerrar contratos e pendncias com fornecedores.
Arquivar toda a documentao do projeto.
Atualizar o banco de dados de Lies Aprendidas da empresa
(quando houver).
Liberar os recursos humanos que trabalharam no projeto.
Elaborar itens de ao para projetos futuros. Itens de Ao
O processo de encerramento basicamente um fechamento administrativo do projeto, que ir

tambm deixar registros para projetos futuros. O encerramento exigir do gerente do projeto uma
integrao das vrias reas do projeto para garantir que tudo tenha sido concludo, sem pendncias,
conforme as atividades listadas na Tabela16.1.
215
Na prtica
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 serviro de fonte de
informaes para o encerramento do projeto.
Como visto nos captulos anteriores, uma documentao de acompanhamento detalhada do projeto
auxilia o gerente do projeto a rastrear causas de problemas que, muitas vezes, podem ter solues 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 comunicao do cronograma. Como discutido
no captulo sobre planejamento das comunicaes, essencial ao sucesso do projeto que o gerente
doprojeto customize a forma como a informao comunicada, dependendo da rea e das preferncias
das partes interessadas. As informaes de datas em um cronograma detalhado no MS Project podem
ser excelentes ao escritrio de projetos (PMO) ou outros departamentos, como TI; porm, para outros
departamentos, como produo ou financeiro, as informaes contidas em um cronograma detalhado
no MS Project podem ser mais difceis de serem entendidas e, portanto, executadas. Departamentos que
trabalham com nmeros gostam de receber informaes do projeto em planilhas do MS Excel.
Para projetos pequenos e menos complexos, o gerente de projeto pode coletar informaes com base
nos documentos gerados no monitoramento e controle do projeto, como o Registro de Problemas (ou outro
controle relativo s solicitaes e anlises de impacto de mudanas), os Relatrios de Andamento, as Atas
de Reunio 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 ao com datas especficas, que devem ser resolvidos por
grupos designados. Esses grupos devem se comprometer a resolver os itens a eles designados ou negociar
solues aos que podem ser resolvidos de imediato ou que sero resolvidos em um futuro prximo.
Para projetos mais longos (acima de seis meses) e complexos, envolvendo vrios departamentos
da empresa e terceiros (fornecedores de servios e produtos, por exemplo), o gerente do projeto pode
enviar um questionrio a essas partes interessadas para coletar informaes sobre o projeto do seu
ponto de vista. Nesse caso, o gerente do projeto deve padronizar o formulrio do questionrio e envi-lo
a todas as partes interessadas tanto dentro como fora da empresa e, com base nessas informaes,
gerar um relatrio sobre o que foi bem-sucedido ou no no projeto, facilitando assim o levantamento
dos itens de ao para projetos futuros.
A lista de itens de ao 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 ao e monitorar a resoluo desses
itens til quando h uma continuidade no trabalho do projeto com as partes interessadas em questo.
A seguir, um exemplo de um questionrio para levantamento das informaes em preparao a uma
reunio de encerramento de um projeto:
1. O que foi bem-sucedido no projeto e o que no foi?
2. O que poderia ser feito de forma diferente?
3. Que surpresas ocorreram durante o projeto que afetaram o trabalho planejado?
4. Que circunstncias do projeto no foram antecipadas?
5. Os objetivos do projeto foram atingidos? Se no foram, o que precisa ser mudado para que futuros
projetos alcancem os objetivos?
Em uma reunio de encerramento, o gerente do projeto levanta os problemas ocorridos e, por meio
de uma discusso voltada para itens de ao para o sucesso de futuros projetos, busca solues para
eliminar as causas de problemas j ocorridos.
O resultado dessas discusses documentado em um formulrio chamado Lies Aprendidas que
inclui informaes sobre o que deu certo e o que deu errado no projeto. O formato desse relatrio de
Lies Aprendidas pode variar, porm a maioria deles inclui as informaes a seguir (Figura16.1):
Captulo 16 Encerramento 217
FIGURA 16.1 Formulrio de Lies Aprendidas.
Dica
Outra forma de realizar a reunio de encerramento levantar os pontos positivos e pontos negativos
do projeto ao vivo e com a colaborao de todas as partes interessadas no projeto. O gerente do projeto
funciona como facilitador e levanta as informaes in loco. A seguir, uma sugesto para o roteiro dessa
reunio de encerramento:
Roteiro para reunio de encerramento1 uma hora
Incio cinco minutos
Reviso rpida do objetivo da reunio.
Reviso das regras da reunio.
Notebooks e celulares no sero permitidos durante a reunio.
Crticas a processos ou procedimentos utilizados no projeto sero bem-vindas.
Crticas a pessoas no sero permitidas.
1
Adaptado do roteiro publicado pelo Planning and Project Management Office da Carnegie Mellon University para reunio
de Lessons Learned.
importante que todos participem, mesmo com pontos de vistas diferentes.

importante manter uma atitude positiva para que a reunio agregue valor ao trabalho detodos.
Sucessos 15 minutos (o facilitador da reunio escreve no quadro as respostas)
O que foi bem-sucedido nas diferentes fases do projeto ou seja, iniciao, planejamento, execuo,
monitoramento e controle, encerramento?
Como a equipe se saiu ao lidar com mudanas s linhas de base durante o projeto (se aplicvel)?
Como a comunicao ocorreu no projeto? O que a equipe do projeto fez que foi mais til comunicao
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 reunio escreve no quadro as respostas)
O que poderia ser melhorado no que se refere ao que aconteceu nas diferentes fases do projeto
(iniciao, planejamento, execuo, monitoramento e controle, encerramento)?
Como a equipe se saiu ao lidar com mudanas s linhas de base durante o projeto (se aplicvel)?
Oque poderia ser feito de forma diferente para responder s mudanas no projeto?
Como a comunicao ocorreu no projeto? O que a equipe do projeto pode fazer para melhorar
acomunicao 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?
Priorizao 15 minutos
Quais seriam os cinco itens de maior importncia no sucesso do projeto?
Quais seriam os cinco itens de maior importncia nas oportunidades de melhorias no projeto?
Fechamento 5 minutos
Quais os itens de ao para a resoluo das cinco melhorias mais importantes que acabaram deser
definidos?
Quem ser o responsvel por cada item de ao?
Quais os procedimentos para acompanhamento da resoluo desses cinco itens de ao?
Com base nessa reunio, o Relatrio de Lies Aprendidas elaborado e enviado a todos para
aprovao. Depois da aprovao, o relatrio arquivado para servir como referncia 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 tenso ou, no caso dos projetos de alta visibilidade
na empresa, causaram muita presso nos membros da equipe, o gerente de projeto deve planejar uma
reserva no oramento para um evento de fechamento. Esse evento pode ser um churrasco, um almoo
com feijoada, caf da manh completo ou at mesmo terminar a reunio de encerramento com pizza
para todos. Esses tipos de evento servem como um sinal de reconhecimento do esforo de todos e
fortalecem o esprito de equipe entre os participantes do projeto.
Aplicao
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 trs itens a seguir em
preparao reunio de encerramento do projeto:
1. O que deu certo no projeto e por que voc acha que deu certo?
2. O que no deu certo no projeto e por que voc acha que isso aconteceu?
3. Quais as suas sugestes para futuros projetos semelhantes a esse?
A reunio de encerramento seguiu o roteiro de uma hora descrito na Dica, e o Gerente de Projeto foi
o facilitador da reunio e o responsvel pela coleta de informaes in loco.
Com base nas discusses durante a reunio, o gerente do projeto elaborou o Relatrio de Lies
Aprendidas. Foram tambm levantados Itens de Ao para futuros projetos, conforme Figura16.2 a seguir.
Aps a reunio houve um evento de confraternizao para a equipe do projeto oferecido pelo pa-
trocinador e dono da rede A Sr. Jos S. com a presena de todas as partes interessadas do projeto,
incluindo o pessoal da empresa Z, a empresa terceirizada responsvel pelos componentes de marketing,
e do especialista em sustentabilidade da prefeitura, que ministrou o workshop aos colaboradores da
rede A (Figura16.2).
FIGURA 16.2 Relatrio de Lies Aprendidas e Itens de Ao Projeto Sustentabilidade para Rede de Supermercados A loja 1.
(continua)
FIGURA 16.2 (Cont.)

FIGURA 16.2 (Cont.)
(continua)
FIGURA 16.2 (Cont.)
Exerccios
Encerramento
Finalizao do projeto da reforma da loja de roupas femininas: encerramento
O projeto da reforma da loja est concludo. No geral, o projeto foi bem-sucedido, pois executou-se
a maioria do que foi planejado sem problemas. Carlos Peixoto realizou uma reunio de encerramento
com sua equipe interna e os fornecedores de produtos e servios, alm de ter documentado os acon-
tecimentos para futuros projetos de reformas em suas outras lojas.
Material de apoio
Baixe o arquivo Lies Aprendidas, na pasta Exerccios em Contedos extras, na pgina web do
livro (www.elsevier.com.br/martacamargo).
Como o projeto da reforma da loja de artigos femininos foi uma simulao para a prtica da docu-
mentao do gerenciamento de projetos, no possvel realizar um processo de encerramento com-
pleto, pois no foi feita a execuo propriamente dita do projeto. Porm, possvel fazer uma reflexo
dos desafios que voc encontrou no planejamento de cada rea de conhecimento.
Utilizando o formulrio de Lies aprendidas, faa uma reflexo sobre o seu desempenho no plane-
jamento do projeto considerando as seguintes informaes:
1. O que deu certo (por exemplo: a releitura do captulo antes de realizar os exerccios facilitou
aelaborao das respostas.).
2. Recomendao para futuros projetos com base no que deu certo neste (por exemplo: sempre
procurar informaes e ler as instrues com cuidado antes de realizar a tarefa do projeto).
3. O que no deu certo (por exemplo: fazer os exerccios sem ler com ateno as explicaes
eosexemplos nos captulos levou a retrabalhos e respostas incompletas ou incorretas).
4. Recomendao para futuros projetos a fim de evitar o que no deu certo neste (por exemplo: estar
sempre bem preparado para planejar um projeto).
Faa o mesmo com relao a cada rea de conhecimento do projeto:
1. Escopo.
2. Tempo.
3. Custos.
4. Qualidade.
5. Recursos Humanos.
6. Comunicaes.
7. Riscos.
8. Aquisies.
A
Exemplo de Anlise de Pr-projeto
Estudo de viabilidade Implantao de um
sistema de controle de verso de arquivos
nodepartamento de localizao da empresa N
Introduo
Localizao de software o processo pelo qual o departamento internacional adapta o produto
desenvolvido no idioma ingls, voltado para o mercado norte-americano, para verses internacionais
voltadas a diferentes mercados estrangeiros, considerando tanto aspectos lingusticos como funcionais.
O departamento de localizao da empresa N est configurado em cinco reas distintas:
1. Terminologia: pesquisa e define os glossrios para as tradues e padronizaes dos termos
dosoftware e da documentao do produto.
2. Gerenciamento de fornecedores: gerencia o trabalho terceirizado do processo de localizao comoum
todo.
3. Controle de qualidade: verifica a qualidade das verses internacionais do software por meio decasos
de testes e outras especificaes, conforme o caso.
4. Engenharia de software: faz a parte tcnica do processo de localizao, envolvendo converso
dosbuilds domsticos em builds internacionais, converso de arquivos para vrios formatos
(web, PDF, grficos) e outras atividades. Na programao de software, um build uma verso
de um programa. Via de regra, um build uma verso pr-lanada e identificada por um nmero
sequencial, medida que vo sendo produzidos at chegar no produto final (por exemplo, aprimeira
verso 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 verso 1.0 do software pronto).
5. Gerenciamento de projetos: elabora os kits de localizao com instrues sobre ferramentas, processos
especficos para cada produto, guias de estilo e especificaes de testes para o pessoal interno e
externo da empresa. Essa rea gerencia o processo inteiro de localizao do produto, que envolve
partes dos trabalhos das outras reas tambm.
O departamento de localizao da empresa N lana as verses internacionais dos produtos na mesma
data que o produto nacional, conhecido como domstico. Nesse modelo de sim-ship (ou lanamento
simultneo do produto de software para diferentes idiomas e mercados ao mesmo tempo), o departa-
mento de localizao comea a trabalhar enquanto a verso em ingls est ainda em desenvolvimento.
Nessas condies de trabalho simultneo entre os dois departamentos (domstico e internacional),
mudanas so constantes nos arquivos originais do domstico, o que exige atualizaes frequentes
nos arquivos-fonte. Como o software produzido simultaneamente em ingls e em vrios idiomas, o
processo de atualizao dos arquivos em todos os idiomas, ao mesmo tempo, um grande desafio aos
gerentes de projetos do departamento de localizao.
O primeiro problema que, para um determinado projeto, os arquivos originais provenientes da
equipe de desenvolvimento do domstico podem consistir em aproximadamente 500 palavras, porm no
estgio da localizao, o nmero se multiplica pelo nmero 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 mdia de trs atualizaes por lanamento (isso para produtos de pequeno a mdio porte,
pois para produtos de grande porte, como o carro-chefe da empresa, esse nmero de atualizaes pode
chegar a 20 ou mais), o nmero de arquivos que passa pelo departamento de localizao pode chegar
a 12 mil, apenas para uma atualizao no arquivo original em ingls.
225
O resultado do aumento no nmero de arquivos que todos esses arquivos precisam ser monitorados
medida que so trabalhados por diferentes fornecedores dos servios de traduo e teste para que a
verso localizada tenha um build localizado que funcione. Durante todo o processo de desenvolvimento
de um software, os componentes do aplicativo so coletados e repetidamente compilados em builds
para serem testados, at se chegar ao produto final.
Outro fator a ser considerado que os arquivos tm formatos diferentes (por exemplo, HMTL, XML,
Java, .txt, .doc etc.). Atualmente, todos esses arquivos so controlados e monitorados manualmente
pelos gerentes de projetos do departamento de localizao.
O segundo problema se refere falta de padronizao para os ambientes de build. No h um con-
trole sobre os arquivos que compem cada build de software que testado. Muitas vezes, partes do
software so produzidas em departamentos diferentes que tm formas diferentes de escrever o cdigo,
fazer as entregas ao departamento de localizao e criar builds de software. O resultado dessa falta de
padronizao a grande dificuldade encontrada pelo departamento de localizao quando se trata
de documentar os diferentes processos e padres e ainda explicar essas diferenas aos fornecedores e
contratados em diversas partes do mundo.
Para agravar ainda mais a situao, dentro do prprio departamento de localizao 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 cdigo-fonte fornecido
pelo departamento de desenvolvimento de software domstico. Essas listas no permitem que eles
saibam se o arquivo totalmente novo ou apenas uma atualizao. Todos os arquivos que vm do
desenvolvimento de software so, portanto, considerados novos e enviados aosgerentes de projetos
para serem enviados aos fornecedores de servios de localizao.
2. O grupo de documentao do produto utiliza um sistema customizado para arquivos de ajuda e
documentao online que consiste basicamente em um arquivo de processador de textos com nomes
de arquivos que entraram e saram, com datas e nomes das pessoas do grupo dedocumentao
domstica que enviaram esses arquivos.
3. O grupo dos gerentes dos projetos de traduo criam tabelas ou planilhas com base nasinformaes
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 umaatualizao para posteriormente enviar
as instrues aos fornecedores.
O processo anterior propenso a erros, principalmente porque, para projetos grandes de mercados
internacionais com prazos extremamente agressivos, o gerente do projeto no tem tempo de verificar
cada arquivo e acaba enviando os arquivos que recebe do desenvolvimento do software domstico
diretamente aos fornecedores de servios de localizao. Isso gera confuso e retrabalho.
O departamento de localizao precisa de um sistema para controlar o hand-off dos arquivos das
equipes de desenvolvimento de software. Esse sistema precisa mostrar informaes atualizadas sobre
os arquivos originais do domstico e as respectivas atualizaes. necessrio tambm que possa ser
compartilhado por vrios departamentos para que constitua a forma oficial e padronizada de gerenciar
os arquivos que compem cada verso localizada de todos os produtos de software da empresa.
Opes atuais de ferramentas de gerenciamento de arquivos

(especificamente para o departamento de localizao da empresa)
De acordo com o estudo feito pela autora das ferramentas disponveis no mercado que atendem essa
necessidade de padronizao de hand-off de arquivos, foram descobertos dois produtos com potencial
de resolver o problema de controle de verso de arquivos:
1. Ferramenta A: ferramenta desenvolvida pela empresa C, opera no Windows e inclui uma interface
do usurio para todas as fases da produo dos arquivos, controle de verso, datas de sign-off
(processo de concluso dos trabalhos) do desenvolvimento, datas de hand-off para localizao, datas
Apndice A Exemplo de Anlise de Pr-projeto 227
de hand-off para os fornecedores, atualizaes, informaes sobre autoria, status dosarquivos na

localizao, arquivos utilizados para partes especficas no processo de localizao e informaes
sobre os arquivo originais necessrios aos builds.
Vantagens: alm de ter uma interface amigvel, mantido e atualizado pelos gerentes de projetos,
fica acessvel a todos que forem inclusos como usurios e tem um custo zero aodepartamento
delocalizao, pois foi desenvolvido por empresa parceira que gostaria decompartilhar 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
informaes sobre marcos do projeto para que o departamento de localizao possa manter suas
informaes corretas e atualizadas. Atualmente, o departamento de desenvolvimento no usa essa
ferramenta e pode haver resistncia contra a incorporao de uma ferramenta que no traz benefcios
diretos ao departamento e ainda aumenta a carga de trabalho da equipe de desenvolvimento (a fim
de alimentar o sistema especificamente para o departamento delocalizao).
2. Ferramenta B: um sistema de gerenciamento de configurao de software que permite s equipes
de desenvolvimento um controle total sobre o cdigo-fonte e as atividades demanuteno.
Gerencia objetivos que representam arquivos-fonte, documentos, casos de testes, programas
executveis, bibliotecas e diretrios. Essa ferramenta tambm gerencia osrelacionamentos entre
esses objetivos.
Vantagens: algumas equipes de desenvolvimento de software da empresa j esto 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 localizao, essa ferramenta inclui
informaes que no se aplicam s necessidades internacionais. As funes principais daferramenta
cobrem todas as fases de programao e escrita dos cdigos-fonte, no o que acontece com os
arquivos aps estarem concludos no idioma ingls. Alm disso, depois de testes com os gerentes
de projetos de localizao, a interface no foi considerada amigvel ou intuitiva, oque requer
documentao e treinamento especficos s equipes de localizao, internas eexternas (incluindo
toda a rede de fornecedores de servios de localizao em todos os pases) para que a ferramenta
possa ser utilizada nos projetos internacionais.
Viabilidade tcnica
A Ferramenta A pode ser instalada em um dos servidores do departamento de localizao sem
afetar a produo dos projetos atuais. Considerando os recursos atuais da rede, no h necessidade
de nenhuma configurao especial ou aquisio 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 questo 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, no necessrio adquirir novas mquinas ou outros
equipamentos, pois todos os computadores foram atualizados recentemente com o processador Intel
e a verso do Windows mais recente. Quanto aos requisitos de software, a Ferramenta A funciona como
um aplicativo qualquer, precisando apenas de uma instalao na mquina do usurio. Essa ferramenta
utiliza interface e terminologia prprias para a rea de localizao, facilitando a utilizao dos novos
usurios. No necessrio treinamento, pois a interface intuitiva e amigvel. Para a equipe de
desenvolvimento entrar com dados especficos sobre verses de arquivos e atualizaes, h um menu
especial que foi considerado simples e fcil de utilizar por um desenvolvedor consultado durante a
realizao deste estudo.
A Ferramenta B requer um servidor dedicado, juntamente com uma mquina UNIX rodando
uma engine de banco de dados. Senhas especiais teriam que ser configuradas a um nmero limitado
de usurios dentro do departamento de localizao, devido s limitaes de licena de uso
(apenas dois usurios por instalao). Seria necessrio treinamento aos usurios do departamento de
localizao, pois a interface e terminologia do produto refletem um ambiente de desenvolvimento
de sistemas e programao de cdigo-fonte, no de localizao.
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 so similares s
ferramentas que utilizamos nos nossos projetos atuais. A empresa C j testou a ferramenta em projetos
de localizao 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 elaborao das listas de arquivos que devem ser enviadas
aos fornecedores de servios de localizao em outros pases.
A interface do usurio da Ferramenta B no amigvel para o pessoal do departamento de locali-
zao. Em um teste-piloto realizado com trs gerentes de projetos, foi constatado que a Ferramenta
B inclui vrios itens da interface do usurio que no se aplicam rea de localizao. Alguns recursos
poderiam ser adaptados, mas a maioria deles se refere a ambientes especficos de desenvolvimento e
programao de software em ingls.
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 servios de localizao tem
sido motivo de constantes atualizaes no oramento dos projetos, incorrendo em solicitaes 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 localizao para traduo em
17 idiomas. Esses arquivos com as respectivas atualizaes foram enviados sem um aviso de que eles j
haviam sido enviados antes nesse caso, tratava-se apenas de uma atualizao de parte do contedo
prvio de cada um deles. Sem esse aviso, foi feito o hand-off aos fornecedores de servios de localizao,
com os respectivos SOW's (Statements of Work ou declaraes de trabalho) e ordens de compra com base
na premissa de que eram arquivos novos. Logicamente que os fornecedores de servios de localizao
no falaram, ou no perceberam, que esses novos arquivos eram novos apenas em parte, e acabamos
pagando a mesma traduo duas vezes.
A tabela a seguir indica como esse tipo de erro acarreta custos desnecessrios e afeta o planejamento
do oramento dos projetos de localizao (Tabela A.1):
Tabela A.1 Custo de uma Atualizao

Contagem Custo mdio Custo total apenas Total de palavras Custo mdio total Perda com a atualizao
depalavras total detraduo da atualizao consideradas considerando
para a atualizao porpalavra novas os17idiomas
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 localizao devido a problemas de controle
de verso de arquivos pode gerar perdas financeiras, pois so considerados como traduo nova no
nmero total de idiomas para o projeto. Esse exemplo ilustra um projeto pequeno: em projetos grandes
com mais de 1 milho de palavras, a ocorrncia de problemas de controle de verso de arquivos resulta
em perdas ainda maiores.
Os custos de aquisio para cada ferramenta encontram-se ilustrados na tabela a seguir (Tabela A.2):
Apndice A Exemplo de Anlise de Pr-projeto 229
Tabela A.2 Custos das Ferramentas

Custo para licena para 20 usurios (gerente de projetos) Ferramenta A Ferramenta B
Compra 0 13.000
Instalao e configurao do software 500 2.000
Configurao 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 restrio
que o cdigo-fonte das ferramentas no pode ser compartilhado apenas a ferramenta pronta.
Poder ser necessria uma declarao por escrito do departamento de localizao afirmando que no
ser feita cpia da Ferramenta A a terceiros ou qualquer prtica de engenharia reversa no produto ou
comercializao do mesmo sem autorizao expressa da empresa C.
Para a Ferramenta B, o departamento de desenvolvimento j tem licenas de uso para produtos do
domstico. Haver necessidade de consulta junto ao departamento jurdico da empresa para verificar
se a utilizao das licenas da ferramenta para a equipe do domstico pode ser estendida a outros
departamentos que produzem verses internacionais do produto de software da empresa. Precisar ser
verificado tambm se o nmero de licenas disponvel hoje suficiente para todos os grupos.
Viabilidade do cronograma
importante observar que qualquer aquisio deve ser realizada pelo departamento de compras
corporativas. Compras acima de US$ 5.000 esto condicionadas aprovao do novo oramento para
o prximo ano. Isso quer dizer que, se for escolhida a Ferramenta B, o departamento de localizao
dever esperar mais dois trimestres para solicitar a aquisio, pois o oramento deste ano foi aprovado
no ano passado. Esse aspecto somado ao tempo necessrio para configurao de software e hardware,
mais o treinamento da equipe, pode adiar a implantao 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 implantao dentro
de duas semanas.
Recomendao
Com base nas viabilidades consideradas anteriormente, recomendamos a aquisio e implantao
da Ferramenta A, que atender s necessidades operacionais e tcnicas do departamento de localizao
sem impactar os cronogramas de produo ou financeiros. O departamento de desenvolvimento doms-
tico concordou com essa avaliao, e os baixos custos de implantao confirmam a viabilidade dessa
opo de ferramenta.
B
Perguntas Frequentes
1. Por que o gerenciamento de projetos foi introduzido em cursos de graduao e ps-graduao
nos ltimos anos?
O gerenciamento de projetos se tornou uma questo estratgica para as empresas que precisam fazer
mais com menos, pois permite uma maximizao dos recursos das empresas e organizaes e agiliza o
tempo de entrada do produto ou servio no mercado. Alm disso, com a atual competitividade em nvel
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 difcil de gerenciar em um projeto real?
Todas as reas apresentam nveis de dificuldade proporcionais aos ambientes tcnicos, organizacio-
nais e culturais em que o projeto est sendo realizado. Normalmente, gerentes de projetos veteranos
concordam que a rea de escopo a mais difcil no a mais complicada de gerenciar, mas de definir.
Isso particularmente verdadeiro em projetos novos e inditos em que pouco se sabe sobre os detalhes
do que de fato precisa ser feito no projeto. Como as outras reas de conhecimento so planejadas em
cima do escopo, uma definio incorreta do escopo gera um efeito domin que leva a retrabalhos e
estouros nos oramentos.
3. O que melhor para um projeto: ter um gerente de projetos tcnico ou bom gestor?
O ideal um equilbrio das duas reas: tcnica e gesto. No muito eficaz um gerente extremamente
tcnico que no mantm as reas do projeto integradas, e, ao mesmo tempo, no vale muito ter um
timo gestor que no entende as particularidades das entregas e atividades envolvidas no projeto. O
mercado normalmente d preferncia aos profissionais da rea tcnica com formao em gerenciamento
de projetos. Isso acontece muito na rea de tecnologia da informao, porm j considerado padro
em outras reas tambm.
4. Como entrar para a profisso de gerente de projetos?
Se voc tem interesse em ingressar ou j atua em posio jnior em gerenciamento de projeto, ou
se est estudando gerenciamento de projeto em um curso de graduao ou ps-graduao, existe uma
certificao do PMI para iniciantes denominada CAPM Certified Associate in Project Management.
O site do PMI Brasil fornece informaes detalhadas sobre a certificao CAPM.
Para conseguir uma posio 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 posio nesse
departamento. Muitas vezes, temos que pagar para trabalhar e investir em uma carreira no longo prazo.
Outra dica fazer trabalhos voluntrios em organizaes no governamentais (ONGs) e pedir para
gerenciar os projetos. Assim, voc no s contribui com a sociedade como tambm adquire experincia e
vai acumulando horas em gerenciamento de projetos. No se esquea de pedir comprovantes a essas ins-
tituies confirmando sua atuao como gerente de projetos e incluindo o nome dos projetos que gerenciou.
O PMI tambm 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 anncios de empregos em websites
nacionais especializados e ir acompanhando o perfil do profissional de projetos que as empresas esto
procurando. Primeiro, veja se voc se encaixa nesse perfil. A profisso de gerente de projetos requer
uma combinao muito especfica de habilidades. Alm das certificaes e experincia, imprescindvel
falar ingls, mesmo que a vaga seja em empresas nacionais.
231
A ltima dica, no s para quem est buscando oportunidades em gerenciamento de projetos, mas
para qualquer profissional, ser flexvel quanto ao local do trabalho. Em pases como os Estados Unidos,
dificilmente o profissional consegue uma colocao profissional na mesma cidade onde nasceu, cresceu
e concluiu o ensino superior. O Brasil um pas que tem passado por um crescimento econmico
acelerado nos ltimos anos, com outras regies, alm 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 mudanas em todos os sentidos para ter sucesso.
5. A empresa onde trabalho tradicional e muito hierrquica. Os donos querem implantar uma
metodologia de gerenciamento de projetos, s que na hora de seguir o processo, ningum quer
fazer nada. O que posso fazer nesse caso?
A primeira coisa ter uma conversa sria com os donos da empresa para entender exatamente
o que querem de uma estrutura de gerenciamento de projetos. necessrio 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 no estejam entendendo porque no a rea deles. Esse pode ser tambm um caso de resistncia
a mudanas, o que requer habilidades especficas para mudar o paradigma das partes interessadas.
De qualquer forma, necessrio determinar se esses donos de fato querem implantar algum tipo de
organizao ou estruturao 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 diagnstico da situao para determinar se a situao
pode ser melhorada, desenvolvendo um entendimento maior sobre gerenciamento de projetos ou uma
customizao 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, disponveis em bancas de jornais, livrarias etc. so
bons para consulta e entendimento de conceitos. Porm, por definio, projeto um esforo temporrio
nico e exclusivo. Cada projeto tem seus prprios desafios que esto relacionados diretamente ao tipo
de produto, empresa, mercado e outras variveis que so nicas para cada projeto. No existe uma fonte
j pronta de informaes 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 especficas que permitem a ele se adaptar a qualquer
circunstncia e achar solues aos mais variados tipos de problemas que acontecem e sempre iro
acontecer no dia a dia da vida de um projeto.
Como dica pessoal da autora, h uma sequncia bsica na aquisio dos conhecimentos na rea
de gerenciamento de projetos:
a. Domnio das reas de conhecimento e processos do PMBOK.
b. Conhecimento de ferramentas informatizadas para elaborar EAPs, cronogramas e oramentos,
para garantir o controle nas linhas de base do projeto.
c. Aperfeioamento na rea de gesto de pessoas e comunicao. O gerente de um determinado
projeto pode ser impecvel tecnicamente, porm se no souber trabalhar com as pessoas ese
comunicar extremamente bem com suas partes interessadas (nas formas oral e escrita, e tanto
pessoal como eletronicamente por e-mail, videoconferncia ou teleconferncia) no ter futuro
nessa rea.
7. Agendo reunies de planejamento, ningum aparece. Fao cronogramas, ningum segue asdatas.
Na minha empresa, no h comprometimento. O que posso fazer nesse caso?
Gerenciamento de projetos top-down, ou seja, o comprometimento com uma metodologia

degerenciamento de projetos deve vir de cima. Deve haver uma comunicao clara do alto escalo
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 opinio sincera do porqu da falta
Apndice B Perguntas Frequentes 233
de colaborao. Talvez haja uma soluo simples, talvez complexa mas comunicar-se para entender
o que est acontecendo de fato fundamental para a resoluo do problema.
8. Acho a maior besteira esse negcio de documentar tudo no projeto. Gera um trabalho
desnecessrio equipe em geral. Passo mais tempo escrevendo a documentao 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 eficincia ou s cria mais trabalho com toda essa
documentao?
A autora j se deparou com casos extremos de empresas grandes ou multinacionais com sistemas
sofisticados prprios de gerenciamento de projetos que geram ocorrncias e relatrios diversas vezes
ao dia, forando a equipe do projeto a preencher formulrios no sistema a todo instante. Isso, de fato,
pode ser contraprodutivo e ocupar muito mais tempo para a documentao do que o necessrio. A do-
cumentao do projeto deve ser feita, pois no mundo corporativo de hoje, o que no est documentado
no existe. preciso que uma referncia formal das informaes-chave esteja disponvel a todos que
trabalham no projeto para que haja consistncia e um mnimo de organizao no que deve ser feito.
O processo de documentao neste livro inclui tipos de documentos bsicos e obrigatrios que no
engessam a equipe com constantes atividades relativas documentao do projeto e so relativamente
fceis de produzir e seguir no dia a dia. responsabilidade do gerente do projeto usar o bom senso para
definir as necessidades de documentao de cada projeto, em vista de seu tamanho e complexidade e
das restries de tempo da equipe.
9. J tentamos implantar uma metodologia de projetos na nossa empresa seguindo o PMBOK, e
no funcionou. Quais as causas mais provveis de isso ter acontecido?
Como explicado no captulo1, Breve Histria do Gerenciamento de Projetos, o que o PMBOK es-
tabelece como padres em gerenciamento de projetos no reflete, necessariamente, um pensamento
novo ou revolucionrio na maneira como gerenciar projetos. Desde a poca da construo das Muralhas
da China e das Pirmides de Giz j havia processos semelhantes aos que temos hoje.
O PMBOK inclui diretrizes para as melhores prticas em gerenciamento de projeto que devem ser
adaptadas realidade de cada empresa com uma metodologia de trabalho real e eficiente com projetos.
mais fcil fazer um downsizing das diretrizes do PMBOK do que fazer um upgrade de uma metodologia
de projetos incompleta e deficiente.
Se a metodologia mencionada no funcionou, talvez seja o caso de a empresa procurar consultores
especializados na rea para realizar um diagnstico 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 no o PMBOK; uma combinao de fatores que vai desde um excesso
de requisitos de documentao para o produto do projeto at a resistncia cultural dos colaboradores
da empresa ou falta de apoio do alto escalo. Pode ser at que a empresa seja catica por si s no
s para a realizao de projetos como para a aplicao de mtodos de controle de qualidade no seu
setor produtivo, nos controles de oramentos em geral, e at mesmo no controle da agenda do diretor
comercial ou do diretor tcnico enfim, problemas estruturais da empresa como um todo. A soluo
nesse caso uma abordagem mais sistmica com uma reengenharia nos processos e nos procedimentos
internos da empresa para que depois se possa chegar customizao da rea de gerenciamento de
projetos naquela realidade organizacional.
10. Trabalho na rea de tecnologia (telefonia, help desk, suporte etc.), e os projetos so decurtssima
durao. s vezes, o solicitante pede o projeto na sexta-feira para estar pronto na segunda-feira.
Sem falar que prestamos servios para vrias empresas que terceirizam paraoutras empresas.
muito confuso e rpido. No conseguimos documentar nada e tudo para ontem. Como
posso, ento, adotar uma metodologia de gerenciamento de projetos qued certo nesse tipo de
ambiente to catico?
Em alguns setores, como a telefonia celular no Brasil, parece que est emergindo um novo conceito:
o projetop, uma mistura de projeto com operao ou trabalho operacional. Como o ciclo de vida do
produto est em uma curva ascendente, comum que o ritmo seja rpido, com uma sensao de caos no
desenvolvimento de produtos e solues. medida que o produto amadurecer, ser possvel identificar
padres de trabalhos e processos que iro atender de forma padronizada s necessidades dos clien-
tes. Chegar uma hora em que o resultado nico e exclusivo no existir mais. O que haver ser uma
variedade de opes de trabalho operacional, que ir se repetir no ciclo de vida do servio ou produto
com algumas customizaes. Hoje, a soluo pode estar na anlise do que chamado de projetop,
na qual se procurar descobrir padres repetitivos. Esses padres indicaro que as operaes talvez
precisem de processos e procedimentos operacionais (e no de uma metodologia de gerenciamento
de projetos) para funcionarem de forma mais organizada e controlada.
11. Qual a importncia de uma certificao em gerenciamento de projetos?
Quem j esteve em situao de contratar um funcionrio ou colaborador sabe da dificuldade de dis-
tinguir o profissional que agrega valor de um profissional que dar prejuzos empresa. No se pode mais
confiar apenas no currculo, pois a internet democratizou as informaes e todos so muito parecidos.
Uma certificao em gerenciamento de projetos uma validao segundo a qual o profissional tem o
conhecimento dos padres e princpios do PMBOK para exercer a profisso na rea de gerenciamento
de projetos. Uma certificao assegura tambm uma consistncia no trabalho dos gerentes de projetos
da empresa, principalmente em caso de empresas multinacionais e de grande porte com operaes
em diversas partes do mundo. Porm, de nada adianta a certificao se o profissional no souber
gerenciar um projeto na prtica. Da a importncia de o profissional procurar formas de aprender e se
aperfeioar constantemente dentro dessa rea. Segundo estudos realizados pelo PMI Brasil, as empresas
confirmaram que no exigem necessariamente uma certificao porm, esse um diferencial para
entrar e se manter na empresa.
Referncias
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. Disponvel 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. Disponvel 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, VAUSA, 2002.
ISO/IEC 27001:2005.Information technology Security techniques Information security management systems. Dis-
ponvel 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.
Disponvel 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. Disponvel 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 Edio.
ed. [S.l.]: PROJECT MANAGEMENT INSTITUTE, 2009.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 5 Edio.
ed. [S.l.]: PROJECT MANAGEMENT INSTITUTE, 2013.
PROJECT Budget Template for IT Software Projects. 2010 Version (v1.01). Axia Consulting Ltd. Disponvel em: www.
axia-consulting.co.uk. Acesso em 21 dez. 2011.
PROJETOS web: Planejamento. Estrutura Analtica do Projeto (EAP) Work Breakdown Structure (WBS). Disponvel em:
http://www.avellareduarte.com.br/projeto/planejamento/planejamento5/planejamento5.htm#ixzz1mwbo. Acesso
em: 15 nov. 2011.
ROADMAP para o Projeto de Implantao do Escritrio de Processos. Elo Group, 2008. Disponvel em:<http://www.elo-
group.com.br/download/Artigo_Roadmap%20para%20Implantacao%20de%20um%20Escritorio%20de%20Processos.
pdf>. Acesso em: 25 ago. 2011.
SIDAOUI, Rogrio Curiosidades histricas. So Paulo: IBRASA, 2004.
SHARMA, Raj. The 6 principles of stakeholder management. Supply Chain Management Review. Outubro, 2008. Disponvel
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. Disponvel
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. Disponvel 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 JerseyUSA: 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, 416. Disponvel em: http://onlinelibrary.wiley.com. Acesso em: 05 jul. 2011.
WEAVER, Patrick. A Brief History of Scheduling. PM Forum. Abril, 2006. Disponvel em: http://www.pmforum.org/library/
papers/2006/A_Brief_History_of_Scheduling.pdf. Acesso em: 22 jan. 2011.
Referncias das pesquisas do projeto de implantao de prticas de sustentabilidade rede A.
AGENDA SUSTENTVEL. A sustentabilidade na prtica. artigos, responsabilidade social, empresas parceiras e cases em
destaque. Disponvel em: http://www.agendasustentavel.com.br. Acesso em: 19 abr. 2010.
Agenda sustentvel. O futuro a gente faz agora. Po de Acar: primeiro supermercado com selo LEED. Disponvel em:
http://planetasustentavel.abril.com.br/noticia/desenvolvimento/conteudo_282198.shtml. Acesso em: 10 mar. 2010.
FRUM DE VAREJO E CONSUMO SUSTENTVEL: EXPERINCIAS, DEBATES E DESAFIOS. Coordenao: Juracy Parente,
Jacques Gelman, Roberta Cardoso. Redao, Edio e Reviso: Luiz Macedo, Maria Furlan da Silva Telles e Roberta
235
Cardoso. So Paulo: FGV, 2009. Disponvel em: <http://www.varejosustentavel.com.br/painel/dbarquivos/dbanexos/

publicaoforumbp.pdf>. Acesso em: 03 mar. 2010.
GBC BRASIL. Construindo um Brasil sustentvel. histrico, misso e viso, metodologia aplicada e certificao LEED. Dis-
ponvel em: http://www.gbcbrasil.org.br. Acesso em: 19 abr.2010.
PO DE ACAR, Lugar de gente feliz. Blog com artigos, informaes sobre as lojas verdes do grupo e dicas de sus-
tentabilidade. Disponvel em: http://www.paodeacucarverde.com.br. Acesso em: 10 mar.2010.
WALMART Brasil, Lojas ecoeficientes. Disponvel 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 oramentos, 111
Adaptao de itens existentes, 96 variveis, 111
Alinhamento com as estratgias da empresa, 25
Alta influncia D
com alta participao, 174 Declarao de Escopo, 49
com baixa participao, 173 Definio
Anlise das opes de sustentabilidade, 96 das entregas e pacotes de trabalho, 72
Aplicao do questionrio, 95 do material, 96
Apresentao Deliverables, 20
da proposta, 96 Distribuio, 97
final, 72 Documentao
Aquisies, 95, 163 de requisitos, 58
plano de gerenciamento, 164 documentao de requisitos, 59
reas de conhecimento na execuo, 186 matriz de rastreabilidade de requisitos, 59
Arquivamento do projeto, 97 plano de gerenciamento de requisitos, 59
Assumption, 20 do gerenciamento das mudanas, 148
Atividades, 21 Documentos iniciais, 94
E
B EAP
Baixa influncia mista, 83
com alta participao, 174 para produtos com ciclo de vida, 83
com baixa participao, 174 para servios, 81
Baslica de Santa Sofia, 6 para um resultado, 83
Benchmarking de prticas sustentveis, 95 Educao para os consumidores, 187
Bottom-up, 71, 111 Elaborao
Brainstorming, 72 do questionrio, 95
do relatrio, 96
C Encerramento, 97, 215
Certificaes ambientais, 188 lies aprendidas, 215
Checklists, 126 processo, 215
Cliente, 17 Engajamento de partes interessadas no projeto, 173
Colaborao mtua, 177 Entregas, 20
Coliseu, 5 Entregveis, 20
Comunicaes, 145 Envolvidos no Projeto, 20
esquema das, 146 Escopo, 18, 49
relatrios e registros de informaes, 146 declarao, 49
Comunicaes, 95 documentao de requisitos, 58
Consenso, 72 documentao 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 analtica do projeto, 68
Cronograma, 99 dicionrio, 90
Custos, 94, 111 estratgias para criao, 71
diretos, 111 nveis, 70
estimativas, 111 tipos de, 77
237
238ndice
Escopo, 94 Instalao de novos itens, 96

do produto, 18 Integrao, 37
do projeto, 18 plano de gerenciamento do projeto, 38
Esquema das comunicaes, 146
Estimativas, 111 L
Estrutura Levantamento de opes de sustentabilidade, 96
analtica do projeto, 68 Lies aprendidas, 215
dicionrio, 90 Linha de base, 19
estratgias para criao, 71 Listas de verificao, 126
nveis, 70
tipos de, 77 M
analtica dos riscos, 152 Marketing, 96
organizacional, 18 Matriz de anlise qualitativa dos riscos, 152
Evitar, 153 Matriz RACI, 140
Execuo, 183 Mdia influncia com mdia participao, 175
reas de conhecimento, 186 Membros da equipe do projeto, 20
problemas comuns e solues, 184 Mtodo
5W2H, 194
F do caminho crtico, 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 histria do, 3 N
obras histricas, 3 Necessidades
princpios bsicos, 17 do negcio, 25
atividades, 21 organizacionais, 25
cliente, 17
entregas, 20 O
escopo, 18 Objetivo, 17
estrutura organizacional, 18 Operao e lojas sustentveis, 187
linha de base, 19 Oramentos, 111
objetivo, 17 Organizao
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 Padronizao da documentao, 94
requisitos, 23 Paramtrica, 111
restrio tripla, 22 Parte Interessada, 20, 169
restrio, 22 plano de gerenciamento, 171
tarefas, 21 registro, 170
Parthenon, 5
I Patrocinador, 20
Imprio Romano, 3 PERT, 10
Implantao, 96 PERT-CPM, 10
Indicadores de envolvimento, 173 Pesquisa
Informaes, registros de, 146 de campo, 95, 189
Infraestrutura, 96 junto aos clientes, 95
Iniciao, 27 Pirmides de Giz, 6
Inspeo, 96 Plano
ndice239
de gerenciamento Restrio Tripla, 22

das aquisies, 164 Reunio
de partes interessadas, 171 de encerramento, 97
do projeto, integrao, 38 de status, 95
do projeto, 94 Riscos, 95, 151
Ponto de vista, 176 estrutura analtica, 152
Pr-projeto, 25 matriz de anlise qualitativa, 152
Premissa, 20 Risk Breakdown Structure, 152
Princpios de sustentabilidade no varejo, 188 Roma, 4
Problemas comuns, execuo, 184
Processo de encerramento, 215 S
Produo, 96 Seleo das opes, 96
Program Evaluation and Review Technique, 10 SMART, 18
Programa Apollo, 9 Solues, execuo, 184
Project Charter, 27, 32 Sponsor, 20
Project Management Professional (PMP), 13 Stakeholders, 20
Projeto, 17, 25 Suposio, 20
iniciao, 27
pr-projeto, 25
T
Proposta de implantao, 96
Tabulao dos dados, 96
Tarefas, 21
Q
Tasks, 21
Qualidade, 123
Tempo, 94, 99
fluxogramas, 124
cronograma, 99
listas de verificao, 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 informaes, 146 financeira, 228
Relatrio(s), 146 legal, 229
de andamento do projeto, 148 operacional, 228
de lies aprendidas, 97 tcnica, 227
de status, 95
Requirements, 23 W
Requisitos, 23 Work Breakdown Structure (WBS), 11, 68
Resources, 21 Work Packages, 21
Restrio, 22 Workshop para os colaboradores e gerentes, 96

Marta Rocha Camargo Gerenciamento de Projetos Fundamentos e Pratica Integrada

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Marta Rocha Camargo Gerenciamento de Projetos Fundamentos e Pratica Integrada

Caricato da

Copyright:

Formati disponibili

Gerenciamento

Copidesque: Lucas de Souza Cartaxo

Elsevier Editora Ltda.

Servio de Atendimento ao Cliente

CIP-BRASIL. CATALOGAO NA PUBLICAO

Camargo, Marta Rocha

1. Administrao de projetos. 2. Empreendimentos. 3. Planejamento estratgico.

13-03453 CDD: 658.404

Do que este livro trata (escopo includo)

Como este livro est estruturado?

6. I mportante: Observaes importantes com relao a uma determinada parte do concei-

FIGURA A.1 Modelo de documento padro.

Recursos de apoio na web

CAPTULO 1 Breve Histria do Gerenciamento de Projetos............................................................03

1.1 Obras Histricas

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

FIGURA 1.2 Aqueduto romano em Segvia, 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, Grcia. Vassilis | Dreamstime.com.

FIGURA 1.6 Coliseu em Roma, na Itlia. Vladimir Sazonov | Dreamstime.com.

FIGURA 1.7 Baslica de Santa Sofia em Istambul, Turquia. Jackmalipan | Dreamstime.com.

FIGURA 1.8 Pirmides de Giz, Egito. Witr | Dreamstime.com.

1.2 Sculo XIX

FIGURA 1.10 Exemplo de um grfico de Gantt. Fonte: Modelos de Cronograma do MS Project.

Outro aspecto importante da histria do gerenciamento de projetos ainda no sculo XX o inves-

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

FIGURA 1.12 Misses Apollo. Philcold | Dreamstime.com.

FIGURA 1.13 Exemplo de um PERT simples.

FIGURA 1.14 PERT-CPM mostrando o caminho crtico (caminho mais longo).

Tabela 1.3 reas de Conhecimento do PMBOK

Tabela 1.4 Processos do PMBOK

1.4 Sculo XXI

CAPTULO 2 Princpios Bsicos em Gerenciamento de Projetos......................................................17

Os objetivos so 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 Suposio (Assumption)

2.1.8 Parte Interessada (Stakeholders ou os Envolvidos no Projeto)

2.1.9 Patrocinador (Sponsor)

2.1.10 Entregas (Deliverables ou Entregveis)

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 Restrio (Constraint)

2.1.15 Restrio Tripla (Triple Constraint)

FIGURA 2.3 Elementos da restrio tripla.

2.1.16 Requisitos (Requirements)

1. Faa a correspondncia 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:

O tipo de documentao elaborado nas propostas de pr-projeto ir variar, dependendo da empresa

A rede de supermercados A atende a clientes da classe B e C em uma cidade do interior do estado de So

FIGURA 3.1 Exemplo de pr-projeto.

FIGURA 3.1 (cont.)

Tabela 3.1 Atividades da Iniciao

FIGURA 3.2 Modelo genrico de um Termo de Abertura.

FIGURA 3.3 (Cont.)

Alm da elaborao e da aprovao do Termo de Abertura, para o projeto de implantao de prticas

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

FIGURA 3.4 (Cont.)

No aconselhvel detalhar o Termo de Abertura com descries de entregas ou atividades

6. I mportante: Observaes importantes com relao a uma determinada parte do concei-