Anda di halaman 1dari 74

GERENCIAMENTO DE PROJETOS

Professor: MSc. Eng. Jos Francisco Resende da Silva

Manaus
Maro - 2015

Sumrio
1. Programa da Disciplina.............................................................................................................. 7
1.1

Ementa ........................................................................................................................................ 7

1.2

Carga Horria Total ................................................................................................................... 7

1.3

Objetivos ..................................................................................................................................... 7

1.4

Metodologia ................................................................................................................................ 7

1.5

Critrios de Avaliao ............................................................................................................... 7

1.6

Bibliografia Recomendada ....................................................................................................... 7

2. Introduo ....................................................................................................................................... 9
3. Definio de Projeto .................................................................................................................. 10
3.1

Propsito ................................................................................................................................... 11

3.2

Interdependncias ................................................................................................................... 11

3.3

Singularidade ........................................................................................................................... 12

3.4

Conflitos .................................................................................................................................... 12

3.5

Ciclo de Vida do Projeto ......................................................................................................... 13

3.6

Conceitos Importantes em Gesto de Projetos .................................................................. 15

3.6.1

Escopo............................................................................................................................... 15

3.6.2

Suposio ou Premissa .................................................................................................. 16

3.6.3

Restrio ........................................................................................................................... 16

3.6.4

Stakeholder....................................................................................................................... 16

3.6.5

Patrocinador (Sponsor) ................................................................................................... 17

3.6.6

Entregas (Deliverables) .................................................................................................. 17

3.6.7

Restrio Tripla (Triple Constraint) ............................................................................... 17

3.6.8

Requisitos ......................................................................................................................... 18

3.6.9

Riscos ................................................................................................................................ 19

4. Evoluo da Gesto de Projetos ......................................................................................... 21


4.1

Sculo XIX ................................................................................................................................ 21

4.2

Sculo XX ................................................................................................................................. 22

4.3

Hoje ............................................................................................................................................ 23

4.3.1

Projects IN Controlled Environments (PRINCE) ......................................................... 23

4.3.2

Project Management Institute (PMI) ............................................................................. 23


MSc. Eng. Jos Francisco Resende da Silva

4.3.3

Por que gerenciar projetos est na moda? ................................................................. 24

5. As reas de Conhecimento em Gesto de Projetos ................................................... 27


5.1

Integrao ................................................................................................................................. 31

5.1.1

Desenvolver o termo de abertura do Projeto (project charter) ................................. 31

5.1.2

Desenvolver o plano de gerenciamento do Projeto ................................................... 31

5.1.3

Dirigir e orientar o trabalho do projeto .......................................................................... 31

5.1.4

Monitorar e controlar o trabalho do Projeto ................................................................. 31

5.1.5

Realizar o Controle integrado de mudanas ............................................................... 31

5.1.6

Encerrar o projeto ou fase .............................................................................................. 32

5.2

Escopo....................................................................................................................................... 32

5.2.1

Planejar gerenciamento de Escopo .............................................................................. 32

5.2.2

Coletar os Requisitos ...................................................................................................... 32

5.2.3

Definir o escopo ............................................................................................................... 33

5.2.4

Criar a EAP ....................................................................................................................... 33

5.2.5

Validar o escopo .............................................................................................................. 33

5.2.6

Controlar do escopo ........................................................................................................ 33

5.3

Tempo ....................................................................................................................................... 33

5.3.1

Planejar Gerenciamento do tempo. .............................................................................. 33

5.3.2

Definir as atividades ........................................................................................................ 33

5.3.3

Sequenciar as atividades ............................................................................................... 34

5.3.4

Estimativa de recursos da atividade ............................................................................. 34

5.3.5

Estimar as duraes das atividades ............................................................................. 34

5.3.6

Desenvolver o cronograma ............................................................................................ 34

5.3.7

Controlar o cronograma .................................................................................................. 34

5.4

Custos ....................................................................................................................................... 34

5.4.1

Planejar o Gerenciamento de Custo............................................................................. 34

5.4.2

Estimar os custos ............................................................................................................ 35

5.4.3

Determinar o Oramento ................................................................................................ 35

5.4.4

Controlar os custos.......................................................................................................... 35

5.5

Qualidade .................................................................................................................................. 35

5.5.1

Planejar gerenciamento da qualidade .......................................................................... 36

5.5.2

Realizar a Garantia da qualidade .................................................................................. 36

5.5.3

Controlar a qualidade ...................................................................................................... 36

5.6

Recursos Humanos ................................................................................................................. 36


MSc. Eng. Jos Francisco Resende da Silva

5.6.1

Planejar o gerenciamento dos Recursos Humanos ................................................... 36

5.6.2

Adquirir a equipe do projeto ........................................................................................... 37

5.6.3

Desenvolver a equipe do projeto................................................................................... 37

5.6.4

Gerenciar a equipe do projeto ....................................................................................... 37

5.7

Comunicaes.......................................................................................................................... 37

5.7.1

Planejar o Gerenciamento da comunicao ............................................................... 37

5.7.2

Gerenciar a comunicao .............................................................................................. 37

5.7.3

Controlar a Comunicao ............................................................................................... 38

5.8

Riscos ........................................................................................................................................ 38

5.8.1

Planejar o gerenciamento dos riscos ........................................................................... 38

5.8.2

Identificar os riscos .......................................................................................................... 38

5.8.3

Realizar a anlise qualitativa de riscos ........................................................................ 38

5.8.4

Realizar a anlise quantitativa de riscos ...................................................................... 39

5.8.5

Planejar as respostas aos riscos................................................................................... 39

5.8.6

Controlar os riscos ........................................................................................................... 39

5.9

Aquisies................................................................................................................................. 40

5.9.1

Planejar o Gerenciamento das aquisies .................................................................. 40

5.9.2

Conduzir as aquisies ................................................................................................... 40

5.9.3

Controlar as Aquisies .................................................................................................. 40

5.9.4

Encerrar as Aquisies ................................................................................................... 41

5.10

Gerenciamento dos Stakeholders do Projeto ..................................................................... 41

5.10.1

Identificao dos Stakeholders...................................................................................... 41

5.10.2

Planejar Gerenciamento de Stakeholders ................................................................... 41

5.10.3

Gerenciar o Envolvimento dos Stakeholders .............................................................. 41

5.10.4

Controlar o Envolvimento dos Stakeholders ............................................................... 41

6. Estrutura Analtica de Projetos (EAP) ............................................................................... 42


6.1

Os passos para a Elaborao de uma EAP ........................................................................ 43

6.2

Top-down X Bottom-up ........................................................................................................... 44

6.3

Pacotes de Trabalho ............................................................................................................... 45

7. O Gerenciamento das atividades. ....................................................................................... 46


7.5.1

Ferramentas e tcnicas .................................................................................................. 54

7.5.1.1

Anlise de rede do cronograma ................................................................................ 54

7.5.1.2

8.5.1.2 O mtodo do caminho crtico ........................................................................ 55

7.5.1.3

8.5.1.3 Software de gerenciamento de projetos ..................................................... 55


MSc. Eng. Jos Francisco Resende da Silva

7.6.1

Medio de Desempenho .............................................................................................. 57

7.6.2

Linha de Base do Cronograma (Atualizaes) ........................................................... 58

7.6.3

Aes Corretivas Recomendadas................................................................................. 58

8. Ferramentas Computacionais para Planejamento e Controle de Projetos ....... 59


8.7.1

Projetos de Pequeno Porte ............................................................................................ 64

8.7.2

Projetos de Mdio e Grande Porte ............................................................................... 64

8.7.3

Portflios de Projetos ...................................................................................................... 64

8.7.4

Softwares Mais Populares no Brasil ............................................................................. 65

8.7.5

Usabilidade ....................................................................................................................... 66

9. Templates ...................................................................................................................................... 67
10. Dicas teis .................................................................................................................................... 70

MSc. Eng. Jos Francisco Resende da Silva

1. Programa da Disciplina
1.1 Ementa
Definio de Projeto. Contexto e Evoluo do Gerenciamento de Projetos. As
reas de conhecimento e os processos de gerenciamento do PMBoK. (Verso 5).
Ciclo de Vida dos Projetos:
Iniciao,
Planejamento,
Execuo,
Controle
Encerramento.
Estruturas Analticas de Projetos (EAP). Diagrama de Gantt. Mtodo
PERT/CPM. Caminho Crtico. Cronograma Fsico e Financeiro. Alocao de recursos
humanos e financeiros. Lies Aprendidas.

1.2 Carga Horria Total


24 horas-aula.

1.3 Objetivos
Apresentar conceitos essenciais para o entendimento da funo do gerente de
projetos, praticando os principais processos preconizados pelo PMI - Project
Management Institute e permitindo que, ao final do mdulo, o aluno esteja apto a
gerenciar um projeto conseguindo o melhor da sua equipe.

1.4 Metodologia
Aulas expositivas, exerccios, atividades individuais e em grupo, anlise de
estudo de caso. Recomenda-se ao aluno que traga notebook (se tiver) para facilitar a
realizao das tarefas prticas em sala de aula.

1.5 Critrios de Avaliao


Prova no valor de 70% da mdia final. Exerccios e atividades no valor de 30% da
mdia final.

1.6 Bibliografia Recomendada


MSc. Eng. Jos Francisco Resende da Silva

MAXIMIANO, Antonio Csar Amaru. Administrao de Projetos: como


Transformar idias em resultados. So Paulo: Atlas, 2002.
MULCAHY, Rita. PMP Exam Prep: Ritas Course in a Book for Passing the
PMP Exam. United States of America: RMC Publications, Inc. Sixth Edition,
2009.
PROJECT MANAGEMENT INSTITUTE - PMI. A Guide to the Project
Management Body of Knowledge, PMBOK Guide, Fifth Edition, 2012.
XAVIER, Carlos Magno da S. Gerenciamento de Projetos: como definir e
controlar o escopo do projeto. So Paulo: Saraiva, 2005.
XAVIER, Carlos Magno da S. et al. Metodologia de Gerenciamento de
Projetos. Rio de Janeiro: BRASPORT Livros e Multimdia ltda., 2006.
VALLE, Andre Bittencourt do, SOARES. [et al].
Fundamentos do
Gerenciamento de Projetos. Rio de Janeiro: editora FGV, 2010.

Currculo Resumido do Professor


Jos Francisco Resende da Silva Mestre em Engenharia Eltrica pela Universidade
de So Paulo (2003). Possui Graduao em Engenharia Eltrica pela Universidade
Estadual Paulista Jlio de Mesquita Filho (1994). Tem experincia na rea de
Engenharia Eltrica, com nfase em Materiais Eltricos, atuando principalmente nos
seguintes temas: cruzeta polimrica, materiais para redes areas de distribuio, wood
crossarm e cruzeta. Atualmente Estudante de Doutorado na Escola de Engenharia de
So Carlos - Universidade de So Paulo (USP). Possui MBA em Gesto Empresarial
pela FGV, 2009 Fundao Getulio Vargas. Estudante de MBA em Gerenciamento de
Projetos pela Fundao Getulio Vargas, 2010. Professor Local, IBE-Business
Education Campinas conveniada da Fundao Getulio Vargas em cursos de Ps
Graduao em Administrao de Empresas, desde 2009. Professor no Curso de MBAEspecializao em Gerenciamento de Projetos do SENAC Jundia. Professor no Centro
Universitrio Nossa Senhora do Patrocinio - CEUNSP, desde 2009, ministrando aulas
nos cursos de Cincias da Computao, Redes de Computadores, Engenharia Eltrica,
Engenharia Mecatrnica, Cincias Contbeis, Engenharia da Produo e Engenharia
de Produo Mecnica.. Atua como Especialista Snior em
Pesquisa e
Desenvolvimento na Diretoria de Operaes da Empresa Elektro Eletricidade e
Servios S.A., Responsvel pela Gesto do Programa de Pesquisa e Desenvolvimento
(incluindo Gerenciamento de Projetos) da Empresa Elektro-Eletricidade e Servios
junto a ANEEL. um dos autores do livro Redes Eltricas Inteligentes no Brasil.

MSc. Eng. Jos Francisco Resende da Silva

2. Introduo
Este mdulo de Gerenciamento de Projetos do MBA em Gesto Empresarial
est focado no desenvolvimento de habilidades e competncias em gerenciamento de
projetos com base nos princpios e padres internacionais mais utilizados e
requisitados pelas empresas de hoje.
O material aqui apresentado um guia de estudo e servir como apoio ao
contedo abordado em sala de aula, com mais detalhes sobre as teorias e os conceitos
da ementa da disciplina.
Tambm esto presentes informaes adicionais com referncias a sites oficiais
e artigos de autoria de profissionais certificados em gerenciamento de projetos, para
aqueles que quiserem se aprofundar ou, at mesmo, buscar uma certificao
profissional em gerenciamento de projetos. Tambm fazem parte deste guia de estudo
todas as atividades que sero realizadas em aula, bem como modelos e exemplos de
documentos de projeto.
Agradecimentos:
Prof.(a) Marta Rocha Camargo, por vrios captulos e sees desta apostila e
guia de estudo.
Prof. Agliberto Alves Acierco, PMP, por vrios captulos e sees deste guia de
estudo.

MSc. Eng. Jos Francisco Resende da Silva

10

3. Definio de Projeto
Segundo o Guia PMBOK, projeto pode ser definido como um esforo
temporrio empreendido para criar um produto, servio ou resultado exclusivo.
Temporrio significa que o projeto possui um incio e fim definidos.
Exclusivo/nico significa que o resultado final do projeto diferente dos resultados de
outras funes da empresa, ou seja, algo que nunca tenha sido feito antes na empresa.
Projetos podem envolver desde uma nica pessoa a milhares e ter a durao de
algumas horas ou vrios anos. Os projetos devem apoiar os objetivos estratgicos da
organizao executora. O final do projeto ocorre quando seu objetivo atingido,
quando o objetivo no ser ou poder ser atingido, ou quando no existir mais a
necessidade do projeto e ele for encerrado.
As origens de um projeto so variadas, desde a resposta a uma demanda de
mercado, necessidade organizacional, solicitao de um cliente, avano tecnolgico ou
atendimento a um requisito legal.
Exemplos de projetos seriam:

Desenvolvimento de um novo produto ou servio


Desenvolvimento de um novo modelo de veculo
Construo de um prdio ou uma casa
Uma campanha publicitria ou de marketing
Uma campanha de vacinao
Realizao de um concurso
Desenvolvimento ou aquisio de um sistema
Uma edio de um jornal ou revista
Realizao de uma viagem

Quando se fala em definio de projeto, importante deixar clara a diferena


entre projeto e operao ou trabalho operacional. Trabalho operacional ou operao
so todas as atividades da empresa desenvolvidas de forma contnua que mantm o
negcio.
Atividades contnuas (no limitadas no tempo) envolvem tarefas repetitivas e
proporcionam condies para o funcionamento normal de uma organizao.
Exemplos de trabalho operacional ou operaes seriam:

Administrao de Recursos Humanos


Preenchimento de um formulrio
Manuteno rotineira de equipamentos
Atendimento a clientes via telemarketing
Realizao de vendas de passagens de nibus em um terminal rodovirio
Produo em srie de um automvel
Compra de materiais de escritrio
Controle de estoque
Pagamento /Recebimento de Contas

MSc. Eng. Jos Francisco Resende da Silva

11

Um projeto existe para atingir um determinado objetivo enquanto que uma


operao contnua tem como propsito sustentar ou manter o negcio. Sendo assim, a
diferena principal entre operaes e projetos que as operaes so processos
contnuos e repetitivos, enquanto os projetos so temporrios e nicos. Para muitas
organizaes, os projetos so uma maneira de atender quelas necessidades que no
podem ser satisfeitas dentro dos limites operacionais normais das mesmas. So
empreendimentos que esto fora das operaes normais, do dia a dia, que uma
empresa oferece. Outro aspecto importante a ser lembrado que os resultados finais
dos projetos podem ocasionar operaes. Operaes podem, tambm, se transformar
em projetos, caso haja um aumento significativo na sua complexidade e no seu escopo.
Por fim, importante observar que quando o projeto termina, as pessoas do
projeto passaro para outros projetos e atividades, diferentemente do pessoal que
trabalha com operaes que acabam realizando sempre as mesmas atividades.

3.1 Propsito
Conforme explicado acima, projeto normalmente uma atividade peridica com
um conjunto bem definido dos resultados finais esperados. Ele pode ser dividido em
tarefas e subtarefas que precisam ser realizadas com o intuito de atingir as metas do
projeto.
O projeto complexo suficiente, j que as tarefas e subtarefas requerem
cuidadosa coordenao em termos de cronometragem, precedncia, custo e
desempenho.
Muitas vezes, o projeto em si precisa ser coordenado com outros projetos que
estejam sendo executados por uma mesma organizao afiliada.

3.2 Interdependncias
Os projetos frequentemente interagem com outros projetos que esto sendo
executados simultaneamente pelas suas organizaes ligadas; mas os projetos sempre
interagem com as operaes padres em execuo nas organizaes ligadas.
Se bem que os departamentos funcionais de uma organizao (marketing,
finanas, fabricao e semelhantes) interagem entre si de forma regular e padronizada,
os padres de interao entre os projetos e esses departamentos tendem a ser
variveis. A rea de Marketing (mercadologia) pode ser envolvida no incio e no fim do
projeto, mas no no meio. A fabricao pode ter um maior envolvimento no transcurso.
O setor financeiro freqentemente envolvido no incio e a contabilidade
(controladoria) no fim, bem como nos relatrios peridicos.
O gerente de projeto precisa tornar claras todas essas interaes e manter o interrelacionamento apropriado com todos os grupos externos.

MSc. Eng. Jos Francisco Resende da Silva

12

3.3 Singularidade
Cada projeto possui alguns elementos que so nicos. Duas construes ou
dois projetos de P&D Pesquisa e Desenvolvimento no so precisamente
semelhantes. Apesar de ser claro que projetos de construo so normalmente mais
rotineiros que os projetos de P&D, alguns graus de personalizao formam as
caractersticas dos projetos. Em adio presena de risco, como observado
anteriormente, essa caracterstica significa que o projeto, por sua natureza, no pode
ser completamente reduzido rotina. A importncia do gerente de projeto enfatizada
porque, como devoto do gerenciamento por exceo, o que ele encontrar a so as
muitas e grandes excees para administrar.

3.4 Conflitos
Mais que a maioria dos administradores, o gerente de projetos vive em um
mundo caracterizado pelo conflito. Os projetos competem com os departamentos
funcionais quanto a recursos e pessoal. Mais srio, com a crescente proliferao de
projetos, o conflito projeto versus projeto por recursos dentro de organizaes
multiprojetos. Os membros da equipe do projeto esto em conflito quase constante
pelos recursos do projeto e pelo papel de liderana na soluo dos problemas do
projeto.
As quatro partes de interesses ou os pilares (cliente, organizaes filiadas,
equipe do projeto e o pblico) em qualquer projeto constantemente definem o sucesso
e as falhas de formas diferentes. O cliente quer vantagens e as organizaes ligadas
querem lucros, as quais podem ser reduzidas se essas mudanas so feitas.
Indivduos que trabalham no projeto so freqentemente responsveis a duas chefias
ao mesmo tempo; essas chefias possuem diferentes prioridades e objetivos.
No gerenciamento de projeto no h lugar para tmidos. Se as caractersticas
acima relacionadas definem um projeto, apropriado perguntar se no so projetos.
Eles so. O uso de uma linha de fabricao para produzir um fluxo de produtos
padronizados um no-projeto.
A produo de relatrios semanais de emprego, a preparao de lanches para a
escola, a entrega de correspondncia, o vo 1501 da GOL do Rio de Janeiro para So
Paulo, a checagem de e-mail, todos so no-projetos.
Enquanto algum possa argumentar que cada uma dessas atividades seja, em
certo grau, nica, no a sua singularidade que a caracteriza. Todas so rotineiras.
Tarefas que so realizadas mais e mais, repetidamente. Essa no a realidade dos
projetos. Cada projeto um evento nico. Mesmo a construo de uma seo da via
expressa interestadual um projeto.
Duas milhas no so a mesma coisa e a construo delas necessita constante
adaptao s diferenas de terreno e subestrutura do solo no qual ser depositada a
faixa de rolagem. Projetos no podem ser administrados adequadamente pelas rotinas
gerenciais utilizadas para um trabalho rotineiro.

MSc. Eng. Jos Francisco Resende da Silva

13

Os conflitos mais freqentes em gesto de projetos impreterivelmente


envolvero um ou mais dos seguintes itens:

Prazos
Prioridades
Recursos
Questes Tcnicas
Polticas Administrativas
Custos
Choques de Personalidade

3.5 Ciclo de Vida do Projeto


A maioria dos projetos passa atravs de estgios similares no caminho entre a
origem at a concluso. Definimos esses estgios, mostrados na figura abaixo como o
ciclo de vida do projeto.
O projeto nasce (sua fase de incio) e o gerente escolhido, a equipe do projeto
e os recursos iniciais so montados, e o programa de trabalho est organizado. Em
seguida, o trabalho passa por um momento de rpida construo da sua forma. O
progresso foi feito.
E isso continuar at que o fim seja visvel. Mas, a concluso do objetivo final
aparenta tomar uma quantidade irregular de tempo, parcialmente porque existe
freqentemente um nmero de partes que devem vir juntas e parcialmente porque os
membros da equipe arrastam os ps por vrias razes e evitam as etapas finais.
O padro de progresso lento-rpido-lento em direo meta do projeto
comum. Qualquer pessoa que tenha prestado ateno na construo de uma casa ou
um prdio observou esse fenmeno. Para a maior parte, esse o resultado da troca de
nveis de recursos utilizados durante os sucessivos estgios do ciclo de vida.

MSc. Eng. Jos Francisco Resende da Silva

14

A Figura a seguir mostra o empenho do projeto, geralmente em termos de


homem-hora ou recursos gastos por unidade de tempo (ou nmero de pessoas
trabalhando no projeto) diagramados em relao ao tempo, onde o tempo foi
fragmentado nas diversas fases da vida do projeto.

Um empenho mnimo exigido no incio, quando o conceito do projeto est


sendo desenvolvido e submetido ao processo de seleo do projeto.
Se esse obstculo for ultrapassado, o aumento planejado da atividade ser
concludo e o trabalho real do projeto seguir sua marcha. Isso crescer at o auge e
depois comear a afunilar quando o projeto aproximar-se da concluso, finalmente
MSc. Eng. Jos Francisco Resende da Silva

15

cessando quando a avaliao estiver completa e o projeto terminado. Como esse sobe
e desce do empenho sempre ocorre, no existe um padro em particular que parea
tipificar todos os projetos, nem nenhuma razo para a diminuio no fim do projeto que
possa assemelhar-se com o desenvolvimento no seu incio. Alguns projetos terminam
sem serem prolongados, como mostrado na Figura acima.
Em alguns casos, o esforo parece nunca cair a zero porque a equipe do
projeto, ou pelo menos um grupo da estrutura, pode ser mantida para o prximo projeto
apropriado que venha em seguida.

3.6 Conceitos Importantes em Gesto de Projetos


Apesar de os termos abaixo serem comuns, muitos iniciantes em gesto de
projetos no conseguem aplic-los na situao de um projeto. Muitas vezes isso
causado por falta de clareza no que os conceitos realmente significam em termos da
prtica de um projeto; outras vezes simplesmente porque o projeto, em si, no est
claro. Independentemente da situao, fundamental que se entenda o que significam,
pois so o ponto de partida da definio de um projeto.
3.6.1

Escopo

Saber o escopo de um projeto identificar e descrever o trabalho que


necessrio para produzir o produto do projeto. Essa definio deve ser detalhada para
assegurar que:
A equipe do projeto entenda o que precisa ser feito.
Todo o trabalho do projeto seja identificado logo no incio, dentro do
possvel.
Sejam aplicados controles gerenciais adequados.
A definio do escopo do projeto normalmente a primeira etapa do
projeto e serve como alicerce para os demais componentes do projeto. Se for
mal feito, todo o trabalho subsequente do projeto sofrer danos muitas vezes
irreversveis.
Para ajudar na definio do escopo do projeto, os seguintes fatores
devem ser considerados.
Escopo do produto: se o produto do projeto for bem definido,
normalmente possvel preparar uma lista das tarefas do projeto. Quando
os requisitos do produto no esto claros, o gerente de projetos deve
constantemente atualizar o escopo para refletir a nova realidade, o que
afeta prazos e custos.
Exigncias contratuais: se o projeto tiver que cumprir termos contratuais,
o mesmo poder especificar exatamente o que deve ser feito. Isso
acontece em projetos governamentais que exigem o cumprimento de
padres especficos de performance e qualidade.
No incio do projeto, normalmente feita uma definio preliminar do escopo do
projeto. O gerente de projetos convoca uma reunio de incio (kick-off) do projeto e
define, em conjunto com os membros da equipe do projeto, o trabalho a ser feito. Na
MSc. Eng. Jos Francisco Resende da Silva

16

fase de planejamento do projeto, essa primeira definio revisada atravs do


processo da Estrutura Analtica do Projeto (EAP), descrita no Captulo 7 deste guia de
estudo.
Nesse ponto do projeto, o gerente de projetos deve ser capaz de decompor o
projeto em tarefas ou pacotes de trabalho e definir entregas, prazos, custos e recursos.
Um conceito importante dentro do escopo o dos deliverables que so as entregas
ou entregveis do projeto. Uma entrega ou deliverable qualquer produto ou servio,
tangvel e verificvel, que deve ser produzido para completar um projeto ou parte dele.
Para ser verificvel, ele deve atender a padres predeterminados para sua concluso,
como especificaes de desenho (design) de um produto (por exemplo, um novo carro)
ou uma lista de verificao das etapas concludas como parte de um servio (por
exemplo, a manuteno dos equipamentos de uma fbrica).
3.6.2

Suposio ou Premissa

Suposio aquilo que tido como certo no projeto. O PMBOK utiliza o termo
premissa e define como fatores que so considerados verdadeiros, reais ou certos sem
prova ou demonstrao, dentro do contexto do projeto. Pode haver circunstncias ou
eventos externos que devem ocorrer para que o projeto seja bem sucedido. Se voc
acreditar na probabilidade de um evento ocorrer, isso seria uma suposio. (contraste
com a definio de um risco.) Se um evento estiver dentro do controle da equipe do
projeto, tal como, testado completamente em uma determinada data, ento isto no
uma suposio. Se um evento tiver uma possibilidade de 100% de ocorrer, ento ele
no uma suposio, quando no h 'uma probabilidade' ou um risco envolvido ( um
fato).
Os exemplos de premissas so suposies que podero ser que 'os oramentos
e os recursos estaro disponveis quando necessrio ou a liberao de um novo
software estar disponvel para o uso no momento onde a fase da construo comea.

3.6.3

Restrio

Restrio todo e qualquer fato limitante execuo do projeto. Pode ser uma
data limite para entrega, operacionalizao do projeto ou recurso financeiro.
basicamente um estado, qualidade ou sentido de estar restrito a uma determinada ao
ou inatividade; algo que afetar o desempenho do projeto ou de um processo.
3.6.4

Stakeholder

Stakeholders so todas as pessoas ou organizaes que possuem um


envolvimento direto ou indireto com o projeto e que podem afetar positivamente ou
negativamente o projeto. O PMBOK utiliza a traduo partes interessadas, porm em
organizaes que trabalham com projetos, comum manter o termo em ingls:
stakeholders.
A equipe de gerenciamento de projetos deve investigar todas as partes afetadas
pelo projeto a fim de identificar todos os stakeholders no apenas os mais bvios. Os
gerentes de projetos que ignoram as partes interessadas podem esperar um impacto
prejudicial nos resultados do projeto. Se um stakeholder no for identificado, poder
MSc. Eng. Jos Francisco Resende da Silva

17

haver grandes problemas principalmente quando se tratar de aprovaes a planos de


aes a riscos.
Administrar as expectativas dos stakeholders pode ser bem difcil, uma vez que
diferentes interessados possuem objetivos diferentes que podem ser conflitantes.
Especificamente, a soluo para o conflito dos stakeholders satisfazer as
necessidades do cliente primeiro. As necessidades do cliente, ou as necessidades da
empresa pela qual o projeto foi iniciado, devero guiar o projeto no decorrer do ciclo de
vida do projeto.
Os stakeholders so tratados na verso 5 do PMBOK na rea do conhecimento
Gerenciamento de Partes Interessadas.
Exemplos de stakeholders, de acordo com o PMBOK, seriam:
Gerente do Projeto a pessoa responsvel pelo gerenciamento do
projeto
Cliente a pessoa ou organizao que ir utilizar o produto do projeto
Organizao Executora a empresa cujos funcionrios esto
diretamente envolvidos na execuo do trabalho do projeto
Membros da Equipe do Projeto a equipe que est executando o
projeto
Equipe de Gerenciamento de Projetos os membros da equipe do
projeto que esto diretamente envolvidos nas atividades de
gerenciamento de projetos
Outros - Proprietrios e provedores de fundos, fornecedores e
contratados, membros da equipe e seus familiares, agncias
governamentais e meios de comunicao, cidados comuns, alm da
sociedade em geral.
3.6.5

Patrocinador (Sponsor)

Pessoa ou grupo que fornece os recursos financeiros para a execuo de um


projeto.

3.6.6

Entregas (Deliverables)

Qualquer documento, produto ou resultado produzido para terminar um


processo, fase ou projeto.
Exemplos de entregas seriam:
Plano do Projeto
Cronograma
Programa de software
3.6.7

Restrio Tripla (Triple Constraint)

A restrio tripla (conhecida tambm como o tringulo de Dempster) ou triple


constraint descreve o equilbrio entre o escopo, o custo e o tempo de um projeto.

MSc. Eng. Jos Francisco Resende da Silva

18

Qualidade foi adicionada depois da criao deste tringulo, subentendendo-se


que se encaixa dentro do escopo. Em todo projeto, importante terminar at certa data
de acordo com determinado valor (custo) ou ambos. Da mesma forma, as entregas do
projeto normalmente devem seguir especificaes mnimas (qualidade) para serem
teis organizao. A rea que tem um pouco de flexibilidade o escopo do projeto.

Durante o planejamento do projeto, o gerente de projeto trabalha com sua


equipe para definir o escopo, cronograma, custo e qualidade do projeto. medida que
o projeto evolui, comum perceber que seu plano precisa de ajustes ou que os
stakeholders esto solicitando mudanas. Se a solicitao de mudana incorrer em
aumento do escopo, ento pelo menos um dos outros vrtices do tringulo tambm
sofrero mudanas. Por exemplo, se for solicitado que se aumente o escopo da
localizao de um software para incluir um novo idioma, ser necessrio gastar mais
dinheiro para alocar mais recursos ou gastar mais tempo para terminar o projeto com
mais trabalho.
Dessa forma, a mudana em uma das restries forar a mudana de pelo
menos um ou mais das outras restries. Uma das responsabilidades mais importantes
do gerente de projetos determinar o impacto que cada mudana solicitada pelos
stakeholders ter no tringulo e, consequentemente, no projeto. Recentemente, duas
novas restries foram adicionadas: risco e satisfao do cliente.
3.6.8

Requisitos

Na rea do conhecimento Gerenciamento de Escopo temos o processo Coletar


Requisitos. Requisito uma condio ou capacidade que deve ser obedecida por um
sistema, produto, servio, resultado ou componente para satisfazer um contrato, um
padro, uma especificao ou outros documentos formais. Os requisitos do projeto
refletem as necessidades, os desejos e as expectativas do sponsor, do cliente e de
outros stakeholders, de forma quantificada e documentada. Exemplos de requisitos
seriam:
O projeto dever seguir os requisitos de segurana conforme Nvel 1
NGS1
A gesto de qualidade do projeto dever estar de acordo com os
requisitos da ISO 9001
MSc. Eng. Jos Francisco Resende da Silva

19

A fase de testes do software dever incluir especificaes para rodar no


Windows XP, NT e Vista;
A documentao do projeto dever seguir os processos e as reas de
conhecimento do PMI.
3.6.9

Riscos

Dentro de um projeto, riscos so eventos ou condies no planejadas, que


podem ter um efeito negativo no seu sucesso. O gerenciamento de riscos o processo
no qual o gerente e a equipe do projeto identificam riscos, analisam e classificam esses
riscos, e determinam que aes devero ser tomadas para impedir ou amenizar os
efeitos negativos ao projeto.
Com base no tamanho, no impacto e na prioridade do projeto, um oramento
pode ser estabelecido para as atividades de gerenciamento de riscos. O planejamento
de riscos , ento, o processo necessrio para decidir como abordar, planejar e
executar as atividades de gerenciamento de riscos de um projeto.
Um plano eficiente de gerenciamento de riscos deve incluir os seguintes itens:
Como os riscos sero identificados
Como a anlise quantitativa ser completada
Como a anlise qualitativa ser completada
Como acontecer o planejamento de resposta ao risco
Como os riscos sero monitorados
Como as atividades de gerenciamento de riscos acontecero durante o
projeto.
O PMBOK define quatro categorias principais de riscos:
Externos:
Regulatrios,
ambientais,
mudanas
no
mercado,
governamentais
Internos: Tempo, custo, mudanas no escopo, inexperincia,
planejamento
inadequado, pessoas, mobilizao do pessoal, materiais, equipamentos
Tcnicos: Mudanas na tecnologia
Imprevisveis: Apenas uma pequena parte dos riscos (algumas pessoas
consideram cerca de 10%).
Em uma abordagem qualitativa ao gerenciamento de riscos, na fase do
planejamento do projeto, o gerente de projetos deve fazer um levantamento de todos
os riscos que podem acontecer no projeto. Essa no uma tarefa fcil, principalmente
se for um projeto novo, sem uma histria para servir como referncia. A tcnica mais
utilizada para levantamento dos riscos de um projeto o brainstoming. O processo de
brainstorming nessas situaes o seguinte:
Um grupo de stakeholders chamado para participar da reunio.
MSc. Eng. Jos Francisco Resende da Silva

20

Todos contribuem com idias para identificar possveis riscos do projeto e


uma idia ajuda a gerar outra.
Os riscos identificados so categorizados e planos de ao estabelecidos.
Outra tcnica a entrevista de especialistas no assunto e stakeholders onde os
entrevistados, atravs de perguntas e discusso, compartilham suas experincias
passadas em projetos similares.
Uma anlise quantitativa de riscos uma forma de priorizar riscos para anlise
ou ao adicional subseqente atravs de avaliao e combinao de sua
probabilidade de ocorrncia e impacto. Esse tipo de anlise pressupe uma avaliao
numrica dos efeitos dos riscos identificados nos objetivos gerais do projeto. Uma
anlise de risco quantitativa conta com nmeros rgidos onde cada risco recebe uma
nota, e no uma avaliao baixa, mdia e alta. As tcnicas utilizadas para a anlise de
risco quantitativa so: anlise do valor monetrio, rvore de deciso e simulao de
Monte Carlo.
Depois de feito um levantamento dos possveis riscos, necessrio desenvolver
opes e aes para diminuir a possibilidade de que os riscos prejudiquem os objetivos
do projeto. Estratgias de respostas a riscos incluem o seguinte:
Prevenir: Eliminar a ameaa eliminando a causa
Mitigar: Reduzir a probabilidade ou o impacto de uma ameaa, tornandoa um risco menor.
Transferir: Tornar outra parte responsvel pelo risco atravs da aquisio
de seguros, terceirizao do trabalho etc.
Aceitar: Simplesmente aceita o risco porque nenhuma outra ao
vivel, ou ento os riscos so considerados de pouca probabilidade,
impacto ou ambos.

MSc. Eng. Jos Francisco Resende da Silva

21

4. Evoluo da Gesto de Projetos


Existe uma rica variedade de projetos em nossa sociedade. Se bem que alguns
possam afirmar que a construo da Torre de Babel ou as Pirmides do Egito foram
alguns dos primeiros projetos, provvel que o homem das cavernas tenha formado
um projeto para juntar a matria prima para fazer ensopado de Mamute.
Nos seus primeiros dias, a gesto de projetos foi usada principalmente em
projetos muito grandes, de complexa pesquisa e desenvolvimento (P&D), como o
desenvolvimento do mssil balstico intercontinental Atlas e sistemas similares de armas
militares. Macios programas de construo foram tambm organizados como
projetos a construo de represas, navios, refinarias e vias expressas, entre outros.
Quando foram desenvolvidas as tcnicas do gerenciamento de projetos, em sua
maioria pelos militares, o uso da organizao de projetos comeou a se ampliar.
Empresas de construo consideraram que a organizao de projetos seria til
em projetos como a construo de centros comerciais ou conjuntos residenciais. As
companhias automotivas usaram a organizao de projetos para desenvolver novos
modelos de automveis.
Mais recentemente, o uso da gesto de projetos
internacionais, e, em particular, as organizaes que produzem
produtos, cresceram rapidamente. Campanhas de publicidade,
aquisies de capital so vrias vezes tratadas como projetos
estenderam ao setor sem fins lucrativos.

por organizaes
mais servios que
fuses globais e
e os mtodos se

Como disciplina, gesto de projetos teve suas origens dcadas atrs, quando as
empresas comearam a perceber a importncia de se organizar o trabalho em equipes
de projetos e integrar diferentes reas e profisses. Para fins didticos, a evoluo da
gesto de projetos pode ser dividida em trs fases, conforme descrito nas prximas
sees.

4.1 Sculo XIX


No fim do sculo XIX, obras governamentais de grande porte nos Estados
Unidos ofereciam um nvel cada vez maior de complexidade devido prpria escala
dos projetos. Por exemplo, projetos de linhas de trem transcontinentais por volta de
1870 exigiam dos gerentes uma habilidade de organizar o trabalho de milhares de
operrios, sem falar a fabricao e montagem de quantidades exorbitantes (para a
poca) de material de construo para as obras. Nenhum mtodo formal foi
desenvolvido nessa poca, porm as empresas comearam a perceber que era
necessrio ter uma maior organizao e controle do trabalho e dos trabalhadores para
conseguirem terminar as obras dentro do tempo esperado.

MSc. Eng. Jos Francisco Resende da Silva

22

4.2 Sculo XX
No incio do sculo XX, projetos grandes, principalmente nas reas de
construo civil, engenharia mecnica e militar, comearam a exigir alguma forma mais
precisa de demonstrar o trabalho que precisava ser feito e como controlar esse
trabalho e seus recursos. Nesse sentido, pode-se dizer que o pai da gesto de
projetos foi Henry Gantt, que desenvolveu as primeiras tcnicas de planejamento e
controle de um projeto. Seguindo os passos das teorias de administrao cientfica de
Frederick Taylor,
Gantt comeou a observar o trabalho dos operrios na construo de navios da
marinha norte-americana na poca da I Guerra Mundial. Durante esses estudos, Gantt
comeou a usar grficos com barras de tarefas e marcadores de pontos importantes do
projeto, delineando a seqncia e a durao de todas as tarefas no processo da
produo. Esses grficos ou diagramas de Gantt se tornaram uma ferramenta valiosa
para os gerentes da poca que conseguiam, ento, ter uma viso melhor do trabalho
como um todo.
Depois da II Guerra Mundial, as complexidades dos projetos e a falta de modeobra na poca ps-guerra exigiam novas estruturas organizacionais (Sisk, 1998). Foi
nessa poca que apareceram os primeiros modelos matemticos que davam aos
gerentes um controle maior sobre projetos extremamente complexos com altos nveis
de sofisticao tecnolgica.
Por volta de 1958, surgiu o Program Evaluation and Review Technique ou
PERT, desenvolvido como parte programa do mssil do submarino Polaris da marinha
dos Estados Unidos (conjuntamente com a Lockheed Corporation). Em linhas gerais, o
PERT apresenta uma ilustrao grfica de um projeto como um diagrama de rede
formado por ns numerados (que podem ser crculos ou retngulos) representando
eventos ou marcos do projeto conectados por meio de vetores (linhas direcionais)
representando as tarefas em um projeto. A direo dos setas nas linhas indica a
sequncia das tarefas.
Um outro modelo que surgiu mais ou menos na mesma poca foi o Critical Path
Method (CPM) ou mtodo do caminho crtico, desenvolvido em conjunto pela DuPont
Corporation e Remington Rand Corporation para projetos da manuteno de planta. O
mtodo do caminho crtico permite definir a sequncia das atividades para que o
projeto seja concludo dentro do prazo estipulado. o caminho mais longo das
atividades que compem o projeto, desde o incio at o fim. Se uma das atividades que
se encontram no caminho crtico no for concluda no tempo determinado, isso significa
que o projeto ter um atraso. por isso que importante entender a sequncia das
atividades no caminho crtico pois um atraso em uma atividade crtica afeta o prazo
final do projeto. importante que se tenha em mente tambm que quando o projeto
est atrasado, no adianta alocar recursos para tarefas no-crticas pois elas no
afetam as datas finais. As tarefas do caminho crtico sempre tero prioridade nesse
sentido.
Os diagramas de Gantt, PERTs e mtodos de caminhos crtico continuam sendo
utilizados para planejamento e controle de projetos at os dias de hoje e foram

MSc. Eng. Jos Francisco Resende da Silva

23

incorporados em programas de software para gerenciamento de projetos como, por


exemplo, o MS Project.

4.3 Hoje
Enquanto os estudos de administrao e modelos de negcios evoluram at os
dias de hoje, as empresas, principalmente de grande porte, comearam a compartilhar
uma estrutura organizacional com base em projetos gerenciados por um profissional
denominado Gerente de Projetos que monta ou trabalha com uma equipe e assegura a
integrao e comunicao do fluxo de trabalho entre profissionais e funes diferentes.
Dentro dessa nova viso de estrutura organizacional, tornou-se necessrio
padronizar as prticas de gerenciamento de projetos. Atualmente, duas instituies se
sobressaem no cenrio mundial de gerenciamento de projetos, conforme descrito a
seguir.
4.3.1

Projects IN Controlled Environments (PRINCE)

O OGC iniciou seus trabalhos lanando o mtodo PRINCE (Projects in


Controlled Environments) por volta de 1989, que se tornou um padro de fato para o
setor pblico e privado na Inglaterra e outros pases, principalmente da Europa.
Embora tenha sido desenvolvido originariamente para o setor de tecnologia da
informao, hoje o PRINCE utilizado largamente em outros setores. Sua ltima
verso, denominada de PRINCE2, foi desenvolvida de forma a incorporar os
requerimentos dos usurios atuais e de vrios projetos no baseados em tecnologia da
informao, tornando-o um guia genrico de melhores prticas para o gerenciamento
de todos os tipos de projetos. Mais informaes podem ser obtidas no site da empresa:
www.prince2.org.uk
4.3.2

Project Management Institute (PMI)

O PMI ou Project Management Institute (Instituto de Gerenciamento de Projetos)


uma instituio sem fins lucrativos fundada em 1969 por cinco voluntrios na cidade
de Filadlfia, estado da Pensilvnia nos Estados Unidos.
O PMI tem cerca de 260.000 membros em 170 pases (dados de 2008) e suas
diretrizes so seguidas e praticadas por empresas de pequeno, mdio e grande porte
do mundo inteiro, em todos os setores: aeroespacial, automotivo, construo,
engenharia, servios financeiros, tecnologia, farmacutica, mdica, telecomunicaes
etc.
Em 1987, os conceitos do PMI foram consolidados em um guia chamado
PMBOK - Guide to the Project Management Body of Knowledge - Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos - que o nico padro ANSI para
gesto de projetos. O Guia PMBOK oferece uma estrutura bsica para entender gesto
de projetos e o ambiente no qual o projeto ocorre. O PMBOK oferece tambm uma
viso geral de como os diversos processos de gesto de projetos interagem.
MSc. Eng. Jos Francisco Resende da Silva

24

Empresas no mundo todo vm adotando os processos do PMBOK para


garantirem uma consistncia nas formas de gerenciar seus projetos, principalmente
quando se tratar de multinacionais com operaes em vrios pases. Nesse aspecto, o
PMBOK traduzido em portugus, espanhol, francs, chins, alemo, italiano,
japons, rabe e russo.
Os Captulos (Chapters) do PMI so regionais e funcionam como captadores e
distribuidores de informaes relacionadas ao tema. atravs dos captulos que o PMI
integra seus membros mundialmente. Existem no Brasil 13 captulos do PMI: So
Paulo, Rio de Janeiro, Minas Gerais, Distrito Federal , Paran, Rio Grande do Sul,
Bahia, Pernambuco, Amazonas, Santa Catarina, Esprito Santo, Gois e Cear. O PMI
oferece a certificao mais reconhecida no campo de Gesto de Projetos o PMP ou
Project Management Professional - que concedido a quem consegue demonstrar,
atravs de uma prova, a experincia efetiva em Gerenciamento de Projetos, com pleno
conhecimento das abordagens, metodologias e prticas de gerenciamento de projetos
descritos no PMBOK. A primeira certificao PMP foi em 1984.
Para fazer o exame, necessrio ter alguns anos de experincia em
gerenciamento de projetos, bem como 35 horas de educao formal nesta rea. A
certificao vai assegurar aos empregadores e clientes que o profissional conhece as
prticas e disciplinas do gerenciamento de projetos, bem como experincia prtica.
Alm da certificao PMP, os padres PMI de gesto de projetos incluem os
PMOs ou Project Management Offices, escritrios de gerenciamento de projetos que
so basicamente locais fsicos dentro das empresas onde profissionais especializados
e credenciados nos processos PMI orientam e do suporte a outros gerentes, equipes
e stakeholders de projetos. Um PMO funciona como um centro de operaes e
informaes para acompanhamento do projeto e resoluo de problemas e dvidas
relativas a processos e objetivos. Ele pode operar continuamente, prestando suporte a
gerentes de projetos na forma de treinamento, software, modelos etc., ou arcando com
a responsabilidade pelos resultados do projeto.
Para mais informaes sobre o PMI, visite site brasileiro em:
http://www.pmisp.org.br
4.3.3

Por que gerenciar projetos est na moda?

A gesto de projetos est to na moda1 por causa das caractersticas da nossa


sociedade de virada do sculo procura do desenvolvimento de novos mtodos de
gesto.
Das muitas foras envolvidas, trs so soberanas:
Expanso exponencial do conhecimento humano;
Demanda crescente por uma faixa ampla de bens e servios complexos,
sofisticados e sob medida;
Evoluo de mercados universais competitivos para a produo e
consumo de bens e servios.

MSc. Eng. Jos Francisco Resende da Silva

25

Todas as trs foras se unem para determinar o uso de equipes para resolver os
problemas que normalmente so resolvidos individualmente. Essas trs foras se unem
para aumentar grandemente a complexidade dos bens e servios produzidos mais a
complexidade dos processos utilizados para produzi-los. Isso, por seu turno, conduz
necessidade por sistemas mais sofisticados para controlar o resultado e o processo.
Primeiro, a expanso do conhecimento permite o uso de um crescente nmero
de disciplinas acadmicas para solucionar problemas associados com o
desenvolvimento, a produo e a distribuio de bens e servios.
Em segundo lugar, a satisfao da continuada demanda por produtos e servios
mais complexos e personalizados depende da nossa habilidade em tornar o desenho
do produto numa parte integrada e inerente do nosso sistema de fabricao e
distribuio.
Em terceiro lugar, os mercados mundiais nos foram a incluir as diferenas
culturais e ambientais nas nossas decises administrativas a respeito do que, onde,
quando e como produzir e distribuir o produto.
O requerido conhecimento no reside no fator individual nem na questo se
possui boa educao ou cultura. Assim, sob essas condies, so utilizadas equipes
para tomar decises e adotar aes. Isso clama por um alto nvel de coordenao e
cooperao entre grupos de pessoas no utilizados particularmente nessa interao.
Amplamente engrenadas na produo em massa de bens elementares,
estruturas organizacionais e sistemas de administrao tradicionais so simplesmente
inadequados para este objetivo. Mas o gerenciamento de projeto . A resposta
organizacional para as foras acima observadas no pode assumir a forma de uma
transformao instantnea do velho para o novo.
Para ser bem sucedida, a transio precisa ser sistemtica, mas ela tende a ser
lenta e tortuosa para a maioria das empresas. A execuo da mudana organizacional
o emprego natural do gerenciamento de projeto, e muitas firmas organizaram projetos
para implementao das suas metas de mudana estratgica e ttica.
Outra fora importante de sociedade a intensa competio entre instituies,
com e sem fins lucrativos, incentivada pelo nosso sistema econmico. Isso exerce uma
extrema presso nas organizaes para tornar seus produtos complexos e
personalizados disponveis o mais rpido possvel. O tempo at o mercado crtico.
As respostas devem vir mais depressa, as decises precisam ser tomadas mais cedo e
os resultados devem ser mais velozes.
Imagine os problemas de comunicao por si s. A informao e o
conhecimento crescem explosivamente, mas o prazo permissvel para localizar e
utilizar o conhecimento adequado est diminuindo. Essas foras operam numa
sociedade que pressupe que a tecnologia pode fazer tudo. O fato que essa
suposio razoavelmente certa, dentro dos limites das leis naturais fundamentais.
O problema no est nesta suposio, tanto quanto est na suposio
concomitante que permite sociedade ignorar os custos econmicos e noeconmicos associados com o progresso tecnolgico, at o momento em que alguns
eventos dramticos voltam nossa ateno para os custos (como, por exemplo, o
acidente nuclear de Chernobyl, o derramamento de leo do Exxon Valdez, o acidente
com a TAM, o acidente com o avio da GOL em pleno ar ou o aquecimento global).
MSc. Eng. Jos Francisco Resende da Silva

26

s vezes, nossa f na tecnologia abalada por dificuldades e crescentes


ameaas devido sua implementao negligente, como no caso do lixo industrial, mas
de uma forma geral, parecemos extraordinariamente tolerantes com as mudanas
tecnolgicas.
Finalmente, os projetos que empreendemos so grandes e cada vez maiores. A
moderna organizao de mquinas-ferramenta, por exemplo, evoluiu de uma mquina
de usinagem por controle numrico para um centro de usinagem e para um sistema
flexvel de fabricao.
Como cada nova capacitao estende nosso alcance, isso serve como base
para novas demandas, que nos foram a estender nosso mbito cada vez mais longe.
Os projetos aumentam em tamanho e complexidade porque o que mais pudermos
fazer, mais tentaremos fazer. Do caminho da rbita terrestre ao pouso na lua at os
vos interplanetrios claro e, logicamente, inevitvel.
Os projetos que chamam a maioria da ateno pblica tendem a ser grandes,
complexos e de empenho multidisciplinar. Vrias vezes esses empenhos so, ao
mesmo tempo, similares e diferentes a partir de prvios projetos com os quais ns
podemos estar mais ou menos familiarizados.
Similaridades com o passado fornecem uma base para dar incio, mas as
diferenas impregnam cada projeto com um risco considervel. As complexidades e os
aspectos multidisciplinares dos projetos exigem que muitas partes sejam colocadas
juntas de maneira que os objetivos primordiais o desempenho, durao (ou
programao) e custos sejam encontrados.

MSc. Eng. Jos Francisco Resende da Silva

27

5. As reas de Conhecimento em Gesto


de Projetos
Conforme prticas do PMI descritas no guia PMBOK verso 5, os processos
esto contidos em dez reas de conhecimento gerencial ou disciplinas:
Gerenciamento de integrao do projeto
Descreve os processos e as atividades que integram os diversos
elementos do gerenciamento de projetos, que so identificados,
definidos, combinados, unificados e coordenados dentro dos grupos de
processos de gerenciamento de projetos.
Gerenciamento do escopo do projeto
Descreve os processos envolvidos na verificao de que o projeto inclui
todo o trabalho necessrio, e apenas o trabalho necessrio, para que
seja concludo com sucesso.
Gerenciamento da qualidade do projeto
Descreve os processos envolvidos na garantia de que o projeto ir
satisfazer os objetivos para os quais foi realizado.
Gerenciamento de tempo do projeto
Descreve os processos relativos ao trmino do projeto no prazo correto.

Gerenciamento de recursos humanos do projeto


Descreve os processos que organizam e gerenciam a equipe do projeto.
Gerenciamento de custos do projeto
Descreve os processos envolvidos em planejamento, estimativa,
oramentao e controle de custos, de modo que o projeto termine
dentro do oramento aprovado.
Gerenciamento das comunicaes do projeto
Descreve os processos relativos gerao, coleta, disseminao,
armazenamento e destinao final das informaes do projeto de forma
oportuna e adequada.
Gerenciamento de riscos do projeto
Descreve os processos relativos realizao do gerenciamento de
riscos em um projeto.
Gerenciamento de aquisies do projeto
Descreve os processos que compram ou adquirem produtos, servios
ou resultados, alm dos processos de gerenciamento de contratos.

Gerenciamento de Partes Interessadas


Descreve os processos que identificam,planejam o gerenciamento,
gerenciam e controlam o envolvimento das partes interessadas.

MSc. Eng. Jos Francisco Resende da Silva

28

Essas reas de conhecimento abrigam 47 processos conforme abaixo:

MSc. Eng. Jos Francisco Resende da Silva

29

Num grupo de processos, os processos individuais so ligados por suas


entradas e sadas. Considerando-se estas ligaes, podemos descrever cada processo
em termos de:
Entradas documentos ou itens documentveis que influenciaro o
processo.
Ferramentas e tcnicas mecanismos aplicados s entradas para criar
as sadas.
Sadas documentos ou itens documentveis resultantes do processo.
Os processos de gesto de projetos, que so comuns maioria dos
projetos na maioria das reas de aplicao, esto listados a seguir:

MSc. Eng. Jos Francisco Resende da Silva

30

Estes processos podem ser visualizados nos grupos de processos e nas reas
do conhecimento conforme segue abaixo (PMBOK verso 5):

MSc. Eng. Jos Francisco Resende da Silva

31

5.1 Integrao
O gerenciamento de integrao do projeto formado pelos processos e
atividades utilizadas para identificar, definir, unificar e coordenar as aes essenciais
para a finalizao com sucesso do projeto, atendendo s necessidades das partes
interessadas nele.
Desta forma, foca-se na escolha dos pontos em que os esforos sero
concentrados e coordenando o trabalho em geral no projeto.
Os processos de integrao so:
5.1.1

Desenvolver o termo de abertura do Projeto (project charter)

o documento que formaliza o projeto, concedendo ao gerente de projetos a


autoridade para aplicar os recursos da organizao nas atividades previstas. O
termo de abertura normalmente emitido pelo patrocinador (sponsors) do projeto. O
termo de abertura liga o projeto ao trabalho em andamento da organizao,
podendo ser precedido por um estudo de viabilidade ou um plano preliminar. Este
documento envolve a documentao dos requisitos de negcios, dos propsitos do
projeto, das necessidades das partes envolvidas e o resultado do projeto.
5.1.2

Desenvolver o plano de gerenciamento do Projeto

Este documento define as formas de execuo, monitorao, controle e


encerramento do projeto, e inclui:
O plano de gerenciamento pode incluir um ou mais planos auxiliares, tais
como:
5.1.3

Dirigir e orientar o trabalho do projeto

Este processo exige que a equipe do projeto, incluindo seu gerente, realize
vrias aes para a execuo do plano de gerenciamento, incluindo:
5.1.4

Monitorar e controlar o trabalho do Projeto

Este processo inclui a coleta, medio e disseminao de informaes sobre o


desempenho do projeto, permitindo que a equipe tenha uma viso sobre o seu
andamento e identificando reas que merecem uma ateno especial. Inclui:
5.1.5

Realizar o Controle integrado de mudanas

Este processo executado desde o incio at a finalizao do projeto, e torna-se


bastante importante pelo fato de que normalmente a execuo do projeto no segue
com toda a preciso, por diversos motivos, o seu plano de gerenciamento.
Para isso necessrio que o plano de gerenciamento, a declarao de escopo e
outros documentos cautelosamente gerenciem suas mudanas, minimizando
potenciais riscos ao projeto.

MSc. Eng. Jos Francisco Resende da Silva

32

5.1.6

Encerrar o projeto ou fase

Este processo inclui a finalizao de todas as atividades encerradas em todos os


grupos e processos de gerenciamento, de forma a formalizar o trmino do projeto,
estabelecendo os procedimentos para a verificao e documentao das entregas,
validando-as com as partes envolvidas.
So desenvolvidos dois procedimentos necessrios:
Encerramento administrativo: detalha todas as atividades, funes e
responsabilidades nas tarefas de encerramento administrativo do projeto,
documentando seus registros, analisando seu sucesso ou fracasso e
arquivando informaes teis, tais como lies aprendidas, para uso
futuro pela organizao.
Encerramento dos contratos: este procedimento detalha as atividades
necessrias para o encerramento de todos os contratos estabelecidos
para o projeto, verificando as entregas realizadas e documentando os
procedimentos administrativos realizados.

5.2 Escopo
O gerenciamento do escopo formado por processos utilizados para assegurar
que o projeto utilize todo o trabalho necessrio, e nenhum a mais, para sua finalizao
com xito, controlando o que est e o que no est includo nas suas definies.
formado pelos seguintes processos:
5.2.1

Planejar gerenciamento de Escopo

o processo de criao de um plano de gerenciamento do escopo que


documenta como o escopo ser definido, validado e controlado

5.2.2

Coletar os Requisitos

Processo de definir e documentar as funes e funcionalidades do projeto e do


produto necessrias para atender as necessidades e expectativas das partes
interessadas. O sucesso do projeto diretamente influenciado pela ateno na captura
e gerenciamento dos requisitos do projeto e produto. Os requisitos incluem as
necessidades quantificadas e documentadas, e as expectativas do patrocinador, cliente
e outras partes interessadas.
Estes requistos precisam ser obtidos, analisados e registrados com detalhes
suficientes para serem medidos uma vez que a execuo do projeto se inicie. Coletar
os requisitos definir e gerenciar as expectativas do cliente. Estes requisitos se
transformam na fundao da EAP. O planejamento do Custo, cronorama e da
qualidade so todos construdos com base nestes requisitos. O desenvolvimento dos
requisitos comea com uma analise da informao contida no termo de abertura do
projeto e nos registros das Partes interessadas.

MSc. Eng. Jos Francisco Resende da Silva

33

5.2.3

Definir o escopo

Esta declarao fundamental para o sucesso do projeto. Sendo desenvolvida a


partir das principais entregas, premissas e restries. Nesta fase, as necessidades e
expectativas das partes interessadas so analisadas e documentadas, incluindo-se
novas premissas e restries de acordo com o andamento do planejamento. Esta
declarao de escopo detalhada servir como base para as futuras decises do
projeto.
5.2.4

Criar a EAP

A EAP uma subdiviso das principais atividades do projeto em partes menores


e melhor gerenciveis, em que cada nvel descendente representa um detalhamento
maior do trabalho do projeto.
Desta forma, possvel ver o cronograma, custos, monitorar e controlar o
trabalho planejado, representado na declarao de escopo aprovada anteriormente, e
permitindo as partes interessadas a visualizar as entregas.
5.2.5

Validar o escopo

o processo de obteno do aceite formal do escopo do projeto terminado e


das entregas, checando se cada uma delas foi finalizada de forma satisfatria.
5.2.6

Controlar do escopo

Este processo influencia nos fatores que criam mudanas no escopo do projeto,
e garante que as mudanas solicitadas e aes corretivas recomendadas sejam
executadas.

5.3 Tempo
Os processos de gerenciamento do tempo so aqueles utilizados para a
execuo do projeto no prazo estabelecido, e incluem:
5.3.1

Planejar Gerenciamento do tempo.

Este o processo que estabelece as polticas, procedimentos e documentao


para o planejamento, desenvolvimento, gesto e controle do cronograma do projeto.
5.3.2

Definir as atividades

Este processo identifica as atividades mais especficas da WBS (pacotes de


trabalho), decompondo-as em componentes menores, as atividades do cronograma.
Desta forma possvel elaborar o cronograma do projeto, monitorar a execuo e o
controle do projeto, especificando tambm as entregas.

MSc. Eng. Jos Francisco Resende da Silva

34

5.3.3

Sequenciar as atividades

O Sequenciamento envolve a identificao e o estabelecimento de


relacionamentos lgicos entre as atividades do cronograma, utilizando relaes de
precedncia adequadas, dando suporte a um cronograma real e factvel.
5.3.4

Estimativa de recursos da atividade

Este processo responsvel pela determinao do tipo e quantidade de


recursos (pessoas, equipamentos e material) necessrios para a realizao do projeto,
bem como quando cada recurso dever estar disponvel para a realizao das suas
atividades, sendo intrinsecamente ligado estimativa de custos do projeto.
5.3.5

Estimar as duraes das atividades

Este processo tem como objetivo especificar o nmero de perodos de trabalho


necessrios para o trmino das atividades previstas no cronograma, utilizando como
base o escopo do trabalho da atividade, os tipos de recursos necessrios e a
disponibilidade dos recursos necessrios, documentando todas as premissas utilizadas
nesta estimativa.
5.3.6

Desenvolver o cronograma

O processo de desenvolvimento do cronograma determina as datas iniciais e


finais para a execuo de cada atividade do projeto, sendo iterativo e contnuo durante
todo o projeto, analisando os recursos necessrios, restries e seqncias de
atividades.
5.3.7

Controlar o cronograma

O processo de controle do cronograma relaciona-se com a anlise do seu


andamento, o controle dos fatores que podem gerar impactos, a determinao de
mudana no cronograma e o gerenciamento das mudanas conforme a sua ocorrncia.

5.4 Custos
Os processos de gerenciamento dos custos so aqueles utilizados para a
execuo do projeto dentro do oramento estabelecido, incluindo o planejamento,
estimativa, oramentao e controle. So eles:
5.4.1

Planejar o Gerenciamento de Custo

O plano de gerenciamento de custos um componente do plano de


gerenciamento do projeto e descreve como os custos do projeto sero planejados,
estruturados e controlados. Os processos de gerenciamento de custos e suas
ferramentas e tcnicas associadas so documentados no plano de gerenciamento de
custos..
MSc. Eng. Jos Francisco Resende da Silva

35

5.4.2

Estimar os custos

O processo de estimativa de cursos formado pela determinao aproximada


dos recursos necessrios para a finalizao de cada uma das atividades do
cronograma. Normalmente, a exatido desta estimativa aumenta na medida em que o
projeto se desenvolve. Por exemplo, estimativas iniciais podem ter uma variao de
50 %, enquanto que numa fase mais madura do projeto esta variao pode cair para
10 %.
Os custos so estimados para todas as atividades cujos recursos sejam
utilizados, sejam pessoas, materiais, equipamentos e instalaes, alm de previso
para custos especiais como contingncia ou mesmo o efeito da inflao.
5.4.3

Determinar o Oramento

O processo de oramentao implica na consolidao dos custos estimados das


atividades, de forma a estabelecer uma linha de base dos custos totais para a medio
do desempenho do projeto.
5.4.4

Controlar os custos

O processo de controle de custos do projeto busca as causas das variaes


positivas e negativas dos custos.

5.5 Qualidade
Segundo a American Society for Quality, a qualidade o grau at o qual um
conjunto de caractersticas inerentes satisfaz as necessidades.
Um elemento muito importante no gerenciamento da qualidade a
transformao das necessidades das partes interessadas em requisitos do projeto,
durante o seu gerenciamento de escopo.
So pressupostos da gerncia da qualidade:
Satisfao do cliente.
Preveno sobre inspeo.
Responsabilidade da gerncia.
Melhoria contnua.
Os processos de gerenciamento da qualidade do projeto implementam os
procedimentos de planejamento da qualidade, garantia da qualidade e controle da
qualidade, com atividades de melhoria contnua dos processos, fazendo com que o
projeto atenda s necessidades que geraram a sua execuo. Incluem:

MSc. Eng. Jos Francisco Resende da Silva

36

5.5.1

Planejar gerenciamento da qualidade

O planejamento da qualidade inclui a identificao de padres de qualidade


relevantes para o projeto, bem como a especificao de como satisfaz-los. Deve ser
realizado em paralelo com outros processos de planejamento, tais como o
desenvolvimento do plano de gerenciamento do projeto, e seguem um dos princpios
fundamentais do gerenciamento da qualidade, no qual se define que a qualidade
planejada, projetada e incorporada, e no inspecionada.
5.5.2

Realizar a Garantia da qualidade

O processo de garantia da qualidade inclui a aplicao de atividades de


qualidade sistemticas planejadas de forma a garantir que o projeto empregar todos
os processos necessrios para o atendimento aos requisitos estabelecidos no seu
planejamento.
5.5.3

Controlar a qualidade

Os processos de controle da qualidade executam o monitoramento de resultados


especficos do projeto, chegando se os mesmos esto aderentes aos padres de
qualidade estabelecidos, identificando formas de eliminar resultados insatisfatrios e
sendo realizado durante todo o projeto. Os padres de qualidade incluem as entregas
do projeto e resultados do seu gerenciamento, tais como custos e prazos. Alm disso,
devem-se utilizar ferramentas de controle estatstico de qualidade, de forma a avaliar
os ndices obtidos.

5.6 Recursos Humanos


Os processos de gerenciamento de recursos humanos so aqueles utilizados
para a organizao e gerenciamento da equipe do projeto, e incluem:
5.6.1

Planejar o gerenciamento dos Recursos Humanos

Este processo especifica funes, responsabilidades e relaes hierrquicas do


projeto, criando tambm o seu plano de gerenciamento de pessoal, sendo que as
funes podem ser delegadas a pessoas ou grupos, internos ou externos
organizao executora.
O plano de gerenciamento de pessoal vai especificar como e quando os
membros da equipe do projeto sero contratados ou alocados, os critrios para sua
liberao para o projeto, suas necessidades de treinamento, critrios para
reconhecimento e premiao, consideraes sobre conformidade e segurana e o seu
impacto na organizao.

MSc. Eng. Jos Francisco Resende da Silva

37

5.6.2

Adquirir a equipe do projeto

Este processo responsvel pela obteno dos recursos humanos necessrios


para a execuo do projeto, e a equipe de gerenciamento pode ou no ter controle
sobre os membros selecionados para o projeto.
5.6.3

Desenvolver a equipe do projeto

Este processo responsvel pela melhoria das competncias dos membros,


atravs do aprimoramento das habilidades com o objetivo de aumentar a capacidade
de executar as atividades do projeto, e a sua interao para o aprimoramento do
desempenho do projeto, atravs de sentimentos de confiana e coeso entre os
membros, aumentando a produtividade da equipe.
Estes esforos apresentam maiores benefcios quando realizados no incio do
projeto, mas no devem ser negligenciados com o passar do tempo.
5.6.4

Gerenciar a equipe do projeto

Este processo envolve o acompanhamento do desempenho dos membros da


equipe, fornecimento de feedback, resoluo de problemas e coordenao de
mudanas para a melhoria do desempenho do projeto. O resultado deste processo a
atualizao do plano de gerenciamento de pessoal e a documentao de informaes
teis para serem adicionadas como lies aprendidas para a organizao.

5.7 Comunicaes
Os processos de gerenciamento das comunicaes so aqueles que garantem
planejamento, coleta, gerao, distribuio, armazenamento, recuperao,
gerenciamento controle, monitoramento e destinao final das informaes do
projeto, entre a equipe do projeto e partes interessadas, e incluem:
5.7.1

Planejar o Gerenciamento da comunicao

Este processo responsvel pelo desenvolvimento de uma abordagem


adequada e um plano de comunicaes do projeto com base em informaes das
necessidades e requisitos das partes interessadas e dos ativos organizacionais
disponveis.
5.7.2

Gerenciar a comunicao

Este processo visa a criao, coleta, distribuio, armazenamento, recuperao


e a disposio final das informaes do projeto de acordo com o plano de
gerenciamento das comunicaes.

MSc. Eng. Jos Francisco Resende da Silva

38

5.7.3

Controlar a Comunicao

Este processo visa o monitoramento e controle das comunicaes ao longo de


todo o ciclo de vida do projeto para garantir que as necessidades de informao das
partes interessadas no projeto sero cumpridos.

5.8 Riscos
Os processos de gerenciamento de riscos so aqueles que garantem a
identificao, anlise, respostas, monitoramento e controle e planejamento do
gerenciamento de riscos em um projeto, aumentando a probabilidade e o impacto dos
eventos positivos e diminuindo a probabilidade e o impacto dos eventos negativos para
o projeto. Riscos podem ser definidos como eventos que, se acontecerem, tero
impactos negativos ou positivos em relao aos objetivos do projeto, como prazo,
custo, escopo ou qualidade.
Podem ter uma ou mais causas, e caso ocorram, um ou mais impactos. Os
riscos so originrios da incerteza que est presente em todos os projetos, sendo
divididos em riscos conhecidos e desconhecidos. Os conhecidos podem ser tratados
de acordo com as tcnicas descritas no PMBOK, enquanto que os desconhecidos no
podem ser gerenciados de forma pr-ativa, sendo necessria a alocao de uma
reserva contingencial.
Os processos de gerenciamento de riscos do projeto incluem os seguintes:
5.8.1

Planejar o gerenciamento dos riscos

O processo de planejamento decide como abordar e executar as atividades de


gerenciamento de riscos do projeto, devendo ser executado no incio do planejamento
do projeto. Este planejamento importante para garantir que o nvel, tipo e visibilidade
do gerenciamento estejam de acordo com o risco e a importncia do projeto para a
organizao, permitindo tempo e recursos para este gerenciamento e para o
estabelecimento de uma base de avaliao de riscos.
5.8.2

Identificar os riscos

Este processo identifica e documenta os riscos que podem afetar o projeto,


sendo uma tarefa que pode envolver toda a equipe do projeto, partes interessadas e
especialistas externos. um processo iterativo, j que novos riscos podem aparecer
durante o projeto, e torna-se importante o envolvimento de toda a equipe, para que seja
desenvolvido nela um sentimento de responsabilidade em relao aos riscos e s
aes de resposta associadas.
5.8.3

Realizar a anlise qualitativa de riscos

O processo de anlise qualitativa avalia a prioridade dos riscos identificados no


processo anterior, utilizando a probabilidade de eles acontecerem, o seu impacto nos
objetivos do projeto e fatores como o prazo e a tolerncia a risco das restries de
MSc. Eng. Jos Francisco Resende da Silva

39

custo, cronograma, escopo e qualidade do projeto. Esta anlise permite uma rpida
priorizao para o planejamento das respostas a riscos, estabelecendo a base para
uma anlise quantitativa dos mesmos.
5.8.4

Realizar a anlise quantitativa de riscos

Este processo analisa o efeito dos eventos de risco priorizados pela anlise
qualitativa, atribuindo uma classificao numrica a eles e apresentando uma
abordagem quantitativa para a tomada de decises num ambiente de incerteza. Esse
processo possibilita:
A quantificao dos possveis resultados do projeto e suas probabilidades
A avaliao da probabilidade de alcance dos objetivos especficos
estabelecidos
A identificao dos riscos mais relevantes
A identificao de metas realistas de custo, cronograma e escopo
A determinao das melhores decises em condies incertas
5.8.5

Planejar as respostas aos riscos

Este processo desenvolve opes e aes para o aumento das oportunidades e


reduo das ameaas aos objetivos do projeto, sendo realizado aps as anlises
qualitativas e quantitativas de riscos do projeto. Este planejamento gerencia os riscos
de acordo com sua prioridade, a partir da insero, quando necessria, de recursos e
atividades no oramento, cronograma e plano de gerenciamento. Alm disso, as
respostas devem ser adequadas priorizao do risco, para que no haja desperdcios
de recursos no contexto do projeto.
5.8.6

Controlar os riscos

Este processo identifica, analisa e planeja riscos recm-surgidos, acompanha os


riscos identificados, monitora o acionamento dos planos de contingncia e revisa a
execuo dos planos de resposta aos riscos, bem como avalia sua eficcia durante
toda a durao do projeto.
Outros objetivos deste processo so:
A determinao se as premissas do projeto continuam vlidas.
Se o risco permanece ou no no seu estgio avaliado, observando suas
tendncias.
Se os procedimentos de gerenciamento riscos esto sendo seguidos.
Se as reservas de contingncia devem ser alteradas, dado os riscos do
projeto.
Este processo tambm pode envolver a escolha de caminhos alternativos,
execuo de planos de contingncia, realizao de aes corretivas e modificaes no
plano de gerenciamento do projeto.

MSc. Eng. Jos Francisco Resende da Silva

40

5.9 Aquisies
Os processos de gerenciamento de aquisies so aqueles que possibilitam a
obteno de produtos ou servios externos, necessrios execuo do projeto. Estes
processos tambm incluem a administrao dos contratos e o controle das mudanas
necessrias para administrao dos contratos ou pedidos de compra solicitados por
membros da equipe do projeto.
Estes processos envolvem contratos, documentos legais entre compradores e
fornecedores que geram obrigaes entre as partes (o fornecedor entrega produtos,
servios ou resultados especificados e recebe em troca uma compensao monetria
ou outro valor).
A equipe do projeto deve tornar o contrato aderente s necessidades especficas
do projeto, e este pode incluir itens como a proposta ou catlogos do fornecedor, de
forma a documentar o escopo do fornecimento.
Os processos de gerenciamento de aquisies do projeto incluem:
5.9.1

Planejar o Gerenciamento das aquisies

Este processo identifica quais necessidades do projeto so mais bem atendidas


atravs do fornecimento externo, e quais podem ser atendidas internamente pela
equipe do projeto, selecionando como, o que, quanto, se e quando a aquisio ser
realizada.
O processo de planejamento de compras e aquisies pode ser bastante
influenciado pelo cronograma do projeto, e tambm inclui a anlise dos riscos
envolvidos nas decises de aquisio. A anlise do tipo de contrato a ser utilizado
tambm um fator importante para a diminuio dos riscos envolvidos na contratao.
5.9.2

Conduzir as aquisies

o processo de obteno das respostas dos fornecedores, seleo de um


fornecedor e adjudicao de um contrato. Nesse processo, a equipe receber licitaes
ou propostas e aplicar critrios de seleo previamente definidos para escolher um ou
mais fornecedores que sejam qualificados para realizar o trabalho e aceitveis como
fornecedor.
5.9.3

Controlar as Aquisies

o processo de gerenciar as relaes de aquisio, monitorar o desempenho do


contrato e fazer mudanas e correes conforme necessrio. Tanto o comprador como
o fornecedor, administra o contrato de aquisio para objetivos semelhantes. Cada um
precisa assegurar que as duas partes cumpram suas obrigaes contratuais e que
seus prprios direitos legais sejam protegidos. O processo de administrao das
aquisies que o desempenho do fornecedor cumpra os requisitos da aquisio e que
o comprador cumpra os termos do contrato legal.

MSc. Eng. Jos Francisco Resende da Silva

41

5.9.4

Encerrar as Aquisies

Este processo envolve atividades administrativas, confirmando que todo o


trabalho e as entregas foram considerados aceitveis.
No caso de no conformidades, o encerramento pode dar origem a uma
demanda judicial contra o fornecedor.

5.10 Gerenciamento dos Stakeholders do Projeto


O gerenciamento dos stakeholders do projeto inclui os processos necessrios
para identificar as pessoas, os grupos, as organizaes que possam afetar ou ser
afetados pelo projeto, para analisar as expectativas dos stakeholders e seu impacto
sobre o projeto e para desenvolver estratgias de gesto adequadas para engajar
efetivamente os stakeholders nas decises de projeto e execuo.
Gerenciamento das partes interessadas tambm se concentra em comunicao
contnua com os stakeholders para entender suas necessidades e expectativas,
abordando questes como elas ocorrem, administrar interesses conflitantes e promover
entre os stakeholders o engajamento nas decises e atividades do projeto. A satisfao
dos Stakeholders devem ser geridos como um objetivo-chave do projeto.
Os processos de gerenciamento dos Stakeholders do projeto incluem:
5.10.1 Identificao dos Stakeholders

Este processo identifica as pessoas, grupos,ou organizaes que impactam ou


sero impactados por uma deciso, atividade ou resultado do projeto, e analisar e
documentar informaes relevantes em relao aos interesses, envolvimento,
interdependncia, influencia, e potencial impacto no sucesso do projeto.
5.10.2 Planejar Gerenciamento de Stakeholders

o processo de desenvolvimento de estratgias apropriadas durante todo o


ciclo de vida do projeto, com base na analise de suas necessidades, interesses, e
potencial impacto no sucesso do projeto.
5.10.3 Gerenciar o Envolvimento dos Stakeholders

o processo de comunicao e de trabalho com as partes interessadas para


atender s suas necessidades / expectativas, abordando questes como elas ocorrem,
e promover o engajamento adequado dos stakeholders nas atividades do projeto ao
longo de seu ciclo de vida.
5.10.4 Controlar o Envolvimento dos Stakeholders

o processo de acompanhamento das relaes gerais dos stakeholders com o


projeto e das estratgias de ajustes e planos para envolver as partes interessadas.

MSc. Eng. Jos Francisco Resende da Silva

42

6. Estrutura Analtica de Projetos


(EAP)
A ferramenta utilizada para a definio do escopo a Estrutura Analtica do
Projeto (EAP), traduo para o portugus de Work Breakdown Structure (WBS). Aps
ser elaborada e aprovada, ela passa a ser a base de referncia do escopo do projeto.
A EAP uma estrutura hierrquica, podendo ser representada como uma lista
identada ou na forma grfica (semelhante a um organograma). Para usar a forma
grfica, que de melhor visualizao, o gerente do projeto necessita utilizar uma
ferramenta que auxilie o desenho.
MSc. Eng. Jos Francisco Resende da Silva

43

Para a maioria dos gerentes que utilizam o MS/Project, que no tem esse
recurso, til usar uma ferramenta de apoio (add-in), como, por exemplo, o EAP Chart
Pro da Critical Tools Corporation (www.criticaltools.com) e outros. Porm, a lista
identada disponvel no MS/Project ou em qualquer editor de textos ou planilha
eletrnica tambm pode ser utilizada para representar a EAP.
A decomposio consiste em ir detalhando (decompondo) os subprodutos
(deliverables) em componentes menores, at que eles estejam em um nvel de detalhe
que permita o gerenciamento (planejamento, execuo e controle) do trabalho do
projeto. A tcnica top-down (de cima para baixo). O primeiro nvel da EAP chamado
nvel de projeto.

6.1 Os passos para a Elaborao de uma EAP


a) Colocar no primeiro nvel (nvel zero) da EAP o nome do projeto.

b) Colocar no segundo nvel (nvel 1, tambm chamado de primeiro nvel de


decomposio ) as fases que estabelecem o ciclo de vida do projeto

Este o mais comum e mais fcil mtodo de desenvolver a EAP. Uma grande
vantagem que a EAP resultante pode ser usada como modelo (template) para muitos
projetos. Sugere-se que as fases do ciclo de vida do projeto podem ser usadas como
primeiro nvel de decomposio, com os subprodutos do projeto repetidos no segundo
nvel. Porm, no quer dizer que esta seja sempre a melhor forma de decompor
inicialmente o projeto.
Alm de ter a possibilidade de ser por fases, a decomposio inicial, assim como
a decomposio em qualquer nvel, pode ser por subprodutos (ex.: decompor uma
bicicleta em suas partes principais), por sistema funcional (ex.: sistema eltrico,
sistema hidrulico, sistema mecnico...), por localizao fsica (ex.: regio nordeste,
regio sul...), por Unidade Administrativa a executar (ex.: divises, departamentos ...)
ou at mesmo por cliente (ex.: de acordo com a fiscalizao). uma prtica usual
colocar no segundo nvel da EAP (primeiro nvel de decomposio) um elemento
referente ao Gerenciamento do Projeto.

MSc. Eng. Jos Francisco Resende da Silva

44

Acrescentar um elemento, no segundo nvel (tambm chamado de primeiro nvel


de decomposio), para conter os deliverables necessrios ao gerenciamento do
projeto.

O trabalho de Gerenciamento deve ser previsto no escopo do projeto e, portanto,


na EAP. Identificar os subprodutos que devam ser entregues para que seja alcanado
o sucesso do projeto em cada fase (ou outra forma de decomposio).
Nesta hora devemos consultar os documentos de alto nvel que guiam o escopo
do projeto (Project Charter) assim como entrevistar clientes e usurios. Caso o nmero
de subprodutos no nvel filho fique muito grande (mais de oito), eles devem ser
agrupados, aumentando em mais um nvel a EAP.
Para cada subproduto, verificar se as estimativas de custo, durao e risco
podem ser desenvolvidas neste nvel de detalhe e se pode ser atribuda a
responsabilidade para a execuo do mesmo. Se a resposta for negativa, decompuser
o elemento da EAP, subdividindo-o em componentes menores, mais manejveis, at
que os subprodutos estejam definidos em detalhe suficiente para suportar o
desenvolvimento dos processos de gerenciamento do projeto (planejar, executar,
controlar e encerrar).
Os elementos nos nveis mais baixos da EAP (aqueles que no foram
decompostos) so denominados pacotes de trabalho (work packages), sendo a base
lgica para a definio de atividades, designao de responsabilidades, estimativa de
custos e planejamento de riscos.
No necessrio que a EAP seja simtrica, ou seja, que todos os subprodutos
sejam decompostos at o mesmo nvel.
Rever e refinar a EAP at que os principais envolvidos (stakeholders) concordem
que o planejamento do projeto pode ser completado com sucesso e que a gerncia e
controle iro produzir os resultados esperados, verificando tambm se esto sendo
atendidos os dez mandamentos da EAP (citados no fim desta apostila).
O MESMO ESCOPO DE UM PROJETO, SOB AS
MESMAS CONDIES, SER REPRESENTADO DIFERENTEMENTE
NA EAP POR DEZ DIFERENTES
EQUIPES DE PROJETO OU, PELA MESMA EQUIPE
DE PROJETO, EM DEZ DIFERENTES OCASIES

6.2 Top-down X Bottom-up


MSc. Eng. Jos Francisco Resende da Silva

45

Acima foi apresentada uma estratgia para elaborao de uma EAP, utilizando a
tcnica top-down (de cima para baixo). Algumas equipes de gerenciamento de projetos
preferem, no entanto, trabalhar com a abordagem bottom-up (de baixo para cima).
O uso da abordagem bottom-up consiste em criar uma lista dos subprodutos
(deliverables) do projeto e depois ir agrupando os mesmos at chegar ao nvel 1 (nvel
de projeto) da EAP. Com essa abordagem voc pode no conseguir uma viso
completa do projeto, sendo possvel voc esquecer algum subproduto.
Se voc achar que voc (ou sua equipe) tenha mais facilidade, em determinado
projeto, para utilizar a abordagem bottom-up, aqui esto os passos para a construo
da EAP:
a) Liste os subprodutos do projeto.
b) Agrupe os subprodutos relacionados entre si para criar um nvel acima
que contenha de dois a oito subprodutos por grupo. O nome do elemento
superior, criado em razo do agrupamento, deve sintetizar as entregas
dos elementos agrupados.
c) Agrupe o nvel mais alto do passo 2, para criar um nvel acima, se
possvel, tambm contendo de dois a oito elementos.
d) Repita o agrupamento at que voc chegue ao nvel de projeto.
e) Revise a EAP perguntando: Est faltando alguma entrega do projeto?
f) Confira a EAP utilizando os dez mandamentos citados.

6.3 Pacotes de Trabalho


Os elementos no decompostos em uma EAP so chamados de pacotes de
trabalho (Work Packages). Por exemplo, na figura abaixo, facilmente identificados
como as folhas da rvore, os pacotes de trabalho, que esto assinalados com uma
seta, so: Documentao; Estrutura; Placa-Me; Disco Rgido; Fonte; Montagem; Teste
Sistema; Sistema Operacional; e Gerenciamento do Projeto.

MSc. Eng. Jos Francisco Resende da Silva

46

7. O Gerenciamento das atividades.


O gerenciamento das atividades do projeto inclui os processos necessrios para
sequenciar as atividades e concluir o projeto a tempo.
1.
2.
3.
4.
5.
6.

Definio da atividade
Sequenciamento de atividades
Estimativa de recursos da atividade
Estimativa de durao da atividade
Desenvolvimento do cronograma
Controle do cronograma

Em alguns projetos, especialmente nos de menor escopo, o seqenciamento de


atividades, a estimativa de recursos da atividade, a estimativa de durao da atividade
e o desenvolvimento do cronograma esto to estreitamente ligados que so
considerados um nico processo, que pode ser realizado por uma pessoa durante um
perodo de tempo relativamente curto. Esses processos so apresentados aqui como
MSc. Eng. Jos Francisco Resende da Silva

47

processos distintos porque as ferramentas e tcnicas para cada um deles so


diferentes.
Embora no seja mostrado aqui como um processo distinto, o trabalho envolvido
na realizao dos seis processos de gerenciamento de tempo do projeto precedido
por um esforo de planejamento da equipe de gerenciamento de projetos.

7.1 Definio da Atividade


A definio das atividades do cronograma envolve identificar e documentar o
trabalho planejado para ser realizado. O processo Definio da atividade identificar as
entregas no nvel mais baixo da estrutura analtica do projeto (EAP, conforme visto
anteriormente), a que chamamos de pacote de trabalho. Os pacotes de trabalho do
projeto so planejados (decompostos) em componentes menores, chamados de
atividades do cronograma, para fornecer uma base para a estimativa, elaborao de
cronogramas, execuo, e monitoramento e controle do trabalho do projeto. A definio
e o planejamento das atividades do cronograma de forma que os objetivos do projeto
sejam atendidos esto implcitos neste processo.
A tcnica de decomposio, conforme aplicada definio da atividade,
envolve a subdiviso dos pacotes do trabalho do projeto em componentes menores e
mais facilmente gerenciveis chamados de atividades do cronograma.
Cada pacote de trabalho dentro da EAP decomposto nas atividades do
cronograma necessrias para produzir as entregas do pacote de trabalho.
Essa definio da atividade freqentemente realizada pelos membros da
equipe do projeto responsveis pelo pacote de trabalho.
Uma lista de atividades padro ou uma parte de uma lista de atividades de um
projeto anterior so frequentemente usadas como um modelo de um novo projeto. As
informaes sobre os atributos da atividade relacionados nos modelos tambm podem
conter uma lista de habilidades de recursos e de suas horas necessrias de esforo,
identificao de riscos, entregas esperadas e outras informaes descritivas. Os
modelos tambm podem ser usados para identificar marcos tpico do cronograma.
A EAP e o dicionrio da EAP refletem a evoluo do escopo do projeto conforme
ele se torna mais detalhado, at chegar ao nvel de pacote de trabalho.
O planejamento em ondas sucessivas uma forma de planejamento de
elaborao progressiva em que o trabalho que ser realizado em curto prazo
planejado em detalhes em um nvel baixo da EAP, enquanto o trabalho distante no
futuro planejado para os componentes da EAP que esto em um nvel relativamente
alto da EAP.
O trabalho a ser realizado dentro de um ou dois perodos de relatrio no futuro
prximo planejado em detalhes conforme o trabalho est sendo terminado durante o
perodo atual.
Portanto, as atividades do cronograma podem existir em vrios nveis de
detalhes no ciclo de vida do projeto.

MSc. Eng. Jos Francisco Resende da Silva

48

Durante o planejamento estratgico inicial, quando as informaes esto menos


definidas, as atividades podem ser mantidas no nvel de marcos.
Os membros da equipe do projeto ou outros especialistas, que so experientes e
especializados no desenvolvimento de declaraes de escopo detalhadas do projeto,
EAPs e cronogramas do projeto, podem fornecer a especializao para definir as
atividades.
Quando a definio do escopo do projeto disponvel insuficiente para
decompor um ramo da EAP at o nvel de pacote de trabalho, o ltimo componente
nesse ramo da EAP pode ser usado para desenvolver um cronograma do projeto de
alto nvel para esse componente.
Esses componentes do planejamento so selecionados e usados pela equipe do
projeto para planejar e agendar o trabalho futuro em vrios nveis mais altos dentro da
EAP. As atividades do cronograma usadas para esses componentes do planejamento
podem ser atividades de resumo, que so insuficientes para dar suporte estimativa,
elaborao de cronogramas, execuo, monitoramento ou controle detalhados do
trabalho do projeto.
Um ponto de controle gerencial pode ser colocado em pontos de gerenciamento
selecionados (componentes especficos em nveis selecionados) da estrutura analtica
do projeto acima do nvel do pacote de trabalho. Esses pontos de controle so usados
como uma base para o planejamento quando os pacotes de trabalho associados ainda
no tiverem sido planejados. Todo o trabalho e o esforo realizados dentro de uma
conta de controle so documentados em um plano de contas de controle.
A lista de atividades uma lista abrangente que inclui todas as atividades do
cronograma planejadas para serem realizadas no projeto. A lista de atividades no
inclui as atividades do cronograma que no so necessrias como parte do escopo do
projeto.
A lista de atividades inclui o identificador da atividade e uma descrio do
escopo do trabalho para cada atividade do cronograma suficientemente detalhados
para garantir que os membros da equipe do projeto compreendam que trabalho
precisar ser terminado. O escopo do trabalho da atividade do cronograma pode estar
em termos fsicos, como metros lineares de cano que sero instalados, colocao
designada de concreto, nmero de desenhos, linhas de cdigo de programa de
computador ou captulos de um livro.
A lista de atividades usada no modelo de cronograma e um componente do
plano de gerenciamento do projeto. As atividades do cronograma so componentes
distintos do cronograma do projeto, mas so componentes da EAP.
Esses atributos da atividade so uma extenso dos atributos da atividade da lista de
atividades e identificam os vrios atributos associados a cada atividade do cronograma.
Os atributos da atividade para cada atividade do cronograma incluem
identificadores da atividade, cdigos de atividades, descrio da atividade, atividades
predecessoras, atividades sucessoras, relacionamentos lgicos, antecipaes e
atrasos, recursos necessrios, datas impostas, restries e premissas.
Os atributos da atividade podem tambm incluir a pessoa responsvel pela
execuo do trabalho, a rea geogrfica ou o local onde o trabalho precisa ser

MSc. Eng. Jos Francisco Resende da Silva

49

realizado e o tipo de atividade do cronograma, como nvel de esforo, esforo distinto e


esforo distribudo.
Esses atributos so usados para o desenvolvimento do cronograma do projeto e
para a seleo, ordenamento e classificao das atividades planejadas do cronograma
de vrias maneiras dentro dos relatrios.
O nmero de atributos varia por rea de aplicao.
Os atributos da atividade so usados no modelo de cronograma.
A lista de marcos do cronograma identifica todos os marcos e indica se o marco
obrigatrio (exigido pelo contrato) ou opcional (com base em requisitos do projeto ou
em informaes histricas).

7.2 Sequenciamento de Atividades


O sequenciamento de atividades envolve a identificao e documentao dos
relacionamentos lgicos entre as atividades do cronograma.
As atividades do cronograma podem ser sequenciadas logicamente usando as
relaes de precedncia adequadas, alm de antecipaes e atrasos, para dar suporte
ao desenvolvimento posterior de um cronograma do projeto realista e alcanvel.
O sequenciamento pode ser realizado usando um software de gerenciamento de
projetos ou tcnicas manuais.
As tcnicas manuais e automatizadas tambm podem ser usadas em conjunto.
a) Mtodo do diagrama de precedncia (MDP) - O MDP um mtodo de
construo de um diagrama de rede do cronograma do projeto que usa caixas
ou retngulos, chamados de ns, para representar atividades e os conecta
por setas que mostram as dependncias. A figura abaixo mostra um diagrama
de rede do cronograma do projeto simples desenhado usando o MDP.
Esta tcnica tambm chamada de atividade no n (ANN) e o mtodo usado pela
maioria dos pacotes de software de gerenciamento de projetos.
O MDP inclui quatro tipos de dependncias ou de relaes de precedncia:
- Trmino para incio:
A iniciao da atividade sucessora depende do trmino da atividade
predecessora.
- Trmino para trmino:
O trmino da atividade sucessora depende do trmino da atividade
predecessora.
- Incio para incio:
A iniciao da atividade sucessora depende da iniciao da atividade
predecessora.
- Incio para trmino:

MSc. Eng. Jos Francisco Resende da Silva

50

O trmino da atividade sucessora depende da iniciao da atividade


predecessora.

No MDP, trmino para incio o tipo mais comumente usado de relao de


precedncia. As relaes do tipo incio para trmino so raramente usadas.
b) Mtodo do diagrama de setas (MDS) - O MDS um mtodo de construo
de um diagrama de rede do cronograma do projeto que usa setas para
representar atividades e as conecta nos ns para mostrar suas dependncias.
A Figura abaixo mostra um diagrama de lgica de rede simples desenhado
usando MDS. Esta tcnica tambm chamada de atividade na seta (ANS) e,
embora menos adotada do que o MDP, ainda usada no ensino da teoria de
rede do cronograma e em algumas reas de aplicao.

MSc. Eng. Jos Francisco Resende da Silva

51

O MDS usa somente dependncias do tipo trmino para incio e pode exigir o
uso de relacionamentos fantasmas chamados de atividades fantasmas, que so
mostradas como linhas pontilhadas, para definir corretamente todos os
relacionamentos lgicos. Como as atividades fantasmas no so atividades reais do
cronograma (no possuem contedo de trabalho), atribuda a elas uma durao nula
para fins de anlise de rede do cronograma. Por exemplo, na figura acima, a atividade
do cronograma F depende do trmino das atividades do cronograma A e K, e
tambm do trmino da atividade do cronograma H.

7.3 Estimativa de Recursos da Atividade


A estimativa de recursos da atividade do cronograma envolve determinar os
recursos (pessoas, equipamentos ou material) e as quantidades de cada recurso que
sero usados e quando cada recurso estar disponvel para realizar as atividades do
projeto. Por exemplo: A equipe de um projeto de construo precisa estar familiarizada
com os cdigos de construo locais. Esse conhecimento muitas vezes facilmente
obtido dos fornecedores locais. No entanto, se o "pool" de mo-de-obra local no
possuir experincia em tcnicas de construo especializadas ou pouco usuais, a
maneira mais eficaz para obter esse conhecimento dos cdigos de construo locais
pode ser incluir um consultor, com custo adicional.
Uma equipe de design automotivo precisar estar familiarizada com as tcnicas
mais recentes de montagem automatizada. O conhecimento necessrio pode ser
obtido contratando um consultor, enviando um projetista a um seminrio sobre robtica
ou colocando algum da produo como membro da equipe do projeto.
Muitas atividades do cronograma possuem mtodos alternativos de realizao.
MSc. Eng. Jos Francisco Resende da Silva

52

Eles incluem o uso de vrios nveis de capacidade ou habilidades de recursos,


tipos ou tamanhos diferentes de mquinas, ferramentas diferentes (manuais versus
automatizadas) e decises de fazer ou comprar relativas ao recurso.
Diversas empresas publicam rotineiramente os valores de produo e os custos
unitrios atualizados dos recursos para um extenso conjunto de reas, material e
equipamentos em diversos pases e locais geogrficos dentro de pases.
O software de gerenciamento de projetos tem capacidade para ajudar a planejar,
organizar e gerenciar "pools" de recursos e para desenvolver estimativas de recursos.
Dependendo da sofisticao do software, as estruturas analticas dos recursos,
as disponibilidades de recursos e os valores dos recursos podem ser definidos, alm
dos vrios calendrios de recursos.
Quando uma atividade do cronograma no pode ser estimada com um nvel
razovel de confiana, o trabalho dentro da atividade do cronograma decomposto em
mais detalhes. As necessidades de recursos de cada uma das partes inferiores e mais
detalhadas do trabalho so estimadas se essas estimativas so ento agregadas em
uma quantidade total para cada um dos recursos da atividade do cronograma. As
atividades do cronograma podem ou no possuir dependncias entre elas que possam
afetar a aplicao e o uso dos recursos. Se existirem dependncias, esse padro de
utilizao de recursos refletido na estimativa de recursos da atividade do cronograma
e documentado.

7.4 Estimativa de Durao da Atividade


O processo de estimativa de duraes das atividades do cronograma usa as
informaes sobre: escopo de trabalho da atividade do cronograma, tipos de recursos
necessrios, estimativas das quantidades de recursos e calendrios de recursos com
as disponibilidades de recursos.
A estimativa de durao progressivamente elaborada e o processo considera a
qualidade e disponibilidade dos dados de entrada. Por exemplo, conforme a
engenharia do projeto e o trabalho de design se desenvolvem, dados mais precisos e
detalhados ficam disponveis e a exatido das estimativas de durao aumenta. Dessa
forma, a estimativa de durao pode se tornar cada vez mais exata e de melhor
qualidade.
A estimativa de durao da atividade exige que a quantidade de esforo de
trabalho necessria para terminar a atividade do cronograma seja estimada, que a
quantidade prevista de recursos a ser aplicada para terminar a atividade do
cronograma seja estimada e que o nmero de perodos de trabalho necessrio para
terminar a atividade do cronograma seja determinado. Todos os dados e premissas
que do suporte estimativa de durao so documentados para cada estimativa de
durao da atividade.
A estimativa do nmero de perodos de trabalho necessrio para terminar a
atividade do cronograma pode exigir que se considere o tempo de corrido como um
requisito relacionado ao tipo especfico de trabalho.
A maioria dos softwares de gerenciamento de projetos para elaborao de
cronogramas lidar com essa questo usando um calendrio de projeto e calendrios
MSc. Eng. Jos Francisco Resende da Silva

53

de recursos de perodo de trabalho alternativos que geralmente so identificados pelos


recursos que exigem perodos de trabalho especficos.
As atividades do cronograma sero trabalhadas de acordo com o calendrio de
projeto e as atividades do cronograma para as quais os recursos esto atribudos
tambm sero trabalhadas de acordo com os calendrios de recursos adequados.
A estimativa de recursos necessrios para a atividade afetar a durao da
atividade do cronograma, pois os recursos atribudos atividade do cronograma, e a
disponibilidade desses recursos, iro influenciar de forma significativa a durao da
maioria das atividades.
Por exemplo, se uma atividade do cronograma exigir dois engenheiros
trabalhando juntos para terminar de forma eficiente uma atividade de design, mas o
trabalho tiver apenas uma pessoa, a atividade do cronograma levar normalmente pelo
menos o dobro do tempo para ser terminada.
No entanto, conforme so acrescentados recursos adicionais ou recursos menos
especializados so aplicados a algumas atividades do cronograma, a eficincia dos
projetos pode ser reduzida.
Essa ineficincia, por sua vez, pode resultar em um aumento da produo do
trabalho menor do que o aumento percentual equivalente dos recursos aplicados.
As duraes das atividades so frequentemente difceis de estimar devido aos
vrios fatores que podem influenci-las, como nveis de recursos ou produtividade dos
recursos. A opinio especializada, orientada pelas informaes histricas, pode ser
usada sempre que possvel. Os membros individuais da equipe do projeto podem
tambm fornecer informaes sobre estimativa de durao ou sobre duraes mximas
recomendadas das atividades a partir de projetos anteriores semelhantes. Se essa
especializao no estiver disponvel, as estimativas de durao sero mais incertas e
arriscadas.
As estimativas de durao da atividade so avaliaes quantitativas do nmero
provvel de perodos de trabalho que sero necessrios para terminar uma atividade
do cronograma.
As estimativas de durao da atividade incluem alguma indicao da faixa de
resultados possveis. Por exemplo: 2 semanas 2 dias para indicar que a atividade do
cronograma ter uma durao de pelo menos oito dias teis e de no mais do que
doze dias (considerando uma semana de trabalho de cinco dias). 15% de probabilidade
de exceder trs semanas para indicar uma alta probabilidade - 85% - da durao da
atividade do cronograma ser de trs semanas ou menos.
Os atributos da atividade so atualizados para incluir as duraes de cada
atividade do cronograma, as premissas feitas no desenvolvimento das estimativas de
durao da atividade e quaisquer reservas para contingncias.

7.5 Desenvolvimento do Cronograma


O desenvolvimento do cronograma do projeto, um processo iterativo, determina
as datas de incio e trmino planejadas das atividades do projeto.

MSc. Eng. Jos Francisco Resende da Silva

54

O desenvolvimento do cronograma pode exigir que as estimativas de durao e


as estimativas de recursos sejam reexaminadas e revisadas para criar um cronograma
do projeto aprovado, que possa servir como uma linha de base em relao a qual o
progresso pode ser acompanhado. O desenvolvimento do cronograma continua
durante todo o projeto conforme o trabalho se desenvolve, o plano de gerenciamento
do projeto se modifica e os eventos de risco esperados ocorrem ou desaparecem
medida que novos riscos so identificados.
Datas impostas nos incios ou trminos das atividades podem ser usadas para
limitar o incio ou o trmino para no comear antes de uma data especificada ou para
no terminar aps uma data especificada.
Embora vrias restries estejam normalmente disponveis no software de
gerenciamento de projetos, as restries no comear antes de e no terminar aps
so as mais frequentemente usadas.
As restries de datas incluem situaes como datas acordadas por contrato,
uma janela de mercado em um projeto de tecnologia, restries de clima sobre
atividades externas, conformidade imposta pelo governo com reparao ambiental e
entrega de material por partes no representadas no cronograma do projeto.
O patrocinador do projeto, cliente do projeto ou outras partes interessadas
frequentemente estabelecem os eventos importantes ou os marcos principais que
afetam o trmino de determinadas entregas at uma data especificada.
Aps serem agendadas, essas datas se tornam esperadas e podem ser
transferidas somente por meio de mudanas aprovadas. Os marcos tambm podem
ser usados para indicar interfaces com trabalho fora do projeto. Esse trabalho
normalmente no est no banco de dados do projeto e os marcos com as datas das
restries podem fornecer a interface adequada do cronograma.

7.5.1
7.5.1.1

Ferramentas e tcnicas
Anlise de rede do cronograma

A anlise de rede do cronograma uma tcnica que gera o cronograma do


projeto. Ela emprega o modelo de cronograma e vrias tcnicas analticas, como o
mtodo do caminho crtico, o mtodo da cadeia crtica, a anlise do tipo "e se?" e o
nivelamento de recursos, para calcular as datas de incio e trmino mais cedo e mais
tarde, e as datas de trmino e de incio agendadas para as partes incompletas das
atividades do cronograma do projeto.
Se o diagrama de rede do cronograma usado no modelo possuir loops de rede
ou terminaes abertas na rede, ento esses loops e terminaes abertas so
ajustados antes da aplicao de uma das tcnicas analticas.
Alguns caminhos de rede podem ter pontos de convergncia de caminhos ou de
divergncia de caminhos que podem ser identificados e usados na anlise de
compresso do cronograma ou em outras anlises.

MSc. Eng. Jos Francisco Resende da Silva

55

7.5.1.2

8.5.1.2 O mtodo do caminho crtico

uma tcnica de anlise de rede do cronograma que realizada usando o


modelo de cronograma. O mtodo do caminho crtico calcula as datas tericas de incio
e trmino mais cedo, e de incio e trmino mais tarde, de todas as atividades do
cronograma, sem considerar quaisquer limitaes de recursos, realizando uma anlise
do caminho de ida e uma anlise do caminho de volta pelos caminhos de rede do
cronograma do projeto.
As datas resultantes de incio e trmino mais cedo e mais tarde, no so
necessariamente as do cronograma do projeto; em vez disso, indicam perodos de
tempo dentro dos quais a atividade do cronograma deve ser agendada, quando
fornecidos: duraes da atividade, relacionamentos lgicos, antecipaes, atrasos e
outras restries conhecidas.
As datas calculadas de incio e trmino mais cedo, e de incio e trmino mais
tarde, podem ou no ser as mesmas em qualquer caminho de rede, pois a folga total
que fornece a flexibilidade do cronograma pode ser positiva, negativa ou nula.
Em qualquer caminho de rede, a flexibilidade do cronograma medida pela
diferena positiva entre as datas mais tarde e mais cedo, e chamada de folga total.
Os caminhos crticos tm uma folga total nula ou negativa e as atividades do
cronograma em um caminho crtico so chamadas de atividades crticas.
Podem ser necessrios ajustes nas duraes das atividades, relacionamentos
lgicos, antecipaes e atrasos ou em outras restries do cronograma para produzir
caminhos de rede com uma folga total positiva ou nula.
Quando a folga total de um caminho de rede for nula ou positiva, ento a folga
livre-o atraso total permitido para uma atividade do cronograma sem atrasar a data de
incio mais cedo de qualquer atividade sucessora imediata dentro do caminho de rede poder tambm ser determinada.
7.5.1.3

8.5.1.3 Software de gerenciamento de projetos

O software de gerenciamento de projetos para elaborao de cronogramas


amplamente usado para auxiliar o desenvolvimento do cronograma. O prximo captulo
deste guia fornece mais detalhes sobre os pacotes de software disponveis no mercado
atualmente.
O cronograma do projeto inclui pelo menos uma data de incio planejada e uma
data de trmino planejada para cada atividade do cronograma. Se o planejamento de
recursos for realizado em um estgio inicial, o cronograma do projeto continuar sendo
preliminar at que as atribuies de recursos sejam confirmadas e as datas de incio e
trmino agendadas sejam estabelecidas.
Esse processo normalmente ocorre at o trmino do plano de gerenciamento do
projeto. Um cronograma alvo do projeto pode tambm ser desenvolvido com datas alvo
para incio e datas alvo para trmino definidas para cada atividade do cronograma.
O cronograma do projeto pode ser apresentado de forma sumarizada, s vezes
chamado de cronograma mestre ou cronograma de marcos, ou apresentado em
detalhes.

MSc. Eng. Jos Francisco Resende da Silva

56

Embora um cronograma do projeto possa ser apresentado na forma tabular, ele


mais frequentemente apresentado de forma grfica, usando um ou mais dos
seguintes formatos:
a) Diagramas de rede do cronograma do projeto. Estes diagramas com
informaes sobre a data das atividades, normalmente mostram a lgica de rede
do projeto e as atividades de caminho crtico do cronograma do projeto. Estes
diagramas podem ser apresentados no formato de diagrama de atividade no n,
conforme mostrado na primeira figura ou apresentados no formato de diagrama
de rede do cronograma com escala de tempo, que s vezes chamado de
grfico de barras lgico.
Esse exemplo tambm mostra como cada pacote de trabalho planejado como
uma srie de atividades do cronograma relacionadas.
b) Grficos de barras. Estes grficos, com barras representando as atividades,
mostram as datas de incio e concluso das atividades, alm das duraes
esperadas.
Os grficos de barras so relativamente fceis de ler e so frequentemente
usados em apresentaes gerenciais.
Para controle e gerenciamento da comunicao, uma atividade de resumo mais
ampla e abrangente, s vezes chamada de uma atividade sumarizadora,
usada entre marcos ou entre vrios pacotes de trabalho interdependentes e
exibida em relatrios de grfico de barras.
c) Grficos de marcos. Estes grficos so semelhantes aos grficos de barras, mas
identificam somente o incio ou o trmino agendado das principais entregas e
das interfaces externas importantes.
Para um cronograma de projeto simples, a Figura fornece uma representao
grfica de um cronograma de marcos, de um cronograma sumarizado e de um
cronograma detalhado. A Figura tambm mostra visualmente os
relacionamentos entre os trs diferentes nveis de apresentao de
cronogramas.
d) Linha de base do cronograma - Uma linha de base do cronograma uma verso
especfica do cronograma do projeto desenvolvida a partir da anlise de rede do
cronograma do modelo de cronograma.
aceita e aprovada pela equipe de gerenciamento de projetos como a linha de
base do cronograma com datas de base de incio e datas de base de trmino.

7.6 Controle do Cronograma


O cronograma do projeto usado para controle o cronograma do projeto
aprovado, que chamado de linha de base do cronograma, que um componente do
plano de gerenciamento do projeto. Ela fornece a base para medio e emisso de
relatrios de desempenho de prazos como parte da linha de base da medio de
desempenho.
Os relatrios de desempenho fornecem informaes sobre o desempenho de
prazos, como as datas planejadas que foram cumpridas e as que no foram.

MSc. Eng. Jos Francisco Resende da Silva

57

Os relatrios de desempenho podem tambm chamar a ateno da equipe do


projeto para problemas que poderiam afetar negativamente o desempenho de prazos
no futuro.
Somente as solicitaes de mudana aprovadas que foram processadas
anteriormente pelo processo Controle integrado de mudanas so usadas para
atualizar a linha de base do cronograma do projeto ou outros componentes do plano de
gerenciamento do projeto.
O relatrio de progresso e a situao atual do cronograma incluem informaes
como as datas de incio e de trmino reais e as duraes restantes das atividades do
cronograma no terminadas.
Se, alm disso, for usada uma medio do progresso, como valor agregado,
ento o percentual completo das atividades do cronograma em andamento poder
tambm ser includo.
Um modelo criado para ser usado de forma consistente nos vrios componentes
organizacionais do projeto pode ser utilizado durante todo o ciclo de vida do projeto
para facilitar a emisso de relatrios peridicos do progresso do projeto.
O modelo pode estar em papel ou em meio eletrnico.
O sistema de controle de mudanas no cronograma define os procedimentos
para efetuar mudanas no cronograma do projeto.
Inclui a documentao, os sistemas de acompanhamento e os nveis de
aprovao necessrios para autorizar mudanas.
O sistema de controle de mudanas no cronograma operado como parte do
processo Controle integrado de mudanas.
7.6.1

Medio de Desempenho

As tcnicas de medio de desempenho produzem a variao de prazos e o


ndice de desempenho de prazos, que so usados para avaliar a extenso das
variaes no cronograma do projeto que realmente ocorrem. Uma parte importante do
controle do cronograma decidir se a variao no cronograma exige aes corretivas.
Por exemplo, um grande atraso em qualquer atividade do cronograma que no
esteja no caminho crtico pode ter pouco efeito sobre o cronograma total do projeto,
enquanto um atraso muito menor em uma atividade crtica ou quase crtica pode exigir
aes imediatas.
A comparao entre as datas do cronograma alvo e as datas de incio e trmino
reais/previstas fornece informaes teis para detectar os desvios e para implementar
aes corretivas no caso de atrasos.
A variao da folga total tambm um componente essencial do planejamento
para avaliar o desempenho de tempo do projeto.
Para facilitar a anlise do progresso do cronograma, conveniente usar um
grfico de barras de comparao, que exibe duas barras para cada atividade do
cronograma.

MSc. Eng. Jos Francisco Resende da Silva

58

Uma barra mostra o andamento atual real e a outra mostra o andamento da linha
de base do cronograma do projeto aprovado.
Isso mostra visualmente onde o cronograma progrediu conforme planejado ou
onde ocorreram defasagens.
7.6.2

Linha de Base do Cronograma (Atualizaes)

As revises do cronograma so uma categoria especial de atualizaes do


cronograma do projeto.
As revises so mudanas nas datas de incio e de trmino do cronograma na
linha de base do cronograma aprovado.
Essas mudanas so normalmente incorporadas em resposta a solicitaes de
mudana aprovadas relacionadas a mudanas no escopo do projeto ou a mudanas
nas estimativas.
O desenvolvimento de uma linha de base do cronograma revisado pode ocorrer
somente como resultado de mudanas aprovadas.
A linha de base do cronograma original e o modelo de cronograma so salvos
antes de criar a nova linha de base do cronograma para evitar a perda de dados
histricos do cronograma do projeto.
As mudanas no cronograma do projeto podem exigir ou no ajustes nos outros
componentes do plano de gerenciamento do projeto.
As mudanas solicitadas so processadas para reviso e destinao pelo
processo Controle integrado de mudana.

7.6.3

Aes Corretivas Recomendadas

Uma ao corretiva tudo que feito para que o desempenho futuro esperado
de prazos do projeto fique de acordo com a linha de base do cronograma aprovado do
projeto. As aes corretivas na rea de gerenciamento de tempo freqentemente
envolvem facilitao, o que inclui as aes especiais tomadas para garantir o trmino
de uma atividade do cronograma no prazo ou com o menor atraso possvel.
As aes corretivas muitas vezes exigem a anlise da causa-raiz para
identificara causa da variao.
A anlise pode abordar as atividades do cronograma, exceto a atividade do
cronograma que est realmente causando o desvio; portanto, a recuperao do
cronograma em relao variao poder ser planejada e executada usando as
atividades do cronograma delineadas posteriormente no cronograma do projeto.
A documentao das causas de variao, das razes que motivaram as aes
corretivas escolhidas e outros tipos de lies aprendidas do controle do cronograma
so documentados nos ativos de processos organizacionais, de forma que integrem o
banco de dados histrico tanto para o projeto, como para outros projetos da
organizao executora.

MSc. Eng. Jos Francisco Resende da Silva

59

8. Ferramentas
Computacionais
para Planejamento e Controle de
Projetos
De acordo com o site www.pm-software-tools.com, existem atualmente nos
Estados Unidos um vasto pacote de software para gerenciamento de projetos divididos
de acordo com suas funes principais. Esses produtos encontram-se listados abaixo:

8.1 Software para Cronograma e Caminho Crtico


Adaptive Planning Tools
o Multi-Project Planner
Advanced Management Solutions, Inc
o AMS Realtime
MSc. Eng. Jos Francisco Resende da Silva

60

AEC Software
o FastTrack Schedule
Artemis International Solutions Corp.
o ProjectView
Bill McMillan
o Can-Plan (Excel & Visual Basic based project management; inexpensive)
Brian C. Christensen
o GanttPV (free, scriptable, open source; for Mac OS X too)
Computerline Limited
o Plantrac Outlook (free demo available)
Computer Systems Odessa corp.
o ConceptDraw Project (30 day free trial available; for Mac OS X too)
Crest Software
o CS Project
o Valesco (estimating software)
Deltek
o Open Plan
Dekker, Ltd.
o Trakker
Effective Automated Systems Engineering
o EASE PMS
IMSI
o TurboProject (Express, Regular, Professional)
Intaver Institute Inc.
o RiskyProject (event chain risk management system)
InterPlan Systems Inc.
o ATC Professional Shutdown / Turnaround Management System (project
management software specific to oil refining and petrochemical process plant
maintenance projects)
KIDASA
o Milestones Professional
Micro Planning International
o Micro Planner X-Pert
Microsoft Corporation
o Microsoft Project
MinuteMan Systems
o MinuteMan Project Management Software
PCF Ltd
o QEI Exec (earned value analysis)
Power Angle Software
o Critical Path Method Project Scheduler (free, 100 task capacity)
Oracle
o Primavera Project Planner (P3)
o Primavera P6
o Primavera SureTrak
o Primavera Contractor
Safran Software Solutions AS
o Safran Planner
o Safran for Microsoft Project
o Safran Project
SharedPlan Software, Inc.
o SharedPlan (Windows, Linux & Mac OS X versions)
Spider Management Technologies
o Spider Project (Russian System)
MSc. Eng. Jos Francisco Resende da Silva

61

VirtualBoss Software
o VirtualBoss (Construction focus; Palm/Pocket PC enabled)

8.2 Software de Cadeia Crtica


Advanced Projects, Inc.
o CCPM+ (Critical Chain add-in for MS Project)
ProChain Solutions, Inc.
o ProChain Project Scheduling (Critical Chain approach)
Sciforma Corporation
o PSNext (Critical Path and Critical Chain methods)
Spherical Angle
o cc-Pulse (Critical Chain add-in for MS Project)
Synchro Ltd.
o Synchro (Critical Chain, 4D visualization with CAD integrations, line of
balance)

8.3 Software de Linha de Equilbrio


PlanMan Oy
o PlanMan Project 2010 (Line of Balance system; free trial available)
Misronet, Inc.
o Q. Scheduling (Line of Balance system; construction project focus; free trial
available)
Peter Clarke
o TimeChg2000 (Line of Balance system)
Vico Software
o Vico Office Schedule Planner (formerly Graphisoft Control 2005 which was
formerly DYNAProject - Line of Balance system; construction project focus).

8.4 Software de Estimativas de Projetos


Bid4Build Enterprises, LLC
o Bid4Build (Construction focus; integrates with Microsoft Project)
Chemuturi Consultants
o PMPal (IT/software development focus; supporting function point analysis
technique, objects points technique, use case points technique, task-based
estimation technique, LOC technique, intermediate COCOMO-I technique)
Client/Server Connection, Ltd.
o CS/10,000 (IT/software development focus)
GeroneSoft
o Code Counter Pro (IT/software development focus; code counter [SLOC,
KLOC] for use with COCOMO and Function Point systems)
MSc. Eng. Jos Francisco Resende da Silva

62

Heavy Construction Systems Specialists, Inc.


o HeavyBid (Construction focus; integrates with Microsoft Project & Primavera
SureTrak)
InterPlan Systems Inc.
o eTaskMaker Project Planning Software (generates PDM schedules for export
to project management software from Artemis, InterPlan, Microsoft, Primavera,
Sciforma, Welcom)
Software Productivity Research
o KnowledgePLAN (IT/software development focus)

8.5 Software de Gesto de Projetos com Base em


Excel/Outlook/Outros (Calendrio)
4aBetterBusiness, Inc.
o Plan & Progress Tracker (MS-Excel based project management software)
Advantage International Inc.
o TaskController (Outlook based, calendar based project management software)
Alexcorp
o Alexsys Team 2 (multi-user, calendar based team management software)
Alexander Fedorenko
o DevPlanner (calendar based project management software)
Anthony DiRuzzo
o EasyProjectPlan (MS-Excel based project management software, interfaces
with MS Project and MS Outlook)
Arrant Solutions
o ArrantSoft XPM, XP, PRO (calendar based project management software)
Automation Centre
o TrackerOffice (Exchange/Outlook or LotusNotes based project management
software)
BLiner
o B-liner (Spreadsheet based project management software)
Business Arts
o ProjectSheet (MS Excel based; simple scheduling system (not PDM))
o TaskSheet (More capacity than ProjectSheet)
o TopSheet (Add-on for ProjectSheet/TaskSheet for high level project views)
Business Spreadsheets
o Project Planning and Management Template (MS-Excel based project
management software)
CODEL
o Project Control (project template library, MS Project knowledge management
add-on)
Experience In Software, Inc.
o Project KickStart (links to critical path scheduling programs [AEC, Kidasa,
Microsoft, Primavera, Sciforma])
Inmotion Mobile Software Solutions HB
o ProjectCompanion (MS Access or SQL Server based; Palm enabled; free
version handles up to 3 concurrent projects)
KiSystems, Inc.
o Ki Biz System (Project Management Module) (Windows & Mac)
Performance Solutions Technology, LLC
o ManagePro (calendar based task manager, synchs with Outlook)
MSc. Eng. Jos Francisco Resende da Silva

63

MS Team
o AvailSuite (calendar based task manager)
National Schedule Masters
o TracTime (construction industry focus)
Orbisoft International
o Task Manager
TeamDirection Inc.
o IntelliGantt (for SharePoint, Basecamp, MS Project)
Turtle Creek Software
o Goldenseal (calendar based project management software for construction
industry)

8.6 Software Corporativo com base em Servidor de Rede


Accord Software
o SmartWorks Project Planner
Asta Development plc
o Asta Powerproject (Construction industry focus)
o Asta Teamplan (IT industry focus, includes collaboration features)
Celoxis Technologies Pvt. Ltd
o Celoxis
Gator Information Technologies Inc.
o acteo (portfolio management, timesheet processing, collaboration and CPM
scheduling)
IBM
o Rational Portfolio Manager
Meridian Project Systems
o Prolog
Pelagon Ltd
o WAM
Project.net
o Project.net (free, open source available)
SimplyPM, LLC
o SimplyPM
Standpipe Studios, L.L.C.
o Vertabase Pro
Team Interactions, Inc.
o EnterPlicity
Websystems Inc.
o AceProject
YellowZone, Inc.
o YZ Project Manager

8.7 Critrios de Escolha


Como visto acima, os produtos de software para gesto de projetos vem em
diferentes nveis de sofisticao e variam em preos tambm, de $50 a $20.000, ou
mais. Para auxiliar empresas e gerentes de projetos a decidirem pelo melhor produto,
MSc. Eng. Jos Francisco Resende da Silva

64

no site www.4pm.com, Dick Billows, PMP, faz a seguinte anlise sobre opes de
produtos de acordo com as necessidades do projeto e da empresa:
8.7.1

Projetos de Pequeno Porte

Nesta categoria encontram-se os projetos em que necessrio planejar e


programar duraes em vez de estimativas de trabalho e capacidades de recursos.
Muitas vezes, no h necessidade de desenvolver ou acompanhar o oramento
do projeto pois os relatrios de andamento do projeto esto restritos a confirmar a data
de concluso de tarefas. Neste nvel de gesto de projetos, a empresa normalmente
no consolida todos os projetos em um portiflio e nem se preocupa em utilizar seu
pessoal ao mximo em diferentes projetos. Nessas situaes, o leque de opes
bastante amplo e muitos pacotes atendem a essa necessidade, como grficos simples
de Gantt e PERT ou produtos de software a um custo de $125,00 como o TurboProject,
Milestone Simplicity ou Quick Gantt.
8.7.2

Projetos de Mdio e Grande Porte

medida que a escala do projeto aumentar e o seu impacto ultrapassar os


limites de uma unidade funcional, haver uma necessidade de recursos mais
sofisticados no software de gerenciamento de projetos. Nesses casos, o gerente de
projetos no consegue trabalhar com uma representao esttica das datas de incio e
fim pois precisa de um software que simule o projeto para reprogramar e otimizar seus
recursos toda vez que houver uma mudana. Controlar o oramento agora uma
questo importante no planejamento e acompanhamento do projeto. H tambm uma
necessidade de monitorar as estimativas de horas de trabalho e os relacionamentos
entre as atividades predecessoras. O software precisa ter recursos para programar e
orar as atividades no apenas do pessoal interno empresa, mas tambm os
recursos de outsourcing. O software deve tambm projetar valores de valor agregado e
caminhos crticos. Nesse cenrio de gerenciamento de projetos, o custo do software
variar de $300 a $500 e os usurios precisaro tambm de treinamento. Os dois
produtos mais populares no momento para esses casos so o Microsoft Project 20022003 e Primavera.
8.7.3

Portflios de Projetos

Nesse tipo de organizao, o gerente de projetos administra mltiplos projetos


dentro de uma organizao estruturada para projetos com diversos gerentes de
projetos.
H, ento, uma necessidade de uma consistncia entre as formas de planejar e
monitorar um projeto, bem como formas de consolidar requisitos de projetos, alocar e
prioritizar recursos, programar a acompanhar o trabalho de pessoas atuando em
diversos projetos ao mesmo tempo. O pacote de software deve ser capaz de identificar
conflitos na demanda de recursos e definir prioridades entre os projetos que requerem
os mesmos recursos. O oramento tambm precisa ser monitorado de acordo com
centros de custos para cada projeto, com ferramentas para simulao e anlise de
riscos. Nesses casos, os pacotes de software podem chegar a um custo de
$20.000,00. Os mais populares so:
MSc. Eng. Jos Francisco Resende da Silva

65

Microsoft Project 2003 (com Project Server) Primavera Project Planner,


Enterprise PM e Micro Planner X-Pert.

8.7.4

Softwares Mais Populares no Brasil

Atualmente, os programas de software mais usados para gerenciamento de


projetos no Brasil so:
MS Project da Microsoft. O processo de criao de um novo projeto no MS
Project segue o padro dos demais programas da Microsoft. Voc pode criar um
projeto dando como ponto de partida a data de incio desejada ou a data de trmino.
Neste ltimo caso, o MS Project parte da data em que o projeto dever estar pronto e vai
retroagindo. Esta opo til quando temos uma data limite para a concluso do
projeto e queremos ter uma idia de quando comear, de modo que o prazo seja
cumprido.
Para mais informaes, consulte o site da empresa no link abaixo:
http://office.microsoft.com/pt-br/project/FX100487771046.aspx
O software Primavera da empresa Primavera vem em diferentes configuraes.
A configurao Primavera Enterprise, o programa de gerenciamento de projetos
"classe-corporativa", oferece aos profissionais de projeto um programa de
planejamento e controle compreensvel e multi-projeto adequado ao gerenciamento de
todos os projetos. Seja voc gerente de projetos ou de programas, um dedicado
planejador ou um alto executivo, voc pode contar com o Primavera Entrerprise para
fornecer um retrato mostrando com que eficincia todos os seus projetos esto sendo
executados. O Primavera Project Planner (P3) proporciona aos gerentes e
programadores de projetos o que eles mais valorizam hoje em dia: controle. a
escolha clara de profissionais no ramo de projetos. P3 o reconhecido padro para
grandes programaes de alta performance e controle de recursos. Equipes de projeto
em localidades ao redor do mundo. Equipes de trabalho grandes e multi-disciplinares.
Projetos de altaintensidade e pequena durao. Projetos corporativos crticos
compartilhando recursos limitados. P3 pode ajudar voc a gerenciar todos eles.
Para mais informaes, consulte o site da empresa no link abaixo:
http://www.primavera.com
O Representante da Primavera no Brasil a empresa Verano e seu site
http://www.verano.com.br/
interessante observar que, no Brasil, o Primavera bastante utilizado por
empresas de engenharia, enquanto o Microsoft Project o preferido para as outras
reas como TI e Telecom. Um outro aspecto interessante que as empresas do
governo brasileiro esto cada vez mais adotando softwares opensource como o
dotProject (http://www.dotproject.net/ ).

MSc. Eng. Jos Francisco Resende da Silva

66

8.7.5

Usabilidade

Do ponto de vista da usabilidade do produto de software, importante que a


deciso da empresa ou do gerente de projetos considere tambm os seguintes fatores:
O software deve ser fcil de instalar e usar pois o que o gerente de projetos no
quer fazer com que sua ferramenta de trabalho adicione complexidade aos seus
projetos.
O software deve ter suporte tcnico e documentao acessvel e compatvel s
necessidades locais de onde o projeto est acontecendo e sendo gerenciado.
O software deve ser compatvel com os outros sistemas da empresa.
O software deve ter um perodo de teste gratuito (free trial ou test drive) para que
todos os fatores acima sejam testados no ambiente real da empresa onde os projetos
sero realizados.
Informaes adicionais podem ser encontradas nos sites abaixo:
http://www.pm-software-tools.com/
http://www.4pm.com/articles/selpmsw.html
http://project-management-software-review.toptenreviews.com/

9. Templates
9.1 Anlise Qualitativa de Riscos

MSc. Eng. Jos Francisco Resende da Silva

Classificao do
Risco

Impacto Conseqncias

Severidade

Descrio do
Risco

Probabilidade

67

Responsvel

Resposta
do Risco

MSc. Eng. Jos Francisco Resende da Silva

Ao

Data para
Ao

68

9.2 Solicitao de Mudanas

MSc. Eng. Jos Francisco Resende da Silva

69

MSc. Eng. Jos Francisco Resende da Silva

70

10. Dicas teis


10.1 Grfico de Gantt no Excel 97-2003
(Fonte: http://pcworld.uol.com.br/dicas/2006/11/30/idgnoticia.2006-11-30.0347841737/)
Esse recurso usado para exibir o avano de tarefas de um projeto. Softwares
caros so usados para este tipo de trabalho, que pode ser feito no Excel. Saiba como
fazer para criar a tabela, siga os seguintes passos:
1. Na primeira coluna de sua planilha, a partir da clula A2, escreva a lista
de tarefas ou etapas do projeto em questo.
2. Na segunda coluna, a partir de B2, escreva as datas ou momentos de
incio de cada fase.
3. Na terceira coluna, a partir de C2, digite as datas de trmino de cada
etapa.
Agora, basta criarmos o grfico. Para simplificar sua construo, posicione o
cursor em uma clula da rea de dados.
1. V em Inserir > Grfico. Na tela de seleo de grficos, escolha o grfico
de barras empilhadas (segunda opo):
2. Clique em Avanar.
3. Na tela seguinte, selecione a aba Srie (ou seqncia, dependendo da
sua verso de Excel);
4. O Excel ir sugerir uma montagem para o grfico, que dever estar como
abaixo. Caso no esteja , selecione as trs colunas e recomece o
processo.

MSc. Eng. Jos Francisco Resende da Silva

71

5. Clique em Avanar. Na aba Linhas de Grade, marque a opo Linhas de


Grade Principais (eixo das categorias x) e Linhas de Grade Principais
(eixo dos valores y). V at a aba Legenda.

MSc. Eng. Jos Francisco Resende da Silva

72

10.2 Grfico de Gantt no Excel 2007


(Fonte: Ajuda do Excel 2007)
Embora o Microsoft Office Excel 2007 no fornea um tipo de grfico de Gantt,
voc pode simul-lo personalizando um tipo de grfico de barras empilhadas para que
ele descreva as tarefas, a durao da tarefa e a hierarquia.

Simular um grfico de Gantt


O procedimento a seguir ajudar voc a criar um grfico de Gantt com
resultados semelhantes aos mostrados no nosso exemplo de grfico de Gantt. Nesse
grfico, usamos os dados de exemplo da planilha. Voc pode copiar os dados para a
planilha ou usar seus prprios dados, contanto que utilize os mesmos cabealhos de
coluna e estrutura de planilha.
1. Copie os dados de exemplo para uma planilha em branco ou abra a
planilha que contm os dados a serem plotados em um grfico de Gantt.

MSc. Eng. Jos Francisco Resende da Silva

73

OBSERVAO: Os valores nas colunas B e C (Incio e Durao ) representam o


nmero de dias desde a data de incio e o nmero de dias necessrios para concluir a
tarefa.
2. 2. Selecione os dados que deseja plotar no grfico de Gantt (A1:C6 nos
dados de exemplo da planilha).
3. 3. Na guia Inserir, no grupo Grficos, clique em Barra.
4. 4. Em Barra 2D, clique em Barras Empilhadas.
5. 5. Clique na rea do grfico.
O recurso Ferramentas de Grfico ser exibido, com as guias Design, Layout e
Formatar.
6. 6. Na guia Design, no grupo Estilos de Grfico, clique no estilo de grfico
a ser usado.

DICA: No nosso grfico de Gantt, usamos Estilo 27.


7. No grfico, clique na primeira srie de dados (Incio) ou selecione-a em
uma lista de elementos de grfico (guia Formatar, grupo Seleo Atual,
caixa Elementos do Grfico).
8. Na guia Formatar, no grupo Seleo Atual, clique em Seleo de
Formato.

9. Clique em Preenchimento
preenchimento.

e,

em

seguida,

clique

10.

Clique em Fechar.

11.

No grfico, clique na legenda e pressione DELETE.

em

Sem

12.
Selecione o eixo vertical (categoria) ou selecione-o em uma lista de
elementos de grfico (guia Formatar, grupo Seleo Atual, caixa
Elementos do Grfico).
MSc. Eng. Jos Francisco Resende da Silva

74

13.
Na guia Formatar, no grupo Seleo Atual, clique em Seleo de
Formato.
14.
Em Opes de Eixo, marque a caixa de seleo Categorias em
ordem inversa e clique em Fechar.
15.
Se voc deseja utilizar cores de temas diferentes das do tema
padro aplicado pasta de trabalho, siga este procedimento:
1. Na guia Layout da Pgina, no grupo Temas, clique em Temas.

2. Em Interno, clique no tema desejado.


DICA: No nosso grfico de Gantt, usamos o tema Escritrio.

MSc. Eng. Jos Francisco Resende da Silva

Anda mungkin juga menyukai