Gerenciamento

de Projetos
Professora: Gizele Corrêa
Edição: 2013

1
 Apresentação
Muitas pessoas hoje se perguntam sobre
o real valor e aplicabilidade desse tal geren-
ciamento de projetos. Muitos estudantes se
perguntam se vale a pena dedicar-se aos estu-
dos de gerenciamento de projetos, quem sabe
fazer carreira nesta área. Se você já ouviu falar
sobre isso, já deve também ter se perguntado
a mesma coisa: até onde vale a pena investir
tempo e dinheiro para garantir um bom geren-
ciamento de projetos?
Essa mesma pergunta já foi feita e repeti-
da muitas vezes por várias pessoas envolvi-
das em empreendimentos das mais diferentes
complexidades. Da preparação de um novo
layout de fábrica ao lançamento de um novo
modelo de carro, da implantação de um novo
software a uma viagem de férias. Mas por que
essa febre avassaladora chamada gerência
de projetos está sendo ouvida e pregada em
toda parte nos dias de hoje?
As estatísticas demostram que:
• Mais de 30% dos projetos são cancela-
dos antes de serem completados;
• Mais de 70% dos projetos falham na en-
trega das funcionalidades esperadas; mos do resgate dos mineiros no Chile (em 69
dias tudo foi planejado e executado perfeita-
• A média de falhas de projetos estoura mente), ou a invasão da favela no Rio de Ja-
em mais de 189% do orçamento e extrapola neiro, ou o programa Apollo...
em 222% do cronograma previsto.
Conseguir terminar o que se previu, den-
Mas com tantos dados negativos, por que tro dos prazos esperados, com o custo com-
deveríamos, então, estudar gerenciamento de binado e da forma como se imaginou ainda é
projetos? um desafio para muitas empresas. E este é um
dos motivos pelos quais as empresas buscam
Porque muitos projetos falham justamente
bons gerentes e tantas pessoas buscam espe-
por não serem realmente gerenciados.
cialização nesta área.
Embora nenhum projeto seja absoluta-
Vamos então entender o que é um projeto,
mente perfeito, alguns deles conseguem che-
como se gerencia e conhecer um pouco mais
gar ao final com uma quantidade mínima de
sobre o assunto?
problemas e, apesar das dificuldades, muitos
projetos terminam com sucesso. É só lembrar- Bons estudos!

2
 Ementa
Apresentação de gerência de projetos;
metodologia de gerência de projetos
- ciclo da vida da gestão de projetos;
análise de riscos e medidas gerenciais
derivadas; gerência de requisitos;
técnicas para planejamento de projetos
objetivos e abrangência - organização
do trabalho - cronograma, PERT,
recursos e custos; uso de ferramentas
de planejamento e acompanhamento de
projetos; software de gerenciamento de
projetos; prática de gerência - motivação

Plano de e tratamento de conflitos em equipes de

projetos.

Estudos
Objetivos Específicos
Objetivo Geral • Conhecer o conceito de projetos e seu
Conhecer os ambiente organizacional;
processos de gerência • Identificar o papel do gerente de
de projetos e as projetos e os envolvidos;
áreas administrativas • Identificar a metodologia de
envolvidas gerenciamento de projetos;
• Identificar as áreas administrativas
envolvidas no gerenciamento de projetos;
• Conhecer os processos de
gerenciamento de projetos com base no
PMBOK;
• Conhecer em mais detalhes dos
processos de gerenciamento de riscos,
Carga horária: 80 horas gerenciamento de custos, gerenciamento
da qualidade, gerenciamento das
comunicações, gerenciamento de
contratos e aquisições.

3
 “Nenhum empreendimento pode ser con-
siderado tão pequeno que não se benefi-
cie do gerenciamento de projetos.”
Sunny Baker

Unidade 1
Noções Objetivos
O
Básicas de Di
• Discernir sobre o universo do
gerenciamento de projetos;
• Conceituar projetos;
Gerenciamento • Identificar o ambiente do projeto;
• Pontuar a relevância da estrutura
organizacional em que projeto está
de Projetos inserido;
• Identificar os tipos de estruturas
organizacionais;
• Contextualizar a importância da cultura
organizacional como diferencial para o
sucesso do projeto.

N esta 1ª unidade, a
introdutória, você aprenderá
o que são os projetos e estudará
alguns conceitos básicos de Conteúdos
gerenciamento de projetos, o
ambiente do projeto, as estruturas • Noções Básicas de Gerenciamento de
organizacionais voltadas ao Projetos;
projeto, as partes interessadas e o • Gerenciamento de Projetos;
que é sucesso em projetos. • Ciclo de Vida de Projetos;
Bons estudos! • Partes Interessadas;
• O Gerente de Projetos;
• Sucesso em Projetos.

4
 1 Terminologias
e Aplicações
S egundo a norma “NBR ISO 21500:2012 Ori-
entações sobre Gerenciamento de Projeto”,
“projeto é um conjunto único de processos que
consiste em atividades coordenadas e con-
troladas com datas de início e fim, empreendi-
das para atingir os objetivos do projeto. O al-
cance dos objetivos do projeto requer provisão
de entregas, conforme requisitos específicos”.
Segundo o PMBOK, “projeto é um esforço
temporário, empreendido para criar um produ-
to, serviço ou resultado exclusivo”.
Temporário não quer dizer que terá uma
curta duração. Por temporário, entende-se
que o mesmo precisa ter um início e um térmi-
no definidos (é finito). O término é alcançado
quando os objetivos do projeto foram atingi-
dos, mas também pode ser quando se conclui
que os objetivos não poderão ser alcançados
ou quando o projeto mostrar-se desnecessário.
Não significa que o resultado deste projeto
será temporário também. O resultado dos pro-
jetos pode ser curto ou duradouro.
Por resultado exclusivo entende-se que
o projeto gera um produto, serviço ou resul-
tado único. Alguns elementos repetitivos po-
dem estar presentes em algumas entregas
dos projetos. Porém esta repetição não muda
a característica de singularidade do projeto. As
diferenças nos projetos podem ocorrer nas en-
5
PMBoK é o guia de referência
em gerenciamento de projetos.
Veremos mais sobre ele a seguir.
tregas fornecidas (produtos e subprodutos),
nas influências das partes interessadas, nos
recursos utilizados, nas restrições, na manei-
ra como os processos são adaptados para
criar o produto ou as entregas.
Esta singularidade pode gerar muitas in-
certezas quanto aos produtos, serviços ou re-
sultados. Algumas tarefas podem ser novas,
gerando mais dificuldade para o planejamento.
O projeto também tem que ter objetivos
definidos e é realizado por pessoas (podendo
ser uma única pessoa, algumas pessoas ou
até várias unidades organizacionais).
O projeto é caracterizado por atividades
encadeadas logicamente de modo a permitir
que, durante a execução, o acompanhamen-
to e o controle sejam precisos.
Ao se iniciar um projeto, é de fundamen-
tal importância que se saiba onde se quer
chegar. Se não for bem definido, qualquer
caminho parecerá poder atendê-lo e a pos-
sibilidade de fracasso torna-se muito mais
elevada.
 Os projetos atingem todos os níveis da
organização. Podem ser aplicados a todas
as áreas do conhecimento humano e muitas
vezes precisa ser subdividido em partes, de
fácil gerenciamento e controle, chamadas
subprojetos.

Como exemplo de projetos pode-se citar:

• Desenvolvimento de um novo produto
ou serviço;
• Instalação de uma nova planta industrial;
• Reestruturação de um setor da empresa;
• Construção de um edifício;
• Realização de uma viagem;
• Uma festa.
Outros exemplos de projeto são a
realização da Copa do Mundo e as Ol-
impíadas, entre outros.
Em todos estes exemplos existem
um ou mais “entregáveis” (deliverables),
que são únicos. Também todos são fini-
tos e tem recursos envolvidos. Alguns
destes envolvem subprojetos auxiliares.

6
 Gerenciamento
de Projetos
Segundo a norma NBR ISO Escopo
21500:2012, “gerenciamento de pro- Comunicação Riscos
jetos é a aplicação de métodos, fer-
ramentas, técnicas e competências
para um projeto.” Ele inclui a inte- Recursos
gração de várias fases do ciclo de Tempo
Humanos
vida do projeto.
Gerenciamento de projetos Projeto
é a aplicação do método, ferra-
mentas, competências e técnicas Partes
de projetar atividades, no intuito Aquisições interessadas
de atender aos requisitos do pro-
jeto. É uma ciência que segue um
processo sistemático.
Custos Integração
Gerenciar projetos é um desafio.
Qualidade
Projeto é algo que nos tira da zona de con-
forto. Se o projeto é fácil, você não será o ger-
ente deste projeto. Não existe projeto fácil. Im-
aginem a cena: você é chamado para
construir uma casa por R$ 1 bilhão, e
terá 20 anos para construir esta casa. Áreas de Conhecimento
Isso é fácil de fazer. Agora pensemos
nesta mesma casa, sendo construída da Gerência de Projetos
em 6 meses, com um limite de R$
80mil. Isso sim é um desafio.
Os 47 processos, distribuídos nas 10 áre-
Gerenciar projetos é atingir metas. Quando as (integração, escopo, tempo, custos, riscos,
você as atinge, novas metas são definidas e o qualidade, comunicação, recursos humanos,
trabalho recomeça. Um novo projeto se inicia e aquisições e partes interessadas) e 5 grupos
o anterior passa a impressão de ser fácil se pre- (iniciação, planejamento, execução, monitora-
cisar repetir. mento e controle, encerramento), serão vistos
Para gerenciar projetos utilizamos os 47 ao longo deste material. Constam, nos anexos,
processos de forma integrada, abrangendo um mapeamento dos grupos de processos e o
os 5 grupos. fluxograma dos processos.

Apesar de muitas pessoas acharem que

gerenciamento de projetos só é aplicável em
grandes empresas, isso é um erro. É possível
aplicar gerenciamento de projetos em qualquer
projeto. Podemos, sim, eliminar alguns proces-
sos, simplificar as áreas, juntar alguns itens e
gerenciar o projeto de forma adequada ao tipo
e tamanho de projeto, aplicando apenas o que
for justificável. Fácil, prático e direto! Podemos
aplicar gerenciamento de projetos no campo
profissional e até em projetos pessoais.

7
 Partes
Interessadas

Governança de projetos
&RQVHOKRRXFRPLWr
H[HFXWLYRGRSURMHWR

2UJmRV 3DWURFLQDGRU 3DUFHLURV

UHJXODWyULRV GRSURMHWR GHQHJyFLRV

(VFULWyULRGH &OLHQWHV (PSUHJDGRV

JHUHQFLDPHQWR $FLRQLVWDV
GRSURMHWR

*UXSRGH *HUHQWH
)RUQHFHGRUHV
LQWHUHVVH GRSURMHWR
HVSHFLDO )LQDQFLDGRUHV
(TXLSHGH
JHUHQFLDPHQWR
GRSURMHWR

(TXLSHGRSURMHWR

Organização do projeto

Segundo o PMBOK, “as partes interes- Dentre as partes interessadas, a principal

sadas no projeto são pessoas e organizações
ativamente envolvidas no projeto ou cujo inter-
esse pode ser afetado como resultado da ex-
ecução ou término do projeto”. Seus interesses
podem sofrer impactos positivos ou negativos
com o projeto. Também podem ser pessoas e
organizações que exercem influencia positiva
ou negativa no projeto.
A equipe de gerência de projetos deve
identificar estas partes, determinar suas ne-
cessidades e expectativas e, na medida do
possível, gerenciar sua influência em relação
aos requisitos para garantir um projeto bem
sucedido.
é o patrocinador (sponsor). O patrocinador é
a pessoa que dá cobertura política e fornece
apoio ao projeto junto à alta gerência. É a pes-
soa que libera a verba do projeto e que auxilia
a fixação da autoridade do gerente de projeto.
É quem delega poderes ao gerente de projeto,
mas principalmente é quem defende o projeto
visando sua viabilização. É o “padrinho” do
projeto.
Outras partes interessadas podem ser:
o cliente, o gerente de projeto, a equipe de
projeto, os usuários finais, os fornecedores, o
escritório de projetos, os gerentes funcionais
e, em alguns casos, a sociedade em geral.

8
 A Tripla
Restrição
O termo “tripla restrição” refere-se Ou seja, se um cliente solicitar uma
às demandas de escopo, tempo e redução no prazo, provavelmente ha-
custo. O PMI define a tripla restrição verá uma alteração no custo e/ou no
como: “Uma estrutura para avaliar escopo. Se for necessário manter
demandas que competem entre o escopo e o custo inalterados,
si”. A forma pela qual essas com certeza é a qualidade que
três demandas são equili- será afetada pela redução do
bradas afeta diretamente a prazo, pois poderá ser ne-
qualidade. Se um desses cessário deixar de realizar
fatores é afetado, pelo testes e inspeções para
menos um dos ou- entregar em tempo re-
tros fatores também duzido.
será afetado.

Com certeza também é necessário gerenciar riscos, qualidade, recursos, etc., nos projetos.
No entanto, essas restrições adicionais acabam afetando o escopo, o tempo e o custo, voltando
à tripla restrição.

A restrição tripla é um bom modo de mostrar as escolhas que devem

ser feitas entre prioridades que competem entre si. Qual destes três
fatores é o mais importante em um projeto? Depende do projeto!
Em cada projeto deve ser determinado qual o fator mais importante
e qual pode ser “sacrificado” caso necessário. O que tem que ficar
bem claro é que, alterando um dos fatores, pelo menos um dos
outros será afetado.

9
 2 Estruturas
Organizacionais
O estilo, a cultura e a estrutura
das organizações podem
ser tanto uma alavanca quanto
um empecilho para a execução
do projeto. O grau de maturação
da organização em relação
ao gerenciamento de projetos
também influencia a execução do
projeto.

A estrutura organizacional
influencia diretamente a execução
dos projetos porque pode afetar a
disponibilidade dos recursos e a
condução dos projetos. Mesmo
quando o projeto é externo
(executado em parcerias ou sob
o comando de várias empresas),
ainda será influenciado pela
organização ou organizações
que o estabeleceu.

As estruturas organizacionais
são definidas em termos do
nível de autoridade do gerente
de projetos. Podem ser do
tipo funcional, matricial (fraca,
balanceada e forte) e projetizada.
Isso determinará quem o gerente
de projetos deve procurar para
obter ajuda com os recursos,
indica como a comunicação
deve ser administrada, além de
outros itens de gerenciamento de
projetos.

10
 Estrutura
Funcional
É a estrutura mais comum, onde a em-
presa é dividida em departamentos funcionais
(manutenção, rede, recursos humanos, vendas,
marketing, PDC, etc.) e cada setor responde ao
seu gerente imediato (a partir de agora chama-
do de gerente funcional). Todos têm suas tare-
fas diárias bem definidas e sabem a quem de-
vem obedecer, bem como a quem se reportar
(no caso, o gerente funcional).
São estruturas conhecidas também como
hierárquicas, pois apresentam um organograma
bem definido em termos de departamentos/fun-
ções organizacionais. Os funcionários são super-
especializados e possuem funções bem definidas.
Para o gerenciamento de projetos as or-
ganizações funcionais são as piores, uma vez Muitas vezes a posição de gerente de
que nelas o gerente de projetos tem pouca ou projeto nem sequer existe formalmente numa
nenhuma autoridade formal. Estrutura Funcional, o que faz com que a mes-
ma seja pouco valorizada e muitas vezes sua
Geralmente, os projetos são realizados autoridade seja próxima de nula. Na estrutura
dentro do departamento e se há alguma ne- funcional manda o gerente funcional (gerente
cessidade de interação com outro setor da do setor). O projeto, e consequentemente seu
empresa, há uma conversa entre os coordena- gerente, perde para as atividades do dia-a-dia
dores/gerentes das duas áreas previamente, e as tarefas que são delegadas com alto nível
tendo a hierarquia respeitada. de prioridade pelo gerente funcional.

11
 Estrutura
Matricial
Existem três tipos de Estruturas Matriciais, mostrando o nível de maturidade em projetos e
as necessidades das empresas que as adotam. As organizações com estrutura matricial tentam
unir o melhor dos dois mundos das estruturas funcionais e projetizadas.
As organizações matriciais podem ser fraca, moderada/balanceada ou forte.

As estruturas matriciais fracas

apresentam características semelhantes
às estruturas funcionais.

O meio termo, onde há o verdadeiro equilíbrio

de autoridade entre o gerente funcional e o
gerente de projetos é a organização matricial
moderada (ou balanceada).

As estruturas matriciais fortes

apresentam características mais
parecidas com as estruturas por projeto.

Este tipo de organização

apresenta duas grandes
vantagens: a equipe do projeto
tem sempre para onde retornar
quando os projetos acabam
e a utilização dos recursos é
otimizada.

Em contrapartida, surge um
grande problema: a comunicação
torna-se mais complexa, pois
a equipe do projeto passa a
responder tanto ao gerente
funcional quanto ao gerente de
projetos.

12
 Estrutura Matricial Fraca
A estrutura matricial fraca traz a figura do
gerente de projetos estabelecida formalmente
dentro da hierarquia da empresa. Os times de
projetos são diversificados (multissetoriais), o
que permite que a empresa trabalhe com pro-
jetos mais complexos. Esta estrutura mostra
uma empresa que percebe a importância dos
projetos, mas que ainda não decidiu/precisou
rever sua posição quanto aos projetos e/ou
desenvolver projetos de grande porte.
Nessa estrutura, o gerente de projetos tem
um pouco mais de visibilidade e sua posição é
definida formalmente, bem como a quantidade
de tempo em que ele ficará alocado naquele
projeto. A existência de times multifuncionais
cria uma diversidade de pensamento criativo e
um expertise que é fundamental para o plane-
jamento eficaz de projetos mais complexos.
13
O problema é que o gerente de
projetos, apesar de formalmente
estabelecido, não tem o mesmo poder
decisório de um gerente funcional. O
dilema rotina x projeto ainda existe,
assim como na estrutura funcional,
uma vez que o time de projetos ainda
se reporta diretamente aos seus
gerentes funcionais.
É mais comum em projetos pequenos
e médios. O gerente e a equipe de projetos
trabalham parcialmente no projeto, mantendo
ainda suas funções tradicionais. E o gerente
de projetos ainda tem baixo poder decisório,
apesar de ser maior do que na estrutura
funcional.
 Matriz Moderada ou Balanceada
A estrutura matricial moderada dá um
pouco mais de poder ao gerente de projeto
e é o meio termo entre a estrutura funcional
e a estrutura por projetos, apresentada mais
a frente. Uma estrutura matricial moderada
indica uma maior maturidade em projetos. As
empresas que adotam a estrutura matricial
moderada tem uma cultura de projetos bem
desenvolvida e reconhecem no gerenciamen-
to de projetos uma ferramenta que agrega va-
lor à organização.
A autoridade do gerente
de projetos é bem definida
e a aquisição de recursos,
comunicação e definição
de prioridades ocorre de
forma mais fácil do que nas
estruturas matriciais fracas.
14
Porém o atrito entre o gerente
de projetos e os gerentes
funcionais tende a ser maior
nessa estrutura, em decorrência
da maior autoridade do gerente
de projetos.
Se não bem definida inicialmente, a co-
municação pode se tornar caótica, com os re-
cursos do time de projetos se reportando aos
gerentes funcionais em vez do gerente de pro-
jetos.
O time de projetos deve ter um foco bem
definido e boa capacidade de gestão de tem-
po, ou problemas com as entregas do proje-
to podem acontecer, devido à ainda existente
pressão para se dar conta também das tarefas
do dia-a-dia.
São normalmente utilizadas em projetos
médios a complexos. O gerente de projetos
está alocado no projeto em tempo integral, as-
sim como a equipe de projetos. O gerente de
projetos tem poder decisório.
 Estrutura Matricial Forte

Este modelo, utilizado em organizações entes de projetos em tempo integral, normal-

de alto nível de maturidade em projetos (mas
que ainda tem necessidade de execução de
algumas rotinas diárias), é ideal para projetos
de alto nível de complexidade, uma vez que
permite que o gerente de projetos tenha uma
parte do time de projetos alocada em tempo
integral para sua execução.
Neste nível, a organização percebe que
projetos são fundamentais para seus objetivos
estratégicos e passa a oferecer apoio aos ger-
mente na forma de um PMO.
Conseguir recursos para os projetos pas-
sa a ser uma tarefa para os gerentes, uma vez
que a quantidade de projetos é grande e a
disponibilidade de recursos normalmente limi-
tada aos funcionários da empresa. Networking
passa a ser uma necessidade, para se influ-
enciar os processos decisórios e conseguir
os recursos necessários para a execução do
projeto.

É utilizado em projetos grandes e complexos. O gerente de

projetos e a equipe de projetos são alocados em tempo integral.
O gerente de projetos tem grande poder decisório e tem grande
apoio administrativo da organização.
15
 Estrutura por Projetos
(ou Projetizada)
A Estrutura Projetizada foca nos projetos
(ao contrário da estrutura funcional, que se
preocupa mais com as atividades do dia-a-
dia). Organizações que empregam a Estrutura
Projetizada lidam quase que exclusivamente
com a elaboração, gerenciamento e execução
de projetos. Algumas vezes, não possuem um
quadro extenso de recursos como nas outras
estruturas e contratam de acordo com a ne-
cessidade do projeto.
Na estrutura por projetos o gerente de pro-
jetos tem toda autoridade. As organizações que
utilizam essa estrutura vivem em torno de seus
projetos. Todos os recursos organizacionais,
sejam humanos, financeiros ou equipamentos,
estão disponíveis para dar suporte aos projetos.
16
São estruturas conhecidas como home-
less, pois a equipe do projeto, após o término
do projeto, não terá mais o que fazer, a menos
que tenha outro projeto para ser alocada. Ou
seja, terminado o projeto, termina também o
contrato da equipe.
O gerente de projetos tem o controle
do projeto, sua autoridade é bem definida
e ele recebe o suporte da própria estrutura
organizacional. Há uma grande chance
de existir um PMO (escritório de projetos,
que veremos nas próximas unidades). Em
alguns casos, existe um pool de recursos
humanos, uma lista de pessoas que podem
ser alocadas em projetos e que ficam a
disposição da organização.
 Porém a estrutura projetizada tem seus
problemas. A seleção de recursos pode ser
complicada quando todos os gerentes pre-
cisam de um determinado recurso, mas este
é escasso. Pode ser um técnico qualificado,
uma determinada ferramenta ou a priorida-
de num financiamento. Isso pode ser mini-
mizado com a existência de um PMO, se o
mesmo determinar as prioridades dos pro-
jetos dentro dos objetivos da organização.
Uma vez que o projeto termine, os recursos
ficam num limbo operacional, sem ter uma
função até que sejam designados para um
novo projeto.
Em organizações que decidem por con-
tratar os recursos, o problema aparece quan-
do o projeto chega perto do encerramento e
os recursos percebem que seu emprego está
ameaçado, pois não há a certeza de uma re-
alocação para um novo projeto, nem a como-
didade de um retorno para a rotina da organi-
zação. Ambas as situações criam certo nível
de insegurança nos mesmos.
O gerente de projetos e a equipe de proje-
tos são alocados em tempo integral. O gerente
de projetos tem poder decisório (de 90 a 100%) e
tem grande apoio administrativo da organização,
além de um pool de recursos à sua disposição.

Não existe uma estrutura que seja perfeita para todas as

organizações, nem a melhor estrutura para desenvolvimento de
todos os projetos. Existe, sim, a necessidade da organização, a
complexidade do projeto e seu nível de maturidade. Nada impede
que uma empresa baseada na estrutura funcional crie uma equipe,
em estrutura matricial forte, para o desenvolvimento de um projeto
que de outra forma não seria possível de se gerenciar. Ou que
uma organização projetizada tenha alguns núcleos funcionais para
projetos internos.

Estrutura da
organização
Matricial
Funcional Por projeto
Características
do projeto
Fraca Balanceada Forte

Autoridade do Pouca ou Baixa a Moderada Alta a

Limitada moderada quase total
gerente de projetos nenhuma a alta

Disponibilidade Pouca ou Baixa a Moderada Alta a

Limitada a alta quase total
de recursos nenhuma moderada

Quem controla o Gerente Gerente Gerente de Gerente de

Misto projetos projetos
orçamento do projeto funcional funcional

Função do gerente Tempo integral

Tempo parcial Tempo parcial Tempo integral Tempo integral
de projetos

Equipe administrativa
do gerenciamento Tempo parcial Tempo parcial Tempo integral Tempo integral Tempo integral
de projetos

Influências da estrutura organizacional nos projetos

17
 3 O Gerente
de Projetos
O gerente de projetos é o res-
ponsável por gerenciar os
projetos, o que implica planejá-
-los e controlá-los. Além disso,
deve: incentivar, motivar e alocar
eficientemente a equipe de exe-
cução; prestar contas às partes
interessadas sobre o andamento
do projeto, quanto a problemas e
soluções, através de relatórios e
reuniões.
O gerente de projetos tem
que servir de exemplo para os
demais. Deve ser líder, organi-
zado, ético. Deve saber motivar,
mas também saber cobrar. Não
precisa, necessariamente, saber O gerente de projetos aloca recursos, ajusta as prio-
tudo sobre a área do projeto, mas ridades, coordena interações com clientes e usuários e
precisa saber tudo de gerencia- geralmente mantém a equipe do projeto concentrada na
mento de projetos, e ter uma boa meta certa. O gerente de projeto também estabelece um
equipe com conhecimentos espe- conjunto de práticas que garantem a integridade e a qua-
cíficos na área do projeto. lidade dos artefatos do projeto.

Cada projeto terá um, e

apenas um, gerente de
projetos. Para grandes
projetos, o gerente de
projetos pode dividir em
subprojetos, e para cada
subprojeto um subgerente
de projetos, que estará
subordinado a ele.

18
 4 Sucesso
em Projetos
Quando se fala em sucesso
em projetos, muita gente
imagina que signifique
terminar o projeto bem antes
do prazo, com custos abaixo
do orçamento, consumiu
menos recursos do que o
previsto, acrescentou-se mais
produtos do que o solicitado
pelo cliente...
19
P orém sob a ótica de gerenciamento de
projetos, nada disso descreve um projeto
bem sucedido. Um projeto bem sucedido é
aquele que é realizado exatamente conforme
o planejado, nem mais, nem menos. O fato de
um determinado projeto superar seu plano, ou
seja, consumir menos recursos que o previsto
ou terminar mais rápido, sob o olhar de ger-
enciamento de projetos, demonstra uma falha,
já que houve erro no planejamento do mesmo
(e não uma economia, como algumas empre-
sas avaliam). Essa falha fez com que os recur-
sos fossem superestimados ou folga fossem
acrescidas nas atividades.
 Assim, o sucesso, em geren-
ciamento de projetos, é definido
através dos resultados obtidos em
relação ao prazo, custo, qualidade
e escopo desejados, sem esque-
cer os demais parâmetros. Segun-
do Ricardo Viana Vargas, para se
considerar um projeto bem sucedi-
do devemos avaliar:

• Se o projeto foi concluído dentro do prazo;

• Se foi concluído dentro do orçamento;

• Se utilizou os recursos de forma eficiente, sem desperdícios;

• Se atingiu a qualidade e a performance desejadas;

• Se foi concluído com o mínimo de modificações no escopo;

• Se foi aceito sem restrições pelo contratante ou cliente;

• Se foi concebido sem que ocorressem interrupções ou

interferências nas atividades normais da organização;

• Se não agrediu a cultura da organização.

Logo, se no fim de um projeto o ger-
ente de projetos identificar que o projeto
durante a execução do projeto acrescen-
tou-se alguns subprodutos não solicitados
pelo cliente, mesmo que o cliente expresse
satisfação com o projeto final, o mesmo
fracassou. Trabalho supérfluo (“gold plat-
ing”) em um projeto desperdiça tempo e
provavelmente custos. Ele contribui para
o fracasso do projeto.
Para que seja possível chegar ao sucesso
nos projetos é importante selecionar corretamente
a equipe, mantendo-a motivada e comprometida,
além de estabelecer es-timativas de custos, tempo
e qualidade de forma realista, sem folgas de se-
gurança, sem ser otimista ou pessimista demais.
Também é importante manter as modificações sob
controle, avaliando sempre seu impacto sobre o
projeto, além de manter a comunicação de forma
coerente, sem falta ou excesso de informações.

20
 5 Projetos
Problemáticos

Todo projeto é um
desafio. Porém S ão aqueles projetos em que a variação entre
o que se esperava e o que aconteceu exce-
deu os limites de tolerância que se podia acei-
há projetos que tar, fazendo com que ele entre em uma rota que
inevitavelmente pode levá-lo ao fracasso. É algo
extrapolam o limite do muito crítico, muito além do desafio normal dos
desafio e tornam-se projetos, e deverá ter um tratamento diferencia-
do, sob pena de fracasso total do mesmo.
problemáticos.

21
 Segundo Ricardo Viana Vargas, existem
alguns indicadores que mostram que um pro-
jeto é problemático:

• O projeto tem um índice de insatisfação do patrocina-

dor, gerência executiva ou o cliente muito altos;
• O cliente diminui sua participação, seu envolvimento
no projeto, afastando-se dele;
• O cliente não está preparado para assumir suas res-
ponsabilidades, não quer tomar decisões em relação ao
projeto;
• Os recursos são ou passam a ser escassos: material
com qualidade e/ou quantidade inferior ao necessário
para o projeto;
• A equipe do projeto demonstra inexperiência e falta
de habilidade com o projeto;
• Há um aumento significativo no turn over, as pessoas
da equipe desistem de fazer parte da equipe e saem,
havendo alta rotatividade;
• Mudanças significativas constantes no escopo do projeto;
• Falta de acordo entre as partes interessadas quanto ao entendimento do que faz ou não parte
do escopo;
• Aumento significativo na probabilidade ou no impacto dos riscos;
• Fracasso na implementação dos planos de contingência dos riscos;
• Atraso do projeto ou estouro no orçamento evidentes;
• Progresso insatisfatório dentro das restrições, ou seja, a evolução do projeto torna o produto
incompatível comercialmente (apartamen-
tos com custo muito acima do mercado,
ou com poucos recursos se comparados
com outros do mesmo preço);
• Aumento da informalidade das docu-
mentações e/ou diminuição na frequência
e confiabilidade na atualização das infor-
mações relacionadas ao projeto, evitando
deixar “provas” do fracasso, ou na tenta-
tiva de recuperá-lo sem deixar registros
dos problemas.

Projetos problemáticos
dependem de um bom gerente
de projetos, de experiência em
gerenciamento de projetos e
de uma equipe dedicada, a fim
de resolvê-lo mais facilmente.

22
 Até aqui...
No decorrer desta unidade, estudamos a defini-
ção de projeto segundo o PMBOK, o significado de
gerenciamento de projeto; o ciclo de vida do projeto
e sua subdivisão em fases, quais sejam: concepção,
planejamento, execução e conclusão; quem são os
stakeholders ou partes interessadas no projeto.
Sobre as estruturas organizacionais, estudamos
o que significam e sua subdivisão em: funcional,
matricial, matricial fraca, moderada ou balanceada
e matricial forte. De cada uma das subdivisões, es-
tudamos as características e como funcionam.
Concluímos verificando qual o foco da Estrutu-
ra Projetizada; as qualidades fundamentais de um
gerente de projetos e enfatizando a importância do
planejamento para o sucesso do projeto.

23
 “O tempo não espera por ninguém, e em
nenhum outro lugar isso é tão real quanto
no gerenciamento de projetos”.
Jim MacTntyre

Unidade 2
PMI,
Certificação
Objetivos
Ob
PMP/CAPM, • Conscientizar-se da importância do PMI;
• Conhecer as certificações existentes;
PMBOK, PMO • Tomar conhecimento do guia PMBOK,
para a área de gerenciamento de projetos;

e Softwares • Conhecer o que são os escritórios de

Projeto;
• Saber mais sobre os softwares de
Gerenciamento de Projetos.

N esta 2ª unidade, você estudará

as diretrizes internacionais que
regem a metodologia de gerência
Conteúdos
• PMI e sua história;
de projetos e conhecerá as • Certificações do PMI;
certificações existentes. • Guia PMBOK;
Bons estudos! • PMO;
• A Tripla Restrição;
• Softwares.

24
 1 O PMI
(Project Management Institute)
Principal associação
mundial sem fins lucrativos
que associa profissionais
de gestão de projetos, o
Project Management Institute
(PMI) foi fundado por cinco
voluntários, em 1969, na
Filadélfia, voluntários
estes que entendiam o
valor do networking, do
compartilhamento das
informações dos processos e
da discussão dos problemas
comuns de projetos.
N o início de 2011 já era considerada a maior
associação do gênero no mundo, uma vez
25
que integra mais de 350.000 associados e
mais de 450.000 certificados em cerca de 190
países (dados de jul/2011 – fonte PMI). São
profissionais que praticam e estudam geren-
ciamento de projeto nas mais diversas áreas
como aeroespacial, automobilística, admi-
nistração, construção, engenharia, serviços
financeiros, tecnologia da informação, farma-
cêutica, telecomunicações, entre outras.
O escritório central localiza-se em Newto-
wn Square, na periferia da cidade da Filadél-
fia, em Pensilvânia (Estados Unidos). Seus
principias objetivos são:
• Formular padrões profissionais de gestão de
projetos;
• Gerar conhecimento por intermédio da in-
vestigação;
• Promover a gestão de projetos como profis-
são através de seus programas de certifica-
ção.
A meta principal do PMI é avan-
çar na prática, na ciência e na pro-
fissão de gerenciamento de projetos
em todo o mundo, de uma maneira
consciente e proativa, para que as
organizações em todos os lugares
apoiem, valorizem e utilizem o ge-
renciamento de projetos – e então
atribuam seus sucessos a ele.
 2 As Certificações

Existem cinco categorias de

certificação pelo PMI, que
são as mais confiáveis e mais
consideradas pelo mercado
de trabalho: PMP, CAPM,
PgMP, PMI-SP e PMI-RMP.

PMP Em linhas gerais o candidato precisa

A credencial Project Management
Professional (PMP) foi criada em 1984
e consiste na certificação da qualidade
profissional individual promovida pelo PMI
e reconhecida em todo o mundo, tanto no
que diz respeito ao conhecimento quanto à
experiência necessária ao bom desempenho
da missão de gerenciar projetos. O processo
de certificação PMP consiste em uma pré-
qualificação do candidato seguido de uma
prova de múltipla escolha sobre as áreas de
conhecimentos em gerenciamento de projetos
segundo o PMBOK.
comprovar experiência em projetos equiva-
lente a um mínimo de 4.500 ou 7.500 horas
dependendo se é ou não formado em nível
superior, além de 35 horas de educação re-
cebida especificamente na área de gerencia-
mento de projetos. É necessário pagar a taxa
de inscrição e realizar o exame.
O exame para PMP consiste de uma
prova de múltipla escolha com 200 questões
-com 4 opções de resposta cada. O candida-
to tem um máximo de 4 horas para completar
o teste. O percentual mínimo de acerto das
questões da prova para garantir a qualificação
do profissional deve ser de 60,5%.

26
 CAPM
A certificação CAPM foi criada com o objetivo de
viabilizar a certificação de membros de equipe
e gerentes de projeto e até de estudantes (com
pelo menos 2º grau completo) que estão iniciando
nas carreiras de gerenciamento de projetos.
Esta certificação tem como objetivo beneficiar
profissionais de todas as áreas, pois demonstra o
interesse do profissional no ganho de conhecimentos
em processos e terminologias de gerenciamento de
projeto.
PgPM
A certificação PgMP foi lançada em 2007 e é voltada
para gerentes de programa, que na definição do
PMI é “um grupo de projetos relacionados gerenciados
de modo coordenado para a obtenção de benefícios
e controle que não estariam disponíveis se eles
fossem gerenciados individualmente. Programas
podem incluir elementos de trabalho relacionados
fora do escopo dos projetos distintos no programa”.
27
PMI-SP e PMI-RMP
E m decorrência dos projetos terem se
mostrado maiores, mais complexos
e mais diversos globalmente, o mercado
sugere que risco e cronograma sejam
tratados como aspectos chave de um
projeto. Assim, o PMI criou, em 2008,
as certificações PMI-SP e PMI-RMP.
A certificação PMI-SP (PMI Sche-
duling Professional) foi criada com o
objetivo de validar a experiência e co-
nhecimento inerente à programação e
elaboração de cronogramas de proje-
to.
A certificação PMI-RMP comprova
a capacitação em termos de habilida-
des e conhecimentos dos profissionais
credenciados para atuarem em proje-
tos críticos, através da identificação e
mapeamento de riscos, definição de
respostas (mitigando ameaças e capi-
talizando oportunidades) e comunican-
do os riscos.
 3 O PMBOK
O Project Management Body of Knowledge,
que nesta apostila chamaremos de
PMBOK® é um conjunto de práticas em
O PMBOK® formaliza diversos conceitos
em gerenciamento de projetos, como a pró-
pria definição de projeto e do seu ciclo de
gerência de projetos levantado pelo Project vida, reconhece 5 grupos de processos de
Management Institute (PMI) e constituem a gerenciamento de projetos e 10 áreas de co-
base da metodologia de gerência de projetos nhecimento. Ao todo, são 47 processos.
do PMI.
Estas práticas são compiladas na forma
Na versão anterior (4ª. Edição),
de um guia, chamado de Guia do Conjunto
de Conhecimentos em gerenciamento de pro- eram 9 áreas apenas, não existia
jetos, ou Guia PMBOK. O PMBOK® não é a área Gerenciamento das Partes
uma norma, é apenas um guia de co- Interessadas. Esta estava inserida
nhecimentos e boas práticas em ge- na área de Comunicação na
renciamento de projetos. Ele traz infor- versão anterior. Eram, então, 42
mações do que fazer, mas não diz como fazer. processos, contra os 47 atuais.
Editado na forma de livro, o PMBOK®
está atualmente na quinta edição (dez/2012) e
traduzido oficialmente para diversos idiomas,
inclusive o português do Brasil. As edições an-
teriores foram publicadas nos anos de 1996,
2000, 2004 e 2008.
A 5ª edição foi lançada em 31 de dezem-
bro de 2012 em inglês, e a previsão é que es-
teja disponível em português em meados de
maio de 2013 .

Note que depois do lançamento

oficial se passarão vários meses
até que haja mudanças nos exames
Certified Associate in Project
Management (CAPM®) e Project
Management Professional (PMP®).
Ou seja, os exames somente vão
passar a refletir o novo guia a partir
do dia 31 de julho de 2013. Até lá
continua valendo a 4a edição do
guia, que é usada desde 2009.

28
 4 O PMO
O PMO (Project Management
Office) é o Escritório de
gerenciamento de projetos. É
um escritório central dentro
da organização que tem a
função de conduzir, planejar,
organizar, controlar e finalizar
o projeto.
29
É a área dentro da empresa responsável por
dar suporte aos projetos e criar padrões
para os projetos. O PMO não fiscaliza os
projetos, apoia o gerente de projetos durante
todas as fases do projeto.
O PMO é o responsável pela metodologia
de gerenciamento a ser utilizada na organiza-
ção no que diz respeito a gerenciamento de
projetos, dar suporte administrativo e metodo-
lógico ao gerente e ao time de projetos e pro-
ver os recursos necessários para a execução
do projeto.
 5 Softwares
Existem vários softwares
que podem ser utilizados
para gerenciar projetos, de
gratuitos a pagos. O mais
conhecido e utilizado é o
MS Project, da Microsoft.
Há também o
Primavera, da
Oracle, mais
completo que o
MS Project, mas
não tão utilizado
ainda.
30
E xistem, ainda, os softwares gratuitos,
nem sempre tão completos, mas que em
alguns casos atendem às necessidades. É
fácil encontrá-los através dos buscadores na
internet.
Muitos consideram difícil a utilização
destes softwares. Muitas pessoas utilizam
esses softwares apenas como planilhas, ou
uma simples agenda, ou utilizam apenas
o mais básico. Porém o software é apenas
uma ferramenta. Gerenciar projetos requer
que se tenha conhecimento e se entenda
os conceitos principais para poder utilizar
qualquer ferramenta. O problema não é a
ferramenta, mas a falta de conhecimento
existente entre os conceitos da gestão de
projetos e como aplicá-los no software em
questão, a fim de tirar dele o melhor provei-
to e ter uma gestão efetiva do projeto.
 Até aqui...
Durante esta unidade, tivemos a oportunidade de
estudar um breve histórico do PMI, seus principais
objetivos e as 5 categorias de certificação, quais
sejam: CAPM, PMP, PgMP, PMI-SP e PMI-RMP.
Verificamos que o PMBOK não deve ser consi-
derado uma norma, mas um conjunto de práticas
em gerência de Projetos e constituem a base da me-
todologia de gerência de Projetos do PMI.
A unidade ainda nos apresentou o PMO, Escri-
tório de Gerenciamento de Projetos; a Tripla Restri-
ção, que se refere às demandas de escopo, tempo
e custo; e os tipos de softwares que auxiliam no
gerenciamento de projetos.

31
 “No começo de um projeto podem-
os fazer tudo, mas não sabemos
nada. No final do projeto sabemos
tudo, mas não podemos fazer nada.”

Unidade 3
Iniciando o
Projeto Objetivo
• Assimilar o conteúdo do conjunto de
processos de iniciação do projeto.

E sta 3ª unidade tem por objetivo

apresentar os processos iniciais
de Gerenciamento de Projetos. O
PMBOK apresenta os processos
por áreas. Aqui, mostraremos os
processos de forma sequencial,
como são utilizados nos projetos.
Bons Estudos!
Conteúdos
• Iniciação do projeto;
• Desenvolvendo o Termo de Abertura;
• Premissas e Restrições;
• Identificando as Partes Interessadas –
Stakeholders;

32
 1 Introdução
P ara começarmos a pensar no desenvolvi-
mento de um plano de gerenciamento de
projetos, devemos responder perguntas como:
• Quais as principais etapas do processo do
projeto?
• Quais os produtos parciais e finais dentro de
cada etapa?
• Quais os requisitos necessários para se ini-
ciar cada etapa?
• O escopo levantado abrange tudo que foi
combinado entregar?
• O orçamento atende às expectativas dos fi-
nanciadores do projeto?
• Qual será o padrão de qualidade exigido
para o projeto?
• Como será o fluxo da comunicação acerca
do andamento do projeto?
• Como se dará o término de uma fase para
outra e entre projetos?
• Quais são os riscos inerentes ao desenvolvi-
mento de cada fase do projeto?
• Quais os tipos de recursos deverão estar
disponíveis ou serem adquiridos?
33
• A equipe está preparada e qualificada para
desenvolver o projeto?
• Em que momentos devem ser realizadas
reuniões de compatibilização entre os parcei-
ros envolvidos no processo?
Muitas outras perguntas podem surgir e
todas as respostas a essas questões levarão
à caracterização dos fluxos dos processos de
um projeto, que poderá ser modelado através
de planos, permitindo que se desenvolva sis-
tema de planejamento destes fluxos e se ana-
lisem estratégias mais adequadas para o seu
desenvolvimento.
O grupo de processo de Iniciação é a
fase em que ocorre a aprovação do projeto,
liberando-o para execução. O processo é for-
mado por:
• Desenvolvimento do Termo de Abertura (Pro-
ject Charter) – Área de Conhecimento: Inte-
gração
• Identificar as partes interessadas – Área de
Conhecimento: Partes Interessadas
Feito isso, é importante realizar uma reunião
de abertura do projeto.
 2 Gerenciamento
da Integração
Desenvolver o Termo de
Abertura do Projeto (TAP)
O Termo de Abertura do
projeto é um documento
que autoriza formalmente
o início do projeto, ou de
uma fase. Ele contém o
levantamento dos requisitos
inicias do projeto, de modo
que satisfaça as partes
interessadas.
34
N este documento, um gerente de projeto
é designado e autorizado para utilizar
recursos nas atividades do projeto. Este
projeto pode ser autorizado por um sponsor
(patrocinador), PMO (escritório de projetos)
ou uma equipe responsável pela gestão do
portfólio da empresa.
No mínimo, um Termo de Abertura do pro-
jeto deve conter:
• Objetivos (mensuráveis);
• Requisitos e a descrição do projeto em
alto nível (descrição do produto/serviço que
será entregue ao final do projeto);
• Justificativa do projeto;
• Escolha do gerente do projeto (apesar
de, na maioria das vezes, o gerente do pro-
jeto ter sido escolhido antes e já participar da
escrita do termo de abertura, o mais comum
é que este documento seja redigido pelo pa-
trocinador);
 • Premissas e restrições (as restrições
mais comuns são: duração ou data de en-
trega do projeto; o orçamento limitado; dis-
ponibilidade de recursos, tanto recursos
humanos quanto material ou equipamento;
potencial impacto social ou ecológico; leis,
regras e/ou outros requisitos legais);
• Riscos iniciais;
• Resultados esperados (benefícios);
• Resumo do cronograma de marcos;
• Resumo do orçamento;
• Requisitos de aprovação para o projeto,
ou seja, quem irá decidir se o projeto está sendo
bem executado e quem irá assiná-lo;
• Nome do patrocinador e outras pessoas
que autorizam o TAP.
O Termo de Abertura deve responder à per-
gunta: “O que, exatamente, deve ser entregue
pelo projeto?” e deverá ser escrito de modo que
não exija mudança enquanto o projeto prossegue.

TERMO DE ABERTURA DO PROJETO Data:____/____/20___

LOGO Projeto: Versão:______/______
Autor: Folha:______de______
Condições do Projeto:
[Explique as condições do projeto(cenário, problema atual, soluções possíveis etc.]
ExpectaƟva do Cliente:
[Descrever a necessidade do trabalho (Por que deverá ser realizado? Para que foi planejado?]
Visão do Projeto:
[Fornecer uma descrição resumida do problema que está sendo resolvido pelo projeto e qual a
oportunidade de negócios atendida por este projeto]
Descrição do Produto e Entregas:
[Iden ficar as entregas em cada fase do projeto. Descrever as entregas de forma clara para que
seja possível à equipe do projeto desenvolvê-lo]
Premissas do Projeto:
[Iden ficar as premissas iniciais do projeto]
Restrições do Projeto:
[Descrever, caso exista, alguma restrição em relação ao projeto]
Metas:
[Descrever o que se pretende alcançar com a conclusão do projeto.]
Riscos:
[Descrever os riscos do projeto.]
Gerente do Projeto - Responsabilidades:
[Fornecer o nome do gerente de projeto designado e o nível da autoridade que lhe foi atribuída.]
Cronograma de Marcos Sumarizado:
[Apresentar o conograma de marcos sumarizado do projeto.]
Recursos Tecnológicos:
[Descrever os recursos tecnológicos necessários para o desenvolvimento do projeto.]
InvesƟmento:
[Informar o valor previsto para o projeto e fornecer o orçamento sumarizado]
Fatores CríƟcos de Sucesso:
[Descrever os fatores crí cos para o sucesso do projeto.]
Aprovação Formal:
Data:________/______/20_____.

Figura 5 - Modelo do Termo de Abertura do Projeto – TAP

35
 Premissas e
Restrições
A definição de premissa,
segundo o dicionário Aurélio,
é “ponto de que se parte para
armar um raciocínio”. Já a
restrição é definida como “ato
ou efeito de restringir”.

E m gerenciamento de projetos, dizemos que

premissas são fatores externos ao projeto
que são arbitrariamente considerados como
verdade, independente de conseguir provar.
Não temos controle sobre esses fatores e por
isso toda premissa gera riscos. Por exemplo:
quero construir um edifício, assumo como
premissa que conseguirei pagar todos os
custos. Porém existe o risco de o material ou
a mão-de-obra ficarem escassos e eu precisar
pagar mais por eles do que o que eu tinha
planejado. Se gerar um risco muito grande,
terei que me proteger desse risco e a premissa
passará a ser restrição.
Para gerenciamento de projetos, restri-
ções são fatores internos, que restringem, li-
mitam. É estipulado pelo projeto, normalmen-
te para proteger-se de um risco. Voltando ao
exemplo de comprar uma casa, para evitar o
risco de não conseguir pagar as prestações,
determino que só poderei pagar um valor X
pela casa, de forma que eu consiga pagar à
vista.
Premissas e restrições geram confusão
até mesmo para gerentes de projetos, e, mui-
tas vezes, nos projetos são considerados no
mesmo tópico para “evitar” erros de classifi-
cação. Mas isso precisa ficar bem claro, pois
serão importantes ao longo do projeto, já que
as premissas são suposições e restrições são
limitações.
Outra maneira de tratarmos as premissas
é como expectativas que devem ser levadas
em consideração para que o projeto tenha su-
cesso.
As premissas e as restrições estão intima-
mente ligadas, e frequentemente são obtidas
nas reuniões iniciais do projeto.

36
 3 Gerenciamento das
Partes Interessadas
Identificar as Partes
Interessadas – Stakeholders
Para que um projeto seja
bem sucedido, é importante
conhecer as pessoas
interessadas do projeto, e cuja
atuação influencie positiva
ou negativamente no projeto.
Também é importante conhecer
quem são as partes impactadas
ou envolvidas no projeto.
37
P ara as partes interessadas, é importante
conhecer o tipo de interesse de cada um
no projeto. O interesse pode ser positivo ou
negativo. Pode parecer estranho falar que
alguém que faça parte do projeto tenha
interesse negativo no mesmo, ou seja, queira
que o projeto seja um insucesso. Um exemplo
é a expansão industrial. Para as indústrias e
a comunidade, o sucesso do projeto é algo
positivo. Já aos olhos dos ambientalistas, isso
é prejudicial. Logo, esses ambientalistas têm
interesse negativo no projeto.
 Também é importante saber Muitos gerentes de projeto avaliam apenas
as influências e impactos positivos, deixando de
qual o poder de influência lado os negativos. Isso gera o risco de fracasso
de cada parte, seja ele poder no projeto. Portanto, é importante definirmos to-
dos os stakeholders, seja sua influência e/ou im-
de influenciar as outras pacto positivo ou negativo.
pessoas, seja o controle É importante ressaltar que as partes interes-
sobre os recursos e poder sadas podem ser identificadas em todos os gru-
sobre o projeto em geral. O pos de processos de gerenciamento de projetos.
No entanto, quanto mais cedo as partes interes-
principal são as partes que sadas forem identificadas, melhor para o projeto.
podem influenciar escopo, Se todas as necessidades e requisitos das partes
interessadas forem considerados na iniciação,
prazo, custo... e antes do início do trabalho do projeto, menos
mudanças serão necessárias posteriormente no
Temos ainda as partes impactadas e
projeto, quando custarão mais caro.
que tem poder sobre o produto do projeto.
São, normalmente, os usuários da edifi- Devemos lembrar de definir o escopo le-
cação. De nada adianta as demais partes vando em consideração o mercado, os futuros
interessadas definirem um escopo se o usuários, além das expectativas do investidor, do
usuário da edificação não aprovar o produto. construtor, etc.

38
 4 Reunião de Abertura
(Reunião de Kick Off)
A reunião de Kick-off é
a chamada reunião de
abertura do projeto. Nela,
todas as informações do
projeto são repassadas à
equipe de projeto (de forma
simplificada).
39
A reunião de Kick-off será, provavelmente, a
reunião mais importante de todo o projeto.
É a reunião onde, aos olhos do cliente, o projeto
realmente começa. Ela deve ser feita no início do
projeto, para melhor entendimento do que se quer,
junto ao cliente ou patrocinador.
Através dessa reunião, coordenada pelo ger-
ente de projetos, gera-se o comprometimento e a
motivação dos envolvidos no mesmo, incluindo o
patrocinador, antes que o trabalho, de fato, inicie.
 A reunião de Kick-off em um projeto é es-
sencial e deve acontecer até mesmo nos pe-
quenos projetos. Não deve durar mais que 1
hora, para que não tenhamos detalhes exces-
sivos nesta reunião.
Os principais pontos apresentados na
reunião de abertura são:
• A contextualização do projeto;
Note que essas informações vêm justa-
mente do termo de abertura do projeto. Nenhu-
ma dessas informações (além da importância
e do objetivo do projeto) devem ser muito de-
talhadas, uma vez que o planejamento do pro-
jeto ainda não foi realizado. Neste momento
ainda não se tem um plano de projeto, apenas
um macro, que possibilita a visão geral para
que seja feito o planejamento detalhado.

• A importância do projeto (por que está sen-
do feito);
• O objetivo do projeto (onde chegaremos
com o projeto);
• O escopo macro do projeto (o que será feito
e o que não faz parte desse projeto);
• Os principais riscos, premissas e restrições;
• As funções e responsabilidades de cada um
no projeto;
• Um breve orçamento geral (estimado, não
detalhado);
• A data de entrega do projeto e os principais
marcos.
A reunião do Kick-off é uma boa oportuni-
dade para juntar todos os membros da equipe,
clientes, stakeholders e formalmente anunciar
o estágio para o começo do projeto. Além dis-
so, é o momento certo para se tirar todas as
dúvidas antes que o projeto inicie.
Assim, quando está claro e definido o que
deve ser entregue pelo projeto está na hora de
encerrar a fase de iniciação e iniciar a fase de
planejamento (definir o “como”).
A decisão tomada nas fases iniciais do
projeto tem grande participação na redução
de seus custos, das falhas da execução e re-
presentam importante informação de apoio à
produção e deve sempre ser revisado como
melhores práticas nos projetos vindouros.

Com o aperfeiçoamento das técnicas de gerenciamento, os gerentes

de projeto terão uma conscientização cada vez maior da necessidade
de melhoria nos escopos e planejamento, gerando assim uma redução
significativa nas áreas de custo, prazo, aumento da vida útil dos
produtos (resultados) dos projetos e a melhoria nos próximos projetos.

40
 Até aqui...
No decorrer dessa unidade, estudamos o pro-
cesso de Iniciação do projeto, fase em que ocorre
a aprovação do projeto. Verificamos que esse pro-
cesso é formado por:
• Integração: Desenvolvendo o Termo de Aber-
tura do Projeto;
• Premissas e Restrições;
• Comunicação: Identificando as Partes Interes-
sadas – Stakeholders;
• Fazendo a Reunião de Abertura (Reunião de
Kick Off).

41
 “O planejamento não é uma tentativa
de predizer o que vai acontecer. O
planejamento é um instrumento para
raciocinar agora, sobre que trabalhos
e ações serão necessários hoje, para
merecermos um futuro. O produto
final do planejamento não é a infor-
mação: é sempre o trabalho.”

Peter Drucker

Unidade 4
Iniciando o Objetivo
Projeto Ao final desta unidade você estará apto
para:
• Assimilar o conteúdo do conjunto de
processos de planejamento do projeto na
área: Escopo.

S eguiremos nesta 4ª. unidade

com os processos de
Gerenciamento de Projetos. Nesta Conteúdos
unidade, entraremos no grupo de
processos de Planejamento. • Coletando os requisitos;
Bons estudos! • Definido o Escopo;
• Conceitos de Escopo;
• Definindo o Escopo;
• Declaração do escopo;
• Criando a EAP (WBS).

42
 1 Planejando o Projeto: Escopo

O Grupo de Processos de Planejamento é a fase do projeto

responsável em planejar e gerenciar o projeto, de forma a
levá-lo ao sucesso.

O planejamento do projeto é a mais

crítica de todas as fases de um pro-
jeto. Dentro desta fase, as pessoas, recursos,
Escopo
Antes de seguir, precisamos entender
dinheiro, fornecedores e tarefas devem estar
melhor o que é escopo do projeto e escopo
corretamente programados, de maneira que
do produto.
o gerente de projetos possa monitorar e con-
trolar as entregas do projeto efetivamente.
Escopo do projeto (Project Scope): O
trabalho que precisa ser realizado para en-
Planejamento parece ser a palavra de
tregar um produto, serviço ou resultado com
ordem de todos que gerenciam projetos. O
as características e funções especificadas.
problema é que algumas pessoas têm uma
Garante que o projeto realize todo e somente
visão míope dos processos de Planejamento.
o trabalho necessário para o seu sucesso.
Alguns acham que um software vai solucionar
todos os problemas da sua empresa. Outros
Define e controla o que será incluído
acham que não é necessário gastar “tanto
ou não no projeto e inclui somente os arte-
tempo e dinheiro planejando, porque afinal
fatos para gerenciar o escopo do projeto e
nós já fizemos isso mais de mil vezes”. Esses
não do produto. Um bom escopo do projeto
erros são fatais e não costuma poupar proje-
impedirá a realização de trabalho extra que
tos e seus gerentes.
não faça parte do projeto (gold plating).
Em Projetos, planejar é FUNDAMENTAL!

43
 O foco está no trabalho, ou melhor, sam toda a confusão e problemas.
nas atividades necessárias para se atingir o
objetivo.
Assim, o escopo do produto deve prever
Escopo do Produto (Product Scope): todas as funcionalidades esperadas e o pro-
As características e funções que caracteri- jeto detalhará todo o trabalho a ser executado
zam o produto/resultado do projeto. O foco para que o produto do projeto seja entregue
está no fruto do trabalho. O escopo do pro- de acordo com o especificado.
duto pode ser dividido em escopo funcional
(são normalmente definidos pelo cliente) e
escopo técnico (características técnicas,
Planejar o gerenciamento
como padrões, especificações, normas le-
gais, procedimentos, etc. e são normalmente
do escopo
definidos pela equipe do projeto).
O Planejamento do Gerenciamento do
Ambos os tipos de gerenciamento de
Escopo tem por objetivo decidir como abor-
escopo devem ser integrados para garantir
dar, planejar e executar as atividades de ger-
que o trabalho do projeto resulte na entrega
enciamento de escopo de um projeto, além de
do produto especificado.
buscar também uma definição e controle do
que está e o que não está incluído no projeto.
Outro cuidado que temos que ter é
que, além dos requisitos explícitos (que estão Criação de um plano de gerenciamento
na forma de registros, especificações, me- do escopo do projeto que documenta como
moriais e outras formas documentadas e que o escopo do projeto será definido, verificado,
são facilmente gerenciáveis) também temos controlado e como a estrutura analítica do pro-
os requisitos implícitos. Estes são os que cau- jeto (EAP) será criada e definida.

44
 2 Coletar
os requisitos
A coleta de requisitos é um processo que
visa documentar todas as funcionalidades e
características do produto e do projeto para
que atenda às expectativas e às necessida-
des das partes interessadas.
E quando falamos em documentar, signi-
fica registrar (escrever) todas as necessida-
des, desejos e expectativas de todas as par-
tes interessadas em relação ao projeto. Pode
ser um formulário simples ou um documento
mais formal, mas deve ser registrado e assi-
nado pelo cliente e pelo patrocinador, a fim de
minimizar conflitos ao longo do projeto, ou ao
término dele.
A coleta de requisitos deve ser feita atra-
vés de entrevistas, de observações, de res-
postas a questionários, etc. A correta coleta e
gerenciamento dos requisitos do projeto e do
produto influenciam diretamente o sucesso do
projeto.
Os requisitos devem ser definidos, anali-
sados e registrados com detalhes suficientes
para serem medidos ao longo de todo o proje-
45
to, do início ao fim. É com base nesses requi-
sitos que o custo, o cronograma e a qualidade
serão construídos.
Definir o
escopo
O processo de definição do escopo é a
descrição detalhada do projeto e do produto,
ou seja, é necessário definir tanto o escopo
do projeto quanto do produto, e ambos têm
que ser claros e específicos, detalhados o su-
ficiente para que todos entendam o projeto.
Deve constar também o que está fora do
escopo. Por exemplo, o projeto é o desenvol-
vimento de um software, porém a implantação
e o treinamento estão fora do escopo.
É o momento em que realmente entende-se
o projeto por completo, pois nesta fase analisa-
-se e define-se todo o trabalho necessário para
entregar o produto esperado. Como saída deste
processo, teremos a Declaração do Escopo.
 3 Declaração
de Escopo
A declaração do escopo do
projeto descreve, em detalhes,
as entregas do projeto e o
trabalho necessário para criar
essas entregas.
46
A declaração do escopo do projeto tam-
bém fornece um entendimento comum do
escopo do projeto a todas as partes interes-
sadas no projeto e descreve os principais ob-
jetivos do projeto.
Além disso, permite que a equipe do pro-
jeto realize um planejamento mais detalhado,
orienta o trabalho da equipe do projeto durante
a execução e fornece a linha de base para
avaliar solicitações de mudanças ou trabalho
adicional e verificar se estão contidos dentro
ou fora dos limites do projeto. A declaração
do escopo detalhada do projeto inclui, direta-
mente ou referenciando outros documentos:
 • Objetivos do projeto: Incluem os cri-
térios mensuráveis do sucesso do projeto. Os
projetos podem possuir uma ampla variedade
de objetivos técnicos, de negócios, custo, cro-
nograma e qualidade. Os objetivos do projeto
também podem incluir metas de custo, crono-
grama e qualidade.
• Descrição do escopo do produto: Ca-
racterísticas do produto, serviço ou resultado
para cuja criação o projeto foi realizado. Essas
características terão normalmente menos de-
talhes nas fases iniciais e mais detalhes nas
fases posteriores, conforme as características
do produto forem progressivamente elabora-
das. A descrição do escopo deve sempre for-
necer detalhes suficientes para dar suporte ao
planejamento posterior do escopo do projeto.
• Escopo do projeto: Normalmente iden-
tifica o que está incluído dentro do projeto e
declara de forma explícita o que está excluído
do projeto, para evitar que uma parte interes-
sada possa supor que um produto, serviço ou
resultado específico é um componente do pro-
jeto.
• Entregas do projeto: As entregas in-
cluem tanto as saídas que compõem o pro-
duto ou serviço do projeto, como resultados
auxiliares, como documentação e relatórios de
gerenciamento de projetos. Dependendo da
declaração do escopo do projeto, as entregas
podem ser descritas de forma sumarizada ou
detalhada.
47
• Critérios de aceitação de produtos:
Define o processo e os critérios para aceitar
os produtos terminados.
• Restrições do projeto: Lista e descre-
ve as restrições específicas do projeto asso-
ciadas ao escopo do projeto que limitam as
opções da equipe. Podem ser orçamento pre-
definido ou datas impostas (marcos do cro-
nograma) divulgadas pelo cliente ou pela or-
ganização executora. Quando um projeto for
realizado sob contrato, em geral as cláusulas
contratuais se constituirão em restrições. As
restrições listadas na declaração do escopo
detalhada do projeto são normalmente mais
numerosas e mais detalhadas do que as lista-
das no termo de abertura do projeto.
• Premissas do projeto: Descreve as
premissas específicas do projeto associadas
ao escopo do projeto e o impacto potencial
dessas premissas, se não forem confirmadas
(riscos). As premissas listadas na declaração
do escopo detalhada do projeto são normal-
mente mais numerosas e mais detalhadas do
que as listadas no termo de abertura do pro-
jeto.
• Requisitos de aprovação: Identifica os
requisitos de aprovação que podem ser apli-
cados a itens como objetivos, entregas, docu-
mentos e trabalho do projeto.
 4 Criar a EAP
(WBS)
E strutura Analítica do projeto (EAP),
em inglês Work Breakdown Structure
(WBS), é uma decomposição hierárquica
orientada à entrega do trabalho a ser realizado
pela equipe do projeto, para atingir os objetivos
do projeto e criar as entregas necessárias.
A EAP organiza e define o escopo total
do projeto. A EAP subdivide o trabalho do
projeto em partes menores e mais facilmente
gerenciáveis. Cada nível descendente da EAP
representa uma definição gradativamente
mais detalhada da definição do trabalho do
projeto. O trabalho planejado está contido
nos componentes de nível mais baixo da
EAP, denominados pacotes de trabalho.
48
A EAP representa o trabalho
especificado na declaração do escopo do
projeto atual aprovada. Os componentes
que compõem a EAP auxiliam as partes
interessadas a visualizar as entregas do projeto.
A EAP – Estrutura Analítica do Projeto é uma
síntese estrutural do projeto, ou seja, a divisão
das atividades em níveis que permitam o
controle. Pode ser representada por um
diagrama onde podemos observar uma
síntese da divisão das atividades e por uma
planilha com o detalhamento dessa divisão.
É a definição clara do objetivo do
projeto e das atividades que o compõem.
Esta estrutura pode ser tão detalhada quanto
necessário, dependendo da necessidade e do
feeling do profissional que a elabora. Em um
projeto há a atividade-macro, as atividades-
mãe, as atividades-filha e os marcos. Esta
hierarquia apresenta-se da seguinte forma:
• Atividade macro: é a atividade que dá
nome ao projeto;
• Atividade-mãe: é a subdivisão da atividade
macro em grupos de atividades;
• Atividade-filha: cada grupo é composto
por pequenas atividades;
• Marco: atividade que determina um
controle (medição de desempenho) durante
o trabalho.
 A EAP pode ser construída de
diversas formas conforme o
EAP por Fases: Organiza fases
propósito e tipo de projeto. As no primeiro nível e eventualmente no
formas mais comuns de montagem segundo nível também.
da EAP são: Por Fases, Por Vantagens:
Entregas e Por Equipes. Abaixo são • Oferece uma visão
apresentados exemplos de EAP’s “cronológica” dos acontecimentos no
em cada uma das formas. projeto;
• Facilita o entendimento de
pessoas leigas;
• Facilita o posterior
gerenciamento das atividades.

Desvantagens:
• Pode ofuscar a visão das
partes necessárias para uma entrega
específica;
• Tende a incentivar que se
incluam atividades administrativas
(ex.: Controle do projeto).

EAP por Entregas: Mostra as partes

necessárias para compor as entregas do projeto.

Vantagens:
• Visualiza claramente as partes que compõe
o projeto;
• Facilita a discussão de soluções técnicas e
caminhos alternativos;
• Facilita identificação de riscos técnicos.

Desvantagens:
• Não oferece visão cronológica.

EAP por Equipes: Visualiza

os pacotes de trabalho a partir da
divisão de Equipes do Projeto.

Vantagens:
• Ótima para ocasiões em
que o projeto tem equipes com
responsabilidades muito diferentes.

Desvantagens:
• Não mostra cronologia nem
a organização das partes das
entregas.

49
 4 Como montar
uma EAP
Figura 6 – Exemplo de Estrutura Analítica do projeto com alguns ramais decompostos até
o nível de pacote de trabalho (adaptado de PMBOK)
A decomposição da EAP pode ser de-
senvolvida em um processo de quatro eta-
pas:
• Primeira Etapa: Identificar as entregas
finais do projeto, concluídas com sua descri-
ção na declaração do escopo. Estas entregas
devem ser definidas da forma como o traba-
lho do projeto é organizado (ciclo de vida do
produto). Por exemplo, em um projeto podem
estar incluídos: Gerenciamento de Projetos,
Viabilidade, Serviços Técnicos, Construção,
Instalações e Vendas.
• Segunda Etapa: Definir as principais
entregas do produto do projeto.
• Terceira Etapa: Decompor as entregas
principais em componentes menores (com-
ponentes constitutivos), para que o nível de
detalhamento seja apropriado para a gestão.
É preciso fazer estimativas de custo e dura-
ção para cada componente identificado.
50
• Quarta Etapa: Revisar a EAP com todos os
envolvidos até que haja uma concordância
entre os membros para que o planejamento
do projeto possa ser completado com suces-
so, e na fase de execução possam ser cum-
pridas as entregas estabelecidas no planeja-
mento.
Obs. 01: Cada elemento da EAP deve
contribuir para o elemento (resultado) ao qual
está subordinado (elemento pai).
Obs. 02: ao descer um nível na EAP, a
soma dos resultados subordinados corres-
ponde ao resultado do pai.
Obs. 03: um elemento da EAP pode ter
somente vários elementos (filhos). Mas um
elemento filho não pode ter mais de um pai.
Obs. 04: os resultados principais neces-
sários ao gerenciamento devem ser incluídos
na EAP.
 Criar a EAP é o procedimento de subdi-
visão das entregas e do trabalho do projeto
em partes menores e de gerenciamento mais
fácil. Assim, se durante a elaboração de um
produto, o gerente do projeto teve dificulda-
des de controlar a realização das atividades,
porque estas possuíam demasiadas entregas
(deliverables), dificultando seu entendimento
do processo de gerenciamento das mesmas,
ele deve aumentar o detalhamento da estrutu-
ra analítica de projeto (EAP) a fim de minimi-
zar o problema.
O resultado (saída) deste processo será
a EAP montada, detalhada ao ponto em que
o gerente e a equipe de projetos considera-
rem adequado.
As EAPs podem ser construídas usando
modelos de projetos semelhantes já concluí-
dos. Embora cada projeto seja único, muitas
empresas executam o mesmo tipo de projeto
repetidamente.
As entregas são similares de projeto para
projeto, e eles geralmente seguem um cami-
nho similar. Os modelos de EAP podem ser
usados como uma ferramenta para simplificar
o trabalho da equipe do projeto, poupando
seu precioso tempo.
A regra 100% é uma característica im-
portante da EAP e determina que a Estrutura
Analítica do Projeto deva incluir 100% do
trabalho definido pelo escopo do projeto,
51
inclusive todas as suas entregas, sejam elas
internas ou externas.
A finalidade da EAP é organizar e definir
o escopo do projeto – o trabalho que não se
encaixa na EAP está fora do projeto. A EAP
identifica o relacionamento entre os pacotes
de trabalho e deve ser atualizada sempre que
necessário, para refletir as mudanças no es-
copo do projeto. A EAP é essencial no projeto
e tem as seguintes utilidades:
• Serve como linha de base do escopo;
• É uma ferramenta de gerenciamento de
projetos;
• Permite a visão de todo o projeto;
• Serve de base para todo o planejamento;
• O trabalho não incluso na EAP não faz
parte do projeto;
• Cria concordância e aceitação formal
do projeto;
• Serve como dispositivo de controle
para manter o projeto na direção certa;
• Possibilita estimativas precisas de cus-
to e tempo;
• Serve para blindar as mudanças no
escopo do projeto.
A forma que você vai encontrar para de-
compor sua EAP irá depender da cultura da
sua empresa e do segmento em que ela atua.
Na construção civil, já é hábito decompor
os pacotes em etapas, subetapas e tarefas -
portanto, em qualquer lugar do Brasil, as pla-
nilhas orçamentárias são praticamente iguais.
 Figura 7 – Exemplo de EAP
A criação da EAP não é uma atividade
para ser feita isoladamente e nem de uma só
vez. O planejamento em ondas sucessivas
consta da elaboração progressiva do pla-
nejamento, conforme as informações sobre
as atividades do projeto forem sendo mais
detalhadas.
De acordo com o PMBOK®, este deta-
lhamento progressivo do plano do projeto é
frequentemente denominado “planejamento
em ondas sucessivas”, indicando que o pla-
nejamento é um processo iterativo e contínuo.
No início do projeto, quando as informações
estão menos definidas, as atividades podem
ser mantidas no nível de marcos.
Precisamos entender que a capacidade
de planejar, gerenciar e controlar o trabalho
aumenta à medida que o trabalho é decom-
posto em níveis mais baixos de detalhe. A
decomposição de uma entrega pode não ser
possível de ser realizada em determinado
momento do projeto. Nesse caso, a equipe
aguarda até que mais informações cheguem
ao seu conhecimento para esclarecer os
detalhes pertinentes desta entrega, para que
ocorra a decomposição num nível menor e
mais gerenciável.
Após a EAP é importante montar o dicio-
nário da EAP, que é um documento de supor-
52
te à EAP. O dicionário EAP fornece informa-
ções mais detalhadas dos elementos da EAP,
incluindo os pacotes de trabalho, entregas e
atividades.
O Dicionário da EAP tem como objetivo:
• facilitar o entendimento do que deve
ser realizado;
• auxiliar o controle do escopo e;
• garantir que todos tenham um entendi-
mento comum sobre um determinado pacote
de trabalho.
Ele pode ser feito em formato de tabela
ou de um texto descritivo. Quanto mais deta-
lhado, melhor, pois ajudará a equipe de proje-
tos a realmente compreender o projeto.
O dicionário EAP poderia incluir os se-
guintes elementos:
• Código identificador do componente;
• Descrição do trabalho do componente;
• Entidade responsável pela execução
do componente;
• Lista dos marcos do cronograma;
• Recursos necessários;
• Estimativas de custos;
• Requisitos de qualidade;
• Critérios de aceitação;
• Referências técnicas;
• Informações do contrato.
 Até aqui...
No decorrer desta unidade, estudamos o Escopo
do projeto, que faz parte do grupo de processos de
planejamento.
Buscando melhor entendimento do processo, no
conceito de escopo, analisamos a distinção entre
escopo do projeto e escopo do produto. Concluí-
mos que é necessário definir tanto um quanto o ou-
tro
No estudo da Declaração do escopo, verificamos
a importância de descrever em detalhes as entregas
do projeto e o trabalho necessário para criar essas
entregas.
Finalizamos com o item Criando a EAP (WBS),
que organiza e define o escopo total do projeto e
subdivide o trabalho do projeto em partes menores
e mais facilmente gerenciáveis.

53
 “Quando eles dizem que você está
atrasado no projeto, isso é somente
uma maneira educada de se dizer
que você tem um péssimo senso de
prazos.”
George McGovern

Unidade 5
Objetivo
Planejando o Ao final desta unidade você estará apto
para:
Projeto: Tempo • Assimilar o conteúdo do conjunto de
processos de planejamento do projeto na
área: Tempo.

N esta 5ª unidade continuaremos
o planejamento do projeto,
desta vez planejando o tempo e
montando o cronograma do projeto.
Bons estudos!
Conteúdos
• Definindo a Lista de Atividades;
• Sequenciando as atividades;
• Estimando as durações das Atividades;
• Alocando os Recursos;
• Montando o Cronograma;
• Diagrama de rede do projeto;
•A Lei de Parkinson e a Síndrome do
Estudante.

54
 1 Planejando o
projeto: cronograma
Gerenciar tempo é pensar
o projeto, como ele deve
acontecer, as metodologias
executivas, enfim, analisar o
projeto inteiro.
55
E ssa etapa não acontece de forma iso-
lada e não acontece uma única vez.
Ela deve ser refeita sempre que for neces-
sário e sempre em conjunto com as demais
áreas.
Ricardo Viana Vargas costuma dizer
que “o executivo brasileiro nunca tem tempo
para planejar, mas sempre tem dinheiro para
refazer”.
 2 Planejar o
gerenciamento do cronograma

O Planejamento do Gerenciamento do Cronograma tem por

objetivo decidir como abordar, planejar e executar as atividades
de gerenciamento do cronograma de um projeto.

Criação de um plano de gerenciamento do cronograma do

projeto que documenta como o cronograma do projeto será
definido, verificado e controlado.

56
 3 Definir a lista
de atividades
E nvolve identificar e documentar as
atividades específicas que devem ser
realizadas para produzir as várias entregas
identificadas na EAP (WBS). Se a definição
do escopo e a criação da EAP foram bem
feitas, esta etapa torna-se bastante simples.
Com base na EAP, devemos decompor
os pacotes de trabalhos em atividades do
cronograma, necessárias para produzir
estes pacotes de trabalho, dispostas em
uma lista, sem considerar nenhum tipo de
sequenciamento ainda. Depois, é só definir
os marcos, que são pontos importantes
no nosso projeto, mas que não envolvem
trabalho algum, nem tempo, custo ou
57
recursos associados. São simplesmente
pontos de referência que indicam que o
projeto alcançou algum ponto importante.
Marcos podem servir para identificar o
início ou a conclusão de alguma entrega
importante.
Para você entender melhor, utilize
substantivos para as entregas e pacotes
de trabalho. Exemplo: Fundação, Estrutura,
Revestimento, Pintura, etc. Para as
atividades, utilize verbos. Exemplo: Preparar
material, Montar slides, organizar festa, etc.
Para os marcos, utilize termos como Fase
Concluída, Software instalado, Pneu trocado,
etc.
 4 Sequenciar
as atividades
Definidas as atividades,
deve-se sequenciá-las.
Sequenciar logicamente as
atividades é o processo de
identificação e documentação
dos relacionamentos entre as
atividades do projeto.
58
C ada atividade e marco, com exceção
do primeiro e do último, são vincula-
dos a pelo menos um predecessor e um su-
cessor.
Vinculação de tarefas é a criação de
dependências entre tarefas visando a ade-
quação do planejamento à realidade dos
serviços. Por exemplo, a tarefa 2 só pode-
rá iniciar após o término da tarefa 1; as ta-
refas 3 e 4 devem iniciar juntas; as tarefas
5 e 6 devem terminar na mesma data, etc.
Podemos vincular nossas tarefas de 4 manei-
ras diferentes:
 Exemplo: - A segurança da festa deve ter-
minar junto com o término da festa.
Término a início (TI)

Início a Término (IT)

A tarefa dependente (B) não poderá ser
iniciada enquanto a tarefa da qual ela depen-
de (A) não for concluída. Este é o mais comum
dos tipos de vínculos.
Exemplo: ”Almoçar” e “Preparar almoço”:
a tarefa “Almoçar” não poderá ser iniciada até
a tarefa “Preparar almoço” ser concluída.
A tarefa B não pode terminar até que a
tarefa A inicie. Ocorre com menor frequência
do que os outros vínculos
Exemplo: - Mandei imprimir novos car-
tões. Continuarei utilizando os cartões antigos
até que os novos estejam prontos.

Início à início (II)

A tarefa dependente (B) não poderá ser

iniciada enquanto a tarefa da qual ela depen-
de (A) não for iniciada. O tipo de vínculo II não
exige que as duas tarefas sejam concluídas
ao mesmo tempo.
Exemplo: - A entrada dos formandos
deve iniciar assim que a música de entrada
iniciar.

Término à Término (TT)

A tarefa dependente (B) não pode ser

concluída até que a tarefa da qual ela depen-
de (A) seja concluída. O tipo de vínculo TT não
exige que as duas tarefas sejam iniciadas ao
mesmo tempo.

Tarefa predecessora é a tarefa cuja data de início ou término determina a data

de início ou término da respectiva tarefa sucessora.

Tarefa sucessora é a tarefa cuja data de início ou término é condicionada pela

tarefa predecessora correspondente.

O uso de tempo de antecipação ou de espera pode ser necessário entre as atividades

para dar suporte a um cronograma de projeto realista e executável.

59
 Determinação
da dependência
Existem três tipos de dependências entre
atividades:
1. Dependências Mandatórias (Obriga-
tória): São aquelas inerentes à natureza do
trabalho que está sendo realizado, traduzin-
do-se numa lógica rígida. Um exemplo é pre-
parar a massa do bolo para somente depois
confeitá-lo.
2. Dependência arbitrada: Podem ser
chamadas de lógica preferencial. O gerente,
ao usar este tipo de relacionamento, deve do-
cumentar a lógica por trás desta decisão. As
lógicas arbitradas ou preferidas permitem que
as atividades aconteçam em uma ordem pre-
ferida, por causa das melhores práticas ou de
condições exclusivas ao tipo de trabalho.
3. Dependências Externas: Como o pró- Aplicação de antecipações
prio nome diz, estas são as dependências
fora de controle do projeto. Alguns exemplos (leads) e esperas (lags)
incluem a entrega de um equipamento por um
fornecedor, ou a decisão de um órgão público
para o início dos serviços. As antecipações e atrasos são valores
acrescentados aos pacotes de trabalho para
alterar seu relacionamento. Considere as ante-
cipações como valores negativos e os atrasos
como valores positivos.

A A

B B
$YDQoR $WUDVR

Figura 8 – Cronograma de barras (Diagrama de Gantt)

executado no software MS Project

Por exemplo, pode haver um relaciona-

mento (TI) entre os serviços de “esquentar o
forno” e a tarefa “misturar a massa do pão”;
num avanço, a cozinheira decide aquecer o
forno 5 minutos antes de terminar de misturar
o pão.
O tempo de atraso é um tempo de espe-
ra. Por exemplo, em um relacionamento (TI) a
cozinheira decide atrasar o aquecimento do
forno para 5 minutos após terminar de misturar
a massa do pão.

60
 5 Estimar os recursos
das atividades

Neste momento, deve se identificar quais recursos (tipos e

quantidades) serão utilizados para realizar cada atividade e alocá-
los. Não faça este processo antes de sequenciar as atividades,
pois a sequência em que as atividades serão executadas
impactará na escolha dos recursos que serão alocados.

61
 6 Estimar as durações
das atividades
Vinculadas as tarefas, devemos
estimar o período necessário
para conclusão individual de
cada atividade do cronograma
(lembrando que os marcos
são atividades com duração
zero e, consequentemente, não
possuem esforço ou trabalho
associados).
62
É um hábito bastante comum acres-
centar-se uma folga (margem
de segurança) em cada tarefa, além do
tempo real necessário para realiza-la.
Porém este é um vício prejudicial ao
projeto. Imagine uma margem de segurança
em cada atividade do projeto. Isso aumenta
consideravelmente o tempo total do projeto. O
ideal é estimar o tempo real necessário para
o término da atividade, deixando para acres-
centar uma margem de segurança no final do
projeto apenas.
 7 Desenvolver o
cronograma
Desenvolver o cronograma
significa determinar as datas de
início e fim para as atividades
do projeto. Se as datas de
início e fim não forem realistas,
é improvável que o projeto
termine como planejado.
63
É neste processo que obtemos a linha
de base do cronograma (um crono-
grama que já foi aprovado e aceito por todos
e será utilizado como base para comparação
do planejado com o que foi executado no pro-
jeto). Esta comparação vai nos permitir perce-
ber como se encontra o projeto em relação ao
cronograma, na etapa de monitoramento.
Como o gerenciamento de projetos apre-
senta processos iterativos, só poderemos fe-
char a linha de base do cronograma defini-
tivamente ao final da fase de planejamento,
depois de executado todos os outros proces-
sos do grupo de planejamento já que a exe-
cução deles sempre causa uma alteração ou
 Figura 9 – Cronograma de barras (Diagrama de Gantt) executado no software MS Project
outra nas atividades e, consequentemente, no
cronograma.
A execução deste processo pode ainda
provocar mudanças em outros documentos e
processos de gerenciamento de projetos, que
deverão ser atualizados.
Desenvolver um cronograma com cente-
Diagrama de rede
do projeto
A C
INÍCIO
B E
Figura 10 - Diagrama de Rede - Método PDM
U m diagrama de rede de projeto é um
esquema de apresentação das ativi-
dades do projeto e dos relacionamentos ló-
gicos (dependências) entre elas. Podem ser
utilizados os métodos de PDM (Método do
diagrama de precedência - mais utilizado) ou
ADM (Método do diagrama de flechas). Abai-
xo a explicação da utilização do método PDM.
64
nas de atividades sem um software adequado
pode ser uma tarefa bastante difícil, portanto
não deixe de considerar este recurso para este
processo. Um dos softwares mais utilizados,
como já dito anteriormente, é o Microsoft Project.
Manualmente, utiliza-se normalmente o dia-
grama de rede.
D
FIM
F
Depois de construído o diagrama de
rede básico, com a sequência e durações
para o projeto, passa-se a determinar os tem-
pos (datas) de início e término de cada ativi-
dade, as folgas dos caminhos, identificar o(s)
caminho(s) crítico(s) e a duração ou tempo de
conclusão do projeto.
 Método do diagrama de precedência
(PDM - Precedence Diagramming Method).
Este é um método de construção de dia- Fn = TMTn – TMCn = IMTn – IMCn
grama de rede que utiliza “nós” para repre-
sentar as atividades e as conecta por setas IMTn = TMTn – Dn + 1 = IMCn + F
que representam as dependências. A figura Obs.: considera-se “n” a atividade atual e
10 apresenta um diagrama simples de rede “n-1” a atividade anterior (predecessora).
desenhado utilizando o PDM. O PDM pode ser
feito manualmente ou no computador. Veja o exemplo:

Para cada atividade integrante de um

projeto podemos definir quatro tempos
que se referem às datas de início e término
da atividade, conforme esquema a seguir:

IMC D TMC
Atividade
IMT F TMT
Onde:
D = Duração da atividade (determinada);
IMC = Início mais cedo: é a data mais
cedo em que uma atividade pode começar,
assumindo que todas as atividades prece-
dentes a ela, começaram nas suas datas mais
cedo;
TMC = Término mais cedo: é a data mais Após o desenho da rede, seguindo as rela-
cedo em que uma atividade pode terminar; ções de precedência estabelecidas, devemos fa-
zer o cálculo da rede através do “passo à frente”
IMT = Início mais tarde: é a data mais tar- para obtenção das datas de início mais cedo e de
de em que uma atividade pode começar, sem término mais cedo (cálculo das linhas superiores).
atrasar a data de término do projeto;
TMT = Término mais tarde: á a data mais A seguir devemos fazer o cálculo de “pas-
tarde em que uma atividade pode terminar, so atrás” para determinar as datas de início mais
sem atrasar a data de término do projeto; tarde e término mais tarde de cada atividade da
rede (cálculo das linhas inferiores). O resultado
F = Folga total é o tempo que uma ativida- será:
de pode atrasar sem comprometer o prazo do
projeto como um todo; 7 10
D
16

10 3 19

As fórmulas utilizadas para calcular o dia- 1 6 6 7 3 9 10 5 14

grama de rede são: A E H
4 3 9 12 5 14 15 5 19

IMCn =TMCn-1 + 1 (para a primeira ativi- 0 0 0 1 2 2 3 2 4 8 8 15 16 4 19 19 0 19

INÍCIO B F J K TÉRMINO
dade da rede, utilizamos IMC = 1) 0 0 0 4 3 5 6 3 7 8 0 15 16 0 19 19 0 19

TMCn = IMCn + Dn - 1 1 3
C
3 4 4
G
7 8 6 13
L
14 2
M
15

1 0 3 4 0 7 12 4 17 18 4 19

TMTn-1 = IMTn - 1
Figura 11 - Diagrama de Rede - PDM

65
 O caminho
crítico
A determinação do caminho crítico de um
projeto é fundamental para que a gerência do
tempo possa controlar de forma eficaz, a reali-
zação correta do cronograma e o cumprimen-
to das datas estabelecidas para o projeto.
“Caminho Crítico” representa a série de
atividades que determina o término mais cedo
do projeto (já que o projeto só termina quan-
do todas as atividades forem concluídas). As-
sim, ele determina a duração total do projeto
e é, consequentemente, também o mais longo
através do projeto (em tempo).
O caminho crítico não é, necessariamen-
te, a maior sequência de atividades do crono-
grama do projeto. Podemos ter, por exemplo,
o cronograma de um projeto mostrado na figu-
ra abaixo:
Mês 1 Mês 2 Mês 3 Mês 4 Mês 5 Mês 6
A
B
C D
E
Figura 12 - Exemplo de Caminho Crítico
Note que o caminho A – C – D é a maior
sequência de atividades deste cronograma.
Há, porém, uma folga entre C e D. É a sequen-
cia A – E que determina a duração do projeto
(7 meses), que é o término mais cedo do pro-
jeto. É a sequência A – E, também, o caminho
mais longo do projeto (A sequência A – B dura
3,5 meses. A sequência A – C – D tem 6 me-
ses de duração).
A folga do caminho crítico é sempre zero.
Caso um GP (gerente de projetos) deseje
antecipar a data de término do mesmo, será
necessário antecipar as datas das tarefas do
caminho crítico.
É possível ter mais de um caminho crítico
em um diagrama de rede de um projeto.
Para o exemplo dado, temos:
66
Para identificação do caminho crítico da
rede basta verificar as atividades que têm a
menor folga total, ou seja, a diferença entre as
datas de início mais tarde e a data de início
mais cedo, ou pela diferença entre as datas
de término mais tarde menos a data de térmi-
no mais cedo. Com isso obtemos a sequência
C, G, J, K, conforme assinalada na figura aci-
ma.
Linha de base
do cronograma
Mês 7
A linha de base do cronograma é a ver-
são formalmente aceita e aprovada pelos en-
volvidos e serve como evidência daquilo que
foi planejado. Ela permite comparar o que foi
executado efetivamente contra o que foi pla-
nejado no plano do projeto.
A Lei de Parkinson, a Sín-
drome do Estudante e as
Multitarefas
Existem três fenômenos bastante conhe-
cidos na execução das atividades dos proje-
tos: Síndrome do Estudante, Lei de Parkinson
e as Multitarefas. Eles são prejudiciais e juntos
podem atrapalhar o andamento dos projetos.
A Lei de Parkinson diz que o trabalho
existente aumenta a fim de preencher e ocu-
par todo o tempo disponível para a sua con-
clusão. Ou seja, se você destinar, por exem-
plo, uma hora para terminar uma atividade, é
bem provável que termine neste prazo. E se
você destinar duas horas para terminar a mes-
 ma atividade, é bem provável que também o
termine dentro deste prazo de duas horas! E é
por isso que se você der a uma pessoa qual-
quer uma atribuição X, com um prazo de 30
dias, ela tenderá a completá-la de uma forma
que ocupe todo o prazo, mas se o prazo for de
apenas 3 dias, é provável que ele a complete
também, e se tiver que fazer em um dia só,
também vai conseguir.
A Síndrome do Estudante significa adiar
o trabalho até o último momento possível. Ela
ganhou esse nome pela forma como os estu- Figura 13 - Síndrome do Estudante (Esforço X Tempo)
dantes lidam com o dever de casa. Imagine Multitarefa é quando um mesmo recurso
dizer a um estudante que ele terá sua primeira executa várias atividades em paralelo. Ou seja,
prova dentro de 4 semanas. Digamos que ele para uma atividade no meio a fim de executar
já tem todo o material, o livro, os objetivos que outra. Isso acontece normalmente por falta de
serão testados e a data. priorização, pois se cada tarefa fosse execu-
tada por completo antes de o mesmo recurso
Quando ele começa a estudar? Na véspe-
iniciar a próxima tarefa, elas não atrasariam.
ra da prova. Por quê? Porque ele tem tempo,
é por isso. Outras tarefas pressionam mais e, Isso acontece porque nos pedem para
portanto, ele atrasa o início de uma tarefa até iniciar várias tarefas simultaneamente e cada
o último momento, para dar tempo de comple- uma delas possui um “cliente” esperando por
tar outro trabalho, que, muito provavelmente, sua saída. Cada cliente quer que a tarefa dele
também está sendo feito no último momento. progrida e constantemente pergunta “já termi-
nou?”, forçando-nos a comutar repetidamente

67
 para a tarefa dele para que algo seja feito e
reportar o progresso. Enquanto estamos tra-
balhando nesta tarefa, outros clientes pedem
o status de suas respectivas tarefas. Este ci-
clo nos força a comutar tarefas repetidamente.
Naturalmente, ao trabalhar numa tarefa você
não está fazendo progresso em nenhuma ou-
tra. Se seus clientes contam com uma entrega
rápida, eles pressionarão para ter um resulta-
do. Para alguns, não é necessário que seja rá-
pido, desde que esteja sendo feito.
Porém, analisemos: qualquer quantidade
de tempo não trabalhado numa tarefa signifi-
ca que a tarefa está sendo atrasada mais do
que seria se você se dedicasse ao seu térmi-
no. Assim, a multitarefa sempre faz com que
uma tarefa demore mais do que deveria. En-
tre outros fatores que se somam está o tempo
de raciocínio que leva para “entrar no trilho”,
e esse tempo pode ser uma parte significativa
do tempo total da tarefa quando se faz multita-
refa. Para o trabalho manual isso pode incluir o
tempo de ajuste da máquina, preparação das
ferramentas e equipamentos apropriados e
colocá-los de volta em seus lugares.
Pense como a multitarefa afetaria você
TAREFA 1ª Sem 2ª Sem 3ª Sem 4ª Sem
Projeto A
Projeto B
Projeto C
Figura 14 – Exemplo de Multitarefa (Fonte: Sciforma Corporation, 2005)
TAREFA 1ª Sem 2ª Sem 3ª Sem 4ª Sem
Projeto A
Projeto B
Projeto C
Figura 15 – Exemplo de Priorização de tarefas sem a Multitarefa (Fonte: Sciforma Corporation, 2005)
68
numa fila de caixas no supermercado. Imagine
que, em vez de atender uma pessoa por vez,
o processo de pagamento no caixa incluísse
passar apenas um produto de cada pessoa na
fila e então fosse repetido até que cada pessoa
passasse todos os seus produtos. Se há ape-
nas uma pessoa na fila, o tempo necessário
para o pagamento seria apenas o tempo ne-
cessário para passar os seus produtos, pegar
seu dinheiro e empacotar suas mercadorias.
Entretanto, se após você chegar na fila
e um ou mais de seus itens tivessem sido re-
gistrados, outra pessoa entra na fila e, em vez
de completar seu pedido, o caixa pegar um
item desta outra pessoa, registrá-lo, e depois
pegar um de seus itens, registrá-lo, e repetir.
Agora demorará duas vezes mais para você
completar sua compra. Enquanto o caixa está
registrando seus itens e, simultaneamente, o
da pessoa atrás de você, outra pessoa entra
na fila. Agora o caixa pega um item seu, de-
pois um da próxima pessoa, e depois um da
nova pessoa, e repete.
Como é possível perceber pelo exemplo
acima, quanto mais tarefas aceitarmos realizar
simultaneamente, mais cada tarefa demorará.
5ª Sem 6ª Sem 7ª Sem 8ª Sem 9ª Sem 10ª Sem 11ª Sem 12ª Sem
5ª Sem 6ª Sem 7ª Sem 8ª Sem 9ª Sem 10ª Sem 11ª Sem 12ª Sem
 Até aqui...
No decorrer desta unidade, estudamos sobre o tempo, conteúdo
do conjunto de processos de planejamento do projeto na área e neces-
sário para produzir as várias entregas identificadas na EAP (WBS).
Os subtópicos estudados foram:
• Sequenciando as atividades: o processo de identificação e do-
cumentação dos relacionamentos entre as atividades do projeto. Cada
atividade e marco, com exceção do primeiro e do último, são vincula-
dos a pelo menos um predecessor e um sucessor.
• Estimando as durações das Atividades: vinculadas as tarefas,
devemos estimar o período necessário para conclusão individual de
cada atividade do cronograma (lembrando que os marcos são ativida-
des com duração zero e, consequentemente, não possuem esforço ou
trabalho associados).
• Alocando os Recursos: Deve se identificar quais recursos (tipos
e quantidades) serão utilizados para realizar cada atividade.
• Montando o Cronograma: Determinar as datas de início e fim para
as atividades do projeto.
• Diagrama de rede do projeto: Esquema de apresentação das ativi-
dades do projeto e dos relacionamentos lógicos (dependências) entre
elas: Método do diagrama de precedência (PDM - Precedence Diagram-
ming Method), método do caminho crítico.
• A Lei de Parkinson e a Síndrome do Estudante: A Lei de Parkin-
son diz que o trabalho existente aumenta a fim de preencher e ocupar
todo o tempo disponível para a sua conclusão. A Síndrome do Estu-
dante significa adiar o trabalho até o último momento possível.

69