0

Primeira Edio

Gerenciamento de Projetos
Orientados a Planos

contato@cursospin.com.br
Av. Djalma Batista, n. 946, sala 08 (Centro Empresarial Santo Remdio) - Vieiralves
Nossa Sra. das Graas Manaus
Telefone (92) 3584-1966
Site: WWW.cursospin.com.br

contato@cursospin.com.br
2

Rafael Dias Ribeiro

Horcio da Cunha e Sousa Ribeiro

Gerenciamento de Projetos
Orientados a Planos

1 Edio

Rio de Janeiro
Horcio da Cunha e Sousa Ribeiro

2015

Todos os direitos reservados. Nenhuma parte deste livro pode ser fotocopiada, gravada, reproduzida ou
armazenada num sistema de recuperao ou transmitida sob qualquer forma ou por qualquer meio
eletrnico ou mecnico sem o prvio consentimento dos autores.

Direito Editorial
Horcio da Cunha e Sousa Ribeiro
Capa
Pintura a leo tela (1997): complexidade de Horcio Ribeiro

R484g

Ribeiro, Rafael Dias; Ribeiro, Horcio da Cunha e Sousa Ribeiro.

Catalogao na fonte por: Edirlane Carvalho de Souza Freitas CRB7-5463

Gerenciamento de projetos orientados a planos

Horcio da Cunha e Sousa Ribeiro. Rio de Janeiro: [s.n.], 2015.
132 p.; il.; 23 cm.

Rafael Dias Ribeiro,

Contm Referncias
ISBN: 978-85-919102-2-9

1. Projetos. 2. Gerncia de projetos. 3. Riscos. 4. Cronogramas. 5. Gesto de

custos. 6. Administrao. I. Ttulo.


CDD 658.404

Dedicatria:
Este livro dedicado a todos os entusiastas pela
cincia de Gerenciamento de Projetos.
Rafael Dias Ribeiro

Dedico este livro aos mais de trinta mil

alunos

para os quais lecionei. Eles me ensinaram muito e

por causa deles sempre estudei muito.

Eles

tambm foram meus professores

Horacio da Cunha e Sousa Ribeiro

Sumrio
Apresentao ......................................................................................................................................... 11
CAPTULO 1 ........................................................................................................................................... 12
1.0 - Introduo ................................................................................................................................ 12
1.1 - Anlises de Ambiente .......................................................................................................... 13
1.2 - Cenrios e seus Projetos... ................................................................................................. 19
1.3 - Projetos Direcionados a Valor e Projetos Direcionados a Planos .................................. 21
1.3.2 - Projeto direcionado a plano: ........................................................................................... 22
CAPTULO 2 ........................................................................................................................................... 25
2.1 - Projeto ....................................................................................................................................... 25
2.1.1 - Programa ........................................................................................................................... 25
2.1.2 - Portflio .............................................................................................................................. 28
2.2 Subprojeto ................................................................................................................................ 28
2.3 - Estruturas Organizacionais ..................................................................................................... 29
2.3.1 - A estrutura espelha a cultura organizacional: .............................................................. 30
2.4 - Estrutura Funcional .................................................................................................................. 30
2.4.1 - Estrutura Projetizada ........................................................................................................ 31
2.4.2 - Estrutura Matricial ............................................................................................................ 32
2.5 - Escritrio de Projetos (PMO - Project Management Office) ............................................... 34
2.6 - Ciclo de Vida de Projeto .......................................................................................................... 36
2.7 - Ciclo de Vida de Produto ......................................................................................................... 37
2.8 - Grupos de Processos de Gerenciamento de Projetos ......................................................... 38
2.9 - Boas Prticas ............................................................................................................................ 39
2.10 - reas de Conhecimento e Processos em Gerenciamento de Projetos ........................... 40
2.10.2 ESCOPO ........................................................................................................................... 41
2.10.3 TEMPO ............................................................................................................................. 42
2.10.4 - CUSTO .............................................................................................................................. 43
2.10.5 - QUALIDADE ..................................................................................................................... 43
2.10.6 - RECURSOS HUMANOS ................................................................................................... 44
2.10.7 - COMUNICAO ............................................................................................................... 44
2.10.8 - RISCOS ............................................................................................................................ 45
2.10.9 - AQUISIES ................................................................................................................... 46
2.10.10 - STAKEHOLDERS ........................................................................................................... 46
CAPTULO 3 ........................................................................................................................................... 47
7



3.1 - Iniciao .................................................................................................................................... 47
3.1.1 - Compreender o Porqu do Projeto e Avaliar a sua Viabilidade com as Restries,
Riscos e Premissas Iniciais ........................................................................................................... 47
3.1.2 - Identificar a Cultura Organizacional, Processos, Procedimentos e Informaes
Histricas ........................................................................................................................................ 48
3.1.3 - Selecionar o Gerente de Projetos ................................................................................... 48
3.1.4 - Identificar Partes Interessadas ....................................................................................... 49
3.1.5 - Desenvolver o Termo de Abertura do Projeto .............................................................. 50
CAPITULO 4 ........................................................................................................................................... 54
4.1 - PLANEJAMENTO ....................................................................................................................... 54
4.1.1 -Incio do Projeto ................................................................................................................. 54
4.2 - Requisitos .................................................................................................................................. 56
4.3 - Criar a Declarao do Escopo do Projeto ............................................................................. 57
4.4 - Avaliar o que Comprar ............................................................................................................ 58
4.5 - Declaraes de Trabalho ........................................................................................................ 59
4.6 - Determinar a Equipe ............................................................................................................... 59
4.7 - Criar a EAP (Estrutura Analtica do Projeto) e o Dicionrio da EAP .................................. 62
4.7.1 - Como Gerar a EAP? .......................................................................................................... 63
4.7.2 - Dicionrio da EAP ............................................................................................................. 64
4.7.3 - Criar a Lista das Atividades ............................................................................................. 65
4.7.4 - Consideraes: .................................................................................................................. 65
4.7.8 - Criar o Diagrama de Redes ............................................................................................. 66
4.7.9 - Estimar as Necessidades de Recursos ........................................................................... 66
4.7.10 - Estimar Tempo e Custo ................................................................................................. 67
4.7.10 .1 - Estimativa de um ponto ............................................................................................ 67
4.7.10.2 - Estimativa Anloga (Top Down) ............................................................................ 67
4.7.10.3 - Estimativa Paramtrica ............................................................................................... 68
4.7.10.4 - Estimativa de Trs Pontos (Anlise PERT, Tcnica de Reviso e Avaliao de
Programa) ...................................................................................................................................... 68
4.8 - Determinar o Caminho Crtico ................................................................................................ 70
4.8.1 Exerccio: .............................................................................................................................. 76
4.9 - Desenvolver o Cronograma .................................................................................................... 79
4.9.1 - Compresso (Crashing) ................................................................................................... 79
4.9.2 - Paralelismo ou Caminho Rpido (Fast Tracking) ......................................................... 80
8



4.9.3 - Desenvolver o Oramento ............................................................................................... 80
4.9.4 - Determinar Padres, Processos e Mtricas de Qualidade ........................................... 82
4.10 - Princpios da Qualidade em Gerenciamento de Projetos ................................................. 83
4.11 - Determinar Todos os Papis e Responsabilidades ............................................................ 86
4.12 - Planejar as Comunicaes .................................................................................................... 87
4.13 - Planejamento de Tratamento de Riscos ............................................................................. 89
4.13.1 - Como classificar que risco deve ter prioridade? ......................................................... 91
4.13.2 -Estratgias de Respostas (Riscos Positivos) ................................................................ 95
4.13.3 - Preparar os Documentos de Aquisies ...................................................................... 95
4.13.4- Realizar a Anlise de Fazer ou Comprar ....................................................................... 95
4.13.5 - Determinar os Critrios de Seleo da Fonte ............................................................. 96
Capitulo 5 ............................................................................................................................................... 97
5.1 - Execuo ................................................................................................................................... 97
5.2 - Auditorias de Qualidade .............................................................................................................. 98
5.4 -Anlise de Processos ................................................................................................................ 99
5.5 - Atividades de Construo da Equipe ................................................................................... 100
5.5.1 - Conflito ............................................................................................................................. 103
5.6 - Selecionar Fornecedores ....................................................................................................... 105
5.7 - Comunicar-se! ........................................................................................................................ 106
Captulo 6 ............................................................................................................................................. 108
6.1 Monitoramento e Controle e a fase de Encerramento ........................................................ 108
6.2 - Monitoramento e Controle .................................................................................................... 108
6.3 - Analisar Variaes e Gerenciar as Mudanas ..................................................................... 110
6.4 -Validar e Controlar o Escopo ................................................................................................. 111
6.5 - Controlar Cronograma ........................................................................................................... 111
6.6 - Controlar Custos ..................................................................................................................... 112
6.7 - Monitorar e Controlar Riscos ................................................................................................ 114
6.8 - Administrar Aquisies .......................................................................................................... 114
6.8.1 - Contrato de Preo Fixo .................................................................................................. 115
6.8.2 - Contrato por Tempo e Material .................................................................................... 115
6.8.3 - Contrato de Custos Reembolsveis .............................................................................. 115
6.9 - Encerramento ......................................................................................................................... 116
Capitulo 7 ............................................................................................................................................. 117
7.1 - Introduo ao Gerenciamento de Projetos Orientado a Valor ........................................ 117
9



7.2 - Princpios geis Originrios do Setor Industrial Tcnica Lean ......................................... 118
7.2.1 - Reduzir o Desperdcio .................................................................................................... 118
7.4 - Tcnica Systems Thinking .................................................................................................... 121
7.5 -Tcnica Work Cells .................................................................................................................. 122
7.6 - Princpios geis Originrios do Setor de Tecnologia da Informao .............................. 122
7.6.1 - Princpios geis ............................................................................................................... 123
7.7 - SCRUM ..................................................................................................................................... 124
7.7.1 - Eventos e Artefatos Scrum ............................................................................................ 126
7.7.2 - Planning Meeting (Reunio de Planejamento) ........................................................... 127
7.7.3 - Review (Reviso) ............................................................................................................ 129
7.7.4 - Retrospective (Retrospectiva) ....................................................................................... 130
Sobre os autores: ............................................................................................................................ 132
Rafael Dias Ribeiro ......................................................................................................................... 132
Horcio da Cunha e Sousa Ribeiro ................................................................................................... 132
Graduado em Engenharia Eltrica pela Universidade do Estado do Rio de Janeiro (1975) ,
Mestrado em Engenharia de Sistemas - Informtica pelo Instituto Militar de Engenharia
(1985), MBA em Gesto de IES pela UNESA. Diretor Geral do Instituto Superior de Tecnologia
do Estado do Rio de Janeiro (FAETEC) - Coordenador de Ps-graduao dos cursos de
Especializao de professores em TICS, e do curso de especializao em Metrologia para
Software. Professor de banco de Dados, Inteligncia Artificial, Sistemas de Informaes,
Engenharia de Software, Anlise e Linguagens de Programao, Produtividade e mtricas de
Software. Pesquisador de processos de negcio e sua ergonomia. Pesquisador de objetos de
ensino visando otimizao do aprendizado. Autor do primeiro livro sobre Inteligncia Artificial
do Brasil. Primeiro livro de anlise orientada a objetos do Brasil. Diretor Geral da FAETERJ-Rio
(antigo IST-Rio). A FAETERJ-Rio tem um curso de formao de analistas de sistemas de nvel
superior e duas ps-graduaes (TIC aplicadas para professores - Metrologia aplicada ao
software), Desenvolveu e implantou novas formas de atendimento pela secretaria, implantou a
utilizao de metodologias dinmicas de ensino nas salas hbridas. Desenvolveu a biblioteca
virtual em Q-RCode. Desenvolvimento de planejamento participativo e utilizao do site virtual
(AVA). Desenvolveu conjunto de indicadores de desempenho para a Faculdade e com isto
obteve a certificao ISO-9001; duas vezes o conceito 4 (2009 e 2011). ................................. 132

10

Apresentao

Com uma economia cada vez mais dinmica e competitiva, informao e

conhecimento surgem e se propagam cada vez mais rpido. No ambiente corporativo,
esse dinamismo provocou um elevado nmero de projetos organizacionais para
atender s diversas demandas.

Segundo o Project Management Institute (PMI), at 2020, 13 milhes de novas

vagas para Gerentes de Projetos sero criadas no mundo, sendo 1.3 Milhes no Brasil.
H uma crescente necessidade de profissionais detentores de habilidades para
gerenciar projetos, que utilizem boas prticas e ferramentas para alcanar os objetivos
do projeto e no apenas intuio ou bom senso. Para responder a esse desafio,
colaboradores devem reunir atributos de conhecimentos tcnicos sobre gerenciamento
de projetos, usando de modo eficiente esse conhecimento, aumentando as chances de
sucesso do projeto. Neste livro pretendemos apresentar as principais tcnicas e
ferramentas para quem deseja atuar na equipe de gerenciamento ou como gerente de
projetos orientados a planos.

11

CAPTULO 1

1.0 - Introduo
Pela necessidade de um aumento contnuo de competitividade, com o
dinamismo e a velocidade com que a informao e o conhecimento circulam, o
ambiente corporativo de vrias empresas necessita utilizar a gerncia atravs de
projetos para se tornar mais eficaz, gil e competitivo.
H uma crescente demanda de profissionais detentores de habilidades para
gerenciar projetos, que utilizem boas prticas e ferramentas para alcanar os objetivos
do projeto e no apenas intuio ou bom senso. Para responder a esse desafio,
colaboradores devem reunir atributos de conhecimentos tcnicos sobre gerenciamento
de projetos, usando de modo eficiente esse conhecimento, aumentando as chances de
sucesso do projeto. Neste captulo iremos compreender o que realmente um projeto
e vamos identificar as caractersticas e diferenas de projetos orientados a planos e de
projetos orientados a valor.
muito comum, no meio corporativo, ouvirmos:
Prximo ms, iniciamos o Projeto XYZ (...)
Esto todos dedicados ao Projeto XYZ (...)
Mas ser que o conceito de projeto usado corretamente? Vamos entender o
que um projeto e suas caractersticas.
A definio do PMBoK -Project Management Body of Knowledge, sobre
projeto, :

Um PROJETO um esforo temporrio empreendido para criar um produto,

servio ou resultado exclusivo.

12

Observe que os projetos possuem caractersticas bem significativas, como:

Temporrios, possuem um incio e um fim definidos;

Planejados, executados e controlados;

Entregam produtos, servios ou resultados exclusivos;

Desenvolvidos em etapas, implementam uma elaborao progressiva;

realizados por pessoas; sofrem restries.

A empresa, assim como a execuo de determinados projetos, algo vivo,

que muda seu comportamento durante a execuo e, em momentos diversos, poder
exigir abordagens diferentes do gestor.

1.1 - Anlises de Ambiente

Os ambientes organizacionais exercem grande influncia na forma como
desenvolvemos e conduzimos o projeto. No apenas o tipo de estrutura
organizacional, como as hierarquizadas, projetizadas ou Matricial (veremos mais
detalhadamente os tipos de estruturas organizacionais no captulo 2), mas outras
caractersticas

como

grau

de

mapeamento

de

processos

organizacionais,

previsibilidade do resultado do projeto, nmero de incertezas e outras caractersticas

tambm influenciam as tcnicas e prticas que sero utilizadas no gerenciamento de
projetos. O autor Jurgen Appelo, em seu livro Management 3.0, procura explicar as
diferenas entre os possveis ambientes organizacionais, nos quais projetos ocorrem,
utilizando duas dimenses distintas.
A primeira dimenso diz respeito estrutura do sistema:
Simples: Fcil de entender.
Complicado: Muito difcil de entender.
A segunda dimenso diz respeito ao comportamento do sistema: Ordenado:
Totalmente previsvel.
13

Complexo: Parcialmente previsvel, mas com muitas surpresas.

Catico: Imprevisvel.
Outra abordagem sobre os ambientes organizacionais o Cynefin Framework,
de Dave Snowden, que descreve uma perspectiva sobre a natureza evolutiva de
sistemas complexos.

O Cynefin Framework tem cinco domnios. Os quatro primeiros so:

Simples (ou bvio), neste domnio, se voc faz X e voc sempre ter Y, e
no importam quantas vezes voc faz X, voc obter o mesmo resultado Y. Voc pode
prever com confiana o resultado final da atividade. Nesses casos, a coordenao pode
ser usada com grande efeito.
A relao entre causa e efeito bvia para todos. A abordagem : Sentir Categorizar - Responder e, assim, podemos desenvolver e/ou aplicar as melhores
prticas (Best Practice).

14

Por exemplo, em uma loja do McDonalds s existe uma melhor forma de

preparar um hambrguer (sempre a mesma temperatura e sempre a mesma
durao), o procedimento j predefinido e treinado.
Complicado, neste domnio, existe uma relao entre causa e efeito, porm
uma srie de diferentes meios poder gerar o mesmo resultado. A escolha de qual
meio ser utilizado depender da anlise do ambiento no momento da deciso.
Esse o reino de especialistas que concentram tempo e energia em trabalhar
tais relaes de causa e efeito. Nesse caso, a cooperao eficaz nesse domnio,
porque muitas vezes h um objetivo final claro em mente, mas voc precisa das foras
combinadas de uma gama de pessoas para alcan-lo.
A relao entre causa e efeito requer uma anlise ou alguma outra forma de
investigao e / ou a aplicao de conhecimento especializado. A abordagem Sentir Analisar - Responder e, nesse caso, podemos desenvolver e/ou aplicar boas prticas
(Goodpractice).
Por exemplo, existem diversas formas de se criar a mistura do concreto em
uma obra. Dependendo da temperatura, umidade, ferramenta e outros fatores,
podem-se utilizar uma tcnica em detrimento de outra. Por exemplo, na obra da usina
de Itaipu, na mistura do concreto, foi utilizado gelo, em vez de gua no estado
lquido, para evitar micro fissuras geradas pelo processo aquecimento que ocorre
durante as reaes qumicas do preparo do concreto. Em uma construo de uma casa
ou edifcio, no comum se utilizar gelo no processo de concretagem.
Complexo, esse domnio caracterizado por causas e efeitos que so to
entrelaados e intrincados que as coisas s fazem sentido em retrospecto. Voc ouve
as pessoas dizerem: "Ah, este resultado aconteceu porque (...)", mas se voc voltar
um pouco atrs e verificar o que aconteceu, de fato, vai obter um resultado diferente.
Retroceder e voltar a jogar, e ainda ter outro resultado. Esse fenmeno ocorre
15

