Manaus
Maro - 2015
Sumrio
1. Programa da Disciplina.............................................................................................................. 7
1.1
Ementa ........................................................................................................................................ 7
1.2
1.3
Objetivos ..................................................................................................................................... 7
1.4
Metodologia ................................................................................................................................ 7
1.5
1.6
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
3.6
3.6.1
Escopo............................................................................................................................... 15
3.6.2
3.6.3
Restrio ........................................................................................................................... 16
3.6.4
Stakeholder....................................................................................................................... 16
3.6.5
3.6.6
3.6.7
3.6.8
Requisitos ......................................................................................................................... 18
3.6.9
Riscos ................................................................................................................................ 19
4.2
Sculo XX ................................................................................................................................. 22
4.3
Hoje ............................................................................................................................................ 23
4.3.1
4.3.2
4.3.3
Integrao ................................................................................................................................. 31
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.2
Escopo....................................................................................................................................... 32
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.3
Tempo ....................................................................................................................................... 33
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
5.4
Custos ....................................................................................................................................... 34
5.4.1
5.4.2
5.4.3
5.4.4
Controlar os custos.......................................................................................................... 35
5.5
Qualidade .................................................................................................................................. 35
5.5.1
5.5.2
5.5.3
5.6
5.6.1
5.6.2
5.6.3
5.6.4
5.7
Comunicaes.......................................................................................................................... 37
5.7.1
5.7.2
5.7.3
5.8
Riscos ........................................................................................................................................ 38
5.8.1
5.8.2
5.8.3
5.8.4
5.8.5
5.8.6
5.9
Aquisies................................................................................................................................. 40
5.9.1
5.9.2
5.9.3
5.9.4
5.10
5.10.1
5.10.2
5.10.3
5.10.4
6.2
6.3
7.5.1.1
7.5.1.2
7.5.1.3
7.6.1
7.6.2
7.6.3
8.7.2
8.7.3
8.7.4
8.7.5
Usabilidade ....................................................................................................................... 66
9. Templates ...................................................................................................................................... 67
10. Dicas teis .................................................................................................................................... 70
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.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.
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.
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:
11
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.
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.
13
Prazos
Prioridades
Recursos
Questes Tcnicas
Polticas Administrativas
Custos
Choques de Personalidade
14
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.
Escopo
16
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
17
Patrocinador (Sponsor)
3.6.6
Entregas (Deliverables)
18
Requisitos
19
Riscos
20
21
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.
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
23
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
24
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
27
28
29
30
Estes processos podem ser visualizados nos grupos de processos e nas reas
do conhecimento conforme segue abaixo (PMBOK verso 5):
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
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
32
5.1.6
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
5.2.2
Coletar os Requisitos
33
5.2.3
Definir o escopo
Criar a EAP
Validar o escopo
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
Definir as atividades
34
5.3.3
Sequenciar as atividades
Desenvolver o cronograma
Controlar o cronograma
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
35
5.4.2
Estimar os custos
Determinar o Oramento
Controlar os 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:
36
5.5.1
Controlar a qualidade
37
5.6.2
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
Gerenciar a comunicao
38
5.7.3
Controlar a Comunicao
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
Identificar os riscos
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
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
Controlar os riscos
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
Conduzir as aquisies
Controlar as Aquisies
41
5.9.4
Encerrar as Aquisies
42
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.
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.
44
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.
46
Definio da atividade
Sequenciamento de atividades
Estimativa de recursos da atividade
Estimativa de durao da atividade
Desenvolvimento do cronograma
Controle do cronograma
47
48
49
50
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.
52
53
54
7.5.1
7.5.1.1
Ferramentas e tcnicas
Anlise de rede do cronograma
55
7.5.1.2
56
57
Medio de Desempenho
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
7.6.3
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.
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:
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)
62
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)
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
Portflios de Projetos
65
8.7.4
66
8.7.5
Usabilidade
9. Templates
9.1 Anlise Qualitativa de Riscos
Classificao do
Risco
Impacto Conseqncias
Severidade
Descrio do
Risco
Probabilidade
67
Responsvel
Resposta
do Risco
Ao
Data para
Ao
68
69
70
71
72
73
9. Clique em Preenchimento
preenchimento.
e,
em
seguida,
clique
10.
Clique em Fechar.
11.
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.