porque, em situaes complexas, tudo to interligado que uma pequena mudana

em uma parte do sistema pode ter um impacto enorme em outro lugar e vice-versa.
O sistema imprevisvel em detalhes, mais ainda podemos discernir padres.
So nessas situaes complexas que a colaborao vem tona. A colaborao
funciona bem para cenrios complexos, pois o estilo de trabalhar de forma
colaborativa corresponde natureza das questes que representam situaes
complexas.
Complexidade imprevisvel, colaborativa, adaptvel; complexidade
confuso difcil trabalhar a questo, e muito menos a resposta colaborativa, pois
envolve reunir uma diversidade de pessoas e talentos para experimentar, criar e testar
possveis abordagens para a soluo de um determinado problema.
Complexidade imprevisvel, isto , dependendo dos fatores (ex: clima
organizacional,

relacionamento

interpessoal,

autoconhecimento

da

equipe,

conhecimento prvio do trabalho que ser realizado e outros) no temos a certeza do

resultado produzido. Assim, no ambiente complexo, temos um grande esforo para
desenvolver o aspecto de confiana entre os membros da equipe para que proporcione
maior criatividade e, dessa forma, inovaes. A relao entre causa e efeito s pode
ser percebida em retrospecto, mas no com antecedncia. A abordagem
Probabilidade - Sentir - Responder e, assim, podemos aplicar a prtica emergente
(emergente).
Por exemplo, ao entrar em um consultrio mdico e relatar que est com dor
noestmago (efeito), alm de tratar dos efeitos, o mdico ir iniciar uma srie de
testes at descobrir a causa.
Catico, este o lugar no qual impossvel discernir a relao entre causa
eefeito. A melhor abordagem nesse domnio simplesmente agir. No h nenhuma
relao entre causa e efeito no nvel de sistemas, a abordagem Agir - Sentir Responder e, assim, podemos desenvolver e aplicar novel practice.
16

Desordem o quinto domnio. o estado de no saber que tipo de

causalidade existe. Em pleno uso, a estrutura do Cynefin tem subdomnios, e o limite
entre simples e catico visto como algo catastrfico.
Observe que existe um grande esforo das empresas em transformarem aes
complexas em complicadas e, posteriormente, em simples (o que no possvel para
todas as atividades), este esforo se justifica pois

economicamente mais

interessante e facilita a expanso do modelo.

Vamos ilustrar com um exemplo fictcio sobre a empresa da dcada de 1920 de
carros Dias Automveis.
Inicialmente a empresa era formada por 3 engenheiros altamente qualificados
que comearam a pesquisar sobre como fazer um carro popular para comercializao
no mercado nacional, o desenvolvimento de um automvel completo no era muito
difundido na poca. Assim para se criar um prottipo foi feitas diversas pesquisas
(com erros e acertos), prottipos de suspenso, posio de chassi, etc. Depois de 1
ano foi criado o primeiro automvel, porm seu custo era elevado e o tempo de
produo era impossvel para atender o objetivo de criao do carro popular. No ano
seguinte, contrataram alguns tcnicos em mecnica e produziram novos veculos.
Durante a produo, desenvolveu se um guia de boas prticas, o que auxiliou muito o
desenvolvimento de automveis e reduziu o custo de produo, mas ainda era muito
caro desenvolver um carro. Nos anos seguintes, os das boas prticas, escolheram
uma e a elegeram a melhor prtica, assim foi possvel decompor o trabalho em partes
e criaram a linha de montagem, como o trabalho j estava planejado a mo de obra
no precisava ser de engenheiros ou tcnicos, o que barateou a produo do
automvel e permitiu a produo em massa.
Existiram as seguintes etapas:

17

Analisando nossa histria sob o prisma do Framework de Cynefin, vemos que

na primeira fase estvamos em um cenrio complexo, com poucas informaes e a
causa s era descoberta quando se analisava o efeito. Por exemplo, por que o
automvel vibrava mais ou menos se o motor era encaixado na horizontal ou na
vertical no veculo. Em um cenrio complexo, importante que os profissionais
possuam uma formao muito boa, pois eles sero os responsveis pela anlise e
orientao do seu dia a dia de trabalho.
Quando mapeamos boas prticas, levamos a empresa para um cenrio
complicado onde possvel optar por uma prtica em funo de outra analisando o
momento. Neste cenrio ainda temos profissionais bem formados, mas podemos
orientar a execuo de tarefas mais simples para profissionais com uma formao
intermediria.
18

Ao definirmos uma das boas prticas como a nossa melhor prtica estamos
simplificando o processo e decompondo o trabalho em partes menores. Desta forma
podemos baratear o custo de produo com profissionais de baixa qualificao
(comparados com os do cenrio complexo). Isso acontece em redes de lanchonetes,
montadoras de produtos industrializados, etc.
No item anterior, fomos capazes de identificar cenrios simples, complexos e
complicados. E cada um destes cenrios possui caractersticas especficas quanto a
tolerncia a erros, tempo de resposta, etc. Iremos analisar agora a tolerncia ao erro
(ou melhor, possibilidade de aprender com o erro) e o tempo de resposta do
sistema.
Nos cenrios caticos e complexos, o erro melhor entendido do que nos
cenrios simples e complicados, j que a relao causa-efeito no existe ou
desconhecida. Essa aceitao conhecida com Fail Fast ou Learning Fast, errando
rpido, temos mais tempo para aprender e refazer.
Quando tratamos sob a perspectiva de tempo de resposta, nos cenrios simples
e caticos, a resposta precisa ser mais rpida do que nos cenrios complexos e
complicados, pois a demora pode provocar perdas significativas. Por exemplo, caso
voc entre em uma lanchonete do tipo fast food (cenrio simples) e o atendimento
demore por volta de 20 minutos, voc provavelmente ir procurar outro
estabelecimento para fazer sua refeio ou, em um prdio incendiando (cenrio
catico), voc no poder demorar muito para agir, concorda?

1.2 - Cenrios e seus Projetos...

Cenrios simples e complicados so mais comuns em projetos de construo,
com alta previsibilidade do produto final do projeto, como a construo de avies,
pontes, prdios, mquinas de caf, etc. Pois seguem um fluxo de construo de pea
por pea, montagem, testes e est pronto para uso, seu processo pode ser
19

decomposto em um plano bem detalhado por etapas (ou entregas parciais) at o todo
estar pronto. J cenrios complexos so bem comuns em projetos de desenvolvimento
de softwares, desenhos e redesenhos de processos organizacionais, campanhas
publicitrias e outros.

A construo etapa aps etapa, dificultando o planejamento

de longo prazo, pois o nmero de incertezas to elevado que um plano longo teria
grande probabilidade de ser descartado devido a um elevado nmero de mudanas
significativas no projeto. Assim muito arriscado definir um plano muito detalhado, j
que necessidades e prioridades mudam de acordo com o andamento do projeto (e
pela prpria dinmica das organizaes).
Diferentes tipos de projetos requerem diferentes mtodos. Em geral projetos de
caractersticas

de

profissionais

do

conhecimento,

em

ambientes

de

rpida

transformao, tm caractersticas complexas e necessitam de tcnicas emergentes

(tcnicas de agilidade). J em projetos de construo, temos grande predominncia de
projetos de cenrios complicados ou simples, porm vale ressaltar que nenhuma
empresa ou projeto est sempre em um cenrio, as empresas navegam por cenrios
diferentes em momentos diferentes e por isso que um bom gerente de projetos deve
saber identificar em qual cenrio a empresa ou projeto est no momento e selecionar
as tcnicas e ferramentas certas para gerenci-lo.

20

Caractersticas de Projeto de

Caractersticas de Profissionais do

Construo

Conhecimento

(Trabalho Industrial)
O trabalho visvel.

O trabalho invisvel.

O trabalho estvel.

O trabalho instvel.

nfase na execuo das etapas.

nfase na mudana.

Mais estruturao e menos deciso.

Menos estruturao e mais deciso.

Foco nas respostas certas.

Foco nas perguntas certas.

Definio de tarefas.

Entendimento das tarefas.

Comando e controle.

Autonomia.

Padronizao.

Inovao contnua.

Foco na qualidade.

Foco na qualidade.

Medio de desempenho
padronizada.

Ensinamento e aprendizado contnuo.

Minimizao do custo pago ao

Trabalhador visto como um ativo e

trabalhador por tarefas.

no como custo.

Quadro

de

comparao

do

trabalho

industrial

com

profissionais

do

conhecimento, adaptado de PMI-ACP Exam Prep, Maki Giffiths, 2012.

1.3 - Projetos Direcionados a Valor e Projetos Direcionados a Planos

Cenrios de projetos de construo, normalmente, seguem uma abordagem
orientada a plano, como temos alta previsibilidade do produto do projeto, podemos
utilizar as tcnicas adequadas para decompor as entregas e definir um plano aceitvel
para a sua produo. J em projetos complexos, a incerteza e imprevisibilidade nos
direcionam a utilizar uma abordagem orientada a valor, visto que a entrega final tem
grande probabilidade de no ser a gerada nos primeiros momentos do projeto.
21

1.3.1 - Projeto direcionado a valor:

Em projetos orientados a valor, quando se investe muito no planejamento,
gerado um risco muito grande ao projeto.

Em cenrios de grande incerteza, o

planejamento precisar ser baseado em muitas premissas (eventos incertos que

definimos como verdade para fins de planejamento) que sero falsas, o que pode
gerar tantas mudanas no plano original que o esforo de adaptao no compensaria
a energia gasta no desenvolvimento do plano original.

1.3.2 - Projeto direcionado a plano:

Em projetos direcionados a plano, como o prprio nome sugere, temos um
grande esforo no planejamento, pois um bom plano aumenta as chances de uma boa
execuo. O guia de boas prticas Project Management Body of Knowledge (PMBOK) PMBoK , do PROJECT MANAGEMENT INSTITUTE - PMI define 47 processos, em 10
reas de conhecimento, que quando utilizadas de acordo com a necessidade do
projeto, aumentam as chances de sucesso de um projeto. Neste livro iremos abordar
os principais processos e suas ferramentas utilizadas no gerenciamento de Projetos
Orientados Planos

22

23

DICA: Observe que nenhum projeto totalmente simples, complicado ou

complexo. Pacotes de trabalho de um mesmo projeto podem ter caractersticas
diferentes, sendo assim, importante observar o momento do projeto para definir a
abordagem adequada de gerenciamento e, nisso, o planejamento em ondas sucessivas
ajuda muito.
Outro ponto importante que tcnicas de gerenciamento de projetos
complicados, como as boas prticas do PMBoK (ex: Plano de comunicaes,
estimativas de custo, declaraes de trabalho de aquisio, etc.), podem ser aplicadas
em projetos complexos, assim como tcnicas de agilidade (ex: Reunio de
Retrospectiva, Reunio de Planejamento da Interao, Definio de Viso do Produto,
planejamento de release, etc.), de projetos complexos, podem ser aplicadas em
cenrios complicados e simples, tudo depende da anlise do gerente do projeto.
Perguntar qual a melhor forma de gerenciar um projeto sem conhecer o projeto
em si, ambiente organizacional e o produto do projeto equivale a perguntar oque
melhor, o martelo ou o alicate? A resposta depende se voc deseja pendurar
um quadro ou fazer uma instalao eltrica. Podemos concluir que NO existe
uma Bala de Prata em Gerenciamento de Projetos. Assim, o entendimento dos
possveis cenrios e o conhecimento das diversas tcnicas e ferramentas de
gerenciamento so essenciais para o gestor de projetos.

24

CAPTULO 2
Neste captulo, vamos apresentar conceitos iniciais de gerenciamento de
projetos, diferenciando projetos, programas e portflios. Trataremos dos diferentes
tipos de estruturas organizacionais e dos ciclos de vida do projeto e do produto.

2.1 - Projeto
Conforme vimos no Captulo 1, um PROJETO um esforo temporrio
empreendido para criar um produto, servio ou resultado exclusivo. E possui
algumas caractersticas, como:
Feito por pessoas;
Elaborado progressivamente;
Sofre restries;
Tem incio e fim (esforo temporrio);
Cria um resultado nico (criar um produto, servio ou resultado exclusivo).

2.1.1 - Programa
O Project Management Institute - PMI define programa como: um grupo de
projetos relacionados gerenciados de modo coordenado para a obteno de benefcios
e controle que no estariam disponveis se eles fossem gerenciados individualmente.
Imagine que em uma cidade a empresa de urbanizao ir executar um projeto que
tem como objetivo asfaltar um determinado conjunto de ruas. Nesta mesma cidade, a
empresa de guas e Esgoto ir instalar tubulaes subterrneas para melhorar o
servio prestado. Observe que os dois projetos so independentes, mas se no existir
uma coordenao, os projetos podero causar desconforto a algumas partes
interessadas e at aumentarem o tempo e o custo de execuo. Por exemplo, no dia
15, a empresa de urbanizao asfalta a Rua XYZ, no dia 17, a empresa de guas e
Esgoto obrigada a remover o asfalto para instalao, o que causar grande
desconforto para todos, concordam?
25

Projetos

Programas

Portflios

Projetos tm

Programas tm

objetivos definidos.

grande alcance e

Escopo elaborado

proporcionam

progressivamente

benefcios mais

ao longo do ciclo

significativos.

Escopo

Portflios tm
um mbito
organizacional
, e mudam de
acordo com os
objetivos
estratgicos
da
organizao.

de vida do projeto.

Mudanas

Os gerentes de

Gestores de

projeto esperam

programas esperam

mudanas e

mudanas a partir

implementam

de dentro e de fora

processos para

do programa e

manter o

esto preparados

gerenciamento e o

para administr-las.

Gestores de
Portflios
monitoram
continuament
e as
mudanas no
ambiente
interno e
externo.

controle de
mudana.

Os gerentes de

Gestores de

projeto,

programas

progressivamente,

desenvolvem o

elaboram

plano global do

informaes de alto

programa e criam

nvel em planos

planos de alto nvel

detalhados ao

para orientar o

longo do ciclo de

planejamento

vida do projeto.

detalhado no nvel
de componente.

Gestores de
Portflios
criam
e mantm
processos
necessrios e
comunicao
em relao ao
portflio.

Planejamento

Os gerentes de

Gestores de

Gestores de
Portflios
26

liderana e viso

podem
administrar ou
coordenar a
equipe de
gesto de
portflios,
programa ou
equipe do
projeto que
podem ter
responsabilidad
es em relao

global.

ao portflio

projetos gerenciam

programas

a equipe do projeto

gerenciam a equipe

para atender aos

do programa e os

objetivos do

gerentes de

projeto.

projeto, fornecendo

Gerenciamento

O sucesso

O sucesso medido

medido pela

pelo grau em que o

qualidade do

programa satisfaz

produto e do

s necessidades e

projeto, respeito ao

aos benefcios para

prazo,

os quais ele foi

cumprimento do

empreendido.

O sucesso
medido em
termos do
desempenho
dos
investimentos
e benefcios
da realizao
do portflio.

Sucesso

oramento e do
grau de satisfao
do cliente.

Os gerentes de

Gestores de

projeto monitoram

programas

e controlam o

monitoram o

trabalho de

progresso dos

produo, servios

componentes do

e resultados para

programa para

os quais o projeto

garantir que as

foi empreendido.

metas,

Gestores de
Portflios
monitoram as
mudanas
estratgicas e
alocao de
recursos
agregados,
resultados,
desempenho e
risco do
portflio.

Monitoramento

cronogramas,
27



oramento e
benefcios do
programa sero
cumpridos.

2.1.2 - Portflio
O Project Management Institute - PMI define portflio como: um conjunto de
projetos, programas ou outros trabalhos agrupados para facilitar o gerenciamento
eficaz desse trabalho, a fim de atingir os objetivos de negcios estratgicos.

Quadro comparativo entre projetos, programas e portflio

2.2 Subprojeto
Uma parte menor do projeto total, que pode ter certa autonomia, mas sua
existncia no faz sentido sozinha. Normalmente, terceirizada ou delegada a outra
rea.
28

Por exemplo, imagine que voc foi contratado para seleo, contratao e
treinamento de recepcionistas para um grande evento musical. Para voc e seu
departamento, isso um projeto, no qual vocs iro realizar atividades de
planejamento, execuo, monitoramento e controle e encerramento, entregando os
profissionais contratados e treinados adequadamente.
Esse projeto do seu departamento faz parte de um projeto maior, que o
evento musical, assim podemos afirmar que ele um subprojeto. Observe que
diferente do exemplo apresentado na explicao sobre programas (Empresa e
Urbanizao X Empresa de guas e Esgoto). No exemplo de Subprojeto, caso o evento
musical seja cancelado, o objetivo do seu projeto, o de seleo de pessoal, perde a
funo, assim, a existncia desse projeto depender da existncia do projeto maior
(evento musical).

Projeto: Evento Musical

Observe que um projeto pode ter

diversos subprojetos.

Seleo de
recepcionista

2.3 - Estruturas Organizacionais

O gerenciamento de projetos a aplicao de conhecimento, habilidades,
ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. O
contexto no qual o projeto realizado afeta muito no modo como ele gerenciado.
Empresas com culturas diferentes possuem formas muito diferentes para gerenciar
projetos (mesmo que sejam projetos com caractersticas semelhantes). Projetos so
influenciados pelas normas culturais, pelas polticas de gerenciamento e pelos
procedimentos das organizaes das quais fazem parte. Identificar o tipo de estrutura
organizacional auxilia a equipe de gerenciamento a planejar melhor, respeitando a
29

cultura e suas caractersticas e, assim, aumentar as chances de sucesso do projeto.

2.3.1 - A estrutura espelha a cultura organizacional:

Dita a forma como o projeto deve ser conduzido;
Reflete na metodologia adotada;
Afeta o ambiente do projeto, principalmente pela sua distribuio de poder
de deciso.
O Project Management Institute - PMI classifica a estrutura organizacional de
uma empresa de trs formas distintas, que so: funcionais, projetizadas ou matriciais.

2.4 - Estrutura Funcional

Comum em organizaes governamentais, militares, empresas tradicionais ou

familiares. Esse tipo de estrutura agrupado por reas de especializao (reas
funcionais), distintas, por exemplo: Departamento de Recursos Humanos,

Estrutura Funcional Fonte: PMBoK 5 Ed.

Departamento de Marketing, etc. O poder de deciso dos gerentes
funcionais (chefes de departamento). Os membros da equipe fazem o trabalho do
projeto, alm do trabalho normal do departamento.

30

Vantagens:
Equipe tem apenas um chefe;
Um ponto de referncia;
Plano de carreira bem definido;
Uso compartilhado de recursos especialistas.
Desvantagens:
Gerente de projeto externo ao departamento no tem autoridade;
Mais ateno s atividades funcionais;
Dificuldade para os projetos interdepartamentais.

2.4.1 - Estrutura Projetizada

Comuns em segmentos de consultoria, construo e engenharia. uma
organizao por projeto, toda a empresa organizada por projeto e o gerente de
projeto tem controle sobre o projeto. O pessoal designado e fica subordinado ao
gerente de projetos. Os membros da equipe fazem o trabalho do projeto e, aps o
encerramento, so designados a novos projetos ou so desligados da empresa
(Essa caracterstica conhecida como Efeito Sem Lar, j que no existe um
departamento para voltarem aps o fim do projeto).

Estrutura Projetizada Fonte: PMBoK 5 Ed.

31

Vantagens:

Foco no projeto, mais lealdade ao projeto;

Uso dedicado de recursos, maior eficcia;

Melhor comunicao.

Desvantagens:

Redundncia de recursos especialistas, menos eficiente;

Sem referncia nica para a equipe, na desmobilizao (sensao de

sem lar);

Perfil mais generalista dos recursos.

2.4.2 - Estrutura Matricial

Esse tipo de estrutura tenta maximizar os pontos fortes das estruturas

funcionais e projetizadas. Nesse tipo de estrutura, os membros da equipe se reportam
a dois chefes (o gerente funcional e o gerente de projetos). Pode ser do tipo fraca,
balanceada ou forte, dependendo do poder do gerente de projetos em relao ao
gerente funcional.

Estrutura matricial forte: O poder do gerente de projetos.

Estrutura Matricial Forte Fonte: PMBoK 5 Ed.

32

Estrutura matricial fraca: O poder do gerente funcional.

Estrutura Matricial Fraca Fonte: PMBoK 5 Ed.

Estrutura matricial balanceada: O poder compartilhado entre o

gerente funcional e o gerente de projetos.

Estrutura Matricial Balanceada Fonte: PMBoK 5 Ed.

Vantagens (em relao funcional):

Mais controle e coordenao dos projetos;

Utilizao mais efetiva dos recursos;

Melhora na comunicao horizontal em projetos interdepartamentais.

33

Desvantagens (em relao funcional):

Mais de um chefe para a equipe, administrao mais difcil;

Comunicao mais complexa;

Maior dificuldade na alocao de recursos;

Potencial maior de conflitos de objetivos.

Quadro Comparativo Entre os Tipos de Estruturas Organizacionais

Quadro Comparativo Fonte: PMBoK 5 Ed.

2.5 - Escritrio de Projetos (PMO - Project Management Office)

O Project Management Institute - PMI define escritrio de projetos como: Um
corpo ou entidade organizacional qual so atribudas vrias responsabilidades ao
gerenciamento centralizado e coordenado dos projetos sob seu domnio.
Diversas pessoas quando iniciam seus estudos no gerenciamento de projetos
ficam com o seguinte questionamento em suas mentes. Se eu tenho um gerente
para cada projeto, que ir trabalhar para o sucesso do projeto, por que
preciso ter um escritrio que tambm faa isso?. Antes de continuar a estudar
sobre escritrio de projetos, vamos a alguns questionamentos que geralmente as
empresas no conseguem responder (mesmo com gerentes de projetos qualificados
34

em todos os seus projetos).

Quantos projetos existem em sua organizao atualmente?
Quanto est sendo investido nesses projetos?
A organizao possui recursos para atender a todos esses projetos?
Como um projeto poder afetar outros?
J existiu algum projeto semelhante no passado? Ocorreu algum problema?
Os projetos esto alinhados com as estratgias da empresa?
Quantos projetos terminam no prazo? E no oramento?
O escritrio de projetos tem vrios papis dentro da organizao em relao
aos seus projetos, mas geralmente investe em trs reas principais:

Metodologia: Fornecem as polticas, as metodologias e os modelos para

gerenciar projetos na organizao. Atua na definio, auditoria, implantao, evoluo

de metodologias para gerenciamento de projetos.

Pessoas: Fornece apoio e orientao a outras pessoas na organizao

sobre como gerenciar projetos, oferece treinamento sobre gerenciamento de projetos

e softwares de gerenciamento de projetos e auxilia no uso de ferramentas especficas
para o gerenciamento de projetos.

Ferramentas: Define, implanta e suporta ferramentas especficas

degerenciamento de projetos.

35

Dependendo da posio na estrutura organizacional, sua atuao pode ser mais

estratgica ou mais operacional, mais abrangente ou mais especfica. Todos os
projetos, ou projetos de um determinado porte, tipo ou influncia, so gerenciados por
esse escritrio. Em qualquer caso, o patrocnio da gerncia superior fundamental.

2.6 - Ciclo de Vida de Projeto

O Project Management Institute - PMI define o ciclo de vida do projeto como
um conjunto de fases do projeto, geralmente em ordem sequencial, e que s vezes se
sobrepem, cujo nome e nmero so determinados pelas necessidades de
gerenciamento e controle da(s) organizao(es) envolvida(s), a natureza em si e sua
rea de aplicao. Um ciclo de vida pode ser documentado como uma metodologia.

Ciclo de vida do projeto

O ciclo de vida do projeto pode ser interpretado como o que voc precisa fazer
para produzir as entregas do projeto. H diferentes tipos de ciclos de vida de projetos,
dependendo do setor em que o gerente de projetos trabalha ou das preferncias da
organizao. Por exemplo:

rea de Construo: Viabilidade, Planejamento, Design, Produo, Entrega

e Ativao.

rea de Tecnologia da Informao: Design de alto nvel, design detalhado,

36

codificao, testes, instalao, homologao, entrega para operaes.

2.7 - Ciclo de Vida de Produto

Esse ciclo dura da concepo de um novo produto at sua retirada do mercado.
Um produto pode requerer ou abranger muitos projetos durante seu ciclo de vida.

Projeto
Ao Natalina

Projeto
Recall 1

Projeto ...

Projeto ...
Projeto ...

Projeto
Construo da
planta fabril de
produo

Projeto de
Descarte

Ciclo de vida do produto

37

2.8 - Grupos de Processos de Gerenciamento de Projetos

Os processos de gerenciamento de projetos incluem os processos de iniciao,
planejamento, execuo, monitoramento e controle e encerramento.

A iniciao do projeto necessria para que o projeto seja aprovado

oficialmente. O gerente de projetos deve fazer, na iniciao, um planejamento de alto
nvel para verificar se o projeto pode ser terminado com as restries (limitaes)
determinadas (prazo, custo, escopo, etc.).
Aps a aprovao do projeto, ele passa da iniciao para o planejamento
detalhado, em que criado o plano de projeto que ir orientar a execuo do trabalho
do projeto, o monitoramento e controle e o encerramento. nessa fase em que temos
o maior esforo de planejamento de projetos orientados a plano.
Aps a aprovao de um plano de projeto realista e vivel, inicia-se a fase de
execuo em que a equipe realiza e termina o trabalho de acordo com os processos e
procedimentos detalhados no plano de gerenciamento de projetos. Enquanto o
trabalho executado, seus resultados (e outras informaes sobre o desempenho do
trabalho) so entradas nos processos de monitoramento e controle para garantir que o
projeto seja executado de acordo com o planejado. Se houver alteraes, so tomadas
as medidas necessrias para ajustar o trabalho ao plano desenvolvido. Por fim, quando
o trabalho for finalizado (ou encerrado) passamos para a fase de encerramento do
projeto.
38

2.9 - Boas Prticas

Existe um conjunto de Boas Prticas para o gerenciamento de Projetos
orientados a Planos. Essas boas prticas esto documentadas em um livro mantido
pelo Project Management Institute - PMI, com o nome de PMBoK (Project
ManagementBody of Knowledge), em que so apresentados 47 processos de
gerenciamento distribudos em 10 reas de conhecimento. Antes de conhecermos os
47 processos, vamos entender o que so Boas Prticas.
Boas Prticas: Significa que existe um entendimento geral de que a aplicao
correta dos processos de gerenciamento apresentados aumenta as chances
desucesso na maioria dos projetos, na maior parte das vezes. A equipe de
gerenciamento de projetos responsvel por determinar o que adequado para cada
projeto especfico.

39

2.10 - reas de Conhecimento e Processos em Gerenciamento de Projetos

2.10.1 -Integrao
Desenvolver Termo de Abertura

Processo de desenvolver o documento que formalmente autoriza o projeto

ou fase.

Desenvolver Plano de Gerenciamento do Projeto

Processo de documentar as aes necessrias para definir, preparar,

integrar e coordenar todos os planos auxiliares.

Dirigir e Gerenciar a Execuo

Processo de executar o trabalho definido no Plano de Gerenciamento do

Projeto.

Monitorar e Controlar o Trabalho

Processo de monitorar e controlar o progresso do projeto de acordo com o

Plano.
40

Realizar Controle Integrado de Mudanas

Processo de revisar, aprovar e controlar solicitaes de mudana, bem

como manter atualizados os documentos do projeto.

Encerrar Projeto ou Fase

Processo de finalizar todas as atividades e encerrar formalmente o projeto

ou fase.

2.10.2 ESCOPO
Planejar Gerenciamento do Escopo

Processo de planejar como o escopo ser definido, validado e controlado.

Coletar Requisitos

Processo de definir e documentar os requisitos necessrios para atender

necessidades e expectativas de interessados.

Definir Escopo

Processo de desenvolver uma descrio detalhada do projeto e do produto.

Criar EAP Estrutura Analtica do Projeto

Estrutura Analtica do Projeto uma subdiviso hierrquica orientada a

entregas. Criar a EAP envolve definir as entregas principais e seus
componentes, bem como todo o trabalho do projeto.

Validar Escopo

Processo de formalizar a aceitao das entregas do projeto.

Controlar Escopo

Processo de monitorar e controlar o escopo do projeto.

41

2.10.3 TEMPO
Planejar Gerenciamento do Tempo

Processo de planejar como ser definido, gerenciado e controlado o

cronograma do projeto.

Definir Atividades

Processo de identificar atividades especficas que precisam ser realizadas

para produzir as entregas do projeto.

Definir Sequncia de Atividades

Processo de identificar e documentar dependncias entre as atividades do

cronograma.

Estimar Recursos das Atividades

Processo de estimar tipo e quantidades de recursos necessrios para

realizar cada atividade do cronograma.

Estimar Duraes das Atividades

Processo de estimar o nmero de perodos de trabalho necessrios para

realizao das tarefas.

Desenvolver Cronograma

Processo de analisar os recursos necessrios, restries do cronograma,

duraes e sequncias de atividades para criar o cronograma do projeto.

Controlar Cronograma

Processo de monitorar e controlar o progresso do projeto e a performance

de execuo do cronograma, tomando medidas corretivas quando
necessrio.

42

2.10.4 - CUSTO
Planejar Gerenciamento dos Custos

Processo de planejar como ser definido, gerenciado e controlado o

oramento do projeto.

Estimar Custos

Processo de estimar os custos dos recursos necessrios para a execuo

das atividades.

Determinar Oramento

Processo de agregar custos estimados de atividades individuais ou pacotes

de trabalho para determinar o oramento do projeto.

Controlar Custos

Processo de monitorar e controlar o progresso do projeto e a performance

de execuo do oramento, tomando medidas corretivas quando
necessrio.

2.10.5 - QUALIDADE
Planejar Gerenciamento da Qualidade

Processo de identificar padres, normas ou requisitos de qualidade do

projeto e produto, e documentar como o projeto demonstrar
concordncia.

Realizar Garantia de Qualidade

Processo de auditar requisitos de qualidade e os resultados das medies

de controle de qualidade para assegurar que os padres apropriados de
qualidade esto sendo observados.

43

Controlar Qualidade

Processo de monitorar e controlar os resultados e as atividades do Plano

de Gerenciamento da Qualidade.

2.10.6 - RECURSOS HUMANOS

Planejar Gerenciamento de Recursos Humanos do Projeto

Processo de identificar e documentar funes, responsabilidades e

habilidades requeridas para a criao do Plano de Gerenciamento de
Recursos Humanos.

Mobilizar Equipe do Projeto

Processo para confirmar a disponibilidade dos recursos humanos e obter

a equipe necessria para terminar o projeto.

Desenvolver Equipe do Projeto

Processo de integrao e construo da equipe do projeto, bem como

melhoria de competncias individuais e coletivas da equipe.

Gerir Equipe do Projeto

Processo

de

acompanhar

desempenho

de

membros

da

equipe,

fornecendo feedback e solucionando conflitos.

2.10.7 - COMUNICAO
Planejar Comunicao

Processo de determinar as necessidades de informaes das partes

interessadas

no

projeto

para

definir

abordagens

adequadas

de

comunicao.

44

Distribuir Informao

Processo

de

tornar

disponveis

as

informaes

necessrias

aos

interessados.
Relatar Desempenho

Processo de coleta e distribuio das informaes sobre o desempenho e

performance do projeto.

2.10.8 - RISCOS
Planejar Gerenciamento dos Riscos
Processo de definir como sero identificados, analisados e gerenciados os
riscos do projeto, incluindo procedimentos e padro para gesto de riscos.
Identificar Riscos
Processo de determinar quais riscos pode afetar o projeto e documentar suas
caractersticas.
Realizar Anlise Qualitativa
Processo de priorizao dos riscos por meio da avaliao subjetiva das suas
probabilidades de ocorrncia e impactos no projeto.
Realizar Anlise Quantitativa
Processo de anlise numrica do efeito dos riscos identificados sobre os
objetivos gerais do projeto.
Planejar Respostas aos Riscos
Processo de desenvolver estratgias e aes para ampliar oportunidades e
reduzir ameaas aos objetivos do projeto.
Monitorar e Controlar Respostas aos Riscos

Processo de monitorar os riscos, implementando as aes do plano de resposta

quando necessrio.
45

2.10.9 - AQUISIES
Planejar Gerenciamento das Aquisies
Processo de documentar as decises de aquisio do projeto, definir tipos de
contratos e identificar potenciais fornecedores.
Conduzir Aquisies
Processo de obter propostas de fornecedores, selecionar fornecedor e
formalizar contrato.
Administrar Aquisies
Processo de gerenciar as relaes contratuais, fiscalizar e monitorar o
desempenho dos contratos.
Encerrar Aquisies
Processo de finalizar formalmente todas as aquisies e contratos do projeto.
2.10.10 - STAKEHOLDERS
Identificar Stakeholders
Processo de identificar pessoas, grupos ou organizaes que poderiam afetar
ou serem afetadas pelo projeto.
Planejar Gerenciamento dos Stakeholders
Processo

de

desenvolver

estratgias

para

engajar

efetivamente

os

stakeholders ao longo do projeto.

Gerenciar Engajamento dos Stakeholders
Processo de gerenciar expectativas e promover o engajamento dos
stakeholders em favor do projeto.
Controlar Engajamento dos Stakeholders

Processo de monitorar os relacionamentos com stakeholders do projeto.

46

CAPTULO 3

3.1 - Iniciao
A iniciao do projeto necessria para que o projeto seja aprovado
oficialmente. Nesta fase, o gerente de projetos dever fazer um planejamento de alto
nvel e verificar se o projeto pode ser terminado com as restries determinadas.
Neste captulo iremos entender as etapas necessrias que compem as boas prticas
de gerenciamento de projetos para a fase de iniciao.

3.1.1 - Compreender o Porqu do Projeto e Avaliar a sua Viabilidade com as

Restries, Riscos e Premissas Iniciais
Projetos so criados nas organizaes por diversos motivos, por exemplo: uma
nova legislao, o lanamento de um novo produto ou servio para atender a uma
demanda de mercado, o redesenho de processos, o avano tecnolgico, uma
necessidade organizacional ou social, uma demanda de cliente ou qualquer outro
motivo. Geralmente, os projetos surgem para atender a uma estratgia organizacional.
O gerente de projetos deve compreender o porqu do projeto. Tal compreenso
ir auxiliar na tomada de deciso em momentos crticos da execuo do projeto. Por
exemplo, os Jogos Pan-americanos do Rio 2007 tinham como objetivo estratgico
apresentar ao mundo a capacidade do Rio de Janeiro receber grandes eventos
esportivos e, assim, credenci-lo para cidade candidata aos Jogos Olmpicos. Voc
considera o projeto dos Jogos Pan-americanos do Rio 2007 um sucesso? Caso o
gerente analise apenas o oramento e os prazos planejados e o que foi realmente
realizado, talvez ele julgue que foi um fracasso, mas analisando a verdadeira essncia
deste projeto, pode-se observar que seu objetivo foi alcanado (portanto: Jogos
Olmpicos do Rio 2016).
OBS: A conduo do projeto ficou muito a desejar, tanto que o planejado e o
executado foram bem diferentes (aumento de custos e estouro de prazos).
47

Com a compreenso do projeto, importante que o gerente de projeto avalie

superficialmente os riscos, restries e premissas iniciais do projeto e j comece a
mapear e documentar esses fatores que iro influenciar no plano e execuo do
projeto.

3.1.2 - Identificar a Cultura Organizacional, Processos, Procedimentos e

Informaes Histricas
Compreender a cultura organizacional, como apresentado no capitulo anterior,
processos e procedimentos so essenciais para um bom plano de projeto. Por
exemplo, o procedimento de contratao do fornecimento de um determinado recurso
pode variar de acordo com a empresa. Em algumas, a contratao direta, em outras,
precisa passar pelo departamento de contratos, departamento de suprimentos ou
qualquer outro, o que ir impactar no plano de aquisies.
Outro fator importante coletar as informaes histricas de projetos
semelhantes, pois conhecendo o histrico, podemos identificar nossos pontos fortes e
fracos, analisar onde erramos e acertamos e, assim, planejar de forma mais eficiente o
prximo projeto. Este Autoconhecimento organizacional auxilia na identificao e
tratamento de riscos, melhora as estimativas, auxilia na conduo de mudanas,
comunicaes, aquisies e em diversas reas do projeto, aumentando suas chances
de sucesso.

3.1.3 - Selecionar o Gerente de Projetos

O processo de seleo de um gerente de projetos pode ser interno ou externo,
de forma geral, podemos dividir as competncias de um gerente de projetos entre
gerenciais e tcnicas. Antes de tudo, o selecionador do gerente de projetos dever
considerar:
Qual o porte do projeto (custos, nmero de recursos, localidades etc)?
48

Qual a natureza do projeto (simples, complicado, complexo)? Muitas vezes, as

habilidades necessrias para essa avaliao no so to simples e a ajuda de outros
gerentes de projetos (que no concorrem a essa vaga, neste projeto, pode ser muito
til).

Qual a durao?

Os recursos so diretos ou terceiros?

Que tipo de poderes ser aplicvel? Qual ser a autonomia desse

gerente?

Qual o perfil da equipe do projeto?

3.1.4 - Identificar Partes Interessadas

Identificar Partes Interessadas o processo de identificao das pessoas,
grupos ou organizaes que podem afetar ou serem afetados por uma deciso,
atividade ou resultado do projeto.
Deve-se analisar e documentar as informaes relevantes a respeito e de seus
interesses, envolvimento, interdependncias, influncia e potencial impacto sobre o
sucesso do projeto.
A principal vantagem desse processo que ele permite que o gerente de
projeto identifique o foco apropriado de cada parte interessada ou grupo de
interessados. Processo que identifica as pessoas e organizaes impactadas pelo
projeto e documenta seus interesses, envolvimento e influncia na realizao do
projeto. fundamental identificar as partes interessadas desde o incio do projeto at
o seu encerramento.

49



Poder
Alto

.F
.L Gerenciar
de perto

Manter
.C Satisfeito
Monitorar

Manter
Informado .U

.X
.Y
Baixo

Interesse
Baixo

Alto

Exemplos de identificao:

Identificao: nome, posio na organizao, local, papel no projeto e

informaes de contato.

Avaliao:

requisitos

essenciais,

principais

expectativas,

influncia

potencial no projeto.

Classificao: interna ou externa; apoiadora, neutra ou resistente.

muito comum o uso de tabelas para manter atualizados os dados e Status de

cada parte interessada do projeto.

Parte interessada

Poder

Interesse

Importncia

Avaliao do Estratgias para ganhar mais suporte ou

impacto
reduzir resistncias

Comentrios

3.1.5 - Desenvolver o Termo de Abertura do Projeto

o processo de autorizao formal de um novo projeto ou da continuao de
um projeto j existente para uma nova fase. Os benefcios do Termo de Abertura so:
50

Autorizao e formalizao do projeto na organizao;

Gerente do projeto nomeado e chancela o grau de autonomia para o uso de

recursos da organizao para o projeto;

Propsito ou justificativa do projeto;

Descrio do projeto de alto nvel;

Requisitos de alto nvel.

Podem conter outras informaes como os riscos inicialmente identificados.

Exemplo de Termo de Abertura

Termo de Abertura do Projeto
Nome do Projeto

Controle de Verses
Verso Data

Autor

Notas da Reviso

Objetivos deste documento

Autorizar o incio do projeto, definindo os poderes do Gerente do Projeto, as

principais responsabilidades, descrever requisitos iniciais, premissas e restries do
projeto, alm de definir as principais entregas
Situao atual e justificativa do projeto
Descreva a situao atual e o que motivou a realizao do projeto. Pode-se
referenciar o business plan ou outros documentos utilizados para a seleo deste
projeto.
51

Objetivos e critrios de sucesso do projeto

Descreva os benefcios esperados detalhando de forma clara os objetivos e
critrios de sucesso. Dica: Seja especfico, indicando a mtrica que ser utilizada para
medir se a meta do projeto/fase foi atingida ou no...
Produtos e principais requisitos
Documente os principais requisitos dos produtos a serem atendidos. (Os que j
foram definidos inicialmente).
Marcos
Liste os principais Milestones

ou marcos do projeto que j tenham sido

definidos no momento da iniciao do projeto. Marcos so pontos significativos do

projeto, eventos cuja ocorrncia precisa ser reportada s partes interessadas de modo
a terem clara visibilidade do seu cumprimento.

Marcos

Previso

Partes interessadas do Projeto

Defina nomes, responsabilidades e nvel de autoridade das principais partes
interessadas do projeto. Veja um exemplo na seo de identificao de partes
interessadas.
Restries
Liste as restries (limitaes definidas) do projeto, por exemplo, oramento,
prazos, recursos e etc.

52

Premissas
Liste as premissas do projeto, ou seja, eventos incertos considerados
verdadeiros para fins de planejamento, por exemplo: Disponibilidade do cliente em
60% durante a criao do prottipo.
Riscos
Liste os principais riscos do projeto, identificados at o momento.
Oramento do Projeto
Estimativa preliminar dos custos do projeto quando possvel nesta fase do
projeto.

Aprovaes
Participante
Patrocinador

Assinatura

Data

do

Projeto
Gerente do Projeto

Observe que possvel adicionar qualquer outra informao que seja relevante
para o projeto no momento de sua iniciao.

53

CAPITULO 4

4.1 - PLANEJAMENTO
Aps a fase de iniciao, entramos na fase de planejamento. Essa a fase que
requer maior esforo do gerenciamento de projetos, pois nessa etapa iremos planejar
todas as atividades que devero ser realizadas durante a execuo do projeto, os
mecanismos de controle e realizao de mudanas e todas as atividades necessrias
para a conduo do projeto e a entrega de seu resultado. Nestecaptulo, iremos
conhecer os principais processos de planejamento e compreender a sua importncia
em projetos orientados a plano.

4.1.1 -Incio do Projeto

O projeto est iniciado e formalizado pelo patrocinado. Vamos iniciar a fase de
planejamento. Em projetos orientados a planos, essa a fase de maior esforo e deve
envolver todas as partes interessadas. O desenvolvimento do plano um processo
iterativo e, quando finalizado, o plano de gerenciamento de projetos pode confirmar a
viabilidade do projeto (pois detalhando o plano de projeto possvel analisar as
necessidades de recursos, prazos, riscos e outras caractersticas que permitem uma
anlise mais detalhada sobre a viabilidade do projeto de acordo com as restries e
possveis limitaes). Vamos analisar a sequncia ordenada de como desenvolver um
bom plano de projeto.
Determinar como Voc Far a Parte de "Como Planejar" de Todos os Planos de
Gerenciamento
Como para um planejamento eficiente o gerente de projetos dever solicitar e
utilizar recursos (espao, equipamento, pessoas, etc), importante que um plano de
alto nvel seja feito com previses de datas de reunies, solicitaes e uso dos
recursos. Assim, os gerentes funcionais podero se planejar para liberar esses
recursos de maneira que interfira o mnimo possvel nas atividades departamentais
54

(funcionais).
Determinar Requisitos Detalhados

Fonte da imagem: PMI-ACP Exam Prep, Maki Griffiths, 2012.

Como representado na imagem acima, quando se pergunta para o solicitante do

projeto o que ele pretende criar (qual o resultado do projeto?), comum que
interpretaes diferentes sobre o produto do projeto surjam na equipe (e at nos
solicitantes do projeto). Para diminuir possveis interpretaes diferentes entre as
partes interessadas, precisamos planejar bem como definir o escopo do projeto e do
produto. Para isso, devemos:
Etapa 1- Coletar Requisitos: Definir e documentar as funes e funcionalidades
(requisitos) do projeto e do produto necessrias para atender s necessidades e
expectativas das partes interessadas.

55

4.2 - Requisitos
Incluem as necessidades e as expectativas do patrocinador, cliente e outras
partes interessadas. Devem ser quantificadas e documentadas. Precisam ser obtidas,
analisadas, registradas com detalhes suficientes para serem medidas. So necessrios
para a Estrutura Analtica do Projeto, planejamento de custos, cronograma e
qualidade.
Os requisitos devem ser:
No ambguos (mensurveis e passveis de testes);
Investigveis;
Completos;
Consistentes;
Aceitveis para as principais partes interessadas.
O sucesso do projeto diretamente influenciado pelo esforo dedicado
captura dos requisitos do projeto e do produto e ao gerenciamento dos mesmos. A
documentao dos requisitos inclui:
Requisitos funcionais;
Requisitos no funcionais;
Requisitos de qualidade;
Critrios de aceitao;
Impactos em outras reas;
Requisitos de suporte e treinamento;
Premissas e restries de requisitos.
muito interessante criar uma Matriz de Rastreabilidade de Requistos, uma
tabela que liga o requisito do produto ou servio a ser entregue desde a sua origens
at a entrega que o satisfaz.

56

O uso de uma matriz de rastreabilidade ajuda a garantir que cada requisito

adiciona valor de negcio atravs da sua ligao aos objetivos de negcio e aos
objetivos do projeto.
Fornece um meio de rastreamento do incio ao fim do ciclo de vida do projeto,
ajudando a garantir que os requisitos aprovados na documentao sejam entregues no
final do projeto, alm de auxiliar na identificar de onde os requisitos foram coletados,
na consulta de possveis impactos quando uma mudana for solicitada, na identificao
requisitos conflitantes e facilitar a comunicao com as partes interessadas que
solicitaram ou sero impactados por determinados requisitos.

Cd. Prioridade Tipo Nome

1
2
3

Quem
Data da ID requisitos
Descrio Justificativa Critrios de Aceitao solicitou Status Concluso EAP relacionados Comentrios

Matriz de Rastreabilidade de Requisitos

4.3 - Criar a Declarao do Escopo do Projeto
Definir escopo o processo de desenvolvimento de uma descrio detalhada do
projeto e do produto. A principal vantagem desse processo que se descreve o
projeto, servio ou resultado e define as fronteiras de quais requisitos coletados sero
includos e /ou excludos do escopo do projeto. (Fonte: PMBOK . 5. ed., p. 120 Traduo livre pelo autor). O escopo pode ser classificado como:

Escopo do Produto: As caractersticas e funes que descrevem um

produto, servio ou resultado.

Escopo do Projeto: O trabalho que precisa ser realizado para entregar um

produto,

servio

ou

resultado

com

as

caractersticas

funes

especificadas.
57

Aps o levantamento do escopo, preciso gerar um documento conhecido

como Declarao do Escopo do Projeto. Esse documento descreve em detalhes
asentregas do projeto e o trabalho necessrio para cri-las. Seu objetivo prover um
entendimento comum do que deve ser feito. A Declarao do Escopo do Projeto
inclui ou faz referncia :

Descrio do escopo do produto;

Critrios de aceitao do produto;
Entregas do projeto;
Excluses do projeto;
Restries e premissas do projeto.
OBS: A declarao de escopo deve ser aprovada pelas principais partes
interessadas antes de dar continuidade ao planejamento do projeto.

4.4 - Avaliar o que Comprar

Avaliar o que comprar tratado no Gerenciamento das Aquisies. Esse o
processo de documentao das decises de aquisio do projeto, especificando a
abordagem e identificao de potenciais vendedores. A principal vantagem desse
processo que ele determina se existir a aquisio de apoio externo ao projeto e, se
houver o que, como, quanto ser necessrio e quando adquirir.
Fonte: PMBoK 5. ed., p. 358.

Nessa ao, importante:

Realizar a anlise de fazer ou comprar;

Escrever a Declarao de Trabalho;

58

Selecionar o Tipo de Contrato;

Criar documentos de Aquisies;

Criar critrio de Seleo de Fornecedores.

4.5 - Declaraes de Trabalho

A Declarao do Trabalho da Aquisio descreve o item de aquisio em
detalhes suficientes para permitir que os fornecedores em potencial determinem se
so capazes de fornecer os produtos, servios ou resultados. Os detalhes podem variar
de acordo com a natureza do item, as necessidades do comprador ou o tipo de
contrato esperado. As informaes includas em uma Declarao do Trabalho podem
englobar especificaes, quantidade desejada, nveis de qualidade, dados de
desempenho, perodo de desempenho, local do trabalho e outros requisitos.
Fonte: PMBoK , 5. ed., p. 358.

4.6 - Determinar a Equipe

Determinar equipe tratado no PMBoK no processo de Planejar
Gerenciamento dos Recursos Humanos. Esse o processo de identificao e
documentao dos papis, responsabilidades, habilidades necessrias, relatrios de
relacionamento e criao de um plano de gerenciamento de pessoal. Conceitos
IMPORTANTES sobre o Gerenciamento de Recursos Humanos em projetos:

Criar sistemas de reconhecimento e recompensa uma importante

funo de recursos humanos e esses sistemas so parte obrigatria do

gerenciamento de projetos.

O gerente de projetos responsvel por melhorar as competncias dos

membros da equipe.

O gerenciamento de recursos humanos realizado principalmente no grupo

de processos de execuo.
59

As atividades de recursos humanos do gerente de projetos so formais e

exigem documentao.
Devem existir papis e responsabilidades formais no projeto, que incluam

auxiliar o gerente de projetos, responsabilidades em reunies e outros

trabalhos no relacionados s atividades.
Os projetos so planejados pela equipe e gerenciados pelo gerente de

projetos.
O gerente de projetos planeja formalmente as atividades de desenvolvimento

da equipe com antecedncia.

O gerente de projetos deve acompanhar o desempenho dos membros da

equipe.
A descrio dos recursos humanos disponveis deve envolver:

Competncia e proficincia.

Experincia prvia.

Interesses pessoais.

Caractersticas pessoais.

Disponibilidade.
Os membros da equipe devem saber para quais pacotes de trabalho e

atividades foram designadas, quais habilidades precisam ter, quando devem

apresentar relatrios, a quais reunies devem comparecer e qualquer outro trabalho
que precisam fazer no projeto.
Papis e Responsabilidades

Quem faz o qu?

Quem decide o qu?

Quais so as responsabilidades de cada um?

Quais as competncias necessrias?

Os

papis

devem

estar

claramente

designados

aos

stakeholders
60

apropriados.

interessante utilizar ferramentas, como Matriz de Responsabilidade e

Organograma do Projeto nessa definio.

Dica: Criando uma Matriz RACI

A Matriz RACI uma ferramenta utilizada para atribuio de responsabilidades,
dentro de um determinado processo, projeto, servio ou mesmo no contexto de um
departamento / funo.
A Sigla RACI significa:

R: Responsvel por executar uma atividade (o executor);

A: Autoridade, quem deve responder pela atividade, o dono (apenas uma

autoridade pode ser atribuda por atividade);

C: Consultado, quem deve ser consultado e participar da deciso ou

atividade no momento que for executada;

I: Informado, quem deve receber a informao de que uma atividade foi

Atividade 1
Atividade 2
Atividade . . .
Atividade n

Diretor X

Analista Pl

Responsabilidade (Deliverable, Processo

ou Atividade
do Projeto*)

Analista Sr

Papel

Diretor Y

Coordenador

executada

R A

Exemplo de Matriz RACI

61

Alm disso, o plano de gerenciamento de Recursos Humanos deve tratar do:

Plano de mobilizao do pessoal (De onde eles vm?).

Calendrio dos recursos (Quais pessoas estaro disponveis? Quando elas

sero utilizadas?).

Plano de liberao do pessoal.

Necessidade de treinamento do pessoal.

Reconhecimento e recompensas (O que so? Quais os critrios?).

Conformidade (Como o projeto cumprir normas relacionadas ao RH?).

Segurana (Quais polticas protegem os recursos?).

4.7 - Criar a EAP (Estrutura Analtica do Projeto) e o Dicionrio da EAP

Criar EAP um processo de subdiviso das entregas e do trabalho em
componentes menores e de gerenciamento mais fcil. A EAP uma decomposio
hierrquica orientada s entregas do trabalho a ser executado pela equipe para atingir
os objetivos do projeto e criar as entregas requisitadas, sendo que cada nvel
descendente da EAP representa uma definio gradualmente mais detalhada na
definio do trabalho do projeto. (Fonte: PMBOK , 4. ed., p. 116.)

Decomposio da Estrutura Analtica do Projeto - Fonte: PMBOK , 4. ed., p. 221.

62

A EAP Estrutura Analtica do Projeto deve ser feita com toda a ateno e EM
EQUIPE, pois a base para muitos processos do planejamento.
OBS: Cuidado para no detalhar demasiadamente, evite o micro gerenciamento.

4.7.1 - Como Gerar a EAP?

Realizar a decomposio do projeto, fases (ou entregas), isto , a subdiviso de
cima para baixo das entregas do projeto em componentes menores e mais facilmente
gerenciveis.
Ateno: possvel que entregas distantes no possam ser decompostas, por
isso a equipe de gerenciamento dever aguardar que as mesmas fiquem mais claras.
Isso conhecido como planejamento em ondas sucessivas (rolling waveplanning).

A EAP deve incluir (tudo) somente o necessrio para entregar o produto e

tambm os produtos de gerenciamento de projeto.
Benefcios da EAP
Subdivide o projeto em partes menores, mais fcil de gerenciar;
63

Melhora a preciso das estimativas de custo e tempo;

Facilita a comunicao;
Previne omisso de entregas;
Diminui riscos de gerenciamento;
Auxilia no comprometimento dos envolvidos no projeto;
Ajuda no gerenciamento de mudanas.
DICA: Sempre que possvel, utilizar EAPs de outros projetos semelhantes,
como modelo de referncia para definio do escopo de um novo projeto.

4.7.2 - Dicionrio da EAP

Cada pacote de trabalho EAP deve ser descrito em detalhes no dicionrio da
EAP. Esse dicionrio descreve as aes e em que sequncia devem ser feitas para
concluir os Pacotes de Trabalho, e outras informaes como:
Descrio;
Trabalhos envolvidos;
Critrios de Aceitao;
Premissas;
Riscos;
Recursos designados;
Durao;
64

Custo;
Marcos do cronograma;
Interdependncias;
E outras informaes que se julguem necessrias.

4.7.3 - Criar a Lista das Atividades

Para cada pacote de trabalho, devem-se identificar as atividades que devem ser
realizadas para produzir as entregas (do pacote de trabalho) do projeto.

Por exemplo, projeto de treinamento:

4.7.4 - Consideraes:
As atividades sero as listadas no cronograma. Essas atividades tero
estimativas de esforo (tempo) e custo.
As atividades NO precisam ser apresentadas em ordem (A ordenao feita
no diagrama de rede).
65

A EAP que apresenta as atividades vinculadas ao Pacote de Trabalho

conhecida como EAP estendida.

4.7.8 - Criar o Diagrama de Redes

O diagrama de redes a representao das atividades do projeto e das relaes
lgicas (dependncias) entre elas.

4.7.9 - Estimar as Necessidades de Recursos

Durao o tempo necessrio para completar uma atividade. Sofrem influncia
de:
Recursos (quantidade, habilidades, disponibilidade, tempo, etc);
Produtividade (ambiente, compartilhamento, etc);
Restries e premissas;
Informaes histricas;
Riscos.
A estimativa de recursos deve ser feita com bastante ateno, pois ir impactar
nas demais estimativas. Por exemplo, em um projeto onde atuaremos com mquinas
de impresso, a velocidade e o nmero de impresses por minuto podero impactar
66

nas estimativas de durao e custo das atividades que iro utilizar esta mquina.
Um ponto de ateno na Estimativa de Recursos diz respeito ao perfil do
profissional que ir atuar em determinada atividade. Por exemplo, um pedreiro com
muita experincia faz uma parede de 200 metros quadrado em 1 dia de 8 horas, um
pedreiro com menos experincia, levar 3 dias para realizar o mesmo trabalho, porm
cinco vezes mais barato que o pedreiro com experincia.

Observe que o perfil

profissional que ser determinado nesta estimativa dever estar no Plano de Recursos
Humanos do projeto.

4.7.10 - Estimar Tempo e Custo

Aps a estimativa dos recursos envolvidos na execuo de uma determinada
atividade, possvel iniciar suas estimativas de durao e de custo. As mesmas
tcnicas de estimativa podem ser aplicadas tanto para tempo quanto para custo.
Project Management Institute - PMI apresenta quatro formas de estimar em projetos
orientados a plano, so elas:

4.7.10.1 - Estimativa de um ponto

Apresenta a estimativa por atividade. Pode ser baseada na opinio

especializada, informaes histricas ou simplesmente adivinhao.

Apresenta a estimativa por atividade.

Pode ser baseada na opinio especializada, informaes histricas ou

simplesmente adivinhao.

4.7.10.2 - Estimativa Anloga (Top Down)

Usa opinio especializada e informaes histricas para prever o futuro.
Analogia com outros projetos.
Tambm chamada de estimativa Top-Down.
67

4.7.10.3 - Estimativa Paramtrica

Observa os relacionamentos entre as variveis em uma atividade para

calcular estimativas.
Duraes estimadas quantitativamente.
Quantidade de trabalho a ser executado x Taxa unitria de produtividade.
Ex.: Passar X metros de cabo por hora.

4.7.10.4 - Estimativa de Trs Pontos (Anlise PERT, Tcnica de Reviso e

Avaliao de Programa)
Baseia-se
na anlise das estimativas: Mais provvel, Otimista, Pessimista.
Baseia-se na distribuio Beta (b)

Distribuio Beta (PERT)

Mdia = (P + 4M + O) /6

Varincia (s2) = [(P-O)/6]2

Desvio Padro: (s) = [(P-O)/6]

68

Distribuio normal

1 : 68,3% da populao

2 : 95,5% da populao

3 : 99,7% da populao

...

6 : 99,9999998%

Veja o exemplo abaixo:

Distribuio normal
1 : 68,3% da populao -> Significa que a Atividade A tem 68,3% de
probabilidade de ser executada entre 6.33 e 8.67
1

= (7.5 1.17 = 6.33 e 7.5 + 1.17 = 8.67)

69

2 : 95,5% da populao -> Significa que a Atividade A tem 95,5% de

probabilidade de ser executada entre 5.16 e 9.84
2

= (7.5 (2 x 1.17) = 5.16 e 7.5 + (2 x 1.17) = 9.84)

3 : 99,7% da populao
...
6 : 99,9999998%

4.8 - Determinar o Caminho Crtico

Mtodo do Caminho Crtico - Critical Path Method (CPM)

Desenvolvido pela Dupont e Remington Rand Corporation entre 1957-58.

Estimativa determinstica (uma estimativa por atividade).

Foco nas folgas para determinar a menor flexibilidade no cronograma.

Determina o tempo mnimo que um projeto precisar para executar todas

as suas atividades.

Caminho com atividades com folga zero, isto , se alguma das atividades
atrasarem, o projeto atrasar.

Pode existir mais de um caminho crtico por projeto.

Como utilizar o mtodo:

Dados da Atividade

70

O quanto mais (CEDO / TARDE) pode a atividade (INICIAR / TERMINAR),

levando-se em conta a sequncia lgica das atividades e as respectivas restries e
premissas. Observe que no so datas e, sim, momentos do projeto. Imagine o
diagrama abaixo:

Onde:

Clculo das datas mais cedo:

1o. Percorrer os caminhos do incio para o fim (Determinao das datas mais
cedo).

A identificao de datas mais cedo para as atividades do projeto (passo para

frente) ir fornecer a durao dos caminhos e do projeto.

71

Significa que o tempo mnimo necessrio para a execuo deste projeto

de 31 unidades de tempo (ex: dias, meses, anos).

72

Clculo das datas mais tarde:

2o. Percorrer os caminhos do fim para o comeo (Determinao das datas
mais tarde).

73

A identificao de datas mais tarde (passo para trs) ir fornecer as folgas

existentes.

Folga Livre

Tempo que a atividade pode atrasar sem afetar a prxima.

FL = ES (sucessora) - EF (da atividade).

74

Folga Total
Tempo que uma atividade pode retardar sem comprometer o prazo do
projeto.
Calculada para a atividade em questo.
Folga total = LS - ES ou LF EF.

As atividades do caminho crtico apresentam folgas iguais a 0 (zero).

75

4.8.1 Exerccio:

Determine o caminho crtico do Diagrama de Redes apresentado abaixo:

Atividade
1
( 5 dias)

Atividade
3
( 6 dias)

Atividade
4
( 1 dia)

Atividade
2
( 5 dias)

Atividade
5
( 9 dias)

RESPOSTA:
IMC

TMC

Nome da Atividade
Quantidade de Folga
IMT

IMC: Incio mais cedo

TMC: Trmino mais cedo
IMT: Incio mais tarde
TMT Trmino mais tarde

TMT

Passo 1: Determinar o Inicio Mais Cedo e Trmino Mais Cedo das Atividades 1 e 2

76

Passo 2: Determinar o Inicio Mais Cedo e Trmino Mais Cedo das Atividades 3 e 5

Passo 3: Determinar o Inicio Mais Cedo e Trmino Mais Cedo da Atividade 4

Passo 4: Determinar o Inicio Mais Tarde e Trmino Mais Tarde das Atividades 4 e 5

77

Passo 5: Determinar o Inicio Mais Tarde e Trmino Mais Tarde da Atividade 3

Passo 6: Determinar o Inicio Mais Tarde e Trmino Mais Tarde das Atividades 1 e 2

Passo 7: Determinar as Folgas (IMT-IMC ou TMT TMC)

78

4.9 - Desenvolver o Cronograma

Toda a informao disponvel organizada em um modelo de cronograma de
forma que a equipe de gerenciamento do projeto possa calcular, analisar cenrios
alternativos, at conseguir determinar um cronograma base. Com o diagrama de rede,
estimativas e com o caminho crtico conhecido, essas informaes so inseridas em
um calendrio (com as caractersticas funcionais do trabalho para o projeto Por
exemplo: O trabalho ir acontecer apenas em dias teis com 8 horas de trabalho
dirias), e assim surge o cronograma do projeto. Este um processo iterativo e
ocorrero vrias vezes durante todo o projeto.
Benefcios de um Bom Cronograma
Estima data de concluso do projeto;
Facilita a comunicao;
Evita conflitos de datas e alocao de recursos;
Mostra a interdependncia das tarefas;
Identifica gargalos do projeto;
Fornece uma base para o controle do projeto.
possvel que o diagrama de rede proposto, depois de transformado em um
cronograma, no atenda restrio de prazo (o projeto est previsto para
terminar aps a data limite imposta pelo cliente, assim necessrio comprimir o
cronograma). Para a Compresso do Cronograma (Sem Alterar o
Escopo), existem duas tcnicas:

4.9.1 - Compresso (Crashing)

Reduo da durao da atividade, normalmente aumentando os recursos e
custos;
Anlise custo/benefcio para obter a maior compresso com o menor custo;
Nem sempre aplicvel;
79

Comprimir as atividades que esto no caminho crtico e considerar aquelas

que sofrem menos aumento de custo.

4.9.2 - Paralelismo ou Caminho Rpido (Fast Tracking)

Atividades que normalmente seriam executadas em sequncia so feitas em
paralelo;
Aumenta o risco e pode causar retrabalho no projeto;
Requer maior domnio das atividades.

4.9.3 - Desenvolver o Oramento

O plano de gerenciamento de custos um componente do plano de
gerenciamento de projeto e descreve como os custos do projeto sero planejados,
estruturados e controlados. O plano de gerenciamento de custos pode incluir
informaes como:
As unidades de medida;
Nvel de preciso;
Regras de medio de desempenho;
Formatos de relatrios;
Descries de processo;
80

Detalhes adicionais;
Especificaes sobre como as estimativas devem ser informadas (em qual
moeda);
Se os custos incluiro custos diretos e indiretos;
Estabelecimento de uma linha de base de custos para medio como parte
do monitoramento e controle do projeto;
Limites de controle (uma quantidade de variao combinada a ser permitida
antes que alguma ao seja necessria);
Procedimentos de controle de mudanas em custo.
Estimar custos o processo de desenvolver uma aproximao dos recursos
monetrios necessrios para terminar as atividades do projeto.A principal vantagem
desse processo determinar a quantidade de custos necessrios para completar o
trabalho do projeto.
A preciso da estimativa aumentar conforme o mesmo progride no seu ciclo de
vida. Portanto, a estimativa de custo um processo iterativo de fase para fase. Por
exemplo, um projeto na fase inicial poderia ter uma ordem de magnitude aproximada
estimada na faixa de -25% a +75%. Mais tarde, conforme as informaes so
conhecidas, as estimativas podem estreitar para uma faixa de - 5% a +10%.
Fonte: PMBOK , 5. ed., p. 201 (Traduo livre pelo Conteudista).

Erro na
estimativa

Tempo no
Projeto

Os custos das atividades so reunidos em pacotes de trabalho. Em seguida, os

81

custos de pacotes de trabalho so reunidos nos custos das contas de controle e, por
fim, nos custos do projeto.

Fonte: PMBOK , 5. ed., p. 231 (Traduo livre pelo conteudista).

4.9.4 - Determinar Padres, Processos e Mtricas de Qualidade

Planejar o Gerenciamento da Qualidade o processo de identificao de
requisitos de qualidade e/ou padres para o projeto e seus produtos, e a
documentao de como o projeto vai demonstrar o cumprimento dos requisitos
pertinentes. A principal vantagem desse processo que ele fornece orientao e
direo de como a qualidade ser gerenciada e validada durante todo o projeto.
QUALIDADE DEFINIDA como O GRAU EM QUE O PROJETO CUMPRE OS
REQUISITOS, isto , a conformidade com os requerimentos e adequao ao uso que
se prope.

Conformidade: verificada pela equipe.

Adequao: verificada pelo cliente.

82

4.10 - Princpios da Qualidade em Gerenciamento de Projetos

W. Edwards Deming, um dos principais gurus da qualidade do mundo, define
qualidade como um grau previsvel de uniformidade e dependncia, baixo custo e
satisfao no mercado. A qualidade aquilo que o cliente necessita e quer, porm as
necessidades e desejos dos clientes esto sempre mudando, assim necessrio
redefinir especificaes constantemente. Os Pontos Chave da Teoria de Deming so
baseadas em:
Controle estatstico de qualidade: Permite alcanar a previso dos limites de
variao, baseando-se em um nmero de dados coletados em experincias
passadas.
Participao

do

trabalhador

no

processo

de

deciso:

tarefa

do

gerenciamento tornar as pessoas mais comprometidas com o trabalho

Limitao das fontes de fornecimento: A inspeo dos bens na entrada e sada
ineficiente e cara, a inspeo no melhora a qualidade e nem a garante,
assim desejvel haver um nmero limitado de fornecedores, assim existir
maior comprometimento no fornecimento e simplificao das finanas.
O Ciclo de Melhorias PDCA (Plan Do- Check Act) , ciclo de Shewhart ou Ciclo
de Deming, foi introduzido no Japo aps a guerra, idealizado por Shewhart, na
dcada de 20, foi Deming que na dcada de 50 o aplicou e o popularizou nas
organizaes.
O Ciclo PDCA uma ferramenta de qualidade que auxilia a tomada de decises
e a melhoria contnua. O ciclo PDCA muito utilizado no desenvolvimento dede planos
de ao e na melhoria de processos.
O ciclo comea pelo planejamento, em seguida a ao ou conjunto de aes
planejadas so executadas, checa-se se o que foi realizado estava de acordo com o
planejado, constantemente e repetidamente (ciclicamente), e toma-se uma ao para
eliminar ou ao menos mitigar defeitos no produto ou na execuo.
A sigla formada pelas iniciais:

P, de Plan Planejar estabelecer os objetivos e processos necessrios

para fornecer resultados de acordo com os requisitos e polticas pr-determinados.

D, de Do Fazer, executar implementar as aes necessrias.

83

C, de Check Checar, verificar monitorar e medir os processos e

produtos em relao s polticas, aos objetivos e aos requisitos estabelecidos e relatar

os resultados.

A, de Act Agir executar aes para promover continuamente a

melhoria dos processos.

O Cliclo SDCA utilizado com o objetivo de manter os ganhos alcanados aps

a elaborao de um projeto de melhoria de processos atravs do ciclo PDCA.
84

Para manter os ganhos alcanados necessrio padronizar as tarefas crticas,

sendo estas as que tero um impacto relevante e significante para a garantia do
resultado desejado.

SDCA S de (Standardize), pela padronizao das melhorias alcanadas

cumprindo os padres estabelecidos para o produto e o processo.
Somente aps a estabilidade que se pode comear a trabalhar em novas
melhorias, novamente e continuamente com o prximo ciclo PDCA.

85

Existem diversas ferramentas de qualidade que dependendo de cada tipo de

projeto podero ser utilizadas para garantir a qualidade planejada. Como regra geral
quando tratamos de qualidade em gerenciamento de projetos, temos que lembrar:
NO fornecer escopo extra (Gold Plating).
Satisfao do Cliente (entender o que realmente o cliente espera).
Preveno antes da inspeo.
Melhorias Contnuas.
Alto nvel de envolvimento da equipe.
Alta gerncia lidera e participa.
Defeito zero.

4.11 - Determinar Todos os Papis e Responsabilidades

o conjunto de atividades de identificao e documentao dos papis,
responsabilidades, habilidades necessrias, relatrios de relacionamento e criao de
um plano de gerenciamento de pessoal.

importante que fique claro:

Quem faz o qu?

Quem decide o qu?
Quais so as responsabilidades de cada um?
Quais as competncias necessrias?
Os papis devem estar claramente designados aos stakeholders apropriados.
interessante utilizar ferramentas, como Matriz de Responsabilidade e
Organograma do Projeto nessa definio.

86

Alm disso, fundamental que se crie um plano de gerenciamento de pessoal

que responda:

Plano de mobilizao do pessoal (De onde eles vm?).

Calendrio dos recursos (Quais pessoas estaro disponveis? Quando elas

sero utilizadas?).

Plano de liberao do pessoal.

Necessidade de treinamento do pessoal.

Reconhecimento e recompensas (O que so? Quais os critrios?).

Conformidade (Como o projeto cumprir normas relacionadas ao RH?).

Segurana (Quais polticas protegem os recursos?).

4.12 - Planejar as Comunicaes

Planejar Gerenciamento das Comunicaes o processo de desenvolvimento de
uma abordagem adequada e um plano de comunicaes do projeto com base em
informaes das partes interessadas, requisitos e ativos organizacionais. Geralmente,
os processos e atividades de comunicao ocupam 90% do tempo do Gerente do
Projeto, afeta todas as partes interessadas no projeto. A qualidade da comunicao
ator determinante de sucesso ou fracasso do projeto, isto , existe uma correlao
direta entre a capacidade de comunicao e o desempenho do projeto. Um conceito
bsico que as comunicaes devem ser eficientes (fornecendo apenas as
informaes necessrias) e eficazes (fornecendo informaes nos formatos certos, no
87

momento certo).
Quem deve receber quais informaes?
Quais so as reais necessidades de informao?
Qual informao necessria, de que tipo?
Em que formato e meio deve ser transmitida a informao?
Com que frequncia?
Qual o fluxo de informaes?
Que barreiras culturais devero ser consideradas nesse processo?
Qual barreira lingustica pode influenciar esse processo?
O uso da tcnica 5W 2H pode auxiliar na criao de uma boa matriz de
comunicao.
What? Qual informao
Why? Qual propsito
Who? Quem o responsvel e Quem precisa da informao
When? Quando
Where? Onde ocorrero ou sero armazenadas
How? Template, Procedimento, Best Practice
How Much? Qual periodicidade
DICA:
Outro aspecto importante que influencia diretamente no processo de
comunicao diz respeito execuo das reunies, j que o gerente de projetos passa
boa parte de seu tempo envolvido com elas. Algumas dicas... (ou melhor, REGRAS)
para uma boa reunio:
Defina um limite de tempo e cumpra-o.
Agende reunies recorrentes com antecedncia.
Rena-se com a equipe regularmente, mas no exagere na frequncia.
88

Tenha um objetivo para cada reunio.

Crie uma pauta com colaborao da equipe.
Distribua a pauta com antecedncia.
Limite-se pauta.
Informe as pessoas sobre suas responsabilidades com antecedncia.
Rena as pessoas certas.
Presida e lidere a reunio com um conjunto de regras.
Designe entregas e prazos para todas as tarefas de trabalho resultantes de
reunio.
Documente e publique as atas de reunio.

4.13 - Planejamento de Tratamento de Riscos

Planejar o Gerenciamento de Riscos o processo de definio sobre como
conduzir as atividades de gerenciamento de riscos de um projeto. A principal
vantagem desse processo garantir que o grau, tipo e visibilidade do gerenciamento
de risco so compatveis com os riscos e com a importncia do projeto para a
organizao.
Os riscos so identificados e gerenciados a partir da iniciao e so
continuamente atualizados ou acrescentados enquanto o projeto est em progresso.
Para isso, TODOS devem ser envolvidos na identificao. At 90% das ameaas
identificadas no processo de gerenciamento dos riscos podem ser eliminadas.
Identificar riscos o processo que determina quais riscos podem afetar o
projeto e documentar suas caractersticas.
Processo contnuo e interativo.
Os riscos devem ser validados.
Quanto mais cedo comear, melhor!
Quanto mais riscos identificados, melhor!
Seja especfico.
89

No tente trazer tudo de uma s vez.

Produza uma lista de riscos.
Um evento de risco algo IDENTIFICADO antecipadamente, que pode ou no
acontecer.
AMEAAS: O que pode dar errado ou ter impacto negativo no projeto.
OPORTUNIDADES: Impactos positivos no projeto.
Ex: Se oferecermos treinamento para melhorar a eficincia, o pacote de
trabalho XYZ pode terminar dois dias antes do esperado.
Uma das tcnicas mais utilizada no tratamento de riscos a anlise subjetiva
dos riscos identificados. O objetivo dessa tcnica analisar a probabilidade e impacto
do risco no projeto.
Probabilidade: Qual a chance de que o risco ocorra?
Por exemplo, imagine que em um projeto identificamos os riscos abaixo:
RISCO

PROBABILIDADE

Fornecedor

atrasar

IMPACTO

entrega do produto X
Mo de obra no treinada
para

uso

do

novo

equipamento
Sada do lder tcnico do
projeto
Paralizao da operao
por motivo de greve dos
colaboradores

90

4.13.1 - Como classificar que risco deve ter prioridade?

Aps a lista dos riscos, a equipe deve escolher qual risco tem a maior
probabilidade (sem considerar o impacto) de ocorrer, para esse risco ser definido
uma expresso subjetiva como MUITO ALTO. Cada um dos outros riscos devero ser
classificados comparativamente com o risco identificado como de maior probabilidade
de ocorrncia.
Como classificamos o risco com a maior probabilidade de ocorrncia como
MUITO ALTO podermos criar as faixas de ALTO, MEDIO, BAIXO e MUITO BAIXO, para
classificar os demais riscos comparativamente.
DICA: A definio das faixas como: ALTO, MEDIO, BAIXO ou MUITO ALTO,
ALTO, MEDIO, BAIXO e MUITO BAIXO so de deciso da empresa.
Por exemplo:
RISCO

PROBABILIDADE

Fornecedor atrasar a

MUITO ALTO

IMPACTO

entrega do produto X
Mo de obra no

MDIO

treinada para uso do

novo equipamento
Sada do lder tcnico do

BAIXO

projeto
Paralizao da operao

BAIXO

por motivo de greve dos

colaboradores

91

Da mesma forma como foi feito para a probabilidade, a equipe deve escolher
qual risco tem a maior impacto (sem considerar a probabilidade) de ocorrer, para esse
risco ser definido MUITO ALTO. Cada um dos outros riscos dever ser classificado
comparativamente com o risco identificado.

RISCO

PROBABILIDADE

IMPACTO

Fornecedor atrasar a

MUITO ALTO

ALTO

MDIO

MDIO

BAIXO

ALTO

BAIXO

MUITO ALTO

entrega do produto X
Mo de obra no
treinada para uso do
novo equipamento
Sada do lder tcnico do
projeto
Paralizao da operao
por motivo de greve dos
colaboradores

Agora vamos calcular EXPOSIO AO RISCO = PROBABILIDADE X

IMPACTO.
Observe que Muito Alto, Alto, Mdio, Baixo e Muito Baixo so subjetivos, assim
iremos atribuir pesos (valores numricos) classificao.

92

Ex:
Muito Alto: 0.9
Alto: 0.7
Mdio: 0.5
Baixo: 0.3
Muito Baixo: 0.1
EXPOSIO AO
RISCO

PROBABILIDADE(P)

IMPACTO(I)

RISCO (PxI)

Fornecedor

0.9

0.7

0.63

0.5

0.5

0.25

0.3

0.7

0.21

0.3

0.9

0.18

atrasar a
entrega do
produto X
Mo de obra
no treinada
para uso do
novo
equipamento
Sada do lder
tcnico do
projeto

Paralizao
da operao
por motivo de
greve dos
colaboradores

93

Aps o clculo de exposio ao risco, teremos um mapa de riscos que nos

ajudar a priorizar os esforos para tratamento de riscos.

Estratgias de Respostas (Riscos Negativos)

Eliminar: eliminar o risco, evitando-o totalmente. Por exemplo: eliminar

a atividade para eliminar o risco. Isto mesmo, NO fazer a atividade.

Transferir: passar a responsabilidade e o custo (parcial ou total) da

consequncia para um terceiro. Por exemplo: Fazer um seguro.

Mitigar: reduzir a probabilidade e/ou o impacto do risco, ao realizada

independente do risco ocorrer ou no. Por exemplo, modificar rotinas e procedimentos

para minimizar o risco ou o impacto.

Aceitar:
Passiva: no faz nada, apenas documenta e s trata se o risco ocorrer.
Ativa: cria uma reserva de contingncia (tempo, dinheiro, recurso, etc)
para ser utilizada caso o risco ocorra. Pode-se criar um plano de
contingncia para ser acionado caso o risco ocorra.

94

4.13.2 -Estratgias de Respostas (Riscos Positivos)

Explorar (o oposto de Eliminar): Adiciona trabalho ou modifica

oprojeto para garantir que a oportunidade ocorra.

Melhorar

(o

oposto

de

Mitigar):

Aumenta

possibilidade

(probabilidade) e/ou os impactos positivos do evento de risco.

Compartilhar: Alocar a propriedade da oportunidade a um terceiro

(criando uma parceria, uma equipe ou um empreendimento conjunto) que
seja mais capacitado para concretizar a oportunidade.

Aceitar: No fazer nada at o risco acontecer.

4.13.3 - Preparar os Documentos de Aquisies

Planejar Gerenciamento das Aquisies o processo de documentao das
decises de aquisio do projeto, especificando a abordagem e identificao de
potenciais vendedores. A principal vantagem desse processo que ele determina se
existir aquisio de apoio externo ao projeto e, se houver, o que, como, quanto ser
necessrio e quando adquirir.
Fonte: PMBOK 5. ed., p. 358 (Traduo livre pelo conteudista).
Realizar a anlise
de fazer ou
comprar

Criar uma
declarao de
trabalho

Determinar os
critrios de
seleo

4.13.4- Realizar a Anlise de Fazer ou Comprar

Um dos principais motivos de comprar reduzir o risco das restries do
projeto, mas pode ser uma deciso porque custam menos, habilidades internas
indisponveis, mais eficientes, focalizar em outros pacotes de trabalho. melhor fazer
se voc deseja manter o controle do trabalho, se envolve informaes ou
procedimentos proprietrios ou se voc deseja desenvolver as habilidades necessrias
durante a construo.

95

Criar uma declarao de trabalho para cada aquisio.

Uma declarao de trabalho a descrio dos produtos ou servios que sero
fornecidos para o projeto, determinando o escopo do trabalho realizado em cada
aquisio.

Deve ser feito com auxlio da Estrutura Analtica do Projeto (EAP).

Deve ser o mais clara, completa e concisa possvel, alm de descrever

todo o trabalho e todas as atividades que o fornecedor dever completar
(incluindo reunies, relatrios e todas as comunicaes).

4.13.5 - Determinar os Critrios de Seleo da Fonte

So includos no plano de gerenciamento de aquisies para proporcionar ao
fornecedor um entendimento das necessidades do comprador e ajudar o fornecedor a
decidir se deve ou no apresentar uma proposta para trabalho.
Podem incluir:

Nmero de anos na atividade.

Estabilidade Financeira.

Entendimento das Necessidades.

Capacidade Tcnica.

Qualidade de desempenho anterior.

Capacidade de Gerenciamento de Projetos.

E tudo que for relevante para auxiliar na seleo do fornecedor do trabalho.

Aps o desenvolvimento do plano de gerenciamento de projetos, esse plano

dever ser aprovado pelas principais partes interessadas. Aps a aprovao, feita a
reunio de partida do projeto (Reunio de Kick-Off), isto , o projeto entrar na fase
de execuo na qual o plano ser posto em ao!

96

Capitulo 5

5.1 - Execuo
Aps a aprovao dos planos de gerenciamento criados na fase de
planejamento, iniciamos a fase de execuo. Na fase de execuo, a equipe termina o
trabalho de acordo com os processos e procedimentos detalhados no plano de
gerenciamento de projetos, criados na fase de planejamento. Nestecaptulo, iremos
conhecer as boas prticas que devem ser realizadas durante a execuo do projeto.
Executar o Trabalho de Acordo com o Plano de Gerenciamento de Projetos
Na fase de execuo, o gerente de projetos integra todo o trabalho de forma
coordenada para executar o plano e produzir as entregas do projeto.
NOTA: Pressupe-se que, ao executar o projeto, o gerente de projetos
dediquetempo ao gerenciamento do cronograma, do oramento, dos riscos, da
qualidade e de todas outras reas de conhecimento.

Produzir Entregas do Produto (Escopo do Produto)

97

Durante a execuo, a tendncia natural que as entregas comecem a ser

realizadas. O processo Validar Escopo, do Monitoramento e Controle responsvel
pela formalizao da aceitao das entregas do projeto concludo.
Solicitar Mudanas e Implementar as Aprovadas
Durante a execuo do plano, riscos podem acontecer, atividades podem levar
mais tempo do que o previsto, variaes de custos e diversos outro motivos que iro
demandar mudanas. As mudanas sero analisadas (pelo Monitoramento eControle)
e podem ser aprovadas ou rejeitadas. importante que o gerente de projetos faa
com que as mudanas aprovadas sejam refletidas no plano de projeto e executadas
(de acordo com o novo plano).
Realizar a Garantia e Auditoria da Qualidade
Realizar a Garantia da Qualidade tem como principais objetivos:
Auditar e assegurar que os padres e objetivos do projeto sero atendidos.
Verificar se os PROCESSOS esto sendo seguidos, tanto os de gerenciamento
quanto os de desenvolvimento do produto. (NO tem foco na entrega e, sim,
nos processos!)
Deve responder s seguintes questes:
Estamos seguindo os procedimentos e processos conforme o planejado?
Podemos melhorar a forma como estamos realizando nosso trabalho?
Ferramentas e Tcnicas de Planejar a Qualidade / Realizar o Controle da
Qualidade

5.2 - Auditorias de Qualidade

Verifica se o projeto est sendo executado de acordo com as polticas e
procedimentos.
98

Pode ser realizado por auditores internos e/ou externos.

Confirma se as aes preventivas, corretivas e reparos de defeito aprovados
foram implementados.

5.4 -Anlise de Processos

Identificar possveis melhorias em tcnicas e organizacionais.
Examinar problemas, restries e atividades sem valor agregado.
Analisar a causa-raiz, determinando causas e definindo aes preventivas.
Gerenciar Pessoas e Equipes
Ao gerenciar pessoas e equipes, importante observar os seguintes pontos:
Mobilizar equipe do
projeto

Desenvolver e gerenciar a
equipe do projeto

Mobilizar Equipe do Projeto

Envolve:

Saber quais recursos esto pr-designados para o projeto e confirmar sua

disponibilidade.

Negociar para obter os melhores recursos possveis.

Contratar novos colaboradores.

Contratar recursos por intermdio do processo de contratao externo

organizao executora terceirizao.

Entender as possibilidades e problemas de usar equipes virtuais.

Gerenciar o risco dos recursos se tornarem indisponveis.

O resultado da mobilizao de equipe do projeto uma lista de equipe do

projeto com:

Designao do pessoal do projeto.

99

Calendrio de recursos.

Atualizao do plano de gerenciamento do projeto.

Desenvolver e Gerenciar a Equipe do Projeto

Lembre-se de que: Criar sistemas de reconhecimento e recompensa uma
importante funo de recursos humanos e esses sistemas so parte obrigatria do
gerenciamento de projetos. (Recompensa no necessariamente se resume a benefcio
financeiro, por exemplo: pode-se recompensar os envolvidos com a designao para
trabalhos e\ou equipes que o colaborador tenha maior interesse).
O gerente de projetos responsvel por melhorar as competncias dos
membros da equipe. Pode-se, por treinamento formal, informal, incluir em atividades
necessrias para aprimorar as competncias dos membros da equipe do projeto. Todo
custo de treinamento deve ser identificado na fase de planejamento e custo do
projeto. Devem existir papis e responsabilidades formais no projeto, que incluam:
auxiliar o gerente de projetos, responsabilidades em reunies e outros trabalhos no
relacionados s atividades.

5.5 - Atividades de Construo da Equipe

Pode ser desde reunies rpidas no projeto at treinamentos experienciais ao ar
livre com facilitadores profissionais. As atividades de construo estimulam a
comunicao para desenvolvimento da confiana e estabelecimento de boas relaes
de trabalho. O desenvolvimento da equipe uma cincia, h at estgios formalmente
identificados de formao e desenvolvimento de equipes.

100

Segundo Bruce Tuckman, a formao de um time geralmente passa por cinco

estgios diferentes:

Esses estgios se iniciam com a formao (forming) na qual os membros do

time comeam a trabalhar juntos, passam para a fase de conflitos (storming), na qual
os membros comeam a aprender a trabalhar juntos, aprendem seus papis e formas
de relacionamentos (Norming). Depois dessa fase, tornam-se um time de alta
performance no qual o trabalho do time e de seus membros eficaz e eficiente. Por
fim, existe a fase de perda de performance (Adjourning), que pode ocorrer por
divergncias, troca de membros, etc.

101

Observe que o comportamento do time e de sua liderana deve ser diferente

em cada fase:
Formao (Forming): Fase de direcionamento.
Membros do time: Baixa competncia, alto comprometimento.
Liderana: Muito direcionamento e baixo suporte individual e ao time.
Conflitos (Storming): Quando o time entra nessa fase, geralmente com
muitos desacordos e conflitos, o lder precisa assumir um papel de Coaching ajudando
na resoluo dos conflitos entre os membros do time sem desgastar as relaes.
Observe que ajudar NO RESOLVER POR ELES. Outra considerao que o conflito
no necessariamente danoso, o conflito algo natural e geralmente surge da
divergncia de idias, assim podem gerar boas idias.
Membros do time: Baixa ou alguma competncia, baixo comprometimento.
Liderana: Muito direcionamento e muito suporte individual e ao time.
Normalidade (Norming): Na fase de normalizao, as regras essenciais
detrabalho e relacionamento surgem para ajudar na auto-organizao, isso no
significa que o lder deve apenas supervisionar, na verdade preciso que ele atue
102

como suporte. Nessa fase, continuam surgindo conflitos e ele precisa suportar as
regras definidas pelo time anteriormente. muito interessante que o lder envolva o
time delegando alguns objetivos para este, como todos devem testar suas produes
ou o time responsvel por monitorar a velocidade de andamento do projeto, e
neste momento que devem surgir as retrospectivas para inspeo e adaptao (e
evoluo) dos processos e relacionamentos.
Membros do time: Moderado ou alta competncia, comprometimentos
variveis.
Liderana: Baixo direcionamento e baixo suporte individual e ao time.
Performance (Performing): Essa fase no dura para sempre e muitos times
NUNCA chegam a esse momento. Muitas vezes, os times existem variando entre as
fases de conflitos (storming) e normalidade (Norming). Na fase de performance, os
times so autnomos, detentores de poder, auto gerenciveis e auto policiados. A
liderana atua mais como direcionando para os objetivos estratgicos do projeto do
que direcionando aes do time, a fase na qual a liderana deve delegar as
responsabilidades para o time.
Membros do Time: Alta competncia, alto comprometimento.
Liderana: Baixo direcionamento e baixo suporte individual e ao time.

5.5.1 - Conflito
Os conflitos so inevitveis em um ambiente de projeto. As origens dos
conflitos podem incluir recursos escassos, prioridades de cronograma e estilos de
trabalho pessoais. As sete origens de conflitos em ordem de frequncia:
1) Cronogramas.
2) Prioridades do Projeto.
103

3) Recursos.
4) Opinies Tcnicas.
5) Procedimentos Administrativos.
6) Custo.
7) Personalidade.
Um gerenciamento de conflitos bem-sucedido resulta em maior produtividade e
em relacionamento de trabalho positivos.
O conflito natural e fora uma busca de alternativas.
O conflito uma questo de equipe.
A abertura resolve conflitos.
A resoluo de conflitos deve se concentrar em questes e no em
personalidade.
A resoluo de conflitos deve se concentrar no presente e no no passado.
O gerente de projeto pode evitar conflitos por meio das seguintes aes:
Informar (e relembrar) equipe:
Exatamente para onde o projeto est direcionado.
As restries e objetivo do projeto.
O contedo do Termo de Abertura do Projeto.
Mudanas.
Decises importantes.
Da designao do trabalho com clareza e sem responsabilidades sobrepostas.
Tornar as tarefas desafiadoras (sempre que possvel).
Seguir as boas prticas de gerenciamento de projetos.

104

5.6 - Selecionar Fornecedores

Na fase de planejamento, fizemos a anlise Fazer ou Comprar (Make or
Buy), criamos a Declarao de Trabalho, selecionamos o Tipo de Contrato,
criamos os critrios de Seleo de Fontes, enviamos os convites para os
possveis fornecedores e esclarecemos suas dvidas sobre o trabalho. Na execuo,
chega o momento da assinatura do contrato. importante lembrar que o contrato
no apenas um instrumento jurdico, ele deve conter TODO o trabalho acertado
entre contratante e fornecedor, assim importante que o gerente de projetos participe
da confeco desse documento.
Lembre-se de que o contrato substitui qualquer acordo, verbal, por e-mail,
acertado em reunio... Assim, tudo acertado previamente dever fazer parte do
contrato.
O contrato um documento legal como obrigaes, deveres e direitos entre
duas partes. Podem incluir, mas no se limitam :
Declarao de obras ou entrega.
Linha base de tempo.
Relatrios de desempenho.
Perodo de execuo.
Papis de e responsabilidades.
Preos.
Condies de pagamento.
Local de entrega.
Critrios de inspeo e aceitao.
Garantia.
Suporte ao Produto.
Limitao de responsabilidade.
Taxas, reteno e penalidades.
Incentivos.
Ttulos de seguro e de desempenho.
105

Subcontrataes subordinadas aprovao.

Alterao do tratamento de solicitao.
Mecanismos de resoluo de prazo e de clusula e alternativa de litgios.
5.7 - Comunicar-se!
Gerenciar Partes Interessadas o processo de comunicar e trabalhar com as
partes interessadas para atender s suas necessidades/expectativas, abordar questes
que ocorram e promover o engajamento das partes interessadas adequado nas
atividades ao longo do ciclo de vida do projeto.
O gerente de projetos deve:
Agir proativamente sobre as EXPECTATIVAS das partes interessadas utilizando

estratgias elaboradas no plano.

Usar o registro de questes para mostrar que suas necessidades esto sendo

atendidas.
Evitar trabalhar na percepo e na subjetividade. As expectativas devem ser

registradas (e acompanhadas, mesmo que tenha um resultado negativo).

da

questo

Questo

Data

de

Identificao

Levantada

Pessoa

Prazo para

por

designa

resoluo

Situao

Data da

Soluo

Soluo

da

Abordar as preocupaes que ainda no se tornaram questes, geralmente

relacionadas com preveno de futuros problemas. Essas preocupaes
precisam ser reveladas e analisadas e os riscos serem avaliados.
Esclarecer e solucionar as questes que foram identificadas. A soluo pode
106

resultar em uma solicitao de mudana ou pode ser tratada fora do projeto

como, por exemplo, ser adiada para outro projeto ou fase, ou transferida
para outra entidade organizacional.
REGRA DE OURO: NUNCA ignore e nem se DISTANCIE das partes
interessadas!

107

Captulo 6

6.1 Monitoramento e Controle e a fase de Encerramento

Segundo o Guia PMBOK , monitorar e controlar o trabalho do projeto
o processo de acompanhamento, reviso e ajuste do progresso para atender
aos objetivos de desempenho definidos no plano de gerenciamento. muito
importante monitorar e controlar o trabalho do projeto, principalmente, para
avaliar o estado do seu projeto durante a sua realizao, identificar reas que
exigem ateno especial e garantir a qualidade do projeto atravs do
monitoramento e aes de controle. Nestecaptulo, iremos conhecer as
principais boas prticas associadas fases de: Monitoramento e Controle e
Encerramento do Projeto.

6.2 - Monitoramento e Controle

O Monitoramento e Controle (representado pela linha na cor vermelha)

ocorrem desde a iniciao at o encerramento do projeto. Os resultados desse
processo no projeto so solicitaes de mudanas (incluindo aes corretivas,
aes preventivas e reparos de defeitos), assim como atualizaes no plano de
gerenciamento nos documentos do projeto.

108

Monitorar e Controlar significa medir em relao ao plano de

gerenciamento do projeto.

Medir o Desempenho em Relao Linha de Base da Medio de

Desempenho e Outras Mtricas Determinadas pelo Gerente de Projetos
Durante a fase de planejamento, so geradas trs linhas de base:
Linha de Base de Escopo (Formada pelos documentos: Declarao de
Escopo,Estrutura Analtica do Projeto (EAP) e Dicionrio da EAP) Essa linha
representa todo o escopo que ser produzido no projeto.
Linha de Base de Tempo (Formada pelo cronograma)Essa linha
apresenta asatividades que sero realizadas, assim como a data de incio,
durao e data final de cada atividade.
Linha de Base de Custo (Formada pelo oramento)Essa linha
representa ooramento do projeto aprovado pelo seu patrocinador no trmino
do planejamento.
Durante a execuo do projeto, o gerente dever acompanhar
(monitorar) o andamento das atividades de acordo com o plano, desvios no
plano podero gerar novos ajustes e mudanas. Observe que existem outros
109

documentos que iro auxiliar a execuo do projeto e que tambm devero ser
monitorados e controlados pelo gerente de projetos (e que tambm podero
provocar mudanas).
6.3 - Analisar Variaes e Gerenciar as Mudanas
Realizar Controle Integrado de Mudanas o conjunto de processos e
elementos necessrios para identificar, avaliar, julgar, documentar e gerenciar
todas as mudanas no projeto. O foco PRINCIPAL do Controle Integrado de
Mudanas
ANALISAR O IMPACTO DE CADA MUDANA EM TODAS AS
RESTRIES DO PROJETO. Para o Controle Integrado de Mudanas,
necessrio responder:
A mudana benfica para o projeto?
A mudana necessria para o projeto?
Podem os objetivos do projeto mudar por causa da mudana?
Qual o impacto no prazo, custo, qualidade, escopo?
Quem tem autonomia para aprovar a mudana?
NO SE ESQUEA!
TODAS as mudanas devem ser documentadas.
Assegurar que as mudanas estejam refletidas no Plano do Projeto.
Nveis apropriados de reviso e aprovao de mudanas foram
definidos no INCIO do planejamento.
Solicitaes de mudana devem seguir um procedimento acordado
previamente.
Solicitao de mudana analisada e aprovada ou rejeitada.
A formalidade da solicitao de mudana pode variar para cada
projeto.

110

NOTA: Com a aprovao da mudana, o gerente de projetos deve

atualizar os planos de projeto afetados, ajustando as verses de documentao
(controle de configuraes). Tambm necessrio que sejam analisadas
novamente as previses e reservas.

6.4 -Validar e Controlar o Escopo

Validar Escopo o processo de formalizao da aceitao das entregas
do projeto concludo.
A principal vantagem desse processo que ele traz objetividade ao
processo de aceitao e aumenta a aceitao das mudanas do produto final,
servio ou resultado, validando cada entrega.
Fonte: PMBOK , 5. ed., p.133. (Traduo livre do conteudista).
Controlar o Escopo envolve medir o desempenho dos escopos do
produto e do projeto e gerenciar mudanas nas linhas de base do
escopo.Tambm usado para gerenciar as mudanas reais quando essas
ocorrerem e integrado aos outros processos de controle. As mudanas no
controladas so freqentemente chamadas de scope creep.
Fonte: PMBOK , 5. ed., p.136. (Traduo livre do conteudista).

6.5 - Controlar Cronograma

Os esforos de controle no so apenas os da medio, eles envolvem
inclusive a tomada de aes corretivas ou preventivas durante todo o ciclo de
vida do projeto para mant-lo alinhado ao plano do projeto.
O controle do cronograma est relacionado a:
Determinao da situao atual do cronograma do projeto.
111

Influncia nos fatores que criam mudanas no cronograma.

Gerenciamento das mudanas reais conforme ocorrem.

6.6 - Controlar Custos

O controle de custos do projeto inclui:
Influenciar os fatores que criam mudanas na linha de base de custos
autorizada.
Assegurar que todas as solicitaes de mudana sejam feitas de
maneira oportuna.
Assegurar que os gastos de custo no excedam os recursos financeiros
autorizados, por perodo e total do projeto.
Monitorar o desempenho de custos para isolar e entender as variaes
a partir da linha de base de custos.
Gerenciar mudanas reais conforme ocorrem.
Monitorar o desempenho do trabalho em relao aos recursos
financeiros gastos.
Prevenir que mudanas no aprovadas sejam includas no relato de
custos ou no uso dos recursos.
Informar s partes interessadas apropriadas a respeito de mudanas
aprovadas e custos associados.
Agir para manter os excessos de custos no previstos dentro de limites
aceitveis.
Observe que algumas anlises isoladas no refletem a real situao do
projeto. Por exemplo:
(...) estamos dentro do prazo (...)
As obras de duplicao da BR-060 sero inauguradas completamente
112

at o finaldo ano. O Departamento Nacional de Infraestrutura e Transportes

(Dnit) garantiu a entrega do trecho entre Jata e Rio Verde.

Fonte:
Disponvel
em:<http://tribunadoplanalto.com.br/index.php?option=com_content&view=art
icle&id

=16893:obras-em-goias-serao-entregues-dentro-do-

prazo&catid=132:economia>. Acesso em: 19 jul. 2014.

No diz se o escopo produzido est de acordo com o plano e nem se
est dentro do oramento. Veja que a anlise de apenas uma das dimenses de
acompanhamento do projeto pode causar uma falsa percepo. Imagine que a
obra esteja no prazo, mas com o oramento acima do previsto em 500%. Outro
dado importante que se o prazo de 3 anos, posso no ter feito
absolutamente nada nos dois primeiros anos e ainda estar no prazo, concorda?
(Ainda no o final do terceiro ano, logo estamos no prazo). Veja que essas
situaes podem ter distores sob outras perspectivas.

(...) estamos dentro do oramento (...)

Ser que o projeto est no prazo? Ser que o escopo est evoluindo de
acordo com o planejado?
(...) estamos dentro do escopo planejado (...)
Ser que o projeto est no prazo para entregar o escopo? Ser que o
custo est de acordo com planejado para entregar o escopo?
Uma das formas mais eficientes de acompanhar a evoluo do projeto
113

utilizando a tcnica de valor agregado (VA). Essa tcnica usada para medir o
desempenho do projeto com relao s linhas de base do escopo, cronograma
e do custo. As medies resultantes da anlise do valor agregado indicam se
houve algum desvio em potencial em relao s linhas de base do escopo,
cronograma e custos.

6.7 - Monitorar e Controlar Riscos

o processo de implementao dos planos de respostas aos riscos,
acompanhamento dos riscos identificados, monitoramento dos riscos residuais,
indicao de novos riscos e avaliao da eficcia do processo de riscos durante
todo o projeto. Outras finalidades do processo Monitorar e Controlar Riscos so
determinar se:
As premissas ainda so vlidas.
A anlise mostra um risco avaliado que foi modificado ou que pode ser
desativado.
As polticas e os procedimentos de gerenciamento dos riscos esto
sendo seguidos.
As reservas de contingncia de custo ou cronograma devem ser
modificadas de acordo com a avaliao atual dos riscos.

6.8 - Administrar Aquisies

Envolve gerenciar o relacionamento entre o comprador e o fornecedor,
alm de assegurar que ambas as partes ajam conforme estipulado no contrato.
Contratos em que o gerente de projetos deve ficar atento, por tipo de
contrato:

114

6.8.1 - Contrato de Preo Fixo

Estar atento reduo de escopo por parte do fornecedor.
Estar atento reduo da qualidade por parte do fornecedor.
Verificar se os custos do fornecedor so custos reais que foram
incorridos e no apenas custos futuros (a menos que haja um acordo
especificando o contrrio). Fique atento s ordens de mudana com
preos excessivos.
Procurar identificar equvocos no entendimento do escopo.

6.8.2 - Contrato por Tempo e Material

Orientar o fornecedor no dia a dia.
Tentar obter entregas concretas.
Assegurar-se de que a durao do projeto no seja prorrogada.
Assegurar-se de que o nmero de horas dedicadas ao trabalho seja
razovel.
Procurar identificar situaes em que outra forma de contrato faa
sentido.

6.8.3 - Contrato de Custos Reembolsveis

Auditar todas as faturas.
Assegurar-se de que todos os custos sejam cobrveis e aplicveis ao
projeto.
Verificar se o trabalho do fornecedor est progredindo com eficincia.
Estar atento ao acrscimo, por parte do fornecedor, de recursos que
no agregam valor e nem realizam trabalho.
Estar atento a desvios de recursos em relao ao proposto
originalmente.
115

Estar atento s cobranas do fornecedor que no constavam no plano

original.
Estimar novamente o custo do projeto.

6.9 - Encerramento
Encerrar Projeto ou Fase
Uma vez que o processo de controle verifica que o produto atende aos
requisitos, a vez de formalizar essa entrega do produto e do projeto. No
encerramento, feita:
Entrega oficial do produto, servio ou resultado final;
Emisso de um documento formal de aceite;
Passagem do produto do projeto para os processos operacionais;
registro final das lies aprendidas (Sem lies aprendidas no existe
melhoria contnua !);
Atualizao do pool de recursos refletindo as novas habilidades e
aumentando a proficincia;
Encerramento das aquisies por confirmao atravs de documento
formal que informa que o contrato terminou;
Arquivamento do acervo de documentos do projeto.
Nas lies aprendidas, devemos classificar e armazenar todo o acervo
do projeto.

116

Capitulo 7

7.1 - Introduo ao Gerenciamento de Projetos Orientado a Valor

O mercado est cada dia mais complexo, no possvel tratar todos os
projetos da mesma forma simplesmente repetindo boas prticas (projetos
orientados a planos) para o sucesso do projeto. O dinamismo e a velocidade
com que a informao e o conhecimento circulam fizeram com que o ambiente
corporativo, onde os projetos ocorrem, tornasse-se instvel, logo, complexo.

Como foi apresentado no captulo 1, alguns projetos esto sujeitos a

mudanas durante a sua execuo, dependendo das mudanas, todo o plano
precisar ser refeito. Essas mudanas geralmente ocorrem por no termos o
escopo do projeto totalmente definido, elevado nmero de premissas (que
podem ser verdadeiras ou falsas) ou por fatores externos ao projeto que
podero

alterar

seu objetivo

forma de

conduo. Neste

captulo,

conheceremos algumas tcnicas de agilidade utilizadas quando gerenciamos

projetos complexos, isto , projetos orientados a valor. Isso no significa que
devemos excluir todas as ferramentas e tcnicas aprendidas em projetos
orientados a planos, mas sim combin-las com as tcnicas que aprenderemos
neste captulo.
O gerenciamento gil diferente do gerenciamento rpido de solues.
A agilidade est em garantir a qualidade e o mtodo de se adaptar e solucionar
problemas durante o desenvolvimento do produto.

117

7.2 - Princpios geis Originrios do Setor Industrial Tcnica Lean

O Lean (em portugus significa enxuto) envolve as pessoas, utilizando
um quadro de princpios, sistemas e ferramentas, para integrar, alinhar e
sincronizar a organizao do projeto com o negcio para fornecer informao
de qualidade e sistemas eficazes, permitindo a manuteno da melhoria
contnua e inovao de processos. Lean tem dois aspectos: Para o exterior,
apoiando a melhoria contnua dos processos de negcio, e para dentro
(interna), melhorando o desempenho dos processos e servios. O sistema Lean
de produo foi desenvolvido pela Toyota e tem um princpio claro e simples:

7.2.1 - Reduzir o Desperdcio

Desperdcio tudo o que no ir gerar valor para o cliente. Esse conceito
foi incorporado em alguns mtodos geis e considera como desperdcio
documentao excessiva, tempo de desenvolvimento parado por falta de
informaes (ou falta de clareza), ou requisitos e funcionalidades em produtos
/servios no solicitados.
Tipos de Desperdcios:
Mura: Desperdcio por tentar prever possveis necessidades futuras.
Evitara mura significa reduzir ao mximo o inventrio, isto , as partes
paradas no meio do processo, comeando ou no terminando.
Muri: Desperdcios que podem ser evitados por planejamento.
Nessacategoria

enquadra-se

excesso

de

burocracia

ou

de

complexidade em processo de produo.

Muda: Desperdcios do dia a dia, criados por uma cultura anterior
detrabalho.
Superproduo.
Transporte desnecessrio.
Inventrio.
118

Locomoo.
Defeitos.
Super processamento.
Espera.
7.3 -Tcnica KanBan

FIM
Sada
(+1 Tquete)

INICIO
Entrada
(-1 Tquete)

Visitante
Em Tquio, no ms de abril, os Jardins do Oriente ficam repletos de
visitantes e turistas que vo l para desfrutar da tranquilidade do parque e
beleza da sakura (flor da cerejeira). Ao entrar no parque, cada visitante recebe
um Admission Ticket, um pequeno carto de plstico sem identificao ou
cobrana que devolvido na sada do parque. O objetivo desse carto
controlar o fluxo de visitantes. Imagine que temos 50 cartes, cada visitante
recebe um ao entrar e o devolve ao sair, se no existirem mais cartes no
momento da entrada, o acesso fica bloqueado at os cartes serem devolvidos
na sada. Assim, o controle de pessoas visitando o jardim garantido de
maneira simples e eficiente.
Se o tquete no tem nenhuma identificao, no registrado e no
utilizado para cobrana, para que ele existe?
Para controlar o WIP (Work in Progress Trabalho em progresso). No
exemplo do Jardim Imperial, cada pessoa representa uma atividade que a
equipe

(o

Jardim)

consegue

processar,

mais

pessoas

(atividades)

comprometeriam a qualidade do jardim (do processamento). Para o KanBan,

119

mais importante que comear novas atividades entregar, isto , terminar as

atividades que esto em andamento.

Para esse controle, a tcnica utiliza um quadro conhecido como Quadro

KanBan. Linha de Produo = sequncia de passos para produzir algo.
Cada estao de trabalho faz sua parte sem considerar fases anteriores e
posteriores. O Kanban permite ver com mais clareza o acmulo de inventrio
Observe, h um limite de inventrio claramente definido (no caso da
imagem, cada etapa tem um controle de WIP de duas atividades). Assim,
controlamos melhor os gargalos da produo e terminamos mais rapidamente
as atividades. Imagine que cada um desses passos seja um processo para o
atendimento de novos candidatos:
120

Temos apenas dois profissionais para cada uma das etapas. Assim,
apenas dois candidatos poderiam ser tratados simultaneamente, sem criar
gargalos. Esta viso ajuda a melhorar o fluxo de produo e identificar gargalos
(e assim dimensionar melhor as equipes para cada etapa).
O KanBan uma tcnica simples, poderosa e fcil de ser utilizada.

7.4 - Tcnica Systems Thinking

Aps reduzir o desperdcio, temos uma melhor viso de nossa linha de
produo (trabalhos redundantes, trabalhos desnecessrios...). Quantas vezes
no vimos consagrados processos de produo atrapalhando uma equipe em
vez de ajud-la? Todas as fases do seu processo so realmente necessrias
para o sucesso final? Essa a reflexo do Systems Thinking. Observe que no
nada mais do que implementarmos, de maneira crtica, tcnicas de melhoria
contnia. SystemsThinking pensar e repensar durante todo o andamento do
projeto no que poderia ser melhorado no prprio processo de desenvolvimento
e nas interaes entre as pessoas envolvidas.

121

7.5 -Tcnica Work Cells

No possvel pensar em encontrar melhorias no processo se cada
indivduo est focado exclusivamente em uma tarefa na qual especialista. A
agilidade entende que os membros do time no devem ser super especialistas
em um assunto especfico, isto , no podem se limitar apenas ao
conhecimento em sua etapa. Devem conhecer todas elas e saber executar
algumas delas.
Cada membro da equipe uma Work Cell: pessoa capaz de trabalhar no
projeto como um todo, em algumas ou todas as suas partes. O conhecimento
mais amplo sobre o projeto incentivado, j que, ao conhecer o todo, mais
interessantes sero as crticas para melhoria. Esse conceito tambm
conhecido como profissionais T Shaped.

7.6 - Princpios geis Originrios do Setor de Tecnologia da

Informao
A agilidade ganhou muita importncia no segmento de desenvolvimento
de software aps mtodos tradicionais de desenvolvimento, como o Mtodo
Cascata, mostrarem-se ineficientes na gerncia de projetos de software. Os
conceitos e princpios geis podem e devem ser utilizados em diversos projetos
que lidam com profissionais de conhecimento e no apenas aos projetos de TI.
Os gerentes bem-sucedidos em projetos complexos (de software)
criaram o que conhecido como Manifesto gil.
Estamos descobrindo maneiras melhores de desenvolver software,
fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho,
passamos a valorizar:
Indivduos

interao

entre

eles,

mais que processos e

122

ferramentas.
Software em funcionamento, mais que documentao abrangente.
Colaborao com o cliente, mais que negociao de contratos.
Responder a mudanas, mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os
itens esquerda.
Alm do Manifesto gil, que serve como norteador de aes e deciso
para a equipe, eles desenvolveram uma srie de princpios agilistas
apresentados abaixo:

7.6.1 - Princpios geis

Podemos

fazer

troca

da

palavra

software

por

produtos/servios,mantendo o ideal por trs de cada um destes princpios.

Nossa maior prioridade satisfazer o cliente, atravs da entrega
adiantada e contnua de software de valor.
Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento.
Processos geis se adquam a mudanas, para que o cliente possa
tirar vantagens competitivas.
Entregar software funcionando com freqncia, na escala de semanas
at meses, com preferncia aos perodos mais curtos.
Pessoas relacionadas a negcios e desenvolvedores devem trabalhar
em conjunto e diariamente, durante todo o curso do projeto.
Construir projetos ao redor de indivduos motivados, dando a eles o
ambiente e suporte necessrio, e confiar que faro seu trabalho.
O mtodo mais eficiente e eficaz de transmitir informaes para, e por
dentro de um time de desenvolvimento, atravs de uma conversa
cara a cara.
Software funcional a medida primria de progresso.
Processos

geis

promovem

um

ambiente

sustentvel.

Os
123

patrocinadores, desenvolvedores e usurios devem ser capazes de

manter, indefinidamente, passos constantes.
A tcnica mais conhecida em gerenciamento de projetos geis
atualmente o SCRUM.
7.7 - SCRUM
Scrum fundamentado nas teorias empricas de controle de processo,
ou empirismo. O empirismo afirma que o conhecimento

vem

da

experincia e detomada de decises baseadas no que conhecido.

OScrum emprega uma abordagem iterativa e incremental para aperfeioar a
previsibilidade e o controle de riscos. O Scrum se apia em trs pilares:
Transparncia

Aspectos significativos do processo devem estar visveis aos

responsveis pelos resultados. Essa transparncia requer aspectos definidos por

um padro comum para que os observadores compartilhem um mesmo
entendimento do que est sendo visto.
Inspeo

Os usurios Scrum devem, freqentemente, inspecionar os

artefatos Scrum e o progresso em direo ao objetivo, para detectar

indesejveis variaes. Essa inspeo no deve, no entanto, ser to frequente
que atrapalhe a prpria execuo das tarefas. As inspees so mais benficas
quando realizadas de forma diligente por inspetores especializados no trabalho
a se verificar.
Adaptao

Se um inspetor determina que um ou mais aspectos de um

124

processo desviou para fora dos limites aceitveis, e que o produto resultado
ser inaceitvel, o processo ou o material sendo produzido deve ser ajustado. O
ajuste deve ser realizado o mais breve possvel para minimizar mais desvios.
Resumidamente, podemos definir o Scrum como um framework
INCOMPLETO*, o qual as pessoas podem resolver problemas complexos e
adaptveis, enquanto entregam produtos de forma produtiva, criativa e com o
maior valor possvel!
*Incompleto porque ele precisar de tcnicas e ferramentas especficas
da atividade fim e da equipe que est atuando no projeto. O Scrum identifica
trs personagens que compem o time Scrum. So eles: Product Owner, a
Equipe de Desenvolvimento e o Scrum Master.
Times Scrum so auto-organizveis e multifuncionais. Equipes autoorganizveis escolhem qual a melhor forma para completarem seu trabalho, em
vez de serem dirigidos por outros de fora da equipe.
Equipes multifuncionais possuem todas as competncias necessrias
para completar o trabalho sem depender de outros que no fazem parte da
equipe.

O Product Owner responsvel por decidir e esclarecer quaisquer

dvidas referentes ao negcio. Ele representa o cliente e deve ter autonomia de
deciso sobre qualquer assunto referente ao negcio. (Decide o que vai ser
125

produzido). A Equipe de Desenvolvimento (Dev. Team) responsvel por

decidir qual a melhor forma de desenvolver o que o Product Owner solicitou.
(Decide como produzir). O Scrum Master responsvel pela melhoria contnua
dos processos, eventos e artefatos do Scrum para o time.
7.7.1 - Eventos e Artefatos Scrum

Backlog do Produto: Todas as funcionalidades de negcio que o novo

produto/servio precisar atender. Como um dos princpios da agilidade a
incerteza e a boa aceitao a mudanas, esse backlog poder ser ajustado
(novas funcionalidades podero surgir e outras deixarem de existir) pelo
Product Owner para atender s novas necessidades do produto/servio.
Sprint Backlog: Funcionalidades escolhidas para serem desenvolvidas
durante aSprint. O corao do Scrum a Sprint, um time-box de um ms ou
menos,durante o qual um Pronto, verso incremental potencialmente
utilizvel do produto, criado. Sprints tm duraes coerentes em todo o
esforo de desenvolvimento. Uma nova Sprint inicia imediatamente aps a
concluso da Sprint anterior. Em cada Sprint, temos a definio do que para
ser construdo,um plano projetado e flexvel que ir guiar a construo, o
trabalho e o resultado do produto.
As Sprints so compostas por:
uma reunio de planejamento da Sprint;
126

reunies dirias (Daily Scrum);

trabalho de desenvolvimento;
uma reviso da Sprint (Review);
restrospectiva da Sprint (Retrospective).
importante observar que, durante a Sprint, no so feitas mudanas
que podem afetar o objetivo da Sprint, a composio da Equipe de
Desenvolvimento permanece constante. As metas de qualidade no
devem diminuir em funo de prazo e entrega e o escopo pode ser
esclarecido e renegociado entre o Product Owner e a Equipe de
Desenvolvimento a qualquer tempo (Isto , NUNCA se distancie do
cliente P.O.).
7.7.2 - Planning Meeting (Reunio de Planejamento)
O Planning Meeting o time-boxed e deve ocupar no mais de 5% do
tempo do Sprint, se o Sprint de 2 semanas, essa reunio no deve consumir
mais de 4 horas. O objetivo definir as histrias que sero feitas no Sprint que
acaba de comear:
} Apresentao da Histria
O P.O. apresenta a viso de negcio dos itens mais prioritrios do
Product Backlog aos desenvolvedores.
} Dvidas do Negcio
Os desenvolvedores tiram suas dvidas sobre as histrias, em termos
da lgica de negcio no entram em questes tcnicas
} Opcional
O Product Owner deve sair da sala, caso permanea ele no deve
emitir opinies para o prximo passo

O qu...
127

} Pontuao
Os desenvolvedores do pontos cada uma das histrias, neste
momento se considera a parte tcnica. (Ex: Pontuao por Planning Poker).
Tem como objetivo estimar o esforo para desenvolver o que foi solicitado na
Sprint. Esta informao utilizada no planejamento de novas Sprints
considerando a capacidade histrica do time desenvolver solues em cada
Sprint.

} Sprint Backlog
Os desenvolvedores apresentam a pontuao para o P.O. e baseado
na pontuao e na capacidade de atendimento por pontos por Sprint da equipe
escolhe as histrias mais prioritrias (negociando com os desenvolvedores, se
necessrio).

} Definio de Metas
}
Se no tiver sido definida durante o processo, o P.O. define a meta do
Sprint.

Como...

O qu...
Daily scrum (Reunio Diria)
Reunies dirias de, no mximo, 15 minutos. Reunio breve e informal,
que deve acontecer sempre no mesmo horrio e local combinado e dela
participam apenas o TIME.

128

Funcionamento:
No horrio combinado, cada membro vai ao local combinado.
Todos de P, respondem s seguintes perguntas:
O que fiz desde o ltimo Scrum?
O que farei at o prximo Scrum?
Quais problemas esto me atrapalhando?
Se algum tiver uma sugesto breve, identifica-se para que, aps o daily
scrum, os interessados se renam para resolver o problema juntos. Observe
que no uma reunio de prestao de contas para o Scrum Master e, sim,
uma forma de todos do time saberem o que est acontecendo no projeto.

7.7.3 - Review (Reviso)

A Reviso da Sprint executada no final da Sprint para inspecionar o
incremento e adaptar o Backlog do Produto, se necessrio. Durante a reunio
de Reviso da Sprint, o Time Scrum e as partes interessadas colaboram sobre o
que foi feito na Sprint. Com base nisso e em qualquer mudana no Backlog do
Produto durante a Sprint, os participantes colaboram nas prximas coisas que
precisam ser prontas.
Essa uma reunio informal, e a apresentao do incremento destina-se
a motivar, obter comentrios e promover a colaborao.
Essa reunio tem um time-boxed de 2.5% do Sprint. Por exemplo, uma
Sprint de duas semanas tem Reunies de Reviso de duas horas.
A Reunio de Reviso inclui os seguintes elementos:
O Product Owner identifica o que foi Pronto e o que no foi
Pronto;
129

A Equipe de Desenvolvimento discute o que foi bem durante a Sprint,

quais problemas ocorreram dentro da Sprint e como esses problemas
foram resolvidos;
A Equipe de Desenvolvimento demonstra o trabalho que est Pronto
e responde s questes sobre o incremento;
O Product Owner discute o Backlog do Produto tal como est. Ele (ou
ela) projeta as provveis datas de concluso baseado no progresso
at a data;
O grupo todo colabora sobre o que fazer a seguir. assim que a
Reunio de Reviso da Sprint fornece valiosas entradas para a
Reunio de Planejamento da prxima Sprint.
O resultado da Reunio de Reviso da Sprint um Backlog do Produto
revisado que define o provvel Backlog do Produto para a prxima Sprint.
Backlog doProduto pode tambm ser ajustado completamente para atender s
novas oportunidades.

7.7.4 - Retrospective (Retrospectiva)

Essa reunio tem um time-boxed de 3.75% do Sprint.
O Scrum Master encoraja o Time Scrum a melhorar, dentro do
processo do framework do Scrum, o processo de desenvolvimento e
as prticas para faz-lo mais efetivo e agradvel para a prxima
Sprint. A reunio de retrospectiva o momento de reflexo e
exposio de problemas de um time e, portanto, o momento no qual
se melhora o processo, evidencia-se e resolve-se problemas que
afligem a equipe.
O propsito da Retrospectiva da Sprint :
Inspecionar como a ltima Sprint foi em relao s pessoas, relaes,
processos e ferramentas;
130

Identificar e ordenar os principais itens que foram bem e as potenciais

melhorias;
Criar um plano para implementar melhorias no modo que o Time
Scrum faz seu trabalho.
Ao final da Retrospectiva da Sprint, o Time Scrum dever ter
identificado melhorias que sero implementadas na prxima Sprint. A
implementao dessas melhorias na prxima Sprint a forma de
adaptao inspeo que o Time Scrum faz a si prpria (Melhoria
Contnua!).

Chegamos ao final de nosso livro, espero que voc tenha gostado e

aprendido as principais tcnicas e ferramentas existentes para o gerenciamento
de projetos. Caso desejem aprofundar seus conhecimentos sobre o assunto, no
meu

site

(http://www.rafaeldiasribeiro.com.br)

tenho

diversos

materiais

exclusivos para os amantes de gerenciamento de projetos!

At o prximo Livro!

131

Sobre os autores:
Rafael Dias Ribeiro
Analista de Sistemas formado pela Universidade Estcio de S,
Mestre em Sistemas e Computao pelo Instituto Militar de
Engenharia, Project Management Professional pelo PMI , Certified
Scrum Master CSM e Certified Scrum Product Owner - CSPO pela
ScrumAlliance e COBIT Foundation Certificate pela ISACA. Possuo
experincia nas reas de modelagem e desenvolvimento de sistemas
de computao, gerenciamento de projetos, prticas emergentes de
agilidade em gerenciamento de projetos complexo, mapeamento de
processos de negcio, planejamento e gerncia acadmica, ensino
distncia e gesto estratgica.

Horcio da Cunha e Sousa Ribeiro

Graduado em Engenharia Eltrica pela Universidade do Estado do
Rio de Janeiro (1975) , Mestrado em Engenharia de Sistemas Informtica pelo Instituto Militar de Engenharia (1985), MBA em
Gesto de IES pela UNESA. Diretor Geral do Instituto Superior de
Tecnologia do Estado do Rio de Janeiro (FAETEC) - Coordenador de
Ps-graduao dos cursos de Especializao de professores em
TICS, e do curso de especializao em Metrologia para Software.
Professor de banco de Dados, Inteligncia Artificial, Sistemas de
Informaes, Engenharia de Software, Anlise e Linguagens de
Programao, Produtividade e mtricas de Software. Pesquisador de
processos de negcio e sua ergonomia. Pesquisador de objetos de
ensino visando otimizao do aprendizado. Autor do primeiro livro
sobre Inteligncia Artificial do Brasil. Primeiro livro de anlise
orientada a objetos do Brasil. Diretor Geral da FAETERJ-Rio (antigo
IST-Rio). A FAETERJ-Rio tem um curso de formao de analistas de
sistemas de nvel superior e duas ps-graduaes (TIC aplicadas para
professores - Metrologia aplicada ao software), Desenvolveu e
implantou novas formas de atendimento pela secretaria, implantou a
utilizao de metodologias dinmicas de ensino nas salas hbridas.
Desenvolveu a biblioteca virtual em Q-RCode. Desenvolvimento de
planejamento participativo e utilizao do site virtual (AVA).
Desenvolveu conjunto de indicadores de desempenho para a
Faculdade e com isto obteve a certificao ISO-9001; duas vezes o
conceito 4 (2009 e 2011).

132

Rafael Dias
Ribeiro

contato@cursospin.com.br
Av. Djalma Batista, n. 946, sala 08 (Centro Empresarial Santo Remdio)
133
- Vieiralves - Nossa Sra. das Graas Manaus
Telefone (92) 3584-1966
Site: WWW.cursospin.com.br