gerenciamento de projetos - ricardo vargas

www.princexml.com

Prince - Personal Edition

This document was created with Prince, a great way of getting web content onto paper.

RICARDO VIANA VARGAS, MSc, IPMA-B, PMP

GERENCIAMENTO

DE PROJETOS

Estabelecendo Diferenciais Competitivos

7ª Edição

3/641

Multibrasil Download - www.multibrasil.net

GERENCIAMENTO

DE PROJETOSEstabelecendo Diferenciais Competitivos

7 ª Edição

Ricardo Viana Vargas, MSc, IPMA-B, PMP


Copyright © 2009 por Ricardo Viana Vargas

Todos os direitos reservados. Nenhuma parte deste livro

poderá ser reproduzida, sob qualquer meio, especialmente

em fotocópia (Xerox), sem a permissão, por escrito, da

Editora.

Editor: Sérgio Martins de Oliveira

Gerente Editorial: Rosa Maria Oliveira de Queiroz

Assistente Editorial: Renata Freire Faria

Revisão de Texto: Jairo Velloso Vargas

Editoração Eletrônica: Abreu’s System Ltda.

Capa: Bárbara Gordon Comunicação

Brasport Livros e Multimídia Ltda.

Rua Pardal Mallet, 2320270-280 Rio de Janeiro-RJ

Telefax: (21)2568-1415 - 2568-1507E-mail: [email protected]://www.brasport.com.br

7/641

mailto:[email protected]


À minha esposa Zélia e às minhas filhasAna Carolina e Gabriela, por sempreiluminarem e tornarem mais doce ealegre minha vida.

9/641

AGRADECIMENTOS

Este trabalho é fruto da cooperação de váriaspessoas. Gostaria de agradecer:

• à editora Brasport, pela confiança e in-teresse em meu trabalho;

• ao Project Management Institute Glob-al Operations Center, pelo apoio e per-missões dadas a esse projeto;

• ao Wagner Maxsen e à Sueli Barroso,grandes amigos de projeto, pelo apoiosem fim na definição e revisão do livro;

• à minha mãe Marly e ao meu queridopai Jairo (in memorian), responsáveispor todos os valores morais e pessoaisque tenho perseguido ao longo dos anos;

• aos meus queridos alunos degraduação, pós-graduação e MBA, coleg-as nessa jornada de trabalho;

• a toda a comunidade de gerenciamentode projetos por fazerem as coisasacontecerem e também por fazerem adiferença em nossa sociedade;

• aos meus parentes, funcionários, ami-gos e alunos que propiciaram todo oalicerce para este livro.

11/641

NOTA DO AUTOR

A 7a. EDIÇÃO

Com o retorno cada vez mais intenso desdeque lancei a primeira edição desse livro em1999, estou agora disponibilizando a sétimaedição do livro. O foco principal dessa ediçãoestá na inclusão dos novos conceitos ap-

resentados no PMBOK® Guide 4a Edição,editado pelo PMI no final de 2008, com atradução para o português disponibilizadaem 2009.

As principais alterações dessa edição são:

• adequação de todos os processos eáreas de conhecimento para o PMBOK®

Guide 4a Edição, incluindo os 42 pro-cessos do guia;

• todos os processos do PMBOK® Guide

4a Edição estarão agora apresentados at-ravés de mapas mentais (mindmaps),um dos mais atuais conceitos de ap-resentação de ideias de gerenciamentodo conhecimento;

• melhoria na definição e distinção entreos conceitos de projeto, subprojeto, pro-grama e portfólio;

• melhoria no gráfico das fases do pro-jeto, ampliando a representação domonitoramento e controle e relacion-ando as fases aos grupos de processo doPMBOK® Guide;

• explicação mais detalhada do conceitode fase e grupo de processos doPMBOK® Guide;

• inclusão da explicação dos documentosrelacionados ao processo “Coletar osRequisitos” do PMBOK® Guide 4ªEdição;

13/641

• todo o glossário do livro foi atualizado

para o PMBOK® Guide 4a Edição;

• refinamento de alguns conceitos en-volvendo escritório de projetos.

Além desses itens, diversas pequenas atualiz-ações foram realizadas, fruto dos inúmerose-mails que recebi desde o início do livro,bem como de uma natural evolução das prát-icas e técnicas atualmente adotadas.

A todas essas pessoas que enviaram email ecomentários, o meu muito obrigado. Estoucerto de que elas continuarão contribuindo.

Boa leitura a todos

Ricardo Viana Vargas, MSc, IPMA-B, PMP

14/641

SOBRE O AUTOR

Ricardo Viana Vargas é especialista em ger-enciamento de projetos, portfólio e riscos.Foi, nos últimos 15 anos, responsável pormais de 80 projetos de grande porte em di-versos países, nas áreas de petróleo, energia,infraestrutura, telecomunicações, informát-ica e finanças, com um portfólio de investi-mentos gerenciado superior a 18 bilhões dedólares.

É o primeiro voluntário latino-americano aser eleito para exercer a função de presidentedo conselho diretor (Chairman) do ProjectManagement Institute (PMI), maior or-ganização do mundo voltada para a adminis-tração de projetos, com cerca de 500 milmembros e profissionais certificados em 175países.

Ricardo Vargas escreveu dez livros sobregerenciamento de projetos, publicados emportuguês e inglês, com mais de 200 mil ex-emplares vendidos mundialmente. Recebeuem 2005 o prêmio PMI Distinguished Awardpela sua contribuição para o desenvolvi-mento do gerenciamento de projetos e o PMIProfessional Development Product of theYear pelo workshop PMDome®, consid-erado a melhor solução do mundo para o en-sino do gerenciamento de projetos.

É professor de gerenciamento de projetos emdiversos cursos de MBA, participando doconselho editorial de revistas especializadasno Brasil e nos Estados Unidos. Vargas é re-visor reconhecido da mais importante refer-ência no mundo sobre gerenciamento deprojetos, o PMBOK Guide. Foi tambémchair da tradução oficial do PMBOK para oportuguês.

16/641

Engenheiro químico e mestre em Engenhariade Produção pela UFMG, Ricardo Vargastem também o Master Certificate in ProjectManagement pela George WashingtonUniversity, além de ser certificado pelo PMIcomo Project Management Professional(PMP) e pela International Project Manage-ment Association como IPMA-B. Participoudo programa de negociações para executivosda Harvard Law School.

Durante onze anos, a partir de 1995, desen-volveu em conjunto com dois sócios um dosmais sólidos negócios de tecnologia, geren-ciamento de projetos e terceirização do mer-cado brasileiro, que contava com 4,000 col-aboradores e gerava uma receita anual de50 milhões de dólares em 2006, quando Ri-cardo Vargas vendeu sua participação parase dedicar integralmente à internacionaliza-ção de seus trabalhos em gerenciamento deprojetos.

17/641

É membro da Association for Advancementof Cost Engineering (AACE), da AmericanManagement Association (AMA), da Inter-national Project Management Association(IPMA), do Institute for Global Ethics e daProfessional Risk Management InternationalAssociation (PRMIA).

Para contato com o autor, utilize os en-dereços abaixo.

[email protected]

www.ricardo-vargas.com

Skype: ricardo.vargas

Twitter: rvvargas

IM: [email protected]: http://www.linkedin.com/in/ricardovargas

18/641




http://www.linkedin.com/in/ricardovargas




SUMÁRIO

- PARTE I -DEFININDO O GERENCIAMENTO DE

PROJETOS 1

INTRODUÇÃO 2

DEFINIÇÃO DE GERENCIAMENTO DE PROJETOS

5

1.1O que é um Projeto? 51.2Diferenciando Projetos, Subprojetos,Programas e Portfólios 7

QUANDO OS PROJETOS SÃO NECESSÁRIOS? 9

CARACTERÍSTICAS DOS PROJETOS 12

DEFININDO O SUCESSO DOS PROJETOS 14

1.3Estimulando o Sucesso do Projeto 15BENEFÍCIOS DO GERENCIAMENTO DE

PROJETOS 17

PRINCIPAIS CAUSAS DE FRACASSO EM

PROJETOS 18

MITOS DO GERENCIAMENTO DE PROJETOS 20

QUESTÕES PARA REVISÃO 21

dummy_split_011.html#filepos63296








PALAVRA CRUZADA 22

- PARTE II-O CICLO DE VIDA DE UM PROJETO 23

1.CICLO DE VIDA DE UM PROJETO 24

CARACTERÍSTICAS DO CICLO DE VIDA 27

1.4Potencial de Adicionar Valor ao Pro-jeto 271.5Custo das Mudanças ou Correções 271.6Oportunidade Construtiva x Inter-venção Destrutiva 281.7Capacidade de Adequação 291.8Incerteza do Risco x Quantidade Ar-riscada 29

AS FASES DO CICLO DE VIDA DO PROJETO 31

INTEGRAÇÃO ENTRE DESEMPENHO, CUSTO E

TEMPO EM PROJETOS 35

1.9Análise do Custo x Duração do Pro-jeto 371.10Análise do Desempenho x Duraçãodo Projeto 381.11Análise do Desempenho x Investi-mento 391.12Análise do Desempenho x Escopo 40

20/641
































PALAVRA CRUZADA 42

- PARTE III -PRINCIPAIS ÁREAS DO

GERENCIAMENTO DE PROJETOS SEGUNDO O

PMBOK GUIDE® 4a Edição 43

1.DEFINIÇÕES 44

PROCESSOS DO PMBOK® GUIDE 4A EDIÇÃO 46

2.DESMEMBRANDO O PMBOK ATRAVÉS DE

MAPAS MENTAIS (MINDMAPS) 49

3.GERENCIAMENTO DA INTEGRAÇÃO 51

1.13Definição 511.14Mindmap dos processos de Geren-ciamento da Integração 511.15Processos de Gerenciamento da In-tegração 511.16Termo de Abertura do Projeto ouProject Charter 541.17Plano Global do Projeto 55

GERENCIAMENTO DE ESCOPO 57

1.18Definição 571.19Mindmap dos Processos de Geren-ciamento de Escopo 58

21/641























1.20Processos de Gerenciamento deEscopo 581.21Documento de Requisitos do Projeto601.22Plano de Gerenciamento dosRequisitos do Projeto 611.23Matriz de Rastreabilidade deRequisitos (RTM) 621.24Declaração de Escopo ou ScopeStatement 621.25Plano de Gerenciamento do Escopo63

GERENCIAMENTO DE TEMPO 64

1.26Definição 641.27Mindmap dos Processos de Geren-ciamento de Tempo 641.28Processos de Gerenciamento deTempo 651.29Plano de Gerenciamento do Crono-grama 68

GERENCIAMENTO DE CUSTOS 69

1.30Definição 69

22/641









































1.31Mindmap dos Processos de Geren-ciamento de Custos 701.32Processos de Gerenciamento deCustos 711.33Plano de Gerenciamento de Custos73

GERENCIAMENTO DA QUALIDADE 74

1.34Definição 741.35Mindmap dos Processos de Geren-ciamento da Qualidade 751.36Processos de Gerenciamento da Qu-alidade 761.37Plano de Gerenciamento da Qualid-ade 77

GERENCIAMENTO DE RECURSOS HUMANOS 79

1.38Definição 791.39Mindmap dos Processos de Geren-ciamento de Recursos Humanos 801.40Processos de Gerenciamento de Re-cursos Humanos 801.41Plano de Gerenciamento de Re-cursos Humanos 83

23/641









































GERENCIAMENTO DAS COMUNICAÇÕES 84

1.42Definição 841.43Mindmap dos Processos de Geren-ciamento das Comunicações 851.44Processos de Gerenciamento dasComunicações 861.45Plano de Gerenciamento das Comu-nicações 89

GERENCIAMENTO DE RISCOS 90

1.46Definição 901.47Mindmap dos Processos de Geren-ciamento de Riscos 911.48Processos de Gerenciamento de Ris-cos 911.49Plano de Gerenciamento de Riscos95

GERENCIAMENTO DAS AQUISIÇÕES 97

1.50Definição 971.51Mindmap dos Processos de Geren-ciamento das Aquisições 981.52Processos de Gerenciamento dasAquisições 99

24/641







































1.53Plano de Gerenciamento dasAquisições 101


pALAVRA CRUZADA 103

- PARTE IV -PREPARANDO A ORGANIZAÇÃO

PARA PROJETOS 104

1.ALTERNATIVAS ORGANIZACIONAIS 105

1.54Organizações não Baseadas em Pro-jetos 1061.55Organizações Baseadas em Projetos107

ESTRUTURA ORGANIZACIONAL FUNCIONAL 108

ESTRUTURA ORGANIZACIONAL POR PROJETOS

110

ESTRUTURA MATRICIAL LEVE 112

ESTRUTURA MATRICIAL BALANCEADA 114

ESTRUTURA MATRICIAL FORTE 116

PROJECT MANAGEMENT OFFICE 117

1.56Tipos de PMO 1181.57Constituindo um PMO 120


PALAVRA CRUZADA 123

25/641

















- PARTE V – O GERENTE DE PROJETOS E SUAS

INTERFACES 124

1.DEFINIÇÕES E HABILIDADES DO GERENTE DE

PROJETOS 125

SELECIONANDO O GERENTE DE PROJETOS 128

PRINCIPAIS ERROS COMETIDOS NA SELEÇÃO DO

GERENTE DE PROJETOS 133

ADMINISTRAÇÃO DE CONFLITOS 135

2.ÉTICA E RESPONSABILIDADE PROFISSIONAL

137

1.58O que é Responsabilidade Profis-sional? 1371.59Subdivisões da ResponsabilidadeProfissional 138

3.QUESTÕES PARA REVISÃO 141

4.PALAVRA CRUZADA 142

- PARTE VI-O MODELO GERAL PARA O

GERENCIAMENTO DE PROJETOS 143

1.JUSTIFICATIVA DO MODELO DO FLUXO DE

ATIVIDADES DO PROJETO 144

FLUXOGRAMA DO PROJETO 145

FASE DE INICIAÇÃO 149

26/641









1.60Problema ou Oportunidade (01) 1491.61Criar o Termo de Abertura ou Pro-ject Charter (02) 1511.62Identificar e Selecionar o Gerente deProjeto (03) 1511.63Criar o Livro Geral do Projeto (04)1511.64Definir o Objetivo, a Justificativa, oProduto e as Entregas do Projeto (05)1531.65Arquivar Informações no Livro Ger-al do Projeto (06) 1561.66Criar Alternativas de Condução doProjeto para Construção do Escopo (07)1561.67Estimar Desempenho, Custo,Tempo, Riscos, Consequências e Culturadas Alternativas (08) 1581.68Arquivar Alternativas com Estim-ativas no Livro Geral do Projeto (09) 1591.69Selecionar o Melhor Conjunto de Al-ternativas para o Projeto (10) 160

27/641













































1.70Descartar e Arquivar para FuturosProjetos (11) 1621.71Criar a Declaração de Escopo doProjeto ou Scope Statement (12) 1631.72Aprovar a Declaração de Escopo (13)164

FASE DE PLANEJAMENTO 165

1.73Definir e Agrupar os Pacotes de Tra-balho e as Entregas do Projeto (WBS)(14) 1651.74Criar Planos de Gerenciamento deEscopo, Qualidade e Comunicações (15,16 e 17) 1681.75Criar a Lista de Atividades para osElementos do WBS (18) 1691.75.1Atividades Executivas ou Tarefas1691.75.2Marcos ou Entregas (Milestones)1691.75.3Atividades-Resumo ou Pacote deTrabalho (Summary Tasks) 170

28/641









































1.76Determinar a Duração das Ativid-ades do Projeto (19) 1701.76.1Atividades com Duração Fixa xAtividades Orientadas para Recursos1711.76.2Análise PERT 1721.76.3Outras Considerações Sobre aDuração das Atividades 1731.77Identificar e Selecionar os Recursose Profissionais para o Projeto (20) 1731.78Alocar Recursos nas Atividades (21)1741.79Criar o Plano de Gerenciamento dePessoal (22) 1741.80Inter-relacionar as Atividades eDefinir Precedências (Diagrama deRede) (23) 1751.80.1Definições 1751.80.2Restrições de Datas nas Ativid-ades 1761.80.3Tipos de Inter-relacionamentos176

29/641













































1.80.4Defasagem e Adiantamento entreas Atividades 1781.80.5Diagrama de Rede 1791.80.6Diagrama de Gantt 1801.81Fazer a Conciliação dos RecursosSuperalocados ou Indisponíveis (24) 1811.81.1Substituição do Recurso por Outroque Esteja Disponível 1811.81.2Troca da Escala de Trabalho 1821.81.3Regime de Trabalho em Horas-Extras 1831.81.4Nivelamento de Recursos 1831.81.5Conclusão 1851.82Calcular o Caminho Crítico (CPM)(25) 1851.82.1Definições Importantes 1861.83Desenvolver o Cronograma do Pro-jeto (26) 1881.84Criar o Plano de Gerenciamento dePrazos (27) 1891.85Calcular o Custo das Atividades e doProjeto (Orçamento) (28) 189

30/641













































1.85.1Custos de Recursos 1891.85.2Custos Indiretos 1901.85.3Estimativa de Custos por Pacotesde Trabalho 1901.85.4Orçamento 1901.85.5Fluxo de Caixa 1911.86Criar Planos de Custos, Riscos eAquisições (29, 30 e 31) 1911.87Desenvolver o Plano de Geren-ciamento do Projeto (32) 1911.88Aprovação do Plano de Geren-ciamento do Projeto (33) 1921.89Arquivar o Plano de Gerenciamentodo Projeto no Livro Geral do Projeto(Linha de Base) (34) 193

FASE DE EXECUÇÃO E FASE DE CONTROLE 194

1.90Executar o Pacote de Trabalho (At-ividades) (35) 1941.91Executar Atividades Auxiliares:Aquisições, Recursos Humanos, Comu-nicações e Qualidade (36) 194

31/641









































1.92Realizar a Análise de ValorAgregado para Avaliação de Desem-penho (37) 1951.92.1Conceitos 1951.92.2Exemplo 1981.93Executar o Controle de Escopo,Tempo, Custos, Qualidade, RH, Comu-nicação, Riscos e Aquisições (38) 2001.94Executar o Controle Integrado deMudanças (39) 2001.95Todos os Trabalhos Foram Concluí-dos? (40) 200

FASE DE ENCERRAMENTO 201

1.96Auditar e Validar o Resultado doProjeto com o Cliente / Patrocinador(41) 2011.97Discutir as Falhas Cometidas Dur-ante o Projeto para Servirem de Base aFuturos Projetos (42) 2021.98Encerrar os Contratos Pendentes(43) 202

32/641









































1.99Desmobilizar o Time e a Estruturado Projeto (44) 2021.100Finalizar o Livro do Projeto e Ter oProjeto Concluído (45 e 46) 202

2.QUESTÕES PARA REVISÃO 203

3.PALAVRA CRUZADA 204

- ANEXO I – UMA NOVA VISÃO DO PMBOK®

GUIDE 2000 205

- ANEXO II – RESPOSTAS DAS PALAVRAS

CRUZADAS 215

- ANEXO III – TRADUÇÃO DO INGLÊS PARA O

PORTUGUÊS DOS PRINCIPAIS TERMOS 222

BIBLIOGRAFIA 238

33/641









- PARTE I -DEFININDO O

GERENCIAMENTO DEPROJETOS

35/641

INTRODUÇÃO

“O tempo não espera por ninguém, e em nenhum outro lugar isso é tão real quanto no geren-

ciamento de projetos.”

Jim MacTntyre

Para atender a demandas de maneira eficaz,em um ambiente caracterizado pela velocid-ade das mudanças, torna-se indispensávelum modelo de gerenciamento baseado nofoco em prioridades e objetivos. Por essarazão, o gerenciamento de projetos tem cres-cido de maneira tão acentuada no mundonos últimos anos. O Project Management In-stitute, juntamente com a Economist Intelli-gence Unit, realizou uma pesquisa sobre ouniverso dos projetos e constatou que cercade 12 trilhões de dólares são hojeempregados em projetos. Isso significaaproximadamente 25% de toda a economia

mundial, empregando mais de 20 milhões deprofissionais em atividades relacionadas àliderança e ao gerenciamento de projetos.Isso confirma o que Tom Peters apresentouem seu artigo “Você é o seu Projeto” em1999. Ele afirmou que, nos próximos 20anos, todo o trabalho será desenvolvido pormeio de projetos. Pouco mais de 10 anos de-pois essa realidade é evidentemente com-provada. David Cleland também afirma que,no futuro, o gerenciamento de projetos seráutilizado para gerenciar as mudanças em to-das as infraestruturas sociais em todos ospaíses, desenvolvidos ou não.

37/641

Figura 1.1 – Evolução mundial dos membros do PMI

no mundo (compilado de PMI Today

“Fact Sheet”, Project Management Insti-

tute, 2002 a 2009)

Por que isso? A maioria das pessoas mal in-formadas pode correr o risco de ver o geren-ciamento de projetos como mais uma“moda” gerencial, proposta por algum dessesgurus da administração moderna. Nadadisso. Na realidade, o gerenciamento de pro-jetos não propõe nada revolucionário e novo.Sua proposta é estabelecer um processo

38/641

estruturado e lógico para lidar com eventosque se caracterizam pela novidade, complex-idade e dinâmica ambiental. Hoje, por maisque tenhamos evoluído tecnicamente,deparamo-nos com um ambiente que evoluiumuitas vezes mais, ou seja, hoje somos muitomais capazes que no passado, porém, essenosso aumento de capacidade é cada vezmenor se comparado com o aumento nadinâmica do ambiente. Precisamos, port-anto, desenvolver mecanismos que reduzamessa diferença entre homem e ambiente.

39/641

Figura 1.2 – Evolução comparativa homem-

ambiente.

Outro fator que impulsiona o gerenciamentode projetos é o crescimento da competitivid-ade. Quem for mais rápido e competente cer-tamente conseguirá melhores resultados. Naárea de tecnologia, isso é extremamenteclaro. Alterações tecnológicas, que anterior-mente levavam décadas para serem imple-mentadas por completo, hoje tomam apenas

40/641

algumas horas, em um nível de complexid-ade altíssimo. Cada vez mais, o gerentecumpre o papel de administrador dessasmudanças. Administrar a rotina de trabalho,agora, já não é fator diferenciador entre asorganizações bem e mal sucedidas.

Diante da pressão desse contexto demudanças, é preciso que nossas empresasconsigam resultados com menos recursos,tempo e cada vez mais qualidade, ou seja,fazer mais que os concorrentes, gastandomenos. A competição irá continuar a pres-sionar para que melhores ideias e processossejam implementados.

41/641

Figura 1.3 – Análise comparativa da complexidade e

da dinâmica dos projetos entre 1960 e

2010.

Como sobreviver em um mundo onde não sesabe exatamente o que vem a ser liderança,produtividade ou lucratividade? Agravandoesse quadro imprevisível, constata-se que acultura empresarial brasileira nunca destinatempo para planejar e sempre obtém din-heiro suficiente para refazer. Qual a saída?

42/641

A grande maioria dos executivos está, hoje,procurando por essa “fórmula do sucesso”. Osucesso, porém, não está em seguir cega-mente as modernas teorias de administraçãoapresentadas. É preciso que se tenha habilid-ade para gerenciar aquilo que se conhecemuito pouco, ou, até mesmo, aquilo de quenão se conhece nada. Podemos ver no mer-cado de tecnologia, principalmente na inter-net e no comércio eletrônico, que não ex-istem, absolutamente, padrões, nem para ve-locidade nem para dinheiro. Esse tipo decompanhia nunca se valorizou tanto e, hoje,um projeto de comércio eletrônico bem suce-dido pode até mesmo valer mais do que todaa parafernália organizacional desenvolvidaem anos por uma empresa. São os novosparâmetros do mercado, onde tudo o quenão existe é rotina. Tudo é projeto.

43/641

DEFINIÇÃO DEGERENCIAMENTODE PROJETOS

“A ideia de que planejar significa adivinhar o futuro é simplesmente absurda.”

Peter Drucker

1.1O que é um Projeto?

Nos últimos trinta anos, o mundo tem en-frentado um incrível dinamismo em suas re-lações intra e interempresariais. As empresaspassam, agora, a ser reconhecidas por suaflexibilidade, capacidade de atender a seusclientes e profissionalismo. Com equipes detrabalho flexíveis, recursos e esforços foca-dos nas necessidades organizacionais eplanejamento baseado em projetos, as cor-porações de sucesso percebem que o uso dosconceitos de gerenciamento de projetos éuniversal, genérico, rompendo todas as bar-reiras culturais, nacionais e regionais, ondeas necessidades de sobrevivência competitivatambém são universais.

O gerenciamento de projetos é um conjuntode ferramentas gerenciais que permitem quea empresa desenvolva um conjunto de habil-idades, incluindo conhecimento e

capacidades individuais, destinados ao con-trole de eventos não repetitivos, únicos ecomplexos, dentro de um cenário de tempo,custo e qualidade predeterminados.

Para se entender o que é gerenciamento deprojetos, é importante que se saiba comclareza o que é um projeto.

Projeto é um empreendimentonão repetitivo, caracterizado poruma sequência clara e lógica deeventos, com início, meio e fim,que se destina a atingir um objet-ivo claro e definido, sendo con-duzido por pessoas dentro deparâmetros predefinidos detempo, custo, recursos envolvidose qualidade.

Para Cleland, um projeto é uma combinaçãode recursos organizacionais, colocados jun-tos para criarem ou desenvolverem algo quenão existia previamente, de modo a proverum aperfeiçoamento da capacidade de

46/641

desempenho no planejamento e na realiza-ção de estratégias organizacionais.

Já para Meredith, um projeto é uma ativid-ade única e exclusiva com um conjunto deresultados desejáveis em seu término. É tam-bém complexo o suficiente para necessitar deuma capacidade de coordenação específica eum controle detalhado de prazos, relaciona-mentos, custos e desempenho.

Nesse contexto, pode-se concluir que projetoé um conjunto de ações, executado demaneira coordenada por uma organizaçãotransitória, ao qual são alocados os insumosnecessários para, em um dado prazo, al-cançar o objetivo determinado. O conceito deorganização transitória está diretamenterelacionado a um esquema organizacionalparticular e temporário que somente existepara tornar o trabalho com projetos mais efi-ciente e intuitivo por parte da organização.

Os projetos atingem todos os níveis da or-ganização. Eles podem envolver uma

47/641

quantidade pequena de pessoas, ou milharesdelas. Podem levar menos de um dia ou vári-os anos. Os projetos, muitas vezes, extrapol-am as fronteiras da organização, atingindofornecedores, clientes, parceiros e governo,fazendo parte, na maioria das vezes, da es-tratégia de negócios da companhia.

Como exemplos de projetos, podem-se citaros seguintes:

• instalação de uma nova plantaindustrial;

• redação de um livro;

• reestruturação de um determinado set-or ou departamento da empresa;

• elaboração de um plano de marketinge publicidade;

• lançamento de um novo produto ouserviço;

• informatização de um determinadosetor da empresa;

• construção de uma casa;

48/641

• realização de uma viagem.

Como exemplos reais de projetos, podem-se

citar os seguintes:1

• construção das pirâmides de Gisé

• construção da muralha da China

• reconstrução dos campos de petróleodo Kuwait devastados pela Guerra doGolfo;

• planejamento e preparação para os jo-gos olímpicos de Sydney e Pequim;

• preparação para a copa do mundo defutebol em 2014 no Brasil;

• construção das usinas hidroelétricas deJirau e Santo Antônio no Rio Madeira(Brasil);

• desenvolvimento de respostas aostremores de terra no estado da Califór-nia, EUA;

• campanha presidencial norte-americana;

49/641



• estudo do desastre aéreo do ônibus es-pacial Challenger;

• construção do novo edifício do con-gresso nacional da Austrália;

• sistema de vigilância da Amazônia(SIVAM);

• exploração da área de Pré-Sal pela pet-rolífera brasileira Petrobras.

Os projetos podem ser aplicados em pratica-mente todas as áreas do conhecimento hu-mano, incluindo os trabalhos administrat-ivos, estratégicos e operacionais, bem como avida pessoal de cada um.

Podem-se destacar as seguintes áreas de ap-licabilidade como os principais utilizadoresda técnica de gerenciamento de projetos:

• engenharia e construção civil;

• desenvolvimento de programas decomputador;

• estratégia militar;

50/641

• política;

• administração de empresas;

• marketing e publicidade;

• pesquisa e desenvolvimento;

• manutenção de planta e equipamentos.

51/641

1.2Diferenciando Projetos,Subprojetos, Programas ePortfólios

Diversas vezes, um projeto necessita ser sub-dividido em partes, de fácil gerenciamento econtrole, denominadas subprojetos. Os sub-projetos são responsáveis por uma pequenaparte do projeto total ou por fases extrema-mente específicas do projeto e podem, namaioria das vezes, ser terceirizadas oudesenvolvidas por grupos isolados. Um sub-projeto não tem sentido se tratado isolada-mente. Subprojeto desvinculado de um pro-jeto é como um braço fora do corpo.

De acordo com o PMI, o termo programa éutilizado para identificar um grupo de proje-tos relacionados que são gerenciados e co-ordenados de modo integrado, obtendo osbenefícios e os controles que não existem ao

gerenciá-los individualmente. O interesse naestruturação do programa é tático.

Já um portfólio é um conjunto de projetos,programas e outros esforços que são agrupa-dos para facilitar o atingimento dos objetivosestratégicos do negócio. Esses componentes(projetos, programas e outros esforços) sãomensuráveis, ordenáveis e priorizáveis. O in-teresse na estruturação do portfólio éestratégico.

Figura 2.1 – As áreas de abrangência de portfólios,

programas, projetos e subprojetos.

53/641

QUANDO OSPROJETOS SÃONECESSÁRIOS?

“O homem razoável se adapta ao mundo, enquanto o homem irracional persiste em tentar ad-

aptar o mundo a si próprio. No entanto, todo o progresso do mundo depende apenas desse

homem irracional.”

Bernard Shaw

Em geral, o gerenciamento de projetos podeser aplicado a qualquer situação onde existaum empreendimento que foge ao que é fixo erotineiro na empresa (ad hoc). Se oempreendimento é único e pouco familiar, éimportante que a atividade de geren-ciamento de projetos seja intensificada. Osucesso da gestão de projetos está

intimamente ligado ao sucesso com que asatividades são relacionadas e realizadas. Abase do sucesso está em identificar e diferen-ciar o projeto das demais atividades desen-volvidas na organização.

A grande dificuldade está no fato de que amaior parte das pessoas realiza trabalhosrotineiros (plain work) e projetos. Fre-quentemente, atividades de projeto e rot-ineiras têm as mesmas necessidades (re-uniões, telefonemas, relatórios, análises) eisso faz com que sua distinção seja aindamais difícil. A diferença básica está nos ob-jetivos. Os projetos possuem metas claras edefinidas sendo realizados em um períododefinido de tempo, e não indefinidamente,como os trabalhos rotineiros.

55/641

Figura 3.1 – Todos os projetos são esforços, mas

nem todos os esforços são projetos

Kerzner pondera que diversas pressões ex-ternas podem forçar as companhias a adotar-em gerenciamento de projetos como formade realizarem seus negócios. São elas asseguintes:

• competição;

• padrões de qualidade;

• redução nas margens de lucro;

56/641

• resultados financeiros;

• fatores tecnológicos;

• aspectos legais;

• aspectos sociais;

• fatores políticos;

• pressões econômicas.

Ao optar pela realização de um determinadoprojeto, uma organização precisa utilizar di-versos critérios de seleção para que os objet-ivos sejam atingidos, garantindo o seu su-cesso. A seguir, destacam-se os critérios maisimportantes:

• realismo;

• capacidade;

• flexibilidade;

• facilidade de uso;

• custo;

• facilidade de informatização.

Cleland propõe que diversos critérios podemser aplicados para a consideração do uso dos

57/641

conceitos de gerenciamento de projetos, con-forme diagrama a seguir.

Figura 3.2 – Necessidade de gerenciamento de pro-

jetos (Cleland).

No diagrama, sete fatores devem ser analisa-dos para a determinação da necessidade, ounão, do gerenciamento de projetos. São osseguintes:

Tamanho do empreendimento –Mesmo considerando que o tamanho é umassunto relativo, pode-se generalizar queempreendimentos que necessitem de umaquantidade de dinheiro, pessoal e tempo

58/641

superior ao normalmente empregado pelaempresa se beneficiem diretamente com ogerenciamento de projetos.

Interdependência – Se o esforço requeruma grande interdependência entre os de-partamentos da organização ou entre a ca-deia de relações cliente-fornecedor, onde asatividades a serem realizadas estão intima-mente relacionadas, o gerenciamento de pro-jetos se torna fundamental.

Importância do empreendimento –Muitas vezes, a força gerencial da empresanão quer que o empreendimento estejasujeito a qualquer tipo de burocracia organ-izacional que possa resultar em perda de res-ultados para os trabalhos. Empreendimentosque tenham um grande grau de risco e incer-teza também se beneficiam diretamente comos projetos.

Reputação da organização – Quando ofracasso no cumprimento de prazos e orça-mentos de um empreendimento pode

59/641

prejudicar seriamente a imagem e areputação da organização, a decisão sobre ouso do gerenciamento de projetos édeterminante.

Compartilhamento de recursos – Comoos projetos envolvem, normalmente, re-cursos altamente especializados, torna-se ne-cessário um compartilhamento de recursosentre diversos projetos e até mesmo entre osprojetos e outros trabalhos da empresa, pararedução de custos. Quando isso se intensi-fica, o gerenciamento de projetos torna-se amelhor técnica de gerenciamento dessesrecursos.

Não-familiaridade – Quando o esforço aser empreendido é completamente novo ediferente do normal, a orientação dos trabal-hos a projetos pode ser fundamental. Issotambém depende do quanto é novo e difer-ente o esforço. Provavelmente, o desenvolvi-mento de um novo produto ou serviço deveser encarado como um projeto, enquanto

60/641

uma alteração em um produto ou serviçopode ser encarada como um trabalho con-vencional, não necessitando de projetos.

Mudanças de mercado – Várias organiz-ações atuam em mercados extremamenteturbulentos, onde as modificações tecnoló-gicas e de mercado geram uma necessidadeconstante de atualização. Nesses casos, ogerenciamento de projetos atua facilitando oprocesso gerencial sem, no entanto, prejudi-car a flexibilidade e a criatividadeorganizacionais.

Na verdade, não é necessário que todos essesfatores sejam favoráveis a projetos para quese possa tratar o empreendimento como umprojeto. Basta que um desses fatores seja de-terminante para que todo o modelo de ger-enciamento de projetos seja necessário.

61/641

CARACTERÍSTICASDOS PROJETOS

“Clientes compram benefícios, resultados, nunca esforços.”

Gregory Githens

As principais características dos projetos sãoa temporariedade, a individualidade doproduto ou serviço a ser desenvolvido peloprojeto, a complexidade e a incerteza.

Temporariedade significa que todo pro-jeto possui um início e um fim definidos, ouseja, é um evento com duração finita, de-terminada em seu objetivo. Wideman afirmaque o ciclo de vida do projeto caracteriza asua temporariedade, partindo de um pro-cesso de trabalho estratégico inicial até at-ingir um topo de trabalho executivo deprodução que antecede o seu término.

Individualidade do produto ou serviçoproduzido pelo projeto, conforme o guia deconhecimento de gerenciamento de projetosdo PMI, significa realizar algo que não tinhasido realizado antes. Como o produto decada projeto é único, suas característicasprecisam ser elaboradas de maneira progres-siva de modo a garantirem as especificaçõesdo produto ou serviço a ser desenvolvido.

A partir dessas duas principaiscaracterísticas, podem-se descrever asdemais.

• Empreendimento não repetitivo -É um evento que não faz parte da rotinada empresa. É algo novo para as pessoasque o irão realizar.

• Sequência clara e lógica de event-os - O projeto é caracterizado poratividades encadeadas logicamente demodo a permitir que, durante a ex-ecução, o acompanhamento e o controlesejam precisos.

63/641

• Início, meio e fim - Todo projeto re-speita um determinado ciclo de vida,isto é, tem uma característica temporal.Muitas vezes, o término de um projetocoincide com o início de outro. Ter iní-cio, meio e fim não significa ser longo oucurto em duração. Podem existir proje-tos de 1 dia ou de 10 anos. Porém, umprojeto que não tem término não é umprojeto, é rotina.

• Objetivo claro e definido – Todoprojeto tem metas e resultados bem es-tabelecidos a serem atingidos em suafinalização.

• Conduzido por pessoas - O cernefundamental de qualquer projeto é ohomem. Sem ele, o projeto não existe,mesmo que se disponha de equipamen-tos modernos de controle e gestão.

• Projetos utilizam recursos – Todoprojeto utiliza recursos especificamentealocados a determinados trabalhos.

64/641

• Parâmetros predefinidos - Todoprojeto necessita ter estabelecidosvalores para prazos, custos, pessoal, ma-terial e equipamentos envolvidos, bemcomo a qualidade desejada para o pro-jeto. É impossível estabelecer, previa-mente, com total precisão, esses parâ-metros. Todos eles serão claramenteidentificados e quantificados no decor-rer do plano do projeto. Entretanto, osparâmetros iniciais vão atuar comoreferências para o projeto e suaavaliação.

Complementando esses conceitos, Wildemanpropõe que os projetos possuem uma sériede características específicas que necessitamde uma atenção especial, conforme mostra atabela a seguir.

65/641

Tabela 4.1 – Características específicas de projetos, con-

forme Wideman (1992).

66/641

DEFININDO OSUCESSO DOSPROJETOS

“O sucesso vem para aqueles que fazem com que ele aconteça, não para aqueles que deixam

que ele aconteça.”

Anônimo

É de fundamental importância que se saiba oque é um projeto bem-sucedido. Muitasvezes, ao avaliar o projeto, a equipe e atémesmo os patrocinadores são levados a anal-isar apenas partes de um conceito muitomais amplo. As questões a seguir são algunsexemplos de aspectos que apenas aparente-mente indicam resultados de sucesso.

Algumas questões comuns não necessaria-mente descrevem o que faz um projeto serbem sucedido, como se tem a seguir.

• O projeto ficou abaixo do orçamentoprevisto?

• O projeto terminou mais rápido?

• O projeto consumiu menos materiais epessoas?

• O cliente foi surpreendido pela qualid-ade do resultado do projeto?

Na verdade, nenhuma dessas respostasdescreve um projeto bem-sucedido SOB AÓTICA DE PLANEJAMENTO E PROJETO.

Um projeto bem-sucedido é aqueleque é realizado conforme oplanejado.

O sucesso é colher o que se plantou. Nemmais nem menos. Muitas vezes a organizaçãoavalia como sucesso o fato de um determ-inado projeto superar o plano, ou seja, con-sumir menos recursos que o previsto. Isso é

68/641

um erro de percepção, uma vez que, sob a ót-ica de gerenciamento de projetos, houve umafalha no planejamento que permitiu que osrecursos fossem superestimados, e não umavitória ou economia. Imagine que umaempresa lance uma campanha publicitáriade um novo produto e planeje uma venda de10.000 unidades do produto em uma sem-ana. Após uma semana, foram solicitadas1.000.000 de unidades. Isso seria um tre-mendo sucesso ou um grande problema,uma vez que a empresa não tem estrutura ecapacidade para atender a tal demanda?

Guss, por meio de uma revisão bibliográficadetalhada da literatura disponível sobre su-cesso de projetos, concluiu que menos de25% dos estudos se propõe a responder àseguinte questão: O que é sucesso deprojetos?

Através dos anos, conforme propõe Kerzner,o conceito do sucesso em projeto mudou sig-nificativamente. Na década de 60, o sucesso

69/641

de projeto estava vinculado diretamente atermos técnicos ou ao funcionamento de umproduto ou serviço desenvolvido por ele.Atualmente, o sucesso de um projeto podeser definido através de resultados obtidos noprazo, no custo e na qualidade desejados,sem deixar de atentar para outros parâmet-ros, que podem até mesmo ser chamados desucesso organizacional, descritos adiante.

Ao se detalharem os quesitos para considerarum projeto como bem sucedido, tem-se aseguinte listagem:

• ser concluído dentro do tempoprevisto;

• ser concluído dentro do orçamentoprevisto;

• ter utilizado os recursos (materiais,equipamentos e pessoas) eficiente-mente, sem desperdícios;

• ter atingido a qualidade e o desem-penho desejados;

70/641

• ter sido concluído com o mínimo pos-sível de alterações em seu escopo;

• ter sido aceito sem restrições pelo con-tratante ou cliente;

• ter sido empreendido sem que ocorres-se interrupção ou prejuízo nas ativid-ades normais da organização;

• não ter agredido a cultura daorganização.

71/641

1.3Estimulando o Sucessodo Projeto

Para estimular o sucesso do projeto, váriasações podem ser tomadas pelo gerente deprojeto e seu time nos âmbitos técnico, or-ganizacional e até mesmo comportamental.

O sucesso dos projetos também está direta-mente relacionado com a capacidade que aorganização tem de favorecer o ambientepara os projetos, uma vez que muitas vezes ogerente/coordenador do projeto não dispõede autoridade suficiente para influenciar osucesso dos resultados.

Essas ações incluem:

• selecionar corretamente os membros-chave do time do projeto;

• desenvolver um senso de comprometi-mento em toda a equipe;

• buscar autoridade suficiente para con-duzir o projeto;

• coordenar e manter uma relação de re-speito e cordialidade com o cliente, osfornecedores e outros envolvidos;

• determinar quais processos precisamde melhorias, especialmente os maisimportantes;

• desenvolver estimativas de custos,prazos e qualidade realistas;

• desenvolver alternativas de backup emantecedência aos problemas;

• manter as modificações sob controle;

• dar prioridade a missão ou meta doprojeto;

• evitar o otimismo ou o pessimismoexagerado;

• desenvolver e manter estreitas linhasde comunicação informal;

73/641

• evitar um número excessivo de re-latórios e análises;

• evitar excessiva pressão sobre o timedurante períodos críticos.

Tudo isso torna óbvia a necessidade de umperfeito relacionamento entre o gerente doprojeto, sua linha intermediária e os ex-ecutantes, para que a execução corra em con-formidade com o que foi previsto e plane-jado. Outra característica fundamental é odesenvolvimento da habilidade dos fun-cionários responsáveis pela execução do pro-jeto para reportar corretamente os fatosacontecidos aos escalões superiores, deforma que esses possam tomar as providên-cias preventivas ou corretivas que se fizeremnecessárias.

Finalmente, é preciso que se compreendaque o sucesso de um projeto não implica queuma organização está completamente bemsucedida em relação às fronteiras do

74/641

gerenciamento de projetos. Conforme Kerzn-er, a excelência em gerenciamento de proje-tos é definida como um fluxo contínuo de su-cessos em projetos.

75/641

BENEFÍCIOS DOGERENCIAMENTODE PROJETOS

“Nenhum empreendimento pode ser considerado tão pequeno que não se beneficie do geren-

ciamento de projetos.”

Sunny Baker

O gerenciamento de projetos proporciona in-úmeras vantagens sobre as demais formas degerenciamento, tendo se mostrado eficaz emconseguir os resultados desejados dentro doprazo e do orçamento definido pela organiza-ção. A principal vantagem do gerenciamentode projetos é que ele não é restrito a projetosgigantescos, de alta complexidade e custo.Ele pode ser aplicado em empreendimentos

de qualquer complexidade, orçamento etamanho, em qualquer linha de negócios.

Dentre os principais benefícios, podem-sedestacar os seguintes:

• evita surpresas durante a execução dostrabalhos;

• permite desenvolver diferenciais com-petitivos e novas técnicas, uma vez quetoda a metodologia está sendoestruturada;

• antecipa as situações desfavoráveis quepoderão ser encontradas, para que açõespreventivas e corretivas possam sertomadas antes que essas situações seconsolidem como problemas;

• adapta os trabalhos ao mercado con-sumidor e ao cliente;

• disponibiliza os orçamentos antes doinício dos gastos;

77/641

• agiliza as decisões, já que as inform-ações estão estruturadas edisponibilizadas;

• aumenta o controle gerencial de todasas fases a serem implementadas devidoao detalhamento ter sido realizado;

• facilita e orienta as revisões da estru-tura do projeto que forem decorrentesde modificações no mercado ou no am-biente competitivo, melhorando a capa-cidade de adaptação do projeto;

• otimiza a alocação de pessoas, equipa-mentos e materiais necessários;

• documenta e facilita as estimativaspara futuros projetos.

78/641

PRINCIPAISCAUSAS DEFRACASSO EMPROJETOS

“Existe muito mais coisa para ser dita sobre o fracasso. Ele é muito mais interessante do que o

sucesso.”

Max Beerbohm

Por que os projetos falham? Mesmo com agrande quantidade de benefícios geradospelos projetos, boa parte deles falha ou nãoatinge o resultado esperado. Muitas falhassão decorrentes de obstáculos naturais ouexternos que estão completamente fora docontrole da organização e que, muitas vezes,somente podem ser minimizados ou evitados

através de um gerenciamento de riscos efi-ciente. São eles os seguintes:

• mudança na estrutura organizacionalda empresa;

• riscos elevados no meio ambiente;

• mudanças na tecnologia disponível;

• evolução nos preços e prazos;

• cenário político-econômicodesfavorável.

Mas a maioria dos insucessos é decorrentede outros tipos de falhas, também chamadasfalhas gerenciais, que podem perfeitamenteser evitadas, tais como:

• as metas e os objetivos são mal-es-tabelecidos, ou não são compreendidospelos escalões inferiores;

• há pouca compreensão da complexid-ade do projeto;

• o projeto inclui muitas atividades emuito pouco tempo para realizá-las;

80/641

• as estimativas financeiras são pobres eincompletas;

• o projeto é baseado em dados insufi-cientes, ou inadequados;

• o sistema de controle é inadequado;

• o projeto não teve um gerente de pro-jeto, ou teve vários, criando círculos depoder paralelos aos previamenteestabelecidos;

• criou-se muita dependência no uso desoftwares de gestão de projetos;

• o projeto foi estimado com base na ex-periência empírica, ou feeling dos en-volvidos, deixando em segundo plano osdados históricos de projetos similares,ou até mesmo análises estatísticasefetuadas;

• o treinamento e a capacitação foraminadequados;

• faltou liderança do gerente de projeto;

81/641

• não foi destinado tempo para as estim-ativas e o planejamento;

• não se conheciam as necessidades depessoal, equipamentos e materiais;

• fracassou a integração dos elementos-chave do escopo do projeto;

• cliente/projeto tinham expectativasdistintas e, muitas vezes, opostas;

• não se conheciam os pontos-chave doprojeto;

• ninguém verificou se as pessoas en-volvidas nas atividades tinham conheci-mento necessário para executá-las;

• as pessoas não estavam trabalhandonos mesmos padrões, ou os padrões detrabalho não foram estabelecidos.

Muitas vezes também é difícil distinguirentre fracasso, fracasso parcial e sucesso deum determinado projeto. Isso implica que oque parece ser fracasso em um determinadoponto do projeto pode ser um sucesso sob

82/641

outro ponto de vista, tornando ainda maisdifícil a avaliação dos resultados do projeto.

Cabe, então, ao gerente de projeto e à suaequipe controlar as possibilidades de insu-cessos mencionadas. Não se pode criar ailusão de que o projeto é algo que não sepode controlar, chegando à frustrante defin-ição de projeto proposta por Kerzner de que“gerenciamento de projetos é a arte de criar ailusão de que todos os resultados obtidospelo projeto foram previamente previstos eplanejados quando, na realidade, não pas-saram de uma sequência absurda de purasorte.”

83/641

MITOS DOGERENCIAMENTODE PROJETOS

“As pessoas podem alterar suas vidas alterando suas atitudes.”

William James

Com o crescimento da utilização dos concei-tos de gerenciamento de projetos por partedas organizações, diversos mitos sobre ger-enciamento de projetos foram superados esubstituídos por conceitos mais modernos edinâmicos. Kerzner, após inúmeros relatosde experiências organizacionais, propôs, emA busca pela Excelência em Gerenciamento

de Projetos2, novos conceitos, que estão lista-

dos na tabela que se segue.



Tabela 8.1 – Transição de conceitos de geren-

ciamento de projetos

85/641

QUESTÕES PARAREVISÃO

1. O que diferencia um projeto de outrosesforços?

2. Por que o gráfico com a análise com-parativa da complexidade e da dinâmicados projetos ao longo das décadas justi-fica o crescente emprego do geren-ciamento de projetos nos negócios?

3. Quais as características que tornamum projeto único?

4. Por que, mesmo com uma série de be-nefícios visíveis, a maioria dos projetosainda não pode ser considerada bemsucedida?

5. Como a organização pode estimular efavorecer o sucesso dos projetos?

6. Por que sob a visão de projetos, su-cesso está vinculado ao cumprimento doplano e não está vinculado ao ato de su-perar o plano?

7. Como a informação histórica podefavorecer o sucesso dos projetos?

8. Explique as características de mul-tidisciplinaridade nos projetos.

9. Forneça cinco exemplos atuais deprojetos reais.

10. Quais são os critérios que podem seraplicados ao avaliar a viabilidade do usodos conceitos de gerenciamento de pro-jetos em uma determinada necessidade?

11. Qual é a diferença entre projeto, sub-projeto e programa?

87/641

PALAVRACRUZADA

Conceitos Básicos de Projetos

89/641

- PARTE II-O CICLODE VIDA DE UM

PROJETO

1. CICLO DEVIDA DE UMPROJETO

Todo projeto pode ser subdividido em de-

terminadas fases3

de desenvolvimento. O en-tendimento dessas fases permite ao time doprojeto um melhor controle do total de re-cursos gastos para atingir as metas estabele-cidas. Esse conjunto de fases é conhecidocomo ciclo de vida. O ciclo de vida possibilitaque seja avaliada uma série de similaridadesque podem ser encontradas em todos os pro-jetos, independentemente de seu contexto,aplicabilidade ou área de atuação.

O ciclo de vida pode ser dividido em um con-junto de fases, normalmente fixas para todosos tipos de projeto, contendo uma série de



passos principais do processo de contextual-izar, desenhar, desenvolver e colocar em op-eração uma determinada necessidade doprojeto. Essas fases, por sua vez, são sub-divididas em estágios, ou etapas específicas,de cada natureza de projeto (construção,desenvolvimento de produtos, etc.). Esses es-tágios são, então, subdivididos em ativid-ades, ou tarefas específicas de cada projeto.

Figura 1.1 – Visão do ciclo de vida do projeto

Conhecer as fases do ciclo de vida propor-ciona uma série de benefícios para quaisquertipos de projetos. Dentre eles, podem serdestacados os seguintes:

92/641

• a correta análise do ciclo de vida de-termina o que foi, ou não, feito peloprojeto;

• o ciclo de vida avalia como o projetoestá progredindo até o momento;

• o ciclo de vida permite que seja indic-ado qual o ponto exato em que o projetose encontra no momento.

Ao longo do ciclo de vida, diversas consider-ações podem ser feitas, principalmente,

• as características do projeto tendem amudar com a conclusão de cada fase doprojeto;

• a incerteza relativa aos prazos e custostende a diminuir com o término de cadafase.

A descrição do ciclo de vida do projeto podeser genérica, representada por um únicográfico, ou detalhada, incluindo vários gráfi-cos, fluxogramas e tabelas, específicos decada atividade.

93/641

Com relação à velocidade de desenvolvi-mento, Meredith afirma que o ciclo de vidados projetos pode ser caracterizado, namaioria das vezes, por um início lentoseguido de um progresso acelerado até at-ingir um pico e, logo em seguida, um de-saceleramento até atingir seu término.

Figura 1.2 – Ciclo de vida do projeto segundo

critérios de velocidade de

desenvolvimento.

94/641

Outra consideração a ser analisada no ciclode vida do projeto é o nível de esforço. Onível de esforço destinado ao projeto inicia-se em praticamente zero e vai crescendo atéatingir um máximo e, logo após esse ponto,reduz-se bruscamente até atingir o valorzero, representante do término do projeto.Entende-se por esforço a quantidade depessoas envolvidas no projeto, o dispêndiode trabalho e dinheiro com o projeto, as pre-ocupações, as complicações, as horas-extrasetc. A localização do valor máximo do gráficopode variar de projeto para projeto. No ent-anto, esse máximo de esforço sempre vai exi-stir em algum momento do projeto. Asuavidade desse ponto de esforço máximoestá diretamente relacionada à qualidadecom que o planejamento foi realizado.Quanto melhor é o plano, mais suave é atransposição do ponto de esforço máxmo.

95/641

Figura 1.3 – Variação do esforço com o tempo para o

projeto.

96/641

CARACTERÍSTICASDO CICLO DEVIDA

A maioria dos ciclos de vida dos projetoscompartilha algumas características comuns,representadas a seguir.

1.4Potencial de AdicionarValor ao Projeto

O potencial de adicionar valor a um projetoé, obviamente, alto no início do projeto,quando a maioria das definições ainda estáno papel, caindo até o término do projeto,quando o potencial de adicionar valor aoprojeto tende a ser mínimo.

Figura 2.1 – Potencial de adicionar valor ao projeto

em função do desenrolar do projeto.

1.5Custo das Mudanças ouCorreções

O custo de promover mudanças no projeto épequeno nas fases iniciais, crescendo expo-nencialmente com o progresso do projeto atéchegar ao seu custo total, podendo atémesmo superá-lo.

Figura 2.2 – Custo das mudanças / correções em

função do desenrolar do projeto.

1.6OportunidadeConstrutiva x IntervençãoDestrutiva

Conforme proposto por Wideman, ao sesobrepor o gráfico de potencial de adicionarvalor ao gráfico de custos de mudança, podese detectar que, nos momentos em que acurva do potencial de adicionar valor superaos custos de correção, tem-se o momento deoportunidade construtiva, quando asmudanças são vantajosas para o projeto.Quando a curva de potencial de adicionarvalor é inferior à de custos de correção, tem-se um cenário de intervenção destrutiva,uma vez que os recursos gastos para mudarsuperam o potencial de adicionar valor aoprojeto.

A conclusão obtida com a análise do gráfico éde que os momentos iniciais do projeto sãoos mais favoráveis à criatividade e à

mudança, uma vez que o cenário é de opor-tunidade construtiva. De modo oposto, osmomentos finais do projeto são fortementedesfavoráveis a novas ideias e criatividaderelacionadas aos processos de mudança,salvo nas mudanças corretivas diretamenterelacionadas ao término dos trabalhos.

Figura 2.3 – Oportunidade Construtiva x Inter-

venção Destrutiva

101/641

1.7Capacidade deAdequação

A capacidade de adequação do projeto anovas necessidades, ou seja, a capacidade dese alterarem as características finais do pro-jeto é grande no início, caindo gradativa-mente com o passar do tempo. Quanto maiso projeto se desenvolve, menor é a capacid-ade de adequação.

Figura 2.4 – Capacidade de adequação do projeto a

novas tecnologias em função do seu

desenrolar

103/641

1.8Incerteza do Risco xQuantidade Arriscada

Ao se comparar a incerteza do risco com aquantidade arriscada, tem-se que, no iníciodo projeto, o nível de incerteza é elevado,porém a quantidade arriscada é pequena,uma vez que se está em uma fase inicial doprojeto. Com seu desenrolar, a incerteza arespeito do risco diminui enquanto a quan-tidade arriscada aumenta, já que o projeto seencontra em fase avançada de execução. Operíodo mais crítico é o período de transição,quando se tem o mais alto impacto do risco(maior produto probabilidade x quantidade

arriscada)4, considerando que o impacto do

risco pode ser dado como o produto da incer-teza do risco pela quantidade arriscada. Essaregião coincide exatamente com o pontomáximo de esforço na relação esforço xtempo, descrita anteriormente, indicando



que o pico de esforço está, exatamente, naregião de maior impacto dos riscos.

Figura 2.5 – Análise comparativa da incerteza dos

riscos com a quantidade arriscada

105/641

AS FASES DOCICLO DE VIDADO PROJETO

As fases do ciclo de vida do projeto de-pendem, intimamente, da natureza do pro-jeto. Um projeto é desenvolvido a partir deuma ideia, progredindo para um plano, que,por sua vez é executado e concluído. Cadafase do projeto é caracterizada pela entrega,ou finalização, de um determinado trabalho.Toda entrega deve ser tangível e de fácilidentificação, como, por exemplo, um re-latório confeccionado, um cronograma es-tabelecido ou um conjunto de atividadesrealizado.

Genericamente, o ciclo de vida de um projetopode ser dividido em fases características,conforme ilustrado a seguir.

Figura 3.1 – O ciclo de vida do projeto subdividido

em fases ou Grupos de Processo

(PMBOK® Guide) característicos

Cada fase ou grupo do projeto normalmentedefine

• qual é o trabalho técnico que deve serrealizado;

• quem deve estar envolvido.

107/641

O número de fases em um projeto é uma fun-ção de sua natureza, podendo variar entrequatro e nove fases características. Diversasentidades, como o Departamento de Defesados Estados Unidos (DOD), a Agência Aer-oespacial Americana (NASA), o Project Man-agement Institute (PMI) e vários autoresdesenvolveram sua própria estratificação doprojeto em fases, porém todas elasabrangem, aproximadamente, a mesmagama de atividades. Para efeito didático, ser-ão consideradas apenas cinco fases caracter-ísticas. Essas cinco fases também são de-nominadas grupos de processos peloPMBOK® Guide.

Fase de Iniciação - É a fase inicial do pro-jeto, quando uma determinada necessidade éidentificada e transformada em um prob-lema estruturado a ser resolvido por ele.Nessa fase, a missão e o objetivo do projeto

108/641

são definidos, os documentos iniciais sãoconfeccionados e as melhores estratégias sãoidentificadas e selecionadas.

Fase de Planejamento - É a fase respon-sável por detalhar tudo aquilo que será real-izado pelo projeto, incluindo cronogramas,interdependências entre atividades, alocaçãodos recursos envolvidos, análise de custos,etc., para que, no final dessa fase, ele estejasuficientemente detalhado para ser ex-ecutado sem dificuldades e imprevistos.Nessa fase, os planos de escopo, tempo, cus-tos, qualidade, recursos humanos, comu-nicações, riscos e aquisições sãodesenvolvidos.

Fase de Execução - É a fase que material-iza tudo aquilo que foi planejado anterior-mente. Qualquer erro cometido nas fases an-teriores fica evidente durante essa fase.Grande parte do orçamento e do esforço doprojeto é consumida nessa fase.

109/641

Fase de Monitoramento e Controle - Éa fase que acontece paralelamente às demaisfases do projeto. Tem como objetivo acom-panhar e controlar aquilo que está sendorealizado pelo projeto, de modo a proporações corretivas e preventivas no menor es-paço de tempo possível após a detecção daanormalidade. O objetivo do controle é com-parar o status atual do projeto com o statusprevisto pelo planejamento, tomando açõespreventivas e corretivas em caso de desvio.

Fase de Encerramento - É a fase quandoa execução dos trabalhos é avaliada atravésde uma auditoria interna ou externa (terceir-os), os documentos do projeto são encerra-dos e todas as falhas ocorridas durante oprojeto são discutidas e analisadas para queerros similares não ocorram em novos proje-tos. Muito conhecida como Fase deAprendizado.

Uma análise direta do gráfico mencionadoanteriormente não é conclusiva quanto à

110/641

interdependência e sobreposição de fases noprojeto. Na verdade, com o desenrolar doprojeto, praticamente todas as fases e gruposde processo são realizadas quase que simul-taneamente, constituindo um ciclo, como émostrado na figura a seguir.

Figura 3.2 – Inter-relacionamento entre as fases/

grupos de processo em um projeto (PMI,

2008)

Sob outro aspecto, pode-se considerar que arealização de uma fase do projeto é tambémum projeto e, portanto, possui um determ-inado ciclo de vida e pode ser subdividida em

111/641

fases. Isso significa que existe uma iniciaçãoda fase de iniciação, um planejamento dafase de iniciação, uma execução e um con-trole da fase de iniciação e uma finalizaçãoda fase de iniciação, partindo, então, para ainiciação do planejamento, etc., como podeser visto na figura a seguir.

Figura 3.3 – Fase de execução detalhada em seu

próprio ciclo de vida

112/641

O PMBOK também evidencia esse inter-rela-cionamento entre as fases de uma maneirabastante clara e intuitiva, representando, emum mesmo gráfico, os ciclos de vida de todasas fases do projeto.

Figura 3.4 – Sobreposição das fases em um projeto

113/641

INTEGRAÇÃOENTREDESEMPENHO,CUSTO E TEMPOEM PROJETOS

Em todo projeto existe uma relação estreitaentre os fatores de desempenho ou perform-ance (escopo e qualidade), custo e tempo.Isso quer dizer que é impossível predeter-minar todos os fatores simultanea-mente. É preciso que, com base em doisfatores, se determine o terceiro como umafunção interna do projeto, ou seja, o máximoque se pode fazer é predeterminar doisfatores e calcular o terceiro como uma

função dos dois anteriores. Em geral, é ne-cessário que se conheçam, detalhadamente,dois fatores e o escopo do projeto para que sedetermine o terceiro fator, fechando todo o

cenário PCT5

do projeto.

No desenvolvimento de cada projeto, é inev-itável se deparar com a inter-relação entredesempenho (escopo e qualidade), custo etempo em um determinado escopo, quedefine aquilo que será, ou não, abrangidopelo projeto, isto é, as necessidades que ser-ão, ou não, atendidas pelo projeto. É impos-sível desenvolver um projeto que tenha umescopo de aplicabilidades ilimitado.

115/641



Figura 4.1 – Relacionamento entre os fatores

desempenho, custo e tempo para um de-

terminado projeto

Shtub afirma que a importância de cada umdesses fatores é dada pela natureza do pro-jeto, podendo um fator ter, ou não, mais im-portância que os demais devido às caracter-ísticas e ao objetivo do projeto específico,como é mostrado a seguir.

116/641

Figura 4.2 – Importância relativa entre os fatores

desempenho, custo e tempo em projetos

diferentes

De modo a facilitar a análise dos fatores, épreciso que se fixe um deles, transformandoa relação tridimensional em uma relação bid-imensional, de fácil entendimento.

117/641

Figura 4.3 – Plano desempenho-custo destacado

para um tempo fixo C

Ao se considerarem os relacionamentos doisa dois têm-se três planos de relacionamento,a saber:

• custo e tempo;

• desempenho e tempo;

• desempenho e custo (mostrado nafigura anterior).

118/641

A seguir, cada um desses relacionamentosserá analisado, procurando-se evidenciar os“pontos ótimos” de relacionamento. Os gráfi-cos que se seguem são ilustrativos e cobrema maioria dos projetos. Contudo, podem exi-stir projetos que não tenham os comporta-mentos aqui colocados.

119/641

1.9Análise do Custo xDuração do Projeto

Figura 4.4-Evolução do custo do projeto com sua

duração

É a relação mais importante entre doisfatores do projeto. Observa-se, no gráfico an-terior, que, em projetos realizados em umprazo reduzido, o custo do projeto torna-seelevado devido à quantidade de horas-extras,pessoal e controle. Quando o tempo

destinado ao projeto é adequado, ele atingeseu ponto mais baixo (custo ótimo). Apósesse período, o custo volta a subir devido àineficiência no projeto e à perda deprodutividade.

Por exemplo, se uma pessoa constrói umacasa de alvenaria em dois meses, o custo doprojeto será elevado devido à grande quan-tidade de pessoas trabalhando, muitas delasem regime de horas-extras, e devido àgrande necessidade de controle, tornando oscustos de administração significativamentemais altos. Se a pessoa dispõe de dez a dozemeses para a construção, encontrará um val-or mínimo de custo (ideal). Porém, se de-morar vários anos para construir a casa, seucusto voltará a aumentar devido a perdas dematerial estocado e retrabalho (ineficiência).

121/641

1.10Análise doDesempenho x Duração doProjeto

Figura 4.5-Evolução do desempenho com a duração

do projeto

Observa-se, no gráfico anterior, que, em pro-jetos com a duração muito reduzida, odesempenho (escopo e qualidade) pode ficarprejudicado pela pressa na conclusão. Já emprojetos com uma duração ideal, o desem-penho é máximo (ponto ótimo). Após esse

ponto, a qualidade do projeto se estabiliza epode até cair devido à ineficiência do projetoe à perda de motivação e senso de equipe.

Por exemplo, é impossível construir umacasa de alvenaria de qualidade em dois dias.Se o construtor dispõe de dez a doze mesespara a construção, encontrar-se-á o pontoideal de qualidade. Porém, se o construtorlevar 50 anos para construir uma casa re-lativamente simples, isso resultará em perdade qualidade por ineficiência, uma vez que aestrutura da casa, a alvenaria e os outroscomponentes estarão expostos às intem-péries e à destruição durante todo o períododo projeto e, muito provavelmente, o time doprojeto deverá ter sido modificado inúmerasvezes nesses 50 anos.

123/641

1.11Análise doDesempenho xInvestimento

Figura 4.6-Evolução do desempenho com o investi-

mento no projeto

Observa-se, no gráfico anterior, que odesempenho do projeto é diretamente rela-cionado ao investimento nele. No entanto, aose atingir um determinado nível deinvestimento, torna-se impossível converter

mais capital em desempenho devido àpresença de outros elementos limitantes doprojeto, como tempo (prazo), riscos e escopo.

Por exemplo, quanto mais capital se utilizapara construir uma casa, maior qualidade elairá ter, pois utilizará materiais superiores emão de obra mais qualificada. Porém, apósum determinado patamar de investimento, odesempenho se estabiliza porque os limit-antes do desempenho passam a ser outros,tais como o escopo e o tempo.

As conclusões anteriores são genéricas e,devido à ineficiência gerencial ou técnica doprojeto, pode-se ter uma casa que consumaum investimento elevado e não tenha a qual-idade desejada.

125/641

1.12Análise doDesempenho x Escopo

Figura 4.7-Evolução do desempenho com o escopo

do projeto

Apesar de o escopo ser um dado definidopelo projeto, na maioria das vezes, é import-ante analisar o impacto de escopos genéricose limitados no desempenho do projeto. Umescopo genérico demais não fornece sequer

referenciais para a medição de desempenho.Já um escopo extremamente reduzido e es-pecífico torna o projeto quase inviável, poisas limitações e as restrições são tantas que odesempenho fica diretamente prejudicado.

Por exemplo, se uma pessoa deseja compraruma casa pronta e estabelece como escopopara sua procura uma casa que tenha cincoquartos, dois andares com varandas pintadasde verde, quatro vagas de garagem isoladasao ar livre, pinheiros amarelos plantados nojardim, fonte luminosa na varanda principal,janelas de vidro na sala de jantar, cozinhacom granito amarelo e bancada em mármorevioleta, ela provavelmente não encontraránenhuma casa exatamente nessas condições,tornando a possibilidade de se atingir odesempenho desejado pequena. Se ela pro-curar por uma casa de três quartos e duas va-gas de garagem e um jardim florido, teráaumentado significativamente a possibilid-ade de encontrar algumas casas que atendam

127/641

a esse escopo. Já se ela procurar por apenasuma casa (escopo muito genérico), possivel-mente várias casas serão encontradas, mas apossibilidade de nenhuma casa agradar émuito grande. Quando se tem um escopogenérico demais, o processo de escolha setorna demorado devido à grande quantidadede opções (desempenho reduzido).

128/641


1. Por que o final de um projeto normal-mente tem um perfil lento develocidade?

2. Explique a diferença entre Oportunid-ade Construtiva e IntervençãoDestrutiva.

3. Por que o Monitoramento e o Con-trole devem acontecer ao longo de todoo projeto?

4. Explique o conceito de que cada faseou grupo de processo pode ser consid-erado um projeto.

5. Por que não é possível a determinaçãodireta do desempenho, do custo e dotempo do projeto de modo simultâneo?

6. Como a importância relativa entre odesempenho, o custo e o tempo para umdeterminado projeto pode influenciar aestratégia de abordagem do projeto?

7. Por que projetos com a duração exces-siva acabam tendo seu custoaumentado?

8. É correto afirmar que quanto maiscapital disponível, mais desempenho éobtido? Justifique.

9. Explique a relação entre escopo edesempenho.

130/641

PALAVRACRUZADA

Ciclo de Vida de um Projeto

132/641

- PARTE III -PRINCIPAIS ÁREAS

DO GERENCIAMENTODE PROJETOS

SEGUNDO O PMBOKGUIDE® 4a Edição

1. DEFINIÇÕES

As áreas do gerenciamento de projetosdescrevem o gerenciamento de projetos emtermos de seus processos componentes.Esses processos podem ser organizados emnove grupos integrados, como descrito nafigura a seguir.

Figura 1.1 – Processo integrado de gerenciamento

de projetos com destaque para as nove

áreas de conhecimento

Cada um desses processos tem um detal-hamento específico e uma abrangência pró-pria, porém está integrado, a todo o mo-mento, com os demais, formando um todoúnico e organizado.

135/641

Gerenciamento da Integração – Áreaque engloba os processos requeridos para as-segurar que todos os elementos do projetosejam adequadamente coordenados e integ-rados, garantindo que o seu todo seja semprebeneficiado.

Gerenciamento de Escopo – Área queengloba os processos necessários para asse-gurar que, no projeto, esteja incluído todo otrabalho requerido, e somente o trabalho re-querido, para concluí-lo de maneira bemsucedida.

Gerenciamento de Tempo – Área queengloba os processos necessários para asse-gurar a conclusão do projeto no prazo prev-isto. É uma das áreas mais visíveis do geren-ciamento de projetos.

Gerenciamento de Custos – Área que en-globa os processos requeridos para assegurarque um projeto seja concluído de acordo comseu orçamento previsto.

136/641

Gerenciamento da Qualidade – Áreaque engloba os processos requeridos para as-segurar que os produtos ou serviços do pro-jeto estarão em conformidade com o solicit-ado pelo cliente, ou contratante.

Gerenciamento de Recursos Humanos– Área que engloba os processos requeridospara fazer uso mais efetivo do pessoal en-volvido com o projeto.

Gerenciamento das Comunicações –Área que engloba os processos requeridospara assegurar que as informações do pro-jeto sejam adequadamente obtidas edisseminadas.

Gerenciamento de Riscos – Área quevisa planejar, identificar, qualificar, quantifi-car, responder e monitorar os riscos doprojeto.

Gerenciamento das Aquisições – Áreaque engloba os processos requeridos paraadquirir bens e serviços de fora da

137/641

organização promotora. Também conhecidocomo gerenciamento de suprimentos oucontratos.

138/641

PROCESSOS DOPMBOK® GUIDE

4A EDIÇÃO6

No PMBOK® Guide 4a Edição são aborda-dos quarenta e dois processos divididos nasnove áreas de conhecimentos apresentadasanteriormente, formando um fluxo contínuode processos, como o descrito na figura aseguir.



140/641

Figura 2.1 – Quarenta e dois processos do PMBOK

Guide 4a Edição subdivididos nas fases

do projeto

Observa-se na figura anterior que os pro-cessos dentro das nove áreas de conheci-mento são inter-relacionados. A questão éque o PMBOK Guide 4ª Edição é estruturadode acordo com as áreas de conhecimento enão com os grupos de processos ou fases doprojeto. O Anexo I apresenta o original doartigo apresentado ao PMI em 2001 quepropõe uma nova visão do PMBOK Guide

orientada para as fases do projeto7.

141/641



2.DESMEMBRANDOO PMBOKATRAVÉS DEMAPASMENTAIS(MINDMAPS)

Mapas mentais, também conhecidos comoMindmaps são considerados um padrãomundial para criação, gerenciamento ecomunicação de ideias. Os mapas mentaisapóiam a organização de ideias, de conheci-mento através de uma visualização intuitiva

e amigável, alem de possuir grande versatil-idade visual.

Mapas mentais se iniciam com uma ideiacentral, onde todos os ramos do mapa signi-ficam uma decomposição da ideia principalem ideias relacionadas, baseadas em ummodelo visual de pensamento.

O pensamento visual é um conceito baseadonas pesquisas de como o cérebro humanofuncional, onde se busca o estímulo do sensovisual e tátil, de modo a aumentar a cri-atividade e o entendimento das partes emum todo unificado, reduzindo o tempo dedesenvolvimento e entendimento de ideias.

Como se sabe, o PMBOK Guide é divididoem nove áreas e quarenta e dois processos,como é apresentado nos mapas mentais aseguir. Em cada um dos próximos capítulos,os mapas mentais de cada uma das áreas ser-ão apresentados em detalhes.

143/641

Figura 3.1 – Mapa mental das nove áreas do geren-

ciamento de projetos segundo o PMBOK

Guide 4a Edição8

Neste mapa mental as nove áreas de conhe-cimento do PMBOK Guide são apresentadasdentro do todo de conhecimento do PMI.

Ao detalhar cada uma das áreas nos quar-enta e dois processos, tem-se o mapa aseguir, onde os processos são agrupados deacordo com as cinco fases ou grupos deprocesso.

144/641



145/641

Figura 3.2 – Mapa mental dos quarenta e dois pro-

cessos do PMBOK Guide 4a Edição.

146/641

3.GERENCIAMENTODAINTEGRAÇÃO

“O sucesso de todo o gerenciamento de projetos depende unicamente da relação entre suas

áreas.”

Vijay K. Verma

1.13Definição

O processo de integração do projeto consisteem garantir que todas as demais áreas es-tejam integradas em um todo único. Seu ob-jetivo é estruturar todo o projeto de modo agarantir que as necessidades dos envolvidossejam atendidas pelo projeto.

Figura 4.1-Gerenciamento da Integração como área

central do gerenciamento de projetos

1.14Mindmap dosprocessos deGerenciamento daIntegração

Os processos de gerenciamento da integ-ração se decompõem conforme o mapa men-tal a seguir.

Figura 4.2 – Mapa mental do Gerenciamento da

Integração

1.15Processos deGerenciamento daIntegração

O PMBOK subdivide o gerenciamento da in-tegração em seis processos:

• Desenvolver o termo de abertura doprojeto (4.1) ;

• Desenvolver o plano de gerenciamentodo projeto (4.2) ;

• Orientar e gerenciar a execução doprojeto (4.3) ;

• Monitorar e controlar o trabalho doprojeto (4.4);

• Realizar o controle integrado demudanças (4.5) ;

• Encerrar o projeto ou fase (4.6).

Figura 4.3 – Processos de Gerenciamento da Integ-

ração distribuídos ao longo das fases do

projeto

Desenvolver o termo de abertura doprojeto - Desenvolver o termo de aberturado projeto é o processo de desenvolvimentode um documento que formalmente autorizaum projeto ou uma fase e a documentaçãodos requisitos iniciais que satisfaçam as ne-cessidades e expectativas das partes in-teressadas. Estabelece uma parceria entre aorganização executora e a organização soli-citante (ou cliente, no caso de projetosexternos).

151/641

Figura 4.4 – Mapa mental do processo Desenvolver

o termo de abertura do projeto

Desenvolver o plano de gerenciamentodo projeto - Desenvolver o plano de geren-ciamento do projeto é o processo de docu-mentação das ações necessárias para definir,preparar, integrar e coordenar todos os pla-nos auxiliares.


o plano de gerenciamento do projeto

Orientar e gerenciar a execução doprojeto - Orientar e gerenciar a execução doprojeto é o processo de realização do

152/641

trabalho definido no plano de gerenciamentodo projeto para atingir os objetivos.

Figura 4.6– Mapa mental do processo Orientar e

gerenciar a execução do projeto

Monitorar e controlar o trabalho doprojeto - Monitorar e controlar o trabalhodo projeto é o processo de acompanhamento,revisão e ajuste do progresso para atenderaos objetivos de desempenho definidos noplano de gerenciamento.

153/641

Figura 4.7-Mapa mental do processo Monitorar e

controlar o trabalho do projeto

Realizar o controle integrado demudanças - Realizar o controle integradode mudanças é o processo de revisão de to-das as solicitações, aprovação e geren-ciamento de mudanças em entregas, ativosde processos organizacionais, documentosde projeto e plano de gerenciamento doprojeto.

Figura 4.8-Mapa mental do processo Realizar o

controle integrado de mudanças

Encerrar o projeto ou fase - Encerrar oprojeto ou fase é o processo de finalização detodas as atividades, de todos os grupos deprocessos de gerenciamento do projeto, paraencerrar formalmente o projeto ou a fase.

154/641

Figura 4.9-Mapa mental do processo Encerrar o

projeto ou fase

No gerenciamento da integração, é import-ante que se atente para os seguintesaspectos:

• Verificar se todas as outras áreas têmprocessos de controle de mudanças es-pecíficos que atuam como subsídio aoprocesso global de controle demudanças;

• manter sempre os registros de desem-penho para garantir um melhor monit-oramento do desempenho;

• avaliar sempre se as metas e os objet-ivos do projeto estão evidenciados emtodos os outros planos do projeto;

155/641

• avaliar sempre de maneira integradaqualquer necessidade dereplanejamento;

• utilizar-se do plano de gerenciamentodas comunicações para garantir que to-das as informações relativas à integ-ração estejam disponíveis para as de-mais áreas.

156/641

1.16Termo de Abertura doProjeto ou Project Charter

O Termo de Abertura do Projeto ou ProjectCharter é o documento legal que reconhece aexistência de um projeto. Ele serve comouma linha de base para o trabalho do gerentedo projeto. Contém diversas informaçõessobre o projeto, incluindo estimativas inici-ais de qual o prazo destinado, recursos ne-cessários e orçamento disponível.

Usualmente o termo de abertura do projetocontém

• título do projeto;

• um resumo das condições que definemo projeto (introdução);

• justificativa do projeto;

• nome do gerente de projeto e suas re-sponsabilidades e autoridades;

• necessidades básicas do trabalho a serrealizado;

• principais partes interessadas;

• descrição do produto do projeto;

• cronograma básico do projeto;

• estimativas iniciais de custo;

• necessidades iniciais de recursos;

• necessidade de suporte pelaorganização;

• premissas e restrições;

• controle e gerenciamento das inform-ações do projeto;

• aprovações com assinatura do exec-utivo responsável pelo documento (ele-mento externo ao projeto).

158/641

1.17Plano Global do Projeto

O Plano Global do Projeto é o documentoformal que descreve os procedimentos a ser-em conduzidos durante a sua execução. É oalicerce de toda a execução. Nele estão con-tidos todos os planos secundários, cronogra-mas, aspectos técnicos, etc.

O Plano Global do Projeto deve conter:

• a visão geral dos objetivos, metas eescopo do projeto de uma maneira re-sumida e macro para atender aos altosexecutivos do projeto (pequena in-trodução do assunto);

• o objetivo detalhado do projeto paraatender ao gerente do projeto e ao timedo projeto;

• o nome e as responsabilidades do ger-ente e do time principal do projeto (mat-riz de responsabilidades);

• o organograma do projeto;

• estudo técnico da solução a ser adot-ada pelo projeto;

• aspectos contratuais quanto à parti-cipação de elementos externos aoprojeto;

• Estrutura Analítica do Projeto ouWork Breakdown Structure (WBS);

• cronogramas (Gráficos de Gantt e Dia-gramas de Rede);

• principais marcos com suas datas;

• utilização de recursos pelo projeto (re-latório com as funções);

• orçamento, análise de custos e fluxosde caixa;

• necessidade de contratação e treina-mento de pessoal;

• formas previstas de avaliação dos ín-dices de qualidade e desempenho a ser-em atingidos pelo projeto;

160/641

• potenciais obstáculos a serem en-frentados pelo projeto e possíveissoluções;

• lista de pendências;

• planos das áreas de conhecimento(também considerados planos auxili-

ares)9:

• Plano de Gerenciamento de Escopo;

• Plano de Gerenciamento de Tempo;

• Plano de Gerenciamento de Custos;

• Plano de Gerenciamento da Qualidade;

• Plano de Gerenciamento de RecursosHumanos;

• Plano de Gerenciamento dasComunicações;

• Plano de Gerenciamento de Riscos;

• Plano de Gerenciamento dasAquisições.

161/641



GERENCIAMENTODE ESCOPO

“Aqueles que se esquecem dos erros do passado estão condenados a repeti-los no futuro.”

George Santayana

1.18Definição

O gerenciamento de escopo tem como objet-ivo principal definir e controlar os trabalhosa serem realizados pelo projeto de modo agarantir que o produto, ou serviço, desejadoseja obtido através da menor quantidade detrabalho possível, sem abandonar nenhumapremissa estabelecida no objetivo do projeto.

Uma importante diferenciação precisa serestabelecida entre projeto e produto, no quediz respeito ao escopo. Kerzner afirma que amaior parte dos ciclos de vida de produtos eprojetos são similares, exceto em um fator:os projetos têm um ciclo de vida predefinido,ao passo que o produto existe enquanto exi-stir uma finalidade comercial para ele, ouseja, enquanto ele for lucrativo e interessantepara a organização.

Portanto, o escopo de um projeto é definidocomo o trabalho que precisa ser

desenvolvido para garantir a entrega de umdeterminado produto dentro de todas as suasespecificações e funções.

Genericamente, o escopo pode ser sub-dividido em:

Escopo Funcional – Conjunto de caracter-ísticas funcionais do produto, ou serviço, aser desenvolvido pelo projeto, tais como ca-pacidade, mercado, filosofia, etc. Normal-mente são direcionados ao cliente e são tam-bém denominados requisitos funcionais;

Escopo Técnico – Características técnicasdo projeto, destacando os padrões e as espe-cificações a serem utilizadas, normas legais aserem obedecidas, procedimentos de qualid-ade (ISO) etc. Normalmente são direcion-ados para a equipe do projeto e são tambémdenominados requisitos técnicos;

Escopo de Atividades – Trabalho a serrealizado para prover o escopo técnico e oescopo funcional do produto, ou serviços, do

164/641

projeto, normalmente evidenciado na Estru-tura Analítica do Projeto (EAP).

Um projeto com um detalhamento de escoposignificativamente grande possui uma com-plexidade muito alta no que diz respeito aogerenciamento de escopo. É importantetrabalhar-se com um escopo que garanta oproduto, ou serviço, do projeto, sem ser de-masiadamente detalhado, para que seu ger-enciamento não se torne excessivamentecomplexo.

Figura 5.1 – Detalhamento do Escopo x Complexid-

ade no gerenciamento

165/641

1.19Mindmap dosProcessos deGerenciamento de Escopo

Os processos de gerenciamento de escopo sedecompõem conforme o mapa mental aseguir.

Figura 5.2 – Mapa mental do Gerenciamento de

Escopo

1.20Processos deGerenciamento de Escopo

O PMBOK subdivide o gerenciamento deescopo em cinco processos, a saber:

• Coletar os requisitos (5.1);

• Definir o escopo (5.2);

• Criar a EAP (5.3);

• Verificar o escopo (5.4);

• Controlar o escopo (5.5).

Figura 5.3 – Processos de Gerenciamento de Escopo

distribuídos ao longo das fases do projeto

Coletar os requisitos - Processo de definire documentar as funções e funcionalidadesdo projeto e do produto necessárias paraatender às necessidades e expectativas daspartes interessadas.

Figura 5.4 – Mapa mental do processo Coletar os

requisitos

Definir o escopo - Definir o escopo é pro-cesso de desenvolvimento de uma descriçãodetalhada do projeto e do produto. A pre-paração detalhada da declaração do escopo écrítica para o sucesso e baseia-se nas entre-gas principais, premissas e restrições que sãodocumentadas durante a iniciação doprojeto.

168/641

Figura 5.5 – Mapa mental do processo Definir o

escopo

Criar a EAP - Criar a EAP é o processo desubdivisão das entregas e do trabalho doprojeto em componentes menores e de ger-enciamento mais fácil.

Figura 5.6 – Mapa mental do processo Criar a EAP

Verificar o escopo - Verificar o escopo é oprocesso de formalização da aceitação dasentregas concluídas do projeto. Inclui a re-visão das entregas com o cliente ou

169/641

patrocinador para assegurar que foram con-cluídas satisfatoriamente e obter deles aaceitação formal das mesmas.

Figura 5.7 – Mapa mental do processo Verificar o

escopo

Controlar o escopo – É o processo demonitoramento do andamento do escopo doprojeto e do produto e gerenciamento dasmudanças feitas na linha de base do escopo.

Figura 5.8 – Mapa mental do processo Controlar o

escopo

170/641

1.21Documento deRequisitos do Projeto

É o documento que registra os requisitos ne-cessários para atender às necessidades doprojeto. Ele pode ser construído a partir derequisitos de alto nível, sendo detalhado pro-gressivamente com o projeto.

Normalmente o Documento de Requisitos doProjeto contém:


• nome da pessoa que elaborou odocumento;

• descrição básica do projeto e daoportunidade;

• objetivo do projeto;

• requisitos funcionais desejáveis(priorizados);

• requisitos não funcionais (relacionadosao desempenho, segurança, confiden-cialidade etc.);

• requerimentos principais de qualidade(serão detalhados no Plano deQualidade);

• critérios de aceitação do projeto;

• potenciais impactos do projeto em out-ras áreas;

• restrições consideradas na criação dosrequerimentos;

• premissas consideradas na criação dosrequerimentos;

• registro de alterações no documento derequisitos;

• aprovações.

172/641

1.22Plano deGerenciamento dosRequisitos do Projeto

O Plano de Gerenciamento dos Requisitos doProjeto é auxiliar ao plano de gerenciamentode projetos e descreve os procedimentos queserão utilizados para documentar como osrequerimentos serão analisados, documenta-dos e gerenciados através do projeto.

No plano, deve estar documentado:



• critério de priorização dos requisitos;

• critérios de rastreabilidade dosrequisitos;

• sistema de controle de mudanças nosrequisitos;

• níveis de aprovação de mudanças nosrequisitos;

• outros assuntos relacionados ao geren-ciamento de requisitos do projeto nãoprevistos no plano;

• registro de alterações no documento;

• aprovações.

174/641

1.23Matriz deRastreabilidade deRequisitos (RTM)

A matriz de rastreabilidade de requisitos ouRequirements Traceability Matrix (RTM) éum documento em forma de tabela que listaos requisitos do projeto de modo a permitir orastreamento do requisito dentro da EAP doprojeto, determinando seu status, teste e re-quisitos relacionados. Tem como objetivogarantir que cada requerimento adicione val-or ao objetivo do projeto e esteja perfeita-mente ligado ao escopo de atividades.

A matriz usualmente contém os seguintescampos:

• ID do requisito;

• nome do requisito;

• descrição do requisito;

• tipo do requisito;

• prioridade do requisito;

• elemento(s) da EAP onde o requisitoestá associado;

• outros requisitos associados e relacion-ados (ID);

• status do requisito;

• critério de aceitação e conclusão;

• comentários.

176/641

1.24Declaração de Escopoou Scope Statement

É o documento que formaliza o escopo de to-dos os trabalhos a serem desenvolvidos noprojeto, servindo de base para futuras de-cisões do projeto. É possível que, ao longo doprojeto, a declaração de escopo seja revisada,ou refinada, para refletir as mudançasacontecidas nele.

Normalmente, a Declaração de Escopocontém:



• nome do patrocinador;

• nome do gerente do projeto e suas re-sponsabilidades e autoridades;

• nome dos integrantes do time doprojeto;

• descrição do projeto;



• produto do projeto;

• expectativa do cliente/patrocinador;

• fatores de sucesso do projeto;

• restrições;

• premissas;

• exclusões específicas (tudo o que nãoserá abordado pelo projeto);

• principais atividades e estratégias doprojeto;

• principais entregas do projeto;

• orçamento básico do projeto;

• plano de entregas e marcos do projeto;


• aprovações.

178/641

1.25Plano deGerenciamento do Escopo

O Plano de Gerenciamento do Escopo é aux-iliar ao plano de gerenciamento de projetos edescreve os procedimentos que serão utiliza-dos para gerenciar todo o escopo do projeto.




• descritivo dos processos de geren-ciamento do escopo (regras gerais);

• priorização das mudanças de escopo erespostas;

• sistema de controle de mudanças deescopo (Scope Change Control System);

• frequência de avaliação do escopo doprojeto;

• alocação financeira das mudanças deescopo;

• nome do responsável pelo plano;

• frequência de atualização do plano degerenciamento do escopo;

• outros assuntos relacionados ao geren-ciamento do escopo do projeto não prev-istos no plano;


• aprovações.

180/641

GERENCIAMENTODE TEMPO

“Quando eles dizem que você está atrasado no projeto, isso é somente uma maneira educada

de se dizer que você tem um péssimo senso de prazos.”

George McGovern

1.26Definição

O gerenciamento do tempo, juntamente como gerenciamento de custos, são as mais visí-veis áreas do gerenciamento de projeto. Agrande maioria das pessoas que se interes-sam por projetos têm como objetivo inicialcontrolar prazos, confeccionar cronogramase redes, etc.

O principal objetivo dessa área é garantir queo projeto seja concluído dentro do prazodeterminado.

Como já se sabe, o tempo não espera porninguém, especialmente por aquele gerenteque constrói cronogramas baseados em datasimpossíveis. O cronograma do projeto ésempre uma restrição, até mesmo quando adata de término não é crítica. Se um projetoatrasa, na maioria das vezes ele irá consumirum capital que ele não tinha previsto, com-prometendo, também, o seu custo, podendo

até mesmo causar sérias consequências mer-cadológicas para o produto, ou serviço, doprojeto.

O gerenciamento do tempo também é con-siderado uma das razões mais importantespara o estabelecimento de conflitos entre osenvolvidos no projeto, conforme estudo real-izado por Thamhain & Wilemon (1975) e rev-isto por Posner (1986).

Figura 6.1 – Tendência de conflitos relativos ao ger-

enciamento do tempo ao longo do pro-

jeto (baseado em trabalhos de Thamhain

e Wilemon)

183/641

1.27Mindmap dosProcessos deGerenciamento de Tempo

Os processos de gerenciamento de tempo sedecompõem conforme o mapa mental aseguir.


Tempo

1.28Processos deGerenciamento de Tempo

O PMBOK subdivide o gerenciamento detempo em seis processos:

• Definir as atividades (6.1);

• Sequenciar as atividades (6.2);

• Estimar os recursos das atividades(6.3);

• Estimar as durações das atividades(6.4);

• Desenvolver o cronograma (6.5);

• Controlar o cronograma (6.6);

Figura 6.3 – Processos de Gerenciamento de Tempo


Definir as atividades - Definir as ativid-ades é o processo de identificação das açõesespecíficas a serem realizadas para produziras entregas do projeto

186/641

Figura 6.4 – Mapa mental do processo Definir as

atividades

Sequenciar as atividades - Sequenciar asatividades é o processo de identificação edocumentação dos relacionamentos entre asatividades do projeto.

Figura 6.5 – Mapa mental do processo Sequenciar

as atividades

Estimar os recursos das atividades -Estimar os recursos da atividade é o processode estimativa dos tipos e quantidades de ma-terial, pessoas, equipamentos ousuprimentos que serão necessários para real-izar cada atividade.

187/641

Figura 6.6 – Mapa mental do processo Estimar os

recursos das atividades

Estimar as durações das atividades -Estimar as durações da atividade é o pro-cesso de estimativa do número de períodosde trabalho que serão necessários para ter-minar as atividades específicas com os re-cursos estimados.

Figura 6.7 – Mapa mental do processo Estimar as

durações das atividades

188/641

Desenvolver o cronograma - Desen-volver o cronograma é o processo de análisede sequências das atividades, suas durações,recursos necessários e restrições do crono-grama visando criar o cronograma doprojeto.


o cronograma

Controlar o cronograma - Controlar ocronograma é o processo de monitoramentodo andamento do projeto para atualização doseu progresso e gerenciamento dasmudanças feitas na linha de base docronograma.

189/641

Figura 6.9 – Mapa mental do processo Controlar o

cronograma

No gerenciamento de tempo, é importanteque se atente para os seguintes aspectos:

• nenhum cronograma é perfeito, masisso não impede que o projeto façasempre a melhor estimativa possível;

• o cronograma do projeto determina,em parte, o seu orçamento;

• o nível de detalhamento dos cronogra-mas é uma função do tamanho doprojeto;

• sempre deve-se estimar o tempobaseado no melhor e no pior cenário;

190/641

• gerenciamento de projetos não ésomente gerenciamento de tempo.

191/641

1.29Plano deGerenciamento doCronograma

Como já citado anteriormente no capítulo deintegração e escopo, o plano de geren-ciamento do cronograma também é consid-

erado um documento de apoio do projeto10

.O plano formaliza os procedimentos que ser-ão utilizados para gerenciar todos os prazosdo projeto.




• descritivo dos processos de geren-ciamento do cronograma (regras gerais);

• priorização das mudanças de prazos;



• sistema de controle de mudanças deprazos (Time Change Control System);

• frequência de avaliação de prazos doprojeto;

• alocação financeira para o geren-ciamento do cronograma;


• frequência de atualização do plano degerenciamento do cronograma;

• outros assuntos relacionados ao geren-ciamento de tempo não previstos noplano;


• aprovações.

193/641

GERENCIAMENTODE CUSTOS

“Nunca se esqueça: uma pequena mentira destrói completamente toda a integridade e a

reputação do projeto.”

Baseado em Baltazar Garcián

1.30Definição

O gerenciamento de custos tem como objet-ivo garantir que o capital disponível será su-ficiente para obter todos os recursos para serealizarem os trabalhos do projeto.

O gerenciamento de custos não pode consid-erar apenas os custos incorridos no próprioprojeto. Muitas vezes, o projeto está desen-volvendo um produto, ou serviço, com in-teresse comercial, e esse produto, por suavez, estará recompensando financeiramentea empresa, retornando tanto o dinheiro in-vestido quanto o lucro desejado, estabelecidona concepção do projeto.

Figura 7.1 – Ciclo financeiro de vida de um projeto

No gráfico anterior, tem-se, em um primeiromomento, o ciclo de investimentos no pro-jeto. O custo total do projeto é de $x, e seuprazo de desenvolvimento é de y meses.Após esse período, inicia-se, imediatamente,a comercialização, obtendo uma receita con-forme a curva superior do gráfico e um lucrooperacional dado pela segunda curva dos re-tornos acumulados. Quando o lucro opera-cional acumulado atinge $x, tem-se o

196/641

Breakeven do projeto, ou seja, o tempo que oprojeto leva para se pagar, que é dado por zmeses a partir do início do projeto, ou z-ymeses a partir do início da comercializaçãodo produto. Após esse período, o projetopassa a ter um lucro real, determinado pelovalor do lucro operacional que superar $x.Porém, o produto desenvolvido também temum ciclo de vida comercial, e, após umtempo t, o produto se deteriora comercial-mente, tendo alcançado uma receita opera-cional final de $k, um lucro operacional totalde $w e um lucro final do empreendimento(resultado) de $(w-x).

Outro aspecto importante com relação aogerenciamento de custos diz respeito aos or-çamentos. O orçamento não pode ser consid-erado simplesmente como uma visão do pla-no. Ele é um mecanismo poderoso de con-trole. O orçamento serve como parâmetro decomparação, uma linha de base da qual seextraem informações sobre o desempenho

197/641

financeiro do projeto. O orçamento precisaser validado ao longo do tempo, durante aexecução do projeto (controle de custos),para que os eventuais problemas sejam iden-tificados o mais cedo possível para que asolução possa ser antecipada, evitando-se,assim, danos mais graves ao orçamento.

Muitas vezes, o gerenciamento de custospropicia um processo de recompensa para osenvolvidos no projeto, através de parti-cipação nos seus resultados. Nesses casos, ocontrole de custos merece uma atenção espe-cial, sendo talvez alvo de um processo de or-çamentação paralelo, de modo a garantir queeles reflitam o real resultado do projeto.

As maiores causas de falhas no geren-ciamento de custos podem ser atribuídas aelementos externos ao processo isolado decustos. São elas:

• interpretação errada do trabalho a serrealizado;

198/641

• omissão na definição do escopo dotrabalho;

• cronograma pobremente definido ouexcessivamente otimista;

• fracasso na avaliação de riscos;

• estrutura analítica do projeto (WBS)mal definida;

• parâmetros de qualidade malestabelecidos;

• fracasso na estimativa dos custos in-diretos e administrativos do projeto.

199/641

1.31Mindmap dosProcessos deGerenciamento de Custos

Os processos de gerenciamento de custos sedecompõem conforme o mapa mental aseguir.


Custos

1.32Processos deGerenciamento de Custos

O PMBOK subdivide o gerenciamento decustos em três processos:

• Estimar os custos (7.1);

• Determinar o orçamento (7.2);

• Controlar os custos (7.3).

Figura 7.3 – Processos de Gerenciamento de Custos


Estimar os custos - Estimar os custos é oprocesso de desenvolvimento de uma estim-ativa dos recursos monetários necessáriospara executar as atividades do projeto.

Figura 7.4 – Mapa mental do processo Estimar os

custos

Determinar o orçamento - Determinar oorçamento é o processo de agregação doscustos estimados de atividades individuaisou pacotes de trabalho para estabelecer umalinha de base dos custos autorizada.

202/641

Figura 7.5 – Mapa mental do processo Determinar

o orçamento

Controlar os custos - Controlar os custosé o processo de monitoramento do progressodo projeto para atualização do seu orça-mento e gerenciamento das mudanças feitasna linha de base dos custos.

Figura 7.6 – Mapa mental do processo Controlar os

custos

No gerenciamento de custos, é importanteque se atente para os seguintes fatores:

• Em projetos sob contrato, é import-ante diferenciar estimativas de custos deprecificação: custos são resultantes dasnecessidades de recursos, etc., do pro-jeto, enquanto o preço é uma decisão deestratégia de negócio da organização;

203/641

• qualquer estimativa de custos deve viracompanhada por sua memória decálculo;

• bancos de dados comerciais semprepodem ser utilizados na estimativa derecursos e custos, bem como os registrosobtidos em projetos anteriores;

• muitas empresas patrocinam seus pro-jetos, mesmo com os custos não sendorecuperados, porque têm interesse ematingir uma meta de longo prazo para aorganização.

204/641

1.33Plano deGerenciamento de Custos

O Plano de Gerenciamento de Custos é auxil-iar ao plano de projeto que descreve os pro-cedimentos que serão utilizados para geren-ciar todos os custos do projeto.




• descritivo dos processos de geren-ciamento de custos (regras gerais);

• descrição das reservas gerenciais e daautonomia em sua utilização;

• sistema de controle de mudanças deprazos (Time Change Control System);

• frequência de avaliação do orçamentodo projeto e das reservas gerenciais;

• alocação financeira das mudanças noorçamento;


• frequência de atualização do plano degerenciamento de custos;

• outros assuntos relacionados ao geren-ciamento de custos não previstos noplano;


• aprovações.

206/641

GERENCIAMENTODA QUALIDADE

“O conceito moderno de qualidade tem foco na satisfação do cliente e na conformidade do pro-

jeto com as necessidades desse cliente, e não com padrões previamente criados pela empresa ou

pelo time do projeto.”

Lewis R. Ireland

1.34Definição

O objetivo mais importante desta área égarantir que o projeto será concluído dentroda qualidade desejada, garantindo a satis-fação das necessidades de todos os en-volvidos. O gerente do projeto é o principalresponsável pelo gerenciamento da qualid-ade no projeto, devendo dar igual prioridadepara o gerenciamento da qualidade, dos cus-tos e do tempo.

Os conceitos de qualidade têm recebido umaatenção diferenciada no gerenciamento deprojetos nos últimos anos. A necessidade demelhorias na qualidade foi impulsionada porvários fatores, dentre eles:

• exigência de alto desempenho;

• ciclo de vida de desenvolvimento deprodutos reduzido;

• níveis tecnológicos elevados;

• processos e equipamentos levados con-stantemente a condições limítrofes.

A qualidade envolve inúmeras dimensões.Dentre elas podem ser caracterizadas asseguintes:

Defeito zero – Não existe tolerância a er-ros dentro do sistema. A meta é que, em to-dos os processos, não existam falhas e existadentro do projeto um ambiente isento dedefeitos.

O cliente é o próximo elemento noprocesso – Conceito baseado na necessid-ade de desenvolvimento de um sistema queseja capaz de garantir que o produto ou ser-viço seja transferido para o cliente demaneira correta.

Faça correto da primeira vez – É metado gerenciamento da qualidade garantir quecada ação do projeto seja desenvolvida cor-retamente na primeira vez, porque seus cus-tos são muito mais baratos assim. O processo

209/641

de correção é várias vezes mais caro que oprocesso de planejamento.

Melhoria contínua – Conceito que recon-hece que o mundo está em constantemutação e que o processo satisfatório, hoje,pode não o ser amanhã, fazendo com que osmecanismos de controle do projeto neces-sitem de aprimoramentos constantes paragarantir a qualidade do produto, ou serviço.

Outro aspecto importante a ser discutido é ocusto da qualidade. O custo da qualidade édefinido como o investimento total para at-ingir a qualidade desejada do produto ouserviço. Isso inclui todo o trabalho ne-cessário para construir um produto, ou ser-viço, que está em conformidade, bem comotodo o custo resultante da não-conformidade.

210/641

Tabela 8.1 – Custos de conformidade x custos de não

conformidade

A maior parte das pessoas acredita que ocusto e a qualidade são linearmente relacion-ados, ou seja, se o orçamento é ampliado em10%, a qualidade também poderá ser mel-horada em 10%. No gráfico a seguir tem-se arelação tempo, custo e a qualidade palpável.

211/641

Figura 8.1 – Relação custo x qualidade palpável ao

longo do tempo no projeto

Observa-se que os primeiros 80% do orça-mento conseguem evidenciar apenas 10% daqualidade. Os outros 20% restantes é quepossibilitam os outros 90% da qualidaderestantes, mostrando uma relação não-linearentre os fatores.

212/641

1.35Mindmap dosProcessos deGerenciamento daQualidade

Os processos de gerenciamento da qualidadese decompõem conforme o mapa mental aseguir.

Figura 8.2 – Mapa mental do Gerenciamento da

Qualidade

1.36Processos deGerenciamento daQualidade

O PMBOK subdivide o gerenciamento daqualidade em três processos:

• Planejar a qualidade (8.1);

• Realizar a garantia da qualidade (8.2);

• Realizar o controle da qualidade (8.3).

Figura 8.3 – Processos de Gerenciamento da Qual-

idade distribuídos ao longo das fases do

projeto

Planejar a qualidade - Planejar a qualid-ade é o processo de identificação dos requisi-tos e/ou padrões de qualidade do projeto e

do produto, além da documentação de comoo projeto demonstrará a conformidade.

Figura 8.4 – Mapa mental do processo Planejar a

qualidade

Realizar a garantia da qualidade - Real-izar a garantia da qualidade é o processo deauditoria dos requisitos de qualidade e dosresultados das medições de controle da qual-idade para garantir que sejam usados ospadrões de qualidade e definições operacion-ais apropriados.

215/641

Figura 8.5 – Mapa mental do processo Realizar a

garantia da qualidade

Realizar o controle da qualidade - Real-izar o controle da qualidade é o processo demonitoramento e registro dos resultados daexecução das atividades de qualidade paraavaliar o desempenho e recomendar asmudanças necessárias.

Figura 8.4 – Mapa mental do processo Realizar o

controle da qualidade

216/641

217/641

1.37Plano deGerenciamento daQualidade

O Plano de Gerenciamento da Qualidade étambém um documento auxiliar do plano degerenciamento de projetos que descreve osprocedimentos que serão utilizados para ger-enciar todos os aspectos da qualidade doprojeto.




• descritivo dos processos de geren-ciamento da qualidade (regras gerais);

• listagem dos requisitos de qualidade;

• listagem dos padrões de qualidadeassociados;

• priorização das mudanças nos requisi-tos de qualidade e respostas;

• sistema de controle de mudanças daqualidade (Quality Change ControlSystem);

• frequência de avaliação dos requisitosde qualidade do projeto;

• alocação financeira das mudanças nosrequisitos de qualidade;

• administração do plano de geren-ciamento da qualidade;


• frequência de atualização do plano degerenciamento da qualidade;

• outros assuntos relacionados ao geren-ciamento da qualidade não previstos noplano;


• aprovações.

219/641

GERENCIAMENTODE RECURSOSHUMANOS

“Esteja sempre alerta para as oportunidades de reconhecer as pessoas e de mostrar a elas que

você elogia e aprecia o seu esforço.”

Vijay K. Verma

1.38Definição

O gerenciamento dos recursos humanos temcomo objetivo central fazer o melhor uso dosindivíduos envolvidos no projeto. Como sesabe, as pessoas são o elo central dos proje-tos e seu recurso mais importante. Elesdefinem as metas, os planos, organizam otrabalho, produzem os resultados, dire-cionam, coordenam e controlam as ativid-ades do projeto, utilizando suas habilidadestécnicas e sociais. Todos os resultados doprojeto podem ser vistos como fruto das re-lações humanas e das habilidades interpess-oais dos envolvidos, uma vez que a satisfaçãopessoal e a qualidade de vida estão se tor-nando um dos fatores-chave da motivação dequalquer profissional.

No passado, a maioria dos projetos se pre-ocupou unicamente com aspectos técnicos,que foram altamente desenvolvidos. Porém,

os aspectos humanos, que poderiam con-duzir o projeto aos mesmos ganhos dodesenvolvimento técnico, foram relegados aum segundo plano. Agora, são eles o foco dosprincipais estudos e trabalhos na área, demodo a compensar essadesproporcionalidade.

O sucesso ou o fracasso do projeto de-pendem diretamente do gerenciamento dosrecursos humanos. Conforme Galbraith,duas premissas asseguram essa afirmativa:

• pessoas influenciam o sucesso ou o fra-casso do projeto;

• os problemas do projeto somente po-dem ser resolvidos por pessoas.

Como os custos e o fluxo de caixa variam sig-nificativamente através do ciclo de vida doprojeto, os recursos humanos são necessári-os em vários níveis de especialidade e exper-iência, dependendo da natureza do trabalhoa ser realizado, do nível de maturidade do

222/641

time do projeto e das restrições internas eexternas.

Figura 9.1 – Tipos de profissionais requeridos ao

longo das fases do projeto

223/641

1.39Mindmap dosProcessos deGerenciamento deRecursos Humanos

Os processos de gerenciamento de recursoshumanos se decompõem conforme o mapamental a seguir.

Figura 9.2 – Mapa mental do Gerenciamento de Re-

cursos Humanos

1.40Processos deGerenciamento deRecursos Humanos

O PMBOK subdivide o gerenciamento de re-cursos humanos em quatro processos:

• Desenvolver o plano de recursos hu-manos (9.1);

• Mobilizar a equipe do projeto (9.2);

• Desenvolver a equipe do projeto (9.3);

• Gerenciar a equipe do projeto (9.4).

Figura 9.3 – Processos de Gerenciamento de Re-

cursos Humanos distribuídos ao longo

das fases do projeto

Desenvolver o plano de recursos hu-manos - Desenvolver o plano de recursoshumanos é o processo de identificar e docu-mentar papéis, responsabilidades, habilid-ades necessárias e relações hierárquicas doprojeto e criar um plano de gerenciamentode pessoal.


o plano de recursos humanos

Mobilizar a equipe do projeto - Mobiliz-ar a equipe do projeto é o processo de con-firmação da disponibilidade dos recursos

226/641

humanos e obtenção da equipe necessáriapara concluir as designações do projeto.

Figura 9.5 – Mapa mental do processo Mobilizar a

equipe do projeto

Desenvolver a equipe do projeto -Desenvolver a equipe do projeto é o processode melhoria de competências, interação eambiente global da equipe para aprimorar odesempenho do projeto.


a equipe do projeto

227/641

Gerenciar a equipe do projeto - Geren-ciar a equipe do projeto é o processo deacompanhar o desempenho de membros daequipe, fornecer feedback, resolver questõese gerenciar mudanças para otimizar odesempenho do projeto.

Figura 9.7 – Mapa mental do processo Gerenciar a

equipe do projeto

No gerenciamento de recursos humanos, éimportante que se atente para os seguintesaspectos:

• o trabalho em time é vital para o su-cesso do projeto;

• o espírito de corpo contribui para osucesso;

228/641

• conflitos podem ocorrer entre o pro-jeto e a organização;

• qualquer promessa feita durante o re-crutamento deve ser documentada;

• os níveis de equipes são muito maisvariáveis em um ambiente de projetoque em um ambiente funcional;

• treinamento e desenvolvimento sãomais complexos e críticos durante o pro-jeto, se comparados com o trabalhotradicional da organização.

229/641

1.41Plano deGerenciamento deRecursos Humanos

O Plano de Gerenciamento de Recursos Hu-manos é o documento formal que descreveos procedimentos que serão utilizados paragerenciar todos os recursos humanos doprojeto.

No plano deve estar documentado com:



• organograma do projeto mostrando aestrutura hierárquica do time do pro-jeto, incluindo os elementos das estru-turas matriciais relacionados;

• diretório do time do projeto contendotodas as informações dos recursos

humanos do projeto, incluindo cargo,área de atuação e contato;

• matriz de responsabilidades relacion-ando os elementos do WBS com os in-tegrantes do time;

• políticas com relação a novos recursos,realocação e substituição de membrosdo time;

• políticas de treinamento;

• critérios de avaliação de resultados;

• critérios de bonificação da equipe;

• frequência de avaliação consolidadados resultados do time;

• alocação financeira para o geren-ciamento de pessoal;

• administração do plano de geren-ciamento de pessoal;


• frequência de atualização do plano degerenciamento de recursos humanos;

231/641

• outros assuntos relacionados ao geren-ciamento de recursos humanos nãoprevistos no plano;


• aprovações.

232/641

GERENCIAMENTODASCOMUNICAÇÕES

“A grande maioria dos atritos, frustrações e ineficiências em nossas relações com as outras

pessoas é causada pela pobreza nas comunicações. ”

David I. Cleland

1.42Definição

Um efetivo processo de comunicação é ne-cessário para garantir que todas as inform-ações desejadas cheguem às pessoas corretasno tempo certo e de uma maneira econom-icamente viável. O gerente de projeto utiliza-se da comunicação para assegurar que o timedo projeto trabalhe de maneira integradapara resolver os problemas do projeto eaproveitar suas oportunidades.

Cleland define a comunicação como um pro-cesso pelo qual a informação é transferidaentre os indivíduos através de símbolos,sinais e outros. Além disso, a comunicação éum processo de duas vias, onde participamativamente o emissor e o receptor da inform-ação, com os envolvidos atuando, na maioriadas vezes, como emissores e receptoressimultaneamente.

Figura 10.1 – Processo de comunicação em duas

vias

As responsabilidades entre o emissor e o re-ceptor podem ser assim distribuídas:

Emissor – Responsável por produzir umainformação clara, de modo que o recebedorpossa entendê-la com facilidade.

Receptor – Responsável por tornar claroque a informação foi recebida e completa-mente compreendida.

Além disso, é importante que também sejamavaliadas as barreiras no processo de comu-nicação, devido à percepção individual decada um, bem como sua personalidade, atit-udes, emoções, etc. A figura a seguir mostrao processo completo de comunicação, in-cluindo esses anteparos.

235/641

Figura 10.2 – Processo de comunicação completo

com anteparos, proposto por Kerzner e

Cleland

Com base nos trabalhos de Mintzberg sobreas estruturas das organizações, podem serestabelecidos alguns fluxos no processo detrabalho provocados por diferentes mecanis-mos de comunicação entre as pessoas dentrode uma organização. São eles:

Fluxo da Autoridade Formal - Onde ainformação flui segundo uma hierarquia in-stituída dentro da organização ou projeto,realçando o fluxo do poder formal.

236/641

Fluxo da Atividade Regulamentada –Onde a informação flui segundo um mecan-ismo padronizado de informação independ-ente da hierarquia dos envolvidos. O focodesse fluxo é a padronização do processo decomunicação.

Fluxo das Comunicações Informais –Onde o processo de comunicação se dá sem apresença de nenhuma estrutura reguladora.As pessoas se agregam em grupos sociais oude relacionamento e neles não existe hierar-quia ou padronização. É o mais veloz e omais arriscado mecanismo de comunicação.

Conjunto das Constelações de Tra-balho – Onde o processo de comunicação sedá através de objetivos claros e adequados acada nível hierárquico da estrutura. Normal-mente, as constelações de trabalho são osmelhores modelos para o desenvolvimentodo processo de comunicação em projetos.

Fluxo do Processo DecisórioEspecífico – Onde o processo de

237/641

comunicação é necessário para decisões es-pecíficas, partindo da geração do problemaaté chegar à decisão específica a ser tomada.

238/641

1.43Mindmap dosProcessos deGerenciamento dasComunicações

Os processos de gerenciamento das comu-nicações se decompõem conforme o mapamental a seguir.

Figura 10.3 – Mapa mental do Gerenciamento das

Comunicações

1.44Processos deGerenciamento dasComunicações

O PMBOK subdivide o gerenciamento dascomunicações em cinco processos:

• Identificar as partes interessadas(10.1);

• Planejar as comunicações (10.2);

• Distribuir as informações (10.3);

• Gerenciar as expectativas das partesinteressadas (10.4);

• Reportar o desempenho (10.5).

Figura 10.4 – Processos de Gerenciamento das

Comunicações distribuídos ao longo das

fases do projeto

Identificar as partes interessadas - É oprocesso de identificar todas as pessoas ouorganizações que podem ser afetadas peloprojeto e de documentar as informações rel-evantes relacionadas aos seus interesses, en-volvimento e impacto no sucesso do projeto.

Figura 10.5 – Mapa mental do processo Identificar

as partes interessadas

Planejar as comunicações - Planejar ascomunicações é o processo de determinar asnecessidades de informação das partes

241/641

interessadas no projeto e definir uma abord-agem de comunicação.

Figura 10.6 – Mapa mental do processo Planejar as

comunicações

Distribuir as informações - É o processode colocar as informações necessárias à dis-posição das partes interessadas no projeto,conforme planejado.

Figura 10.7 – Mapa mental do processo Distribuir

as informações

242/641

Gerenciar as expectativas das partesinteressadas - Gerenciar as expectativasdas partes interessadas é o processo decomunicação e interação com as partes in-teressadas para atender às suas necessidadese solucionar as questões à medida queocorrerem.

Figura 10.8 – Mapa mental do processo Gerenciar

as expectativas das partes interessadas

Reportar o desempenho - Reportar odesempenho é o processo de coleta e dis-tribuição de informações sobre o desem-penho, inclusive relatórios de andamento,medições do progresso e previsões.

243/641

Figura 10.9 – Mapa mental do processo Reportar o

desempenho

No gerenciamento das comunicações, é im-portante que se atente para os aspectos aseguir:

• As pessoas dão o melhor de si quandocompreendem completamente as de-cisões que as afetam e suas razões. Elasprecisam perceber o que têm de fazer e oporquê, o seu desempenho em relaçãoao esperado e a sua situaçãoprofissional;

• se a base do gerenciamento de projetosé a formalização de processos para al-cançar melhor desempenho, a

244/641

informação e a comunicação não podemser relegadas ao improviso e à intuição;

• a decisão sobre o que comunicar, paraquem e como deve ser incorporada a to-das as fases do planejamento;

• os diferentes veículos de comunicaçãose complementam, combinandomensagens gerais e específicas para at-ingir diversos públicos;

• informe sempre, em ocasiões regularese com honestidade. Isso cria credibilid-ade para o processo;

• nas situações de crise, seja ágil. In-forme a posição atual, ainda que nãoseja a definitiva. Ninguém gosta desaber por último, e a falta de inform-ações é fonte para boatos, criando in-stabilidade no projeto;

• as pessoas não têm de concordar paracooperar com uma decisão, mas têm de

245/641

compreender como e por que ela foitomada.

246/641

1.45Plano deGerenciamento dasComunicações

O Plano de Gerenciamento das Comu-nicações é o documento formal que descreveos procedimentos que serão utilizados paragerenciar todo o processo de comunicaçãono projeto.

No plano, devem estar documentados:



• descritivo dos processos de geren-ciamento das comunicações;

• eventos de comunicação (reuniões eapresentações);

• cronograma dos eventos decomunicação;

• atas de reunião;

• exemplo de relatórios do projeto;

• ambiente técnico e estrutura dearmazenamento e distribuição dainformação;

• alocação financeira para o geren-ciamento das comunicações;


• frequência de atualização do plano degerenciamento das comunicações;

• outros assuntos relacionados ao geren-ciamento das comunicações não previs-tos no plano;


• aprovações.

248/641

GERENCIAMENTODE RISCOS

“Riscos devem ser assumidos somente quando os benefícios potenciais excedem os custos de

correção de uma decisão tomada erroneamente.”

R. Max Wideman

1.46Definição

Na maioria dos projetos, os riscos associadoscom grandes empreendimentos têm mere-cido uma atenção especial dos gerentes deprojeto, devido não só às grandes somas dedinheiro que estão em suas mãos, como tam-bém à reputação do time e dos patro-cinadores do projeto.

Gerenciamento de riscos possibilita a chancede melhor compreender a natureza do pro-jeto, envolvendo os membros do time demodo a identificar as potenciais forças eriscos do projeto e responder a eles, geral-mente associados a tempo, qualidade e cus-tos. Portanto, a sobrevivência de qualquerempreendimento, atualmente, está intima-mente vinculada ao conceito de aproveitaruma oportunidade, dentro de um espectro deincertezas. O que torna a gestão dos riscos setornar tão importante são fatores diversos,

como o aumento da competitividade, oavanço tecnológico e as condições econôm-icas, que fazem com que os riscos assumamproporções muitas vezes incontroláveis.

Figura 11.1 – Abrangência do Gerenciamento de Ris-

cos (com base em Wideman)

Todo risco necessita ser avaliado segundodois aspectos: probabilidade de ocorrência egravidade das consequências. Ao se multipli-car a probabilidade de um determinado riscoacontecer com sua gravidade, normalmenteexpressa em valores de prejuízo financeiro,tem-se um conceito fundamental para aquantificação dos riscos denominado ValorMonetário Esperado (Earned MonetaryValue). As prioridades na resposta ao risco

251/641

serão para os eventos que apresentaremmaior Valor Monetário Esperado.

EMV = P x G

onde P = ProbabilidadeG = Gravidade (valor monetário)

Figura 11.2 – Avaliação e quantificação de Riscos

252/641

1.47Mindmap dosProcessos deGerenciamento de Riscos

Os processos de gerenciamento de riscos sedecompõem conforme o mapa mental aseguir.


Riscos

1.48Processos deGerenciamento de Riscos

O PMBOK subdivide o gerenciamento deriscos em seis processos:

• Planejar o gerenciamento dos riscos(11.1);

• Identificar os riscos (11.2);

• Realizar a análise qualitativa dos riscos(11.3);

• Realizar a análise quantitativa deriscos (11.4);

• Planejar as respostas aos riscos (11.5);

• Monitorar e controlar os riscos (11.6).

Figura 11.4 – Processos de Gerenciamento de Riscos


Planejar o gerenciamento dos riscos -Planejar o gerenciamento dos riscos é o pro-cesso de definição de como conduzir asatividades de gerenciamento dos riscos deum projeto.

255/641

Figura 11.5 – Mapa mental do processo Planejar o

gerenciamento de riscos

Identificar os riscos - Identificar os riscosé o processo de determinação dos riscos quepodem afetar o projeto e de documentaçãode suas características.

256/641

Figura 11.6 – Mapa mental do processo Identificar

os riscos

Realizar a análise qualitativa dosriscos - Realizar a análise qualitativa deriscos é o processo de priorização de riscospara análise ou ação adicional através daavaliação e combinação de sua probabilidadede ocorrência e impacto.


análise qualitativa dos riscos

Realizar a análise quantitativa deriscos - Realizar a análise quantitativa deriscos é o processo de analisar numerica-mente o efeito dos riscos identificados nosobjetivos gerais do projeto.

257/641


análise quantitativa de riscos

Planejar as respostas aos riscos - Plane-jar as respostas aos riscos é o processo dedesenvolvimento de opções e ações paraaumentar as oportunidades e reduzir asameaças aos objetivos do projeto.


respostas aos riscos

Monitorar e controlar os riscos - Mon-itorar e controlar os riscos é o processo de

258/641

implementação dos planos de respostas ariscos, acompanhamento dos riscos identific-ados, monitoramento dos riscos residuais,identificação de novos riscos e avaliação daeficácia do processo de riscos durante todo oprojeto.

Figura 11.10 – Mapa mental do processo Monitorar

e controlar os riscos

No gerenciamento de riscos, é importanteque se atente para os seguintes aspectos:

• Compreenda o projeto, produto ouprocesso a ser empreendido;

• identifique os elementos do projetosujeito a riscos;

• desenvolva uma lista de ameaças efraquezas para cada elemento;

259/641

• priorize as ameaças e as fraquezas;

• identifique impactos;

• identifique os controles a serem adota-dos para evitar, ou minimizar, osimpactos;

• crie controles alternativos para quandoos controles principais não forem efet-ivos, ou não puderem ser acionados;

• gere sempre documentação para servirde base a futuros projetos.

260/641

1.49Plano deGerenciamento de Riscos

O Plano de Gerenciamento de Riscos é o doc-umento formal que descreve os procedimen-tos que serão utilizados para gerenciar osriscos através do projeto. O plano de riscos éum dos planos secundários do plano geral doprojeto.

No plano, devem estar documentados osseguintes dados:



• descritivo dos processos de geren-ciamento de riscos (regras gerais);

• RBS – Risk Breakdown Structure paraa Identificação dos Riscos;

• riscos identificados;

• qualificação dos riscos;

• quantificação dos riscos;

• sistema de controle de mudanças deriscos (Risk Change Control System);

• respostas planejadas aos riscos;

• planos de contingência;

• reservas de contingência;

• frequência de avaliação dos riscos doprojeto;

• alocação financeira para o geren-ciamento de riscos;

• administração do plano de geren-ciamento de riscos;


• frequência de atualização do plano degerenciamento de riscos;

• outros assuntos relacionados ao geren-ciamento de riscos não previstos noplano;


• aprovações.

262/641

263/641

GERENCIAMENTODAS AQUISIÇÕES

“O comprador sempre precisa ter vários olhos, o vendedor não precisa ter nenhum.”

George Herbert

1.50Definição

O gerenciamento das aquisições tem comoobjetivo dar garantia ao projeto de que todoelemento externo participante do projeto irágarantir o fornecimento de seu produto, ouserviço, para o projeto.

A relação entre o fornecedor e o projeto é de-terminada usualmente pela quantidade deriscos incorridos pelas partes. Normalmente,o custo de um determinado suprimento, oucontrato, está diretamente relacionado com orisco associado àquele trabalho. Por causadesse fator de risco, muitas vezes o custo nãoé o único elemento a ser analisado na nego-ciação. O tipo de contrato também passa adeterminar um papel fundamental no pro-cesso. Cada tipo de contrato representa certograu de incerteza e riscos para o gerente deprojeto. Os principais tipos de contratos es-tão listados a seguir.

Contrato de Preço Fixo Global (FFP -Firm Fixed Price ou Lump Sum Con-tract) - Essa modalidade de contrato en-volve um preço fixo total para produtos bemdefinidos.

Contrato de Preço Fixo Global com In-centivo (FPI - Fixed Price IncentiveContract) - Tipo de contrato em que ocomprador paga ao vendedor uma quantiafixa (conforme estabelecido em contrato), e ovendedor poderá ganhar uma quantia adi-cional se satisfizer os critérios estabelecidosde desempenho. A essência desse tipo decontrato está na incerteza de quanto irácustar a realização do trabalho. Para tal, aspartes acordam em uma meta de custos euma participação de cada uma das partes doresultado.

Contratos de Custo (Administração)com Incentivo sobre os Resultados(CPIF – Cost Plus Incentive Fee) - Essamodalidade engloba o pagamento

266/641

(reembolso) para o vendedor de seus custosreais acrescidos de um prêmio por economia,isto é, quanto mais o fornecedor economizar,maior será o seu bônus sobre o resultado,dentro de um limite mínimo e máximo deremuneração.

Contratos de Custo (Administração)com Prêmio Fixo (CPFF - Cost PlusFixed Fee) - Esta modalidade engloba opagamento (reembolso) para o vendedor deseus custos reais acrescidos de um valor fixoadicional como forma de remuneração. É osegundo menos desejável pela equipe do pro-jeto porque não incentiva que o contratadoeconomize, uma vez que o fornecedor nãotem nada a ganhar ou perder com as eco-nomias ou desperdícios nas contratações enos fornecimentos.

Contratos por Administração (CPPC -Cost Plus Percentage of Cost Con-tract) - Essa modalidade engloba o paga-mento (reembolso) para o vendedor de seus

267/641

custos reais acrescidos de um percentualdesse custo como forma de remuneração. É omenos desejável pela equipe do projetoporque não incentiva que o contratado eco-nomize, uma vez que seu lucro é uma funçãodos custos incorridos, ou seja, quanto maiselevados forem os custos, mais o fornecedorganha.

Contrato por Preço Unitário (UnitPrice Contact) - Modalidade de contratoem que o vendedor recebe um montante porunidade de serviço (ex.: $20 por hora paraserviços elétricos, ou $1 por metro cúbico deterra removida) e o valor total do contratoestá em função das quantidades necessáriaspara concluir o trabalho.

Com relação ao grau de risco para ofornecedor e para o comprador, tem-se oseguinte espectro de riscos:

268/641

Figura 12.1 – Tipos de contratos e riscos associados

As estratégias para aquisições variam deempresa para empresa, podendo ser de re-sponsabilidade da área de compras daempresa ou ser de responsabilidade dopróprio projeto.

Como os suprimentos normalmente estãofora do ambiente organizacional, eles podemvariar de acordo com a facilidade que se tempara obtê-los e com a quantidade de fornece-dores capacitados para tal. A figura a seguirmostra o espectro estrutural do mercado.

269/641

Figura 12.2 – Espectro estrutural do mercado

270/641

1.51Mindmap dosProcessos deGerenciamento dasAquisições

Os processos de gerenciamento dasaquisições se decompõem conforme o mapamental a seguir.

Figura 12.3 – Mapa mental do Gerenciamento das

Aquisições

1.52Processos deGerenciamento dasAquisições

O PMBOK subdivide o gerenciamento dasaquisições em quatro processos:

• Planejar as aquisições (12.1);

• Conduzir as aquisições (12.2);

• Administrar as aquisições (12.3);

• Encerrar as aquisições (12.4).

Figura 12.4 – Processos de Gerenciamento das

Aquisições distribuídos ao longo das

fases do projeto

Planejar as aquisições - Planejar asaquisições é o processo de documentação das

decisões de compras do projeto, especific-ando a abordagem e identificando fornece-dores em potencial.


aquisições

Conduzir as aquisições - Realizar asaquisições é o processo de obtenção de res-postas de fornecedores, seleção de umfornecedor e adjudicação de um contrato.

273/641

Figura 12.6 – Mapa mental do processo Conduzir as

aquisições

Administrar as aquisições - Administraras aquisições é o processo de gerenciar as re-lações de aquisição, monitorar o desem-penho do contrato e fazer mudanças e cor-reções conforme necessário.

Figura 12.7 – Mapa mental do processo Adminis-

trar as aquisições

274/641

Encerrar as aquisições - Encerrar asaquisições é o processo de finalização decada aquisição do projeto. Como envolveverificar se todo o trabalho e as entregas sãoaceitáveis, serve de apoio ao processo de en-cerramento do projeto ou a fase.

Figura 12.8 – Mapa mental do processo Encerrar as

aquisições

No gerenciamento das aquisições, é import-ante que se atente para os seguintesaspectos:

• utilize um checklist para a preparaçãode propostas e contratos;

• avalie os riscos antes de escolher umdeterminado tipo de contrato;

275/641

• sempre reveja, com o departamentojurídico, o contrato a ser assinado;

• garanta, através de contrato ou seguro,os riscos não cobertos.

276/641

1.53Plano deGerenciamento dasAquisições

O Plano de Gerenciamento das Aquisições éo documento formal que descreve os proced-imentos que serão utilizados para gerenciartodos os contratos do projeto.

No plano, devem estar documentados osseguintes fatores:



• descritivo dos processos de geren-ciamento das aquisições (regras gerais),incluindo quais elementos serão objetode contrato;

• gerenciamento e tipos de contratos;

• critérios de avaliação de cotações epropostas;

• avaliação de fornecedores;

• frequência de avaliação dos processosdas aquisições;

• alocação financeira para o geren-ciamento das aquisições;

• administração do plano de geren-ciamento das aquisições;


• frequência de atualização do plano degerenciamento das aquisições;

• outros assuntos relacionados ao geren-ciamento das aquisições não previstosno plano;


• aprovações.

278/641


1. Qual é a diferença entre garantia econtrole da qualidade?

2. Quais as diferenças na aplicação daanálise qualitativa e quantitativa deriscos? Cite vantagens e desvantagens decada uma.

3. Qual tipo de escopo é descrito emuma EAP?

4. Explique os tipos profissionais re-queridos no time de projeto em funçãodas fases do projeto.

5. Diferencie os tipos de contrato e seusriscos associados.

6. Explique os elementos 5W e 2H paraa criação do plano de comunicação doprojeto.

7. Qual é a diferença entre estimativasde custos e orçamentação?

8. Como é realizado o planejamento derecursos e qual sua relação com o geren-ciamento de recursos humanos?

9. Diferencie escopo técnico de escopofuncional.

280/641

pALAVRACRUZADA

282/641

- PARTE IV -PREPARANDO A

ORGANIZAÇÃO PARAPROJETOS

1.ALTERNATIVASORGANIZACIONAIS

“Existem duas formas de ser criativo. A primeira é cantar e dançar. A segunda é preparar o

ambiente para que as pessoas dancem e cantem.”

Warren Bennis

Muitas vezes, ao se trabalhar com projetos, oexecutivo deve estar atento ao fato de que oprojeto faz parte de um todo organizado e es-tá sujeito às influências da cadeia de poder.A autonomia do gerente de projeto estásempre limitada aos interesses da empresa.Infelizmente, a grande maioria está poucopreparada para lidar com essas estruturasorganizacionais.

Todo projeto está imerso em uma determin-ada hierarquia de sistemas que precisa serconstantemente respeitada pelo gerente deprojeto. Não se pode considerar o projetomais importante que a própria organizaçãoou, até mesmo, maior que o meio ambienteque cerca todas as organizações.

Figura 1.1 – A hierarquia dos sistemas proposta por

Kerzner

O estilo organizacional apropriado para umprojeto específico depende quase que

285/641

totalmente de sua natureza e do estilo organ-izacional da empresa. Para que o projeto sejaestruturado efetivamente, o gerente de pro-jeto deve compreender não somente asopções organizacionais disponíveis, mastambém os resultados prováveis da imple-mentação do projeto dentro da organizaçãoem inúmeros aspectos.

As estruturas organizacionais refletem-sediretamente nos projetos por elas gerencia-dos, uma vez que a importância dada ao as-sunto do projeto, a disponibilidade dos en-volvidos e o interesse da organização são in-fluenciados diretamente pela natureza da es-trutura organizacional adotada pelaempresa.

Dentre as principais estruturas, destacam-se:

• organizações funcionais;

• organizações matriciais leves com ex-pedidor de projetos;

286/641

• organizações matriciais leves com co-ordenador de projetos;

• organizações matriciais balanceadas;

• organizações matriciais fortes;

• organizações por projetos.

A maioria das empresas modernas envolvetodas essas estruturas ao mesmo tempo emseus organogramas, havendo desde setoresonde a estrutura é totalmente funcional atédepartamentos inteiros com estruturavoltada completamente para projetos. Essasestruturas são denominadas estruturas com-postas ou mistas.

287/641

Tabela 1.1 – A estrutura organizacional e sua in-

fluência nos projetos (PMBOK Guide 4a

Edição)

É importante ressaltar que várias propostasde alternativas organizacionais retratam oprocesso de maneira bastante simplista,onde, com uma ou duas perguntas, ousa-sedeterminar os parâmetros organizacionais deuma companhia. Na verdade, é necessáriauma análise muito mais cuidadosa, no in-tuito de assegurar que determinada altern-ativa organizacional é a melhor opção parauma organização em um dado momento.Nos próximos capítulos serão apresentadosalguns modelos de organizações com o objet-ivo de expor determinados comportamentosorganizacionais.

288/641

1.54Organizações nãoBaseadas em Projetos

Normalmente as empresas são voltadas paraa fabricação de um determinado bem ou aprestação de algum tipo de serviço. Nessestipos de organização, os projetos são utiliza-dos apenas para apoiar as linhas de produtosou serviços. São, na maioria das vezes,empresas com pequeno desenvolvimentotecnológico e, portanto, um eventual líder deprojeto tem mais dificuldades para conduziros trabalhos, já que os projetos não fazemparte da lista de prioridades da organização.

Algumas companhias não baseadas em pro-jetos possuem departamentos, ou empresasterceirizadas, que atuam como empresas ori-entadas para projetos no intuito de supriresses esforços localizados.

São algumas características das organizaçõesnão baseadas em projetos as seguintes:

• os gerentes e responsáveis não têmdisponibilidade, ou tempo, para atuarem projetos. A necessidade principal daempresa é o suporte ao processoprodutivo;

• a autoridade do gerente funcional é su-perior à autoridade do gerente de pro-jeto, dificultando o controle da equipepor parte do gerente de projeto;

• a equipe do projeto não é compreen-dida e respeitada pelo restante daempresa;

• o pequeno investimento da organiza-ção em treinamento e capacitação dasequipes que trabalharão nos projetos;

• a grande necessidade de obtenção deconhecimento externo para gerenciar osprojetos (consultorias).

290/641

1.55Organizações Baseadasem Projetos

São organizações onde o trabalho é total-mente caracterizado por projetos e, portanto,cada um desses projetos possui um controlepróprio. O trabalho da empresa consiste emagregar todos esses projetos. Exemplos típi-cos de empresas baseadas em projetos são asempresas de construção civil e as empreiteir-as, empresas de desenvolvimento de soft-ware e produtos, indústria aeroespacial,empresas de desenvolvimento de produtos,empresas de marketing e de consultoria,dentre outras.

São características das organizações basea-das em projetos as seguintes:

• os gerentes e responsáveis têm dispon-ibilidade, ou tempo, para atuarem emprojetos, uma vez que sua função prin-cipal é gerenciar os projetos;

• a autoridade do gerente de projeto éabsoluta, assumindo, também, o con-trole funcional dos envolvidos, per-mitindo a integração e o controle poruma única pessoa;

• grande parte dos funcionários da or-ganização é integrante de algum projeto;

• elevado investimento da organizaçãoem treinamento e capacitação dasequipes de projetos;

• necessidade de apoio externo (con-sultorias) para gerenciar os projetossomente em casos complexos.

292/641

ESTRUTURAORGANIZACIONALFUNCIONAL

“Estruturas funcionais são perigosas porque os conflitos tendem a aumentar entre as priorid-

ades relativas dos diferentes projetos concorrendo por recursos limitados.”

Robert Youker

Este modelo organizacional se caracterizapor utilizar a mesma linha de controle paraprojetos e rotina. É marcado pela presençada hierarquia funcional na organização. Osprojetos são conduzidos por equipes perten-centes a cada departamento, e suas re-sponsabilidades são limitadas pelas fronteir-as de suas funções. A importância dada aosprojetos é pequena e as tarefas

desempenhadas normalmente têm algumvínculo funcional com o envolvido.

As vantagens de utilizar estruturas funcion-ais para gerenciar um projeto são asseguintes:

• familiaridade do time em trabalho con-junto, uma vez que as posições estãopreviamente definidas;

• as políticas administrativas já estãocompreendidas pelo grupo;

• a disponibilidade de equipe é contro-lada pelo gerente funcional, reduzindoos conflitos;

• eficiência no controle e otimização decronogramas, já que as pessoas podemtrabalhar em projetos e rotina ao mesmotempo, alternando entre atividades deprojeto e rotina quase queinstantaneamente;

• autoridade claramente definida pelahierarquia funcional.

294/641

As desvantagens da estrutura funcional sãoas seguintes:

• recursos limitados à esferadepartamental;

• burocracia elevada para o projeto, aoutilizar o fluxo do processo de trabalhoda empresa;

• perda de foco no projeto devido ao focoser dividido com a rotina;

• orientação departamental do projeto,ou seja, as prioridades do departamentopassam a ser as do projeto.

295/641

Figura 2.1 – Estrutura Funcional com destaque em

preto para os profissionais alocados no

projeto

296/641

ESTRUTURAORGANIZACIONALPOR PROJETOS

“Tudo está em constante mutação e cada mudança parece um aprimoramento.”

Aléxis de Tocqueville

Modelo organizacional caracterizado poruma estrutura quase exclusiva de projetos naorganização, englobando toda a parte fun-cional da organização dentro de cada pro-jeto. Nessas organizações, os projetos sãoconduzidos por gerentes de projeto que sededicam em tempo integral ao projeto e têmautonomia total, inclusive responsabilidadecom as atividades de gerente funcional per-ante os membros do projeto. Têm umaequipe administrativa que se dedica

integralmente ao projeto. Os projetos são arazão de ser da empresa. Essas organizaçõesnormalmente têm departamentos adminis-trativos que se reportam diretamente aosgerentes de projeto e têm como objetivoúnico dar suporte aos projetos da empresa.

As vantagens de utilizar estruturas de pro-jeto são as seguintes:

• clara definição de autoridade atravésda presença do gerente de projeto;

• processo de comunicação simplificadoporque todas as pessoas se reportam aomesmo gerente de projeto, que está fo-cado nas metas e nos objetivos doprojeto;

• desenvolvimento de especialidadescom o aprendizado na atividade deprojetos;

• a empresa voltada para projeto temfoco e prioridade diferenciados paraseus projetos, dando força para a busca

298/641

do atingimento das metas e dosobjetivos.

As desvantagens da estrutura de projetos sãoos seguintes:

• duplicação de esforços em projetoscom igualdade de prioridades sendodesenvolvidos ao mesmo tempo;

• no término do projeto, corre-se o riscode perda da equipe em função da inse-gurança criada;

• competição interna na empresa porpoder e recursos;

• dificuldade na reintegração das pess-oas da equipe à estrutura convencionalda empresa com o fim do projeto.

299/641

Figura 3.1 – Estrutura por Projetos com destaque

para todos os funcionários alocados em

projetos

300/641

ESTRUTURAMATRICIAL LEVE

“Nas estruturas matriciais leves, muitas vezes, a única pessoa leal ao projeto é seu expedidor

ou coordenador.”

Dwayne Cable

Estrutura caracterizada pela alocação depessoas na condução de projetos com umapequena autoridade formal sobre as ativid-ades e os recursos do projeto. Esse adminis-trador, coordenador ou expedidor do projetoé, basicamente, um staff dos executivos, quetem a responsabilidade operacional sobre oprojeto. Estrutura usada apenas quando oprojeto é relativamente pequeno e simples,ou essa iniciativa é a primeira iniciativa degerenciamento de projetos da empresa.

É caracterizada também pela presença dahierarquia funcional na organização, porémsem a mesma força das estruturas funcionaisclássicas. Representa uma mistura de carac-terísticas funcionais e de projetos. A im-portância dada aos projetos ainda é pequena.

As principais atribuições desse profissionalsão os seguintes:

• identificar áreas críticas;

• propor soluções de problemas;

• encaminhar as decisões de dentro parafora e de fora para dentro do projeto;

• promover a comunicação entre os in-tegrantes do time;

• apoiar o gerenciamento do projeto comregularidade.

302/641

Figura 4.1 – Estrutura Matricial Leve

303/641

ESTRUTURAMATRICIALBALANCEADA

“A estrutura matricial balanceada sempre cria uma situação de conflitos entre o projeto e a

linha funcional.”

John R. Adams

Estrutura caracterizada pela alocação de umgerente de projetos formal para conduzir otrabalho no projeto. Esse coordenador ougerente de projeto passa a ter, agora, umconjunto maior de responsabilidades e é en-carregado de coordenar diversas atividadesdo projeto. Estrutura usada não só apenasquando o projeto ainda é relativamentepequeno e simples, como também nasprimeiras experiências de gerenciamento de

projetos da empresa. Grande cuidado deveser tomado com os níveis de conflitos quepossam ser gerados entre as áreas funcionaise as de projetos.

Como no caso da estrutura matricial leve,esse modelo é também caracterizado pelapresença da hierarquia funcional na organiz-ação, porém sem a mesma força das estru-turas funcionais clássicas. Representa umamistura de características funcionais e deprojetos. A importância dada aos projetosainda é limitada.

As principais atribuições desse profissionalsão as seguintes:

• atribuir atividades aos elementos daestrutura funcional;

• compartilhar autoridade e decisõescom o gerente funcional;

• controlar o atingimento das metas edos objetivos estabelecidos;

305/641

• promover a comunicação entre os in-tegrantes do time e entre o projeto e aorganização.

Figura 5.1 – Estrutura Matricial Balanceada

306/641

ESTRUTURAMATRICIALFORTE

“A estrutura matricial se tornou um dos mais populares modelos para gerenciar projetos em

um ambiente de múltiplos projetos.”

Vijay K. Verma

Com o crescimento da importância dada aogerenciamento de projetos pela organização,torna-se necessária uma estrutura que com-porte as características funcionais e as deprojetos em diferentes proporções, res-ultando em um sistema autoridade/re-sponsabilidade/disponibilidade misto dentroda empresa. Nessas organizações, os projetossão conduzidos por gerentes de projeto quese dedicam em tempo integral ao projeto e

têm autonomia comparável à do gerente fun-cional. Esses gerentes de projeto se agrupamem um departamento ou área da empresaque se destina ao gerenciamento dos proje-tos da empresa, que por sua vez passam a serimportantes e estratégicos para o negócio.

Figura 6.1 – Estrutura Matricial Forte

308/641

PROJECTMANAGEMENTOFFICE

“O tempo de mudar é agora. Nunca é tarde para se fazer alguma coisa.”

Carl Sandburg

Atualmente várias organizações estão adot-ando estruturas de Escritórios de Projetos(Project Office) em suas atividades de geren-ciamento de projetos. Escritórios de projetotêm como objetivo prioritário suportar osprojetos, visando aumentar o nível de matur-idade organizacional e consequentemente,aumentar a taxa de sucesso desses projetos.

O Escritório do Projeto é um local centralpara conduzir, planejar, organizar, controlare finalizar as atividades do projeto.

A função do escritório em uma organizaçãopode variar de uma assessoria, limitada à re-comendação de políticas e procedimentospara projetos individuais, até uma estruturagerencial completa, que, além de administraros projetos específicos, irá estabelecer aspolíticas aplicáveis a projetos e a gestão es-tratégica desses empreendimentos.

O Escritório do Projeto é também um centrode informações e controle que contém gráfi-cos, diagramas, documentação e cronogra-mas. Ele mostra essas informações emparedes, quadros brancos e negros, com-putadores etc. Ele também é a casa do timedo projeto, onde todo o suporte estádisponível. Vários autores chamam oEscritório do Projeto de QG (Quartel Gener-al). Ele deve ser montado sempre antes doinício do projeto.

O crescimento do interesse pelos escritóriosde projeto é decorrente de várias razões

310/641

específicas, dentre elas podem ser destaca-das as seguintes:

Inexistência de padrão para reportardesempenho – Não existe um padrão uni-forme de desempenho, com isso as ativid-ades de avaliação e comparação entre proje-tos fica seriamente prejudicada.

Sobrecarga dos gestores – Os gestoresde projeto estão sobrecarregados e o es-critório de projetos fornece a informação quesuporta a decisão.

Aumento na complexidade e dinâmicados projetos – Devido ao ambiente cadavez mais complexo dos projetos, a necessid-ade de apoio especializado no controle dosempreendimentos contribui significativa-mente para o sucesso dos trabalhos.

Lições aprendidas não são documenta-das – As organizações precisam cada vezmais registrar as lições aprendidas nos proje-tos para conseguir construir diferenciaiscompetitivos sustentáveis.

311/641

Os principais objetivos do Escritório do Pro-jeto são:

• centralizar as informações;

• estabelecer políticas e procedimentospara projetos;

• ser um centro de apoio ao time;

• representar fisicamente o projeto;

• estimular o espírito de corpo do time.

Suas principais funções administrativas são:

• gerenciamento de cronogramas;

• geração e elaboração de documentos erelatórios do projeto;

• atuar como a Sala de Situação ou WarRoom;

• manutenção de histórico do projeto;

• operação de ferramentas computacion-ais e softwares de gerenciamento deprojetos.

312/641

Figura 7.1 – Exemplo de layout simplificado de um

escritório de projetos, evidenciando os

seus principais papéis no gerenciamento

dos projetos

313/641

1.56Tipos de PMO

Existem basicamente três níveis de escritóri-os de projeto de acordo com a finalidade e acaracterística de atuação desejada pelaorganização:

Projeto Autônomo – Escritório de projetoseparado das operações da empresa, desti-nado ao gerenciamento de um projeto ouprograma específico, onde a responsabilid-ade quanto ao sucesso ou fracasso do projetoé do PMO. Conhecido também como PMO deProjeto Isolado.

Figura 7.2 – Modelo de PMO para projeto autônomo

Project Support Office – Escritório deprojeto de esfera departamental destinado aoapoio a diversos projetos simultâneos, forne-cendo suporte, ferramentas e serviços deplanejamento, controle de prazos, custos,qualidade, dentre outros. Também podefornecer recursos técnicos, metodologia de

315/641

gerenciamento de projetos, metodologia degestão do conhecimento, interfacesorganizacionais, tornando-se um centro decompetência em projetos. Conhecido tam-bém como PMO Departamental.

Figura 7.3 – Modelo de PMO para Project Support

Office

Enterprise Project Support Office –Escritório de projetos de esfera corporativa,atuando no gerenciamento estratégico de to-dos os projetos da organização. Suas prin-cipais funções são o planejamento estratégi-co dos projetos, o gerenciamento dos proje-tos corporativos e interdepartamentais, agestão do conhecimento empresarial em

316/641

projetos, além de representar a interfaceentre os envolvidos no projeto. Quando eng-loba atividades relacionadas ao conjunto deprojetos, tais como a priorização de projetose alinhamento estratégico, é comumentechamado de Enterprise Portfolio Manage-ment Office (EPMO)

Figura 7.4 – Modelo de PMO para Enterprise Pro-

ject Support Office

317/641

1.57Constituindo um PMO

Um assunto com grande popularidade naárea de projetos diz respeito aos procedi-mentos de criação do escritório de projeto.Diversos autores criaram metodologias pró-prias para a implantação do escritório deprojetos. Tomando por base os trabalhos deBlock & Frame e de Crawford, têm-se oitopassos básicos de implementação, a saber:

1. Escolha do tipo de escritório a serimplementado

2. Obtenção do suporte e apoio ne-cessário (patrocinador)

3. Criação da infraestrutura do es-critório (instalações, funcionamento,etc.)

4. Motivar e doutrinar envolvidos

5. Programar estrutura (relatórios, anál-ises, ferramentas, etc.)

6. Estabelecer projeto-piloto

7. Entrada em operação

8. Feedback e melhoria contínua

319/641


1. Diferencie as estruturas matriciaisleves das estruturas funcionais.

2. Diferencie a abrangência do ProjectSupport Office e Enterprise ProjectSupport Office.

3. Compare as desvantagens da estru-tura funcional com a estrutura porprojetos.

4. Por que a estrutura matricial é carac-terizada por um elevado nível deconflitos?

5. Por que mesmo em uma estrutura deprojetos pode existir um percentual daorganização não dedicado a projetos?

6. Analise e compare os critérios dealocação do gerente de projeto com seucargo e posição na empresa.

321/641

PALAVRACRUZADA

323/641

- PARTE V – OGERENTE DE

PROJETOS E SUASINTERFACES

1. DEFINIÇÕESEHABILIDADESDO GERENTEDE PROJETOS

“Como gerente de projetos, você tradicionalmente tem muito mais responsabilidades do que

autoridade.”

Michael S. Dobson

Muito do sucesso ou fracasso de um projetoestá no gerente do projeto. Ele será o respon-sável por planejar, implementar e completaro projeto, iniciando seus trabalhos assim queo projeto começa. Normalmente, o gerentedo projeto tem que controlar o escopo

complexo, envolvendo centenas de pessoas,milhares de atividades e, muitas vezes, mil-hões de dólares.

Um dos principais riscos que se pode encon-trar, atualmente, é a convicção que algumaspessoas têm de que, com softwares de plane-jamento, elas se tornarão gerentes de projetoinstantâneos.

Mesmo podendo desempenhar outras ativid-ades funcionais na organização (estruturasfuncionais ou matriciais leves), o gerente deprojeto é o responsável último pelo sucessodo projeto, tendo uma série de demandasquase que exclusivas, incluindo:

• produzir o produto final do projetodentro dos prazos, custos e desempenhoexigidos;

• atingir objetivos contratuais de lucro;

• adquirir os recursos adequados para oprojeto, em quantidade e qualidade;

326/641

• contratar e motivar os integrantes dotime;

• lidar com obstáculos e possibilidadesde fracasso, usando precisão e energia;

• gerir estrategicamente os riscos doprojeto;

• desenvolver canais de comunicaçãoefetivos;

• desenvolver mecanismos de nego-ciação com todos os elementos internose externos do projeto para garantir ocumprimento do plano do projeto.

Gerentes de projeto, diferente dos gerentesfuncionais, não têm poder para alcançar seusobjetivos sozinhos. Eles dependem dos seussuperiores, subordinados e pares para dis-tribuir os esforços para tornar o projeto bemsucedido. Então, por que alguns indivíduossão mais bem-sucedidos como gerentes deprojetos do que outros? A resposta pode sersimples. Eles conseguem esses sucessos

327/641

porque possuem algumas competências es-pecíficas, dependentes de um conjuntoamplo de fatores, muitos dos quais têmmuito pouca ou nenhuma relação direta comhabilidades técnicas.

Dentre essas habilidades, podem ser destaca-das as seguintes:

• Habilidades nas comunicações

• Habilidade de escutar

• Habilidade de persuadir

• Habilidades organizacionais

• Planejamento

• Estabelecimento de objetivos

• Análise

• Habilidades no Gerenciamento do time

• Empatia

• Motivação

• Espírito de corpo

• Lealdade

• Ética

328/641

• Habilidades de liderança

• Ser exemplo constante

• Energia

• Visão

• Delegação

• Atuação otimista

• Habilidades internas

• Flexibilidade

• Criatividade

• Paciência

• Persistência

Um estudo de Mulcahy (2002) comprovatambém que as características relacionadasàs habilidades pessoais e ao gerenciamentode times são consideradas as mais import-antes por um grupo de 1041 gerentes de pro-jetos pesquisados. A tabela a seguir mostraos resultados encontrados.

329/641

Tabela 1.1 – Quadro das habilidades do gerente de

projeto (Mulcahy, 2002)

330/641

SELECIONANDO OGERENTE DEPROJETOS

“O gerente de projeto perfeito vale o seu peso em ouro.”

Ralph L. Kliem

Provavelmente, é uma das mais difíceis de-cisões que a alta direção da organização pre-cisa tomar. O gerenciamento de projetos nãoserá realizado com sucesso sem bons ger-entes de projeto.

O processo de seleção do gerente de projetodeve considerar algumas questões:

• Quais são os potenciais candidatos?

• Como eles serão selecionados?

• Como serão desenvolvidas carreirasem gerenciamento de projetos?

• Como serão desenvolvidas habilidadesde gerenciamento de projetos?

• Como será avaliado o desempenho dogerente de projeto?

Três pilares sustentam a seleção do mais ad-equado gerente de projeto:

• habilidades;

• motivação;

• personalidade.

Figura 2.1 – Pilares da seleção do gerente de projeto

Jeffrey Pinto e Jeffrey Trailer listaram umconjunto de fatores que precisam ser

332/641

avaliados durante a seleção do gerente deprojetos, estratificado segundo conjuntos dehabilidades:

A – Resolução de problemas

1. Análise do Problema

• Habilidades conceituais e mentais

• Habilidade de gerenciar grande quan-tidade de informação ao mesmo tempo

• Capacidade de identificar problemas

• Capacidade de encontrar sintomaspara identificar as causas

• Capacidade de análise dos dados es-senciais para a tomada de decisões

• Habilidade no desenvolvimento de to-das as possíveis soluções e suasconsequências

2. Julgamento e Senso Prático

• Escolher entre as possíveis soluções amais adequada

333/641

• Tomar decisões que levam em consid-eração as restrições do projeto e de seuambiente

• Sempre ter em mente a perspectivaglobal do projeto, e não apenas uma desuas faces

3. Capacidade de Decisão

• Propensão a tomar decisões

• Comprometimento com as decisões,até mesmo em situações delicadas ecomplexas

• Configurar uma estratégica concretade implantação da decisão

B – Administração

4. Planejamento e Organização

• Identificar objetivos e prioridades

• Estabelecer distribuição do trabalho notempo

• Organizar os recursos para atingir osobjetivos

334/641

• Definir as atividades e seus métodos detrabalho

5. Controle

• Manter controle diário sobre as ativid-ades em relação às datas de términoprevistas

• Garantir ações corretivas imediatas senecessário

• Acompanhar os orçamentos e exercercontrole financeiro

6. Estratégia e Know-HowOrganizacional

• Manter-se sempre bem informado

• Construir redes de colaboração in-formal e formal

• Conhecer os elementos externos aoprojeto (fornecedores e serviços)

• Conhecer a organização e suasoperações

335/641

• Ter habilidade de trabalhar em harmo-nia com a realidade da organização

• Ter habilidade de empregar terceirospara atingir objetivos

7. Conhecimento Especializado

• Conhecer as informações, os princípi-os, as teorias e as técnicas que são úteispara o projeto e para as demais áreas(finanças, contratos, marketing, etc.)

C – Supervisão e Gerenciamento doTime

8. Delegação de Responsabilidades

• Acreditar sempre no trabalho das out-ras pessoas

• Estruturar claramente as tarefas a ser-em realizadas e permitir a iniciativa dotime nos trabalhos

• Delegar as responsabilidades nos ní-veis apropriados

• Compartilhar parte das responsabilid-ades com o time

336/641

• Alocar autoridade e recursos para queo time possa tomar decisões signific-ativas em suas áreas de atuação

• Ter habilidade para trabalhar com sub-ordinados que têm especializações es-pecíficas em determinadas áreas sem sersubmisso ou negligente

9. Estruturação do Time

• Estruturar as tarefas a serem realiza-das e comunicá-las claramente ao time

• Ter habilidade de utilizar seu poderunilateralmente

• Usar reforços para estimular o time

• Estabelecer controles que favorecem aconclusão das atividades de acordo comos objetivos

10. Consideração com o Time

• Ter consideração pelas pessoas quecompõem o time

337/641

• Identificar suas necessidades egarantir sua satisfação

• Ser amável e educado com as pessoas

11. Desenvolvimento do Time

• Realizar avaliações de desempenhoperiódicas e dar feedback

• Identificar as necessidades de treina-mento com base em suas atividadesatuais e futuras

• Criar estratégias de treinamento

• Demonstrar importância ao treina-mento através da liberação de verbas,pessoas e até mesmo tempo pessoal paraatividades de treinamento

12. Trabalho em Time, Flexibilidade eCooperação

• Ter capacidade de trabalhar comoparte de um grupo

• Reconhecer as circunstâncias querequerem trabalho em time ou decisãoem time

338/641

• Ser receptivo aos outros pontos devista

• Estar preparado para mudar a própriaopinião

13. Resolução de conflitos

• Ter habilidade de coordenar especialis-tas de diferentes áreas

• Reconhecer uma situação de conflito eresolvê-la da maneira mais eficiente

• Conhecer a psicologia dos conflitos

D – Relações Interpessoais

14. Comunicação Oral

• Comunicar eficientemente emconversas

• Realizar apresentações de qualidade

• Concretizar as comunicações a respeitodo projeto

15. Influência, Persuasão e Negociação

339/641

• Estar ciente dos sentimentos, das ne-cessidades e das expectativas dosdemais

• Ter consciência dos efeitos da condutade uns nos outros

• Ter habilidade de influenciar os de-mais para atingir os objetivos

• Trazer o interlocutor para o seu pontode vista enquanto mantém um bomrelacionamento

16. Ascendência Sobre os Demais

• Gostar de comandar

• Ter necessidade de dominar os demaissem ser dominado

• Estar ciente das influências de algunssobre os demais

E – Outras Habilidades Pessoais

17. Necessidade de Proatividade

• Ter sempre a necessidade de atingiralgo único

340/641

• Ter constante desejo de fazer o melhore de ser o melhor

• Transformar diretamente ações emresultados

• Ter dinamismo e energia

• Ter otimismo para acreditar na capa-cidade de influenciar os eventos ao seuredor

18. Autoconfiança, Maturidade e Esta-bilidade Emocional

• Confiar em si mesmo e em suacapacidade

• Estar pronto para lidar com as con-sequências pessoais diante da di-ficuldade nas decisões

• Ter estabilidade emocional e força

• Ter capacidade de controlar emoções

• Ter resistência ao estresse no curto eno longo prazo

19. Lealdade, Honestidade e Integridade

341/641

• Apoiar as políticas e os valores daorganização

• Colocar os interesses da companhiaantes dos interesses próprios

• Respeitar os superiores

• Respeitar as obrigações

• Ter integridade pessoal e profissional

20. Tolerância diante da Ambiguidade eAbertura à Mudança

• Aceitar as incertezas e as situações ad-versas que ocorrem inevitavelmente noprojeto

• Desejar trabalhar em organizaçõesflexíveis como as matriciais ou suasvariantes

• Ter propensão a alterar planos, aprox-imações, estratégias, políticas ou prátic-as de acordo com as demandas do pro-jeto e da organização

21. Interesse pelo Trabalho

342/641

• Ser motivado pelo trabalho

• Ter esperança de que seu plano de car-reira corresponda às oportunidadesoferecidas

• Ter interesse pelas condições de tra-balho (local, horários, salário, etc.)

A experiência profissional do candidato tam-bém é de vital importância para o sucesso doprojeto. É desejável que o candidato tenhatrabalhado em diferentes tipos de projetopara ter conseguido desenvolver-se e acumu-lar habilidades na prática de gerenciamentode projetos.

343/641

PRINCIPAISERROSCOMETIDOS NASELEÇÃO DOGERENTE DEPROJETOS

“Todo homem é fruto de suas próprias ideias.”

Miguel de Cervantes

Ainda que os executivos da empresa tenhamuma clara descrição do que se espera do ger-ente de projeto, muitas vezes a sua seleção éfeita de maneira equivocada, escolhendo-se oprofissional errado para tal função. A seguir

estão alguns critérios comuns segundo osquais a pessoa errada pode ser selecionada.

Maturidade – Muitas vezes a empresa con-sidera maturidade como o tempo de trabalhodo candidato, idade ou até mesmo suaaparência física. Não é essa a maturidadeque se precisa do gerente do projeto. O que énecessário é uma maturidade vinda da ex-posição a vários tipos de projetos em váriasposições.

Disponibilidade – A organização não podeselecionar o gerente do projeto somenteporque o profissional está disponível. É pre-ciso que ele tenha todas as característicasdescritas anteriormente e esteja disponível.Outro erro é selecionar o gerente de projetoperfeito, porém completamente indisponível,devido a outras atividades na organização.

Experiência Técnica – Não se pode escol-her como gerente de projeto pessoas que têmapenas as habilidades técnicas. Certamenteelas não conseguem desvincular suas

345/641

atividades dos aspectos técnicos,esquecendo-se dos outros aspectos do geren-ciamento de projetos. A seleção de um téc-nico para gerente de projeto somente éaceitável em projetos que requerem, basica-mente, experiência técnica para seu desen-volvimento, como projetos de pesquisa edesenvolvimento.

Orientação ao Cliente – Não se pode se-lecionar o gerente do projeto simplesmentepara satisfazer um pedido do cliente. Sercapaz de se relacionar com o cliente não éuma garantia de que o projeto será bem-sucedido.

Exposição – O gerente de projeto não deveser selecionado apenas para ganhar ex-posição às técnicas de gerenciamento de pro-jetos. Primeiro, o gerente de projetos, ao re-tornar, pode estar obsoleto em suas ativid-ades funcionais. Segundo, provavelmente elenão vai querer retornar à atividades funcion-ais após ter trabalhado em projetos.

346/641

Experiência na empresa – Não se podegarantir que um profissional será um grandegerente de projeto apenas porque ele já pas-sou por várias áreas da organização. Isso atémesmo pode indicar que o candidato não éestável em nenhuma posição da empresa. Sea pessoa não tem competência, colocá-la naatividade de gerenciamento de projetossomente irá aumentar o dano causado aonegócio.

Finalmente, é preciso considerar osseguintes fatores:

• Profissionais não devem ser pro-movidos a gerentes de projetos apenasporque já atingiram o mais alto patamarde salários de sua função.

• Gerentes de projetos devem ser pagossobre resultados, não sobre o número depessoas supervisionadas.

347/641

ADMINISTRAÇÃODE CONFLITOS

“É a diferença de opiniões que faz com que existam as corridas de cavalos.”

Mark Twain

O trabalho em gerenciamento de projetostambém é caracterizado por conflitos e incer-tezas. Conflitos entre os departamentos fun-cionais e o time do projeto na concorrênciapor recursos, pessoal e dinheiro e conflitosde interesses entre os envolvidos(stakeholders) no projeto. O cliente, ao real-izar um determinado projeto, desejamudanças, a organização que executa o pro-jeto deseja lucros, que podem ser reduzidosse as mudanças desejadas pelo cliente foremrealizadas. O time do projeto é, então,

dirigido por dois chefes com interesses dis-tintos e muitas vezes opostos.

Conflitos, se não gerenciados adequada-mente, podem ser destrutivos para o projeto.Eles podem baixar drasticamente o moral dotime e a produtividade, criando tensões entrepessoas, causando a formação de mecanis-mos de competição interna negativos. É im-portante que o gerente de projeto seja capazde reconhecer as potenciais origens dos con-flitos e quando, no ciclo de vida do projeto,esses serão benéficos ou maléficos para ostrabalhos.

349/641

Figura 4.1 – Nível de Conflitos x desempenho da or-

ganização (com base em Robbins e

Kotse)

De acordo com o gráfico anterior, pode-seconsiderar que, em um ponto x, onde o nívelde conflito é abaixo do esperado, tem-se umdesempenho comprometido devido à apatia,à falta de ideias e de iniciativa do time e dogerente de projeto. No ponto y, tem-se a mel-hor relação conflito-desempenho, uma vezque eles são funcionais e se relacionam coma criatividade e a iniciativa. O terceiro ponto(z) mostra um excesso de conflito, que é neg-ativo para o projeto, uma vez que leva aocaos, à falta de cooperação mútua e aos con-flitos pessoais.

Podem ser considerados aspectos positivosdo conflito os seguintes:

• força mudanças;

• aumenta a criatividade na criação denovas opções;

350/641

• melhora as comunicações se ambas aspartes estiverem interessadas em gan-hos mútuos;

• aumenta a energia e a coesão do grupo;

• promove o balanceamento entre podere influência, quando associado a téc-nicas efetivas de solução de problemas;

• clarifica as metas.

Quanto aos aspectos negativos, podem sercitados os seguintes:

• aumenta a hostilidade e agressividade;

• apresenta desejo de ser o vencedor, po-dendo bloquear a criação de novasalternativas;

• inibe as comunicações porque a in-formações relevantes não sãocompartilhadas;

• causa estresse e cria uma atmosferadesfavorável;

351/641

• pode, se conduzido da formaganhador-perdedor, causar perda destatus ou posição;

• apresenta discussões que podem gan-har conotação pessoal.

Kerzner destaca sete potenciais fontes deconflitos durante o gerenciamento deprojetos:

• conflito de prioridades no projeto;

• conflito a respeito de procedimentosadministrativos;

• conflitos de opiniões técnicas e dedesempenho;

• conflitos de recursos humanos;

• conflitos sobre custos e orçamentos;

• conflitos sobre agendamento dostrabalhos;

• conflitos pessoais.

Cabe ao gerente de projeto lidar com os con-flitos e administrá-los, fazendo com que o

352/641

projeto se beneficie, permanentemente, dasdiscussões e dos diferentes pontos de vista,evitando que os conflitos gerem perda deprodutividade ou descontrole para o projeto.

353/641

2. ÉTICA ERESPONSABILIDADEPROFISSIONAL

Um dos aspectos fundamentais do trabalhoem projetos está na ética e na responsabilid-ade profissional do gerente de projeto e desua equipe. Mulcany (2000) afirma que oprofissional de gerenciamento de projetostem a responsabilidade de suportar a integ-ridade e a ética da profissão. Isso envolve as-segurar que todas as ações tomadas estãosempre alinhadas com os requerimentos le-gais e com os padrões éticos.

Ao se fazer isso, estará se garantindo a integ-ridade das necessidades dos envolvidos, bemcomo da parte da sociedade que sofre im-pacto direto pelo projeto.

Como os projetos envolvem mudanças queafetam tanto a sociedade quanto asempresas, torna-se necessário realizar essasmudanças dentro de aspectos éticos eresponsáveis.

355/641

1.58O que éResponsabilidadeProfissional?

É o conjunto de ações do gerente de projetosde modo a assegurar uma atitude respon-sável e ética.

Essas ações podem ser resumidas nosseguintes itens:

• faça a coisa correta;

• siga o processo correto;

• aja eticamente;

• reporte qualquer violação;

• lide com os problemas;

• aumente de modo permanente a basede conhecimento e as melhores práticasdo projeto;

• procure os conflitos de interesse e atueem sua solução.

Muitas vezes os aspectos éticos estão rela-cionados ao processo cultural de um país ouregião e até mesmo aos aspectos relacion-ados ao tipo de educação da pessoa.

Um exemplo dessa abordagem está noseguinte problema:

“Quando você checa o calendário do projeto,você observa que uma reunião muito import-ante com um profissional crítico para o pro-jeto foi agendada e você não foi informado.Qual é a MELHOR decisão a ser tomada?

1. Evitar citar o problema para o mem-bro do time e continuar a observá-lo

2. Notificar seu chefe sobre o problema

3. Tratar do problema com o membro dotime

4. Tratar do problema com o chefe domembro do time

Como um profissional com responsabilidadedeve olhar de frente o problema e não ter

357/641

atitudes omissas, a decisão mais adequada étratar do problema com o membro do time.

358/641

1.59Subdivisões daResponsabilidadeProfissional

A responsabilidade profissional se subdividenos seguintes aspectos:

• garantir a integridade individual;

• contribuir para a base de conheci-mento em gerenciamento de projetos;

• aprimorar a competência individual;

• balancear o interesse dos envolvidos;

• interagir com o time e os envolvidos deum modo cooperativo e profissional.

Garantir a Integridade Individual visagarantir a integridade e o profissionalismoatravés da aderência aos requerimentos le-gais e padrões éticos de modo a proteger acomunidade e todos os envolvidos.

A garantia da integridade individual pode serevidenciada nos seguintes aspectos:

• sempre diga a verdade em todos os re-latórios, conversações e outras comu-nicações, mesmo que seja solicitado avocê que faça o contrário;

• siga as regras de copyright e outrasleis;

• nunca divulgue os dados da empresa apessoas não autorizadas;

• valorize e proteja a propriedadeintelectual;

• nunca coloque seus interesses pessoaisacima dos ganhos do projeto;

• previna os conflitos de interesse e lidecom eles quando ocorrerem;

• não ofereça ou receba suborno oupresentes inadequados;

• trate todos com respeito;

• reporte violações às leis, às políticas donegócio, ética e a outras regras;

360/641

• cuidado, não coloque amizade e re-lações pessoais acima da lei;

• siga os processos corretos;

• se, por exemplo, um gerente de projetonão tem autoridade, é requerido pela re-sponsabilidade profissional que o ger-ente de projetos busque essa autoridade;

• em resumo: faça as coisas certas.

Contribuir para a Base de Conheci-mento em Gerenciamento de Projetossignifica compartilhar informações aprendi-das, melhores práticas, pesquisas, etc., den-tro das devidas comunidades, visandogarantir a melhoria da qualidade dos pro-cessos, aprimorando a capacitação dos coleg-as e da profissão.

A contribuição para a base de conhecimentoem gerenciamento de projetos pode ser evid-enciada nos seguintes aspecto

361/641

• compartilhe as lições aprendidas como projeto com outros gerentes de projetoda empresa;

• suporte a educação de outros gerentesde projetos e envolvidos sobre geren-ciamento de projetos;

• realize pesquisas para descobrir mel-hores práticas na área e compartilhe-ascom os demais;

• escreva artigos sobre gerenciamento deprojetos;

• aprimore a competência individual;

• aprimore a competência individualpela aplicação contínua do conheci-mento adquirido para melhorar osserviços;

• trabalhe continuamente para entendersuas forças e fraquezas pessoais;

• continue a aprender;

• planeje seu desenvolvimentoprofissional;

362/641

• busque novas informações e práticasque poderão ajudar sua empresa e seusprojetos;

• continue a aprender sobre a área deatuação da empresa.

Balancear o Interesse das Partes In-teressadas significa recomendar estratégiasque podem relacionar, conciliar e satisfazerdiferentes necessidades das partes interessa-das. Compreende determinar a razão por queo projeto foi iniciado, como as constantes tri-plas do projeto (PCT) se relacionam e secompletam.

O balanceamento do interesse das partes in-teressadas pode ser evidenciado nosseguintes aspecto:

• determine e compreenda as necessid-ades e objetivos de cada um dosenvolvidos;

• procure ativamente por necessidadesconflitantes;

363/641

• mantenha o time e os interessados en-volvidos e busque a gerência superiorquando o time não conseguir resolver osconflitos;

• determine as possíveis soluções pararesolver os conflitos;

• utilize a negociação, a comunicação e odesenvolvimento de times para solu-cionar interesses divergentes;

• realize reuniões, entrevistas e dis-cussões para resolver os conflitos;

• busque alternativas quando algumadas técnicas empregadas prejudicaremoutros aspectos do projeto (Fast Track-ing, Crashing);

• realize mudanças e aprove novamenteo Termo de Abertura ou Project Charterse forem necessárias para dar um bal-anceamento ao interesse dos envolvidos.

Interagir com o Time e os Envolvidosde um Modo Cooperativo e

364/641

Profissional significa respeitar as pessoas,assimilando diferenças culturais, étnicas esociais de modo a garantir um ambiente col-aborativo e participativo.

O relacionamento entre os envolvidos de ummodo cooperativo e profissional pode serevidenciado nos seguintes aspectos:

• respeite as diferenças culturais;

• diversidade pode tornar o projeto maisrico e divertido;

• previna o choque cultural através dotreinamento e do conhecimento das cul-turas diferentes;

• descubra e respeite as diferentesformas de trabalho e comunicação entreos membros do time;

• utilize uma comunicação clara com apessoa certa e da forma certa de modo aprevenir que diferenças culturais setornem um problema.

365/641

3. QUESTÕESPARAREVISÃO

1. O gerente de projetos deve ser neces-sariamente um técnico? Justifique.

2. Quais os principais critérios naseleção de um gerente de projetos?

3. Por que a maturidade pode ser vistade maneira equivocada na seleção dogerente de projetos?

4. Relacione as características do ger-ente de projetos com os tipos profission-ais requeridos no time de projeto emfunção das fases do projeto (visto nocapítulo de gerenciamento de recursoshumanos).

5. Até que ponto conflitos podem serbenéficos?

6. Como o gerente de projetos deve ex-plorar os conflitos positivos?

7. Por que um gerenciamento de confli-tos adequado pode forçar mudanças?

8. Relacione o nível de conflito em cadafase do projeto em casos de projetosbem sucedidos e mal sucedidos.

367/641

4. PALAVRACRUZADA

369/641

370/641

- PARTE VI-OMODELO GERAL

PARA OGERENCIAMENTO DE

PROJETOS

1.JUSTIFICATIVADO MODELODO FLUXO DEATIVIDADESDO PROJETO

A grande maioria das pessoas que iniciamseus trabalhos com projetos não sabe exata-mente que passos seguir para planejar, ex-ecutar e controlar um projeto de maneiraeficaz. Muitas dessas pessoas não sabem se-quer como começar um projeto, perdendotempo em decorrência da inversão de prior-idades e sequência. Por isso, este capítulo

tem como objetivo descrever, passo a passo,todas as etapas necessárias para se implantarum projeto com qualidade. Este modelo foibaseado nas teorias propostas no PMBOK,bem como nos comentários de Lewis, Kerzn-er, Schtub, Galbraith e Sanders, mencion-ados na bibliografia deste livro e, depois, ad-aptado. O objetivo desta adaptação é ad-equar o modelo geral de gerenciamento deprojetos à realidade competitiva brasileira.

373/641

FLUXOGRAMA DOPROJETO

Para melhor compreender o fluxo de ativid-ades do projeto, tem-se, a seguir, o fluxo-grama geral do desenvolvimento do projeto.O fluxograma proporciona uma visão se-quencial de todos os trabalhos a serem real-izados pelo projeto, incluindo testes, de-cisões, aprovações e arquivamentos.

O fluxo foi elaborado para solucionar agrande dificuldade encontrada pelos profis-sionais ao encadear suas atividades e açõesdentro de um projeto.

É importante ressaltar que, mesmo sendo ofluxo um processo sequencial, as fases deplanejamento, execução e controle sãocíclicas até a conclusão do projeto, conforme

figura a seguir, discutida no capítulo a re-speito do ciclo de vida do projeto.

Figura 2.1 – Inter-relacionamento entre as fases em

um projeto (PMI, 2008) - repetição

Todos os itens do fluxo serão discutidos nospróximos capítulos. Os números entreparênteses em cada subtítulo destacam oitem representado dentro do fluxo.

375/641

376/641

Figura 2.2 – O fluxograma geral do projeto (Fase

de Iniciação)

377/641

378/641

Figura 2.3 – O fluxograma geral do projeto (Fase

de Planejamento)

379/641

380/641

Figura 2.4 – O fluxograma geral do projeto (Fases

de Execução, Controle e

Encerramento)

381/641

FASE DEINICIAÇÃO

1.60Problema ouOportunidade (01)

Todo projeto tem sua origem em um prob-lema ou uma oportunidade. Pode-se consid-erar que o não aproveitamento de uma opor-tunidade representa um problema para a or-ganização, uma vez que empresas concor-rentes, ou até mesmo o mercado consum-idor, estão se preparando para se adequarema essas oportunidades. É o marco que de-termina o início de um projeto. Esse pro-cesso consiste em desenvolver um conceitopara o projeto. É representado por frases dotipo: “Nós necessitamos...”, “Seria interess-ante se...”, “Podemos fazer...”, dentre outras.

O desenvolvimento formal da oportunidade,ou do obstáculo, deve detalhar o máximopossível toda a situação atual da organização,os fatos geradores do problema ou das opor-tunidades a serem aproveitadas.

Problema é o obstáculo que estáentre o local onde se está e o localem que se gostaria de estar.

Diante dessa definição, pode-se ter comometas a serem atingidas por essa formaliza-ção as seguintes:

• identificar e realizar, da melhor formapossível, os esforços necessários para sechegar ao outro lado;

• evitar, de todas as formas possíveis,que o obstáculo aumente ou passe a pre-judicar outras atividades;

• saber avaliar corretamente se o que sequer é realmente chegar ao outro lado.

Muitas vezes essas definições são o prob-lema. Muitos projetos chegam a uma soluçãocorreta para um problema errado. É import-ante que se saiba aonde se quer chegar antesde começar a realizar.

A partir da definição do problema é que sepode determinar as soluções possíveis. Por

384/641

exemplo: “Qual é a melhor maneira de seganhar dinheiro?” Essa definição de prob-lema é muito geral e permite que muitos ob-jetivos específicos possam ser considerados.

Se se modificar o problema para “Como euposso ganhar dinheiro comprando evendendo automóveis?”, tem-se um prob-lema muito mais focado e específico.

Ao se definir o problema, é importante quese saiba qual o seu tipo e características. Ex-istem, basicamente, dois tipos de problemas:

• problemas de Variáveis Abertas;

• problemas de Variáveis Fechadas.

Problemas de Variáveis Abertas sãoproblemas que não possuem uma únicasolução determinada e clara. Estão sujeitos amodificações mercadológicas, ambientais eaté mesmo a decisões estratégicas daempresa. A grande maioria dos problemasque envolvem gerência de projetos são prob-lemas abertos.

385/641

Problemas de Variáveis Fechadas pos-suem apenas uma única solução matematica-mente definida. Por não sofrerem nenhumainfluência do ambiente externo, são desolução e controle aparentemente mais fácil.

Uma situação delicada acontece quando umproblema de variáveis abertas é simplificadopara um problema de variáveis fechadas. Aose proceder a essa simplificação, deve-se at-entar para as variáveis que continuarão ex-postas ao ambiente de mudanças e controlá-las o máximo possível, para que os efeitos deuma mudança indesejável possam serevitados.

386/641

Figura 3.1 – Análise de problemas com variáveis

abertas e fechadas

Todo problema formalmente escrito deve re-speitar as seguintes regras:

• deve ser escrito em pelo menos duasformas diferentes por pessoasdiferentes;

• o ponto principal do problema deve serdestacado isoladamente;

387/641

• a pergunta “O que eu quero realmentefazer é...?” deve ser respondida.

388/641

1.61Criar o Termo deAbertura ou ProjectCharter (02)

Após definida a necessidade de se estabele-cer um projeto, deve ser criado o Termo deAbertura ou Project Charter. Como já visto,o Project Charter é o documento legal quereconhece a existência de um projeto. Eleserve como uma linha de base para o tra-balho do gerente do projeto. Contém diver-sas informações sobre o projeto, incluindoestimativas iniciais de qual o prazo desti-nado, os recursos necessários e o orçamentodisponível. Todos esses dados são prelimin-ares e, normalmente, realizados pelos exec-utivos da empresa, identificando suas ne-cessidades e interesses.

Podem se considerar como elementos doProject Charter:


• um resumo das condições que definemo projeto (introdução);

• nome do gerente de projeto e suas re-sponsabilidades e autoridades;

• necessidades básicas do trabalho a serrealizado;

• descrição do produto do projeto;

• cronograma básico do projeto;

• estimativas iniciais de custo;

• necessidades iniciais de recursos;

• necessidade de suporte pelaorganização;

• controle e gerenciamento das inform-ações do projeto;

• aprovações com assinatura do exec-utivo responsável pelo documento (ele-mento externo ao projeto).

Como já visto, esse processo é integrante dosprocessos de gerenciamento da integração.

390/641

391/641

1.62Identificar eSelecionar o Gerente deProjeto (03)

Essa etapa é a responsável pela identificaçãoe seleção do gerente de projeto. A partirdesse ponto, o gerente de projeto é o con-dutor central dos processos seguintes.Maiores detalhes podem ser vistos na ParteV do livro – O Gerente de Projeto e SuasInterfaces.

1.63Criar o Livro Geral doProjeto (04)

É importante que todas as informações doprojeto sejam documentadas. A docu-mentação tem três objetivos básicos:

• Registrar, formalmente, as decisões eaprovações dos envolvidos (assinaturas,observações, etc.);

• facilitar a revisão da estrutura doprojeto;

• servir de base para futuros projetos daempresa (aprendizado).

O livro geral do projeto, ou Project Data-book, é um documento que registra todos osfatos acontecidos no projeto, desde a fase dedefinição até a fase de finalização.

No caso de livros do tipo “papel”, ele devepossuir as seguintes características:

• todas as páginas devem ser numeradase rubricadas pelo responsável pelo livro;

• o termo de abertura do livro deveconter os nomes das pessoas que terãoacesso direto a ele, bem como a relaçãode todas as pessoas que poderão repres-entar diretamente os envolvidos(cliente, os fornecedores e a equipe doprojeto);

• nenhuma página do livro deve ser re-movida, retirada do conjunto ousubstituída;

• todas as decisões tomadas pelo projetodevem ser registradas imediatamente nolivro e autorizadas por escrito pelosenvolvidos;

• o fechamento do livro geral do projeto,com a rubrica de todos os envolvidoscom o projeto (clientes, fornecedores,etc.), deverá ser feito quando as páginasdo livro estiverem esgotadas, ou o pro-jeto tiver sido concluído;

394/641

• no caso de projetos grandes, devem sercriados vários livros de projeto; esseslivros devem ser numerados sequencial-mente e fechados um a um, logo apósseu término;

• não se devem utilizar dois livros deprojeto simultaneamente, para que osdados fiquem centralizados em umúnico documento.

Atualmente é muito comum confeccionar olivro através do computador. Nesse caso,diversos softwares de gestão eletrôn-ica de documentos (GED) podem serutilizados, desde que garantam as ca-racterísticas de armazenamento esegurança.

O Gerenciamento Eletrônico de Documentosconverte informações de texto, voz e imagenspara a forma digital. Funciona com softwarese hardwares específicos e utiliza as mídiasópticas, em geral, para armazenamento.

395/641

Um sistema de GED usa a tecnologia da in-formática para captar, armazenar, localizar egerenciar versões digitais das informações,dentre elas:

Voz - Informações geradas de forma verbal,tais como atas de reunião, aprovaçõesverbais, etc.

Texto - Informações normalmente maisformais. Vão de cartas a contratos, planilhas,manuais, etc.

Imagem - Informações que não podem serrepresentadas nas formas anteriores: mapas,fotografias, assinaturas, etc.

396/641

Figura 3.2 – Exemplo GED da solução de Enterprise

Project Management da Microsoft através

do Microsoft Project Web Access

O livro geral do projeto não é apenas umdocumento que formaliza e registrador de fa-tos. Ele é uma fonte de consultas sobre oprojeto e, portanto, todas as considerações,discussões e conclusões devem estar regis-tradas, mesmo que se venha a concluir, pos-teriormente, que a consideração feita era in-completa, ou absolutamente errada. Nessecaso, o registro dessas falhas servirá de basepara que, em futuros projetos, essas falhasnão voltem a ocorrer.

Lembre-se: gerenciamento de projetos não ématemática e, na maioria das vezes, subesti-mar uma alternativa ou consideração, pormais absurda que pareça à primeira vista,pode representar o fracasso do projeto.

397/641

1.64Definir o Objetivo, aJustificativa, o Produto eas Entregas do Projeto (05)

Todo projeto necessita de um objetivo e umajustificativa clara e tangível, bem como seusprodutos e entregas devem ser bem defin-idos. O objetivo destaca aquilo que se queratingir com o término do projeto. A justific-ativa é o objetivo implícito no projeto, arazão de ser de todo o projeto. Os produtossão os bens, ou resultados, que se espera col-her ao término do projeto. As entregas são osresultados físicos atingidos ao longo do pro-jeto que asseguram que os produtos serãoobtidos de maneira satisfatória.

Objetivo é a representação formaldaquilo que se quer atingir com otérmino de um projeto. É facil-mente mensurável e controlável.

Normalmente é definido por verb-os de ação. Parâmetros numéricosde tempo, custo e desempenho de-vem estar descritos no objetivo.

Exemplo: Implementar o geren-ciamento de projetos na divisão dentrodas metodologias estabelecidas pela di-visão de projetos corporativos da mat-riz (USA), dentro de um prazo máximode 180 dias corridos a partir de janeirode 2004 e com um custo total estimadode $1.000.000 (custo adicional)

Justificativa é tudo aquilo que es-tá oculto no objetivo, isto é, é arazão de ser do projeto, o benefí-cio gerado por ele. É de difícilmensuração porque representa,na maioria das vezes, um senti-mento da organização. Tambémconhecido como missão.

399/641

Exemplo: Preparar a divisão para umaumento significativo na demanda porserviços decorrentes de um aumentonas linhas de produtos oferecidos pelacompanhia e de movimentos deconcorrentes.

É importante ressaltar que o objetivo e a jus-tificativa sempre se completam. Isso significaque o objetivo, sozinho, não define o projeto.É preciso que ele esteja associado a uma de-terminada justificativa ou razão. Por outrolado, uma determinada necessidade ou justi-ficativa também pode caracterizar inúmerosobjetivos.

400/641

Figura 3.3 – Relacionamento entre objetivo e justi-

ficativa para um escopo definido

A seguir, são dados dois exemplos que carac-terizam a consistência entre objetivo e justi-ficativa, para um escopo definido.

Exemplo 01

Objetivo - Concluir o curso de Adminis-tração (Empresas) em uma universidadepública no limite máximo de quatro anos.

Justificativas possíveis para esseobjetivo

• Realização pessoal

401/641

• Consecução de uma estabilidade fin-anceira e possibilidade de ascensãoprofissional

• Simpatia pelo assunto

• Conhecimento de pessoas

• Status e reconhecimento

• Sequência da carreira dos pais ou pess-oas de influência pessoal

Observa-se, nessas missões, que um únicoobjetivo é capaz de ter implícitas inúmerasdelas.

Exemplo 02

Necessidade: Consecução de estabilidadefinanceira e possibilidade de ascensãoprofissional.

Objetivos possíveis para essa necessid-ade (justificativa)

• Montar um restaurante à beira-mar evender bebidas e comidas típicas daregião.

402/641

• Concluir o curso de administração deempresas em uma universidade públicano limite máximo de quatro anos.

• Fazer um MBA no exterior e retornarao Brasil como mestre em adminis-tração de negócios.

Observa-se que uma única necessidadepode-se traduzir em diferentes objetivos.

Produtos são todos os resultadosfísicos obtidos na conclusão doprojeto. Os produtos identificam aabrangência do projeto.

Exemplo: Metodologia imple-mentada e documentada comaprovação do patrocinador, bemcomo um projeto-piloto imple-mentado na divisão para avaliara efetividade da metodologia. Ex-emplo: O produto de um curso

403/641

superior é o diploma de fim decurso.

Entregas são todos os resultadosfísicos ou semiprodutos obtidosao longo do projeto. Servem paramedir e avaliar o desempenho doprojeto. Normalmente podem serdefinidas através de marcos ouetapas no cronograma.

Exemplo: O projeto da implementaçãodo gerenciamento de projetos em umaempresa pode ter uma entrega cha-mada “Diagnóstico concluído”, outrachamada “Treinamento realizado”,outra chamada “Software instalado”.Ambas são entregas de um único pro-jeto e servem para identificar o que foi eo que não foi concluído.

404/641

Exemplo: O histórico escolar é um re-latório com as entregas concluídas emum curso superior.

405/641

1.65Arquivar Informaçõesno Livro Geral do Projeto(06)

Após terem sido definidos os objetivos, a jus-tificativa, os produtos e as entregas do pro-jeto, essas definições devem ser arquivadasou gravadas no Livro Geral do Projeto, junta-mente com o Termo de Abertura (ProjectCharter), para posterior acompanhamento.

1.66Criar Alternativas deCondução do Projeto paraConstrução do Escopo (07)

Esta etapa é a responsável pela criação de al-ternativas (formas) de se conduzir o projeto.Seu objetivo é descrever como serão realiza-dos os trabalhos durante o projeto de modo afacilitar a construção do escopo do projeto.Usualmente o PMBOK Guide se refere a esseprocesso como “Coleta de Requisitos”.

As alternativas geradas devem ser capazes deresponder à seguinte questão:

Como nós iremos fazer isso?

Diversos fatores devem ser considerados aose criarem alternativas, uma vez que diversoselementos do ambiente ou da empresa po-dem favorecer ou não determinadasestratégias:

Fatores ambientais

• tecnologia

• economia

• governo

• localização geográfica

• sociedade

Fatores Organizacionais

• experiência dos profissionais

• relações de trabalho

• disponibilidade física de recursos

• experiência no tipo de projeto a serdesenvolvido

• imagem da empresa

• atitude da alta gerência

• moral dos empregados

• posicionamento do marketing

• comprometimento da organização como projeto

• expectativas dos envolvidos

408/641

A expectativa da alta gerência, normalmente,é a maior influenciadora do sucesso ou dofracasso do projeto. Quando essas expect-ativas, ou previsões, para o desempenho doprojeto são irreais, o impacto é quase semprenegativo.

A criação dessas alternativas deve ser realiz-ada no tempo certo. As alternativas desen-volvidas precocemente são vagas e impre-cisas, já que não se conhece praticamentenada do projeto. Quando o desenvolvimentodas alternativas é feito tardiamente, as de-cisões normalmente já foram tomadas, limit-ando muito as alternativas viáveis e gerandoum custo elevadíssimo de implementação,como foi visto nos capítulos anteriores.

A maioria das alternativas de condução é cri-ada através de reuniões de Brainstorming,onde cada pessoa sugere alternativas paracada fase, ou etapa, do problema definido,sem que haja discriminações ou críticas por

409/641

parte dos outros envolvidos. Esse processo éconhecido como Estratificação.

Por exemplo, em uma implementação de umescritório de projetos (PMO), diversos assun-tos precisam ser abordados, tais como o soft-ware, o hardware, o padrão a ser usado, otreinamento, dentre outros.

No caso do treinamento básico, pode-se de-terminar através de Brainstorming a maiorquantidade possível de alternativas paracada categoria destacada, como é ap-resentado no mapa a seguir.

410/641

Figura 3.4 – Exemplo de mapa mental para a cri-

ação de alternativas (Mapa mental)

Pode-se observar que todas as alternativas,por mais absurdas que pareçam, foram colo-cadas no plano para serem avaliadasposteriormente.

411/641

1.67Estimar Desempenho,Custo, Tempo, Riscos,Consequências e Culturadas Alternativas (08)

Para cada alternativa gerada em cadacategoria, deve-se estimar sua qualidade(desempenho), seu custo, seu tempo de ex-ecução e sua capacidade de atender aoescopo definido para o projeto. Os valoresgerados nessa fase devem ser os mais pre-cisos possíveis, sem que se perca muitotempo em análises e discussões. Afinal, elessão somente estimativas. As estimativas, porserem empíricas, devem ser estimadas at-ravés de notas (0 a 10). Quanto mais próx-ima de dez for a nota, mais aquela altern-ativa atenderá ao que foi estabelecido no ob-jetivo. Ou seja, se uma alternativa recebeuma nota alta para o risco, isso

significa que o nível de risco da altern-ativa é pequeno. Uma nota baixa parao risco representa um risco elevado,uma vez que os riscos não estãoatendendo ao que foi estabelecido nadefinição dos objetivos. Os parâmetrosdevem ser calculados através de histórico,simulação ou estatísticas. Todas as altern-ativas deverão ser mantidas no processo deanálise, mesmo que elas apresentem valoresabsurdos, se comparados com os valores es-tabelecidos para o projeto. A análise de cadaalternativa e a escolha da mais adequadaserá realizada posteriormente.

Os fatores de análise estão descritos a seguir:

Desempenho (P) – Representa a qualid-ade intrínseca daquela alternativa dentro doprojeto. Quanto mais qualidade tem a altern-ativa, maior será sua nota. A abreviação “P”foi mantida pela popularidade do termoPerformance.

413/641

Custos (C) – Representa o custo de se optarpela alternativa. Na atual conjuntura dosprojetos, quanto menor o custo, maior será anota.

Tempo (T) – Representa o período detempo gasto para executar a alternativa. Naatual conjuntura dos projetos, quanto menoro prazo, maior será a nota (tempo é sempreum fator crítico).

Riscos (R) – representa um perigo, ou pos-sibilidade de perigo, que pode ser geradopela alternativa durante sua implantação. Oprojeto corre risco enquanto está sendo real-izado, nunca após seu término. Riscos po-dem ser previsíveis, ou não. No caso deriscos não previsíveis, como desastres aé-reos, desabamentos ou enchentes, deve-setrabalhar com a distribuição probabilísticapara que se faça a estimativa.

Consequência (CO) – São os fatos negat-ivos, ou positivos, que o projeto pode gerarapós sua conclusão, tais como demissões,

414/641

oportunidades de vendas de produtosagregados, impactos ambientais, retaliaçõespor parte de fornecedores, clientes e outrosenvolvidos.

Adequação à Cultura (AC) - Significaverificar se a alternativa está dentro do con-texto cultural vigente na organização e nomercado. Alternativas que propõem umchoque cultural na empresa, ou no mercado,devem merecer atenção especial em suaanálise.

415/641

1.68Arquivar Alternativascom Estimativas no LivroGeral do Projeto (09)

Todas as alternativas devem ser arquivadascom suas respectivas estimativas. O arquiva-mento é realizado através de tabelas paracada alternativa em cada categoria.

Uma sugestão de tabela para cada alternativaé mostrada na figura a seguir.

Figura 3.5-Tabela de arquivamento de alternativas e

respectivas estimativas para o projeto

Como exemplo, tem-se, na figura a seguir, atabela de arquivamento das alternativas“Treinamento realizado externamente” paraa categoria “Treinamento básico”. Os valorese as notas apresentadas são meramenteilustrativos.

Figura 3.6 – Exemplo para a alternativa “Treina-

mento realizado externamente”

417/641

1.69Selecionar o MelhorConjunto de Alternativaspara o Projeto (10)

A seleção da alternativa mais adequada parase conduzir o projeto é feita através de com-paração direta entre as alternativas disponí-veis. Todas as estimativas realizadas paracada alternativa serão comparadas nessafase, tais como

• desempenho;• custo;• tempo;

• riscos;• consequências;• cultura e outros

Diversos mecanismos podem ser utilizados

na seleção da alternativa11

, mas os maiscomuns são os modelos de pontuação e pon-deração. Os modelos de pontuação e ponder-ação consistem em atribuir notas de 0 a 10para cada alternativa em cada fator analis-ado. Todos os fatores recebem um peso



relativo à sua importância para o projeto,normalmente variável de 1 a 3. O total depontos é calculado através de média pon-derada de cada nota ao peso relativo do fat-or, ou seja,

Onde TotalFatores = nº total defatores analisados.

Lembre-se! Quanto maior a nota, maisefeito positivo a alternativa tem para o pro-jeto. Por exemplo, uma nota alta para o fatorrisco representa um risco baixo (efeitopositivo).

419/641

Figura 3.7 – Modelo de Pontuação e Ponderação

Padrão

Para a tabela anterior, pode-se interpretar afórmula dada para o cálculo da nota total daalternativa como

Analogamente, para as demais alternativas,tem-se

• alternativa 2 ? Nota 8,74 em 10 pontos;

• alternativa 3 ? Nota 2,94 em 10pontos;

• alternativa 4 ? Nota 4,47 em 10 pontos.

Portanto, a alternativa 2 é a que apresentamaior nota e, consequentemente, maior pos-sibilidade de atender melhor aos fatorescolocados.

420/641

O modelo de pontuação e ponderação temcomo objetivo apoiar a escolha da altern-ativa, porém não deve ser utilizado como aúnica forma de selecionar alternativas. Algu-mas vezes, escolhem-se alternativas commenos pontuação, mas que, diante do con-senso do grupo, apresentam maior facilidadede execução.

Essa tabela é construída para cada categoriaa ser analisada, escolhendo-se a melhor emcada uma delas. O conjunto final de altern-ativas do projeto é a soma de todas as altern-ativas vencedoras. Uma única precaução pre-cisa ser tomada no que diz respeito à coerên-cia e à sinergia entre as alternativas. Podeacontecer que a escolha de uma alternativaem uma categoria entre em contradição coma melhor alternativa em outra categoria. Porexemplo: se a opção de software escolhidapara o escritório de projetos for uma soluçãobaseada em um computador de tecnologiaRisc, não será possível escolher no hardware

421/641

um computador com tecnologia Intel, umavez que o programa escolhido não funcionaem máquinas Intel, por exemplo.

Como exemplo de conjunto de alternativas,tem-se, para o projeto de implementação doescritório de projetos.

1. Geral

o O custo de pessoal interno não está incluído no

valor anterior e não será considerado por já

fazer parte do custo indireto da empresa.

o Serão consideradas críticas as atividades com

folga menor ou igual a 3 dias.

2. Diagnóstico

o Realizado pela divisão de gerenciamento de proje-

tos da matriz (USA), com custos arcados pela di-

visão, tais como deslocamentos, traslados, hos-

pedagem, etc.

o É acompanhado por consultor especializado

externo.

3. Treinamento

o Prevê treinamento de software e metodologia de

gerenciamento de projetos, integralmente

422/641

terceirizado para a empresa GP Projetos, inclus-

ive para os usuários finais.

o Prevê treinamentos básicos (150 participantes) e

avançados (30 participantes) sobre geren-

ciamento de projetos, além do treinamento para

a equipe de suporte (30 participantes).

o Inclui palestra para diretoria e alta gerência.

o As máquinas utilizadas no treinamento já serão

as definitivas dos usuários.

o O treinamento será em horário integral e com to-

das as turmas sequenciadas.

o O treinamento terá preço fechado por turma (30

alunos cada).

4. Software

o Microsoft Project 2002 com Microsoft Project Web

Access para todas as máquinas.

o Software de Gestão Eletrônica de Documentos no

servidor.

o SQL Server 2000 como plataforma de banco de

dados no servidor.

o Windows.net (server) e Windows XP Professional

para servidores e usuários, respectivamente.

423/641

o Instalação realizada pelo departamento de

informática.

o Produtos precisam ser adquiridos.

o Programa para GED precisa ser avaliado e

adquirido.

5. Hardware

o 2 Servidores IBM adquiridos diretamente da IBM

(incluindo Backup).

o 165 Microcomputadores Dell Pentium IV I,4GHz

com 512MB de Memória RAM, HD de 40 GB e

rede (15 computadores de Backup).

o Instalação realizada pelo departamento de in-

formática da companhia.

o Inexistência de outros equipamentos disponíveis

devido ao deslocamento dos atuais para outros

setores.

6. Piloto

o Lançamento de campanha publicitária.

o Duração máxima de 15 dias de execução.

o Realizado por empresa especializada (GP Proje-

tos) em parceria com a divisão.

424/641

o A avaliação de resultados deve incluir o

patrocinador.

7. Padronização

o Inclusão de padronização de projetos, relatórios,

modos de exibição, estrutura de GED através do

site www.ricardovargas.com.br/fronteiras.

o Realização externa (GP Projetos) com apoio da

divisão.

o Confecção dos padrões realizada internamente

pela empresa.

o Padrão aprovado pelo gerente de projeto.

Observa-se que esse conjunto de alternativasbasicamente estrutura o escopo do projeto eserve de base para a criação da Declaração deEscopo (Scope Statement).

425/641

1.70Descartar e Arquivarpara Futuros Projetos (11)

Todas as alternativas que participaram daseleção e não foram selecionadas devem serdescartadas do projeto e arquivadas para fu-turos projetos. A razão para o arquivamentodessas alternativas está no fato de que, se, nodecorrer da execução do projeto, aconteceralguma falha grave na alternativa anterior-mente escolhida, mantêm-se disponíveis al-ternativas de condução já criadas eanalisadas.

1.71Criar a Declaração deEscopo do Projeto ouScope Statement (12)

Essa etapa tem como objetivo criar a De-claração de Escopo. Como foi visto nocapítulo de gerenciamento de escopo, oscope statement é o documento que formal-iza o escopo de todos os trabalhos a seremdesenvolvidos no projeto, servindo de basepara futuras decisões do projeto. É possívelque, ao longo dele, a declaração de escoposeja revisada, ou refinada, para refletir asmudanças acontecidas no projeto.

Normalmente, a Declaração de Escopocontém:



• nome do patrocinador;

• nome do gerente do projeto e suas re-sponsabilidades e autoridades;

• nome dos integrantes do time doprojeto;

• descrição do projeto;



• produto do projeto;

• expectativa do cliente/patrocinador;

• fatores de sucesso do projeto;

• restrições;

• premissas;

• exclusões específicas (tudo o que nãoserá abordado pelo projeto);

• principais atividades e estratégias doprojeto;

• principais entregas do projeto;

• orçamento básico do projeto;

• plano de entregas e marcos do projeto;

428/641


• aprovações.

429/641

1.72Aprovar a Declaraçãode Escopo (13)

A Declaração de Escopo deve ser, formal-mente, aprovada por todos os envolvidos einteressados de maneira formal, normal-mente através de assinatura no livro geral doprojeto. Essa aprovação tem como objetivoevitar posteriores reclamações, que poderi-am ter sido evitadas com essa formalização.Normalmente, a aprovação da declaração deescopo também representa a liberação damaior parte da verba disponível para oprojeto.

No caso de não aprovação da declaração deescopo, é preciso que o projeto seja revisto,caso essa ação seja possível. Caso contrário,o projeto pode ser abortado (passo 13A -Rever viabilidade do projeto ou abortarprojeto).

FASE DEPLANEJAMENTO

1.73Definir e Agrupar osPacotes de Trabalho e asEntregas do Projeto (WBS)(14)

Nessa etapa, todos os pacotes de trabalho esuas entregas devem ser identificados e agru-pados, constituindo um todo organizado. Amaioria das entregas principais está definidano Project Charter e são as entregas dasfases ou atividades de resumo do projeto.

Pacote de Trabalho é o produto aser entregue no mais baixo nívelda estrutura analítica do projeto(WBS). Um pacote de trabalhopode ser repartido em atividades.Também podem ser denominadasatividades de resumo.

Entregas são todos os resultadosfísicos, ou semiprodutos, obtidosao longo do projeto. Servem paramedir e avaliar o desempenho doprojeto. Normalmente, podem serdefinidas através de marcos, ouetapas no cronograma.

Os pacotes de trabalho são estruturados demodo a compor o Work Breakdown Struc-ture, ou WBS. O WBS, também conhecidocomo Estrutura Analítica do Projeto (EAP).

A EAP é a ferramenta de gerenciamento doescopo do projeto. Cada nível descendentedo projeto representa um aumento no nívelde detalhamento do projeto, como se fosseum organograma. O detalhamento pode serrealizado até o nível desejado, apresentandodados genéricos ou detalhados. O detal-hamento mais usual é até o pacote de tra-balho (work package)

433/641

Figura 4.1 – Exemplo de EAP

São características da EAP as seguintes:

• permite que se veja a contribuição dospacotes de trabalho (work package) noprojeto principal;

• permite o direcionamento das equipes,dos recursos e das responsabilidades;

• determina quais materiais serão ne-cessários para a execução de cadapacote;

434/641

• determina o custo final do projeto apartir do custo de cada pacote ouentrega.

Suas principais vantagens são as seguintes:

• conjuntos de entregas agrupadas deforma simples;

• fácil atribuição de responsabilidades;

• fácil desmembramento do projeto empacotes de trabalho (work package).

Suas principais desvantagens são asseguintes:

• não diferencia, visualmente, o prazo ea duração de cada pacote, bem como aimportância de cada um;

• não mostra as interdependências entreas entregas e os pacotes;

• requer técnica e habilidade para con-fecção e não é construída graficamentepelo Microsoft Office Project, sendo ne-cessária a utilização do Microsoft Office

435/641

Visio ou do WBS Chart Pro (www.critic-altools.com).

O descritivo de cada pacote de trabalho com-põe o Dicionário da WBS. Nele estão con-tidos os seguintes elementos:

• descrição detalhada do trabalho a serrealizado;

• lista de premissas para a realização dopacote;

• lista de recursos para a realização dotrabalho;

• pacotes predecessores e sucessores.

É importante ressaltar que, apesar do nomeconter a palavra dicionário, o Dicionário daWBS não é um livro de termos e definições.

A EAP pode ser detalhada na medida da ne-cessidade do projeto. Projetos muito com-plexos exigem um detalhamento elevadopara um melhor acompanhamento. Projetosmais simples não necessitam de detalhamen-tos significativos. Os níveis mais comuns de

436/641

detalhamento do projeto são mostrados nafigura a seguir.

Figura 4.2 – Nomes e detalhamento para as estru-

turas do WBS

Existem duas formas de estruturação dasatividades para compor a EAP, a saber:

• técnica Top-to-Bottom ouDecomposição;

• técnica Bottom-Up.

Técnica Top-to-Bottom ouDecomposição

É a forma mais fácil de criar e detalhar as en-tregas necessárias. Sua estrutura deve sercriada de cima para baixo, isto é, das

437/641

macrofases do projeto até os níveis de es-forço (entregas estritamente operacionais).Sua construção segue os seguintes passos:

1. identificam-se as grandes fases doprojeto;

2. para cada fase identificada, detalham-se as entregas desejadas;

3. para cada entrega, detalha-se o pacotede trabalho necessário para a suaconclusão;

4. se necessário, para cada pacote detrabalho, detalha-se o nível de esforçolocalizado para a conclusão do respect-ivo pacote;

5. agregam-se os conjuntos de modo aproduzir a EAP.

Técnica Bottom-Up

Exige maior técnica do gerente de projeto.Sua estrutura deve ser criada de baixo paracima, isto é, a partir de um conjuntoaleatório de entregas, gerado através de

438/641

brainstorming ou da experiência dos parti-cipantes. Procuram se agrupar os pacotes detrabalho de modo a criar entregas. As entre-gas são agrupadas em fases, e as fases, noprojeto. Deve ser utilizado para corrigir pro-jetos já iniciados incorretamente. Sua con-strução segue os seguintes passos:

1. obtém-se o conjunto de entregas at-ravés de brainstorming, ou através daexperiência dos envolvidos;

2. criam-se os pacotes de trabalho paraatingir as entregas;

3. agrupam-se as entregas em fases;

4. agrupam-se as fases em um projeto.

12

439/641



Figura 4.3 – Técnica Top-to-Bottom x Bottom-Up

440/641

1.74Criar Planos deGerenciamento de Escopo,Qualidade e Comunicações(15, 16 e 17)

Logo no início do planejamento, é import-ante que os planos de gerenciamento deescopo, qualidade e comunicações sejamdesenvolvidos, uma vez que a maior partedas informações necessárias para esses pla-nos já está disponível, e eles serão de ex-tremo valor para a construção do plano doprojeto. Conforme já visto, esses planos têmcomo objetivo administrar e controlar de-terminadas áreas do projeto de maneiraformal, descrevendo os procedimentos queserão utilizados para gerenciar todo oescopo, a qualidade e as comunicações.

Maiores detalhes sobre os planos podem serencontrados nos capítulos das áreas do ger-enciamento de projetos.

442/641

1.75Criar a Lista deAtividades para osElementos do WBS (18)

Após definida a EAP, é importante que todosos pacotes de trabalho sejam estratificadosem suas atividades ou tarefas (nível deesforço).

Atividades são as etapas ne-cessárias para se completar umprojeto. São executadas em umasequência caracterizada pelanatureza do projeto. As atividadespodem ocorrer sequencialmenteou simultaneamente.

Muitas vezes essa etapa é feita concomitante-mente com as definições dos pacotes de tra-balho (etapa anterior). A maioria dos progra-mas de computador destinada a esse fimtrata os dois processos como um só, a serem

realizados em conjunto, ou seja, o projeto vaisendo decomposto até que todas as etapas eentregas sejam atingidas.

Os principais tipos de atividades são:

• atividades executivas ou tarefas(Tasks);

• marcos ou entregas (Milestones);

• atividades-resumo ou pacotes de tra-balho (Summary Tasks).

1.75.1Atividades Executivas ouTarefas

São as atividades relacionadas diretamentecom a ação dentro do projeto.

Exemplos de atividades executivas:

• embalar computadores;

• limpar o terreno;

• digitar o relatório de compras;

• revisar um artigo.

444/641

1.75.2Marcos ou Entregas(Milestones)

O marco representa um evento, ou condição,que marca a execução de um grupo de ativid-ades relacionadas entre si, ou o término deuma fase de projeto. Servem, também, paraidentificar as entregas dos pacotes de tra-balho e não possuem duração. É tambémchamado de etapas.

Exemplos de marcos:

• telhado pronto (entrega);

• testes do produto realizados;

• recebimento da 3ª parcela.

1.75.3Atividades-Resumo ouPacote de Trabalho (SummaryTasks)

São atividades que englobam outras ativid-ades, denominadas subatividades. Elas

445/641

representam um conjunto de atividades, to-talizando duração, datas e custos das ativid-ades a elas pertencentes. As atividades de re-sumo também podem ser chamadas de pa-cotes de trabalho.

Exemplos:

• fase de planejamento;

• construção do alicerce da casa;

• desenho do protótipo do produto;

• fase de Design.

A decomposição do pacote de trabalho ematividades e entregas pode ser visualizada nafigura a seguir.

446/641

Figura 4.4 – Decomposição do Pacote de Trabalho

em atividades e entregas

447/641

1.76Determinar a Duraçãodas Atividades do Projeto(19)

Essa etapa tem por objetivo calcular ou de-terminar, corretamente, a quantidade detempo necessária para executar cada ativid-ade para que, ao ser integrante de um crono-grama, possa determinar a duração do pro-jeto. Essa etapa é conduzida em paralelo àalocação de recursos nas atividades, uma vezque existe uma dependência intrínseca entreduração e quantidade de recursos.

A duração de uma atividade é otempo necessário para que aatividade possa ser realizada.Pode ocorrer em semanas, dias,horas e minutos, dependendo decada projeto.

Para se calcular a duração do projeto, é ne-cessário que se conheçam todos os recursosalocados na atividade e a produtividade decada um deles.

Segundo Lewis, estima-se que, em um pro-jeto, o tempo perdido em atividades não liga-das a ele é de 40% do tempo total. Esse con-ceito é denominado Fator de Produtivid-ade. Não se deve ser surpreso quando, aoalocar um recurso em um projeto comhorário integral (full time), perceber que, naverdade, o recurso trabalhará apenas quatroou cinco horas por dia. O uso do fator deprodutividade no cálculo do tempo ne-cessário para o recurso completar a atividadetorna a estimativa mais realista.

1.76.1Atividades com DuraçãoFixa x Atividades Orientadas paraRecursos

449/641

Ao alocar um recurso em uma atividade,deve-se avaliar se o recurso influencia, demaneira direta ou não, a duração da ativid-ade. Se um recurso não influencia a duraçãode uma atividade, essa atividade é denomin-ada de duração fixa (fixed duration). Se umrecurso influencia a duração de uma ativid-ade, essa atividade é denominada de ori-entada para recurso (resource driven). Asatividades que são orientadas para recursosreduzem sua duração com o acréscimo naquantidade de recursos, isto e,

Figura 4.5 – Atividades com duração fixa e ori-

entada para recursos

450/641

Observa-se, pela figura anterior, que ativid-ades com duração fixa não são beneficiadaspor acréscimos na quantidade de recursos.Já atividades com duração orientada para re-cursos são muito beneficiadas por umaumento na quantidade de recursos.

A orientação para recursos tem um limite devalidade lógico, de forma que, depois de pas-sado esse limite, um aumento de recursosnão provoca redução na duração da atividadee, em casos extremos, pode até aumentar aduração da atividade. Por exemplo, se umpedreiro constrói uma parede em 4 dias, é deesperar que 2 pedreiros a construirão em 2dias. Porém, é absurdo considerar que 5000pedreiros construirão a parede em 23segundos.

O quadro a seguir compara durações fixas eorientadas para recursos.

451/641

Figura 4.6 – Exemplo de comportamento fixo e ori-

entado para recursos para as atividades

O ato de aumentar a quantidade de recursosa fim de reduzir a duração de uma atividadeé denominado Compressão ou Crashing econstitui uma das formas mais populares decompressão de duração de atividades.

1.76.2Análise PERT

Outro processo fundamental no cálculo daduração das atividades é a análise PERT,onde a duração de cada atividade é calculadaatravés da estimativa da duração otimista,pessimista e mais provável da atividade. Aduração única final da atividade será determ-inada através da média ponderada das trêsestimativas.

452/641

Os pesos de cada tipo de duração podemvariar de acordo com o projeto. Porém, a re-lação mais comum é de 1, 4 e 1 para a dur-ação otimista, mais provável, e pessimista,ou seja,

A análise PERT possibilita uma precisãomuito maior ao se estimarem durações deatividades.

A análise PERT é utilizada em conjunto coma distribuição normal para determinar aprobabilidade que o projeto tem de ser con-cluído em um determinado prazo, sendo esseprocesso extremamente importante no ger-enciamento de riscos.

Análises estatísticas mais sofisticadas podemser realizadas, tais como cálculos de desvio-padrão, aproximação por curvas estatísticas,simulação de Monte Carlo, etc.

453/641

1.76.3Outras Considerações Sobrea Duração das Atividades

Uma atividade pode utilizar recursos emhorário integral, ou em horários parciais. Re-cursos pouco qualificados, ou pouco espe-cializados (operários em geral), devem serutilizados, sempre que possível, em horáriosintegrais, evitando-se, assim, a perda detempo na troca das atividades, uma vez que oseu trabalho não é especializado. Os recursosaltamente especializados e técnicos (con-sultores) ou recursos de supervisão (chefes egerentes) devem ser utilizados em trabalhosparciais, característicos de supervisão, umavez que sua presença não é exigida durantetodo o tempo da atividade e, por apresentarum custo elevado, necessita ser mais bemaproveitada.

Os mecanismos mais comuns para alocaçãode recursos são as matrizes de atribuição de

454/641

responsabilidades. Elas resolvem um dosproblemas frequentes de gerenciamento deprojetos, que é converter as relações hierár-quicas dos organogramas funcionais em re-lações dinâmicas dentro do projeto.

Figura 4.7 – Matriz de Atribuição de

Responsabilidades

455/641

1.77Identificar e Selecionaros Recursos e Profissionaispara o Projeto (20)

A finalidade dessa etapa é identificar todosos recursos que serão necessários para oprojeto, selecioná-los de modo que eles es-tejam disponíveis para realizar as atividadesdo projeto. Os profissionais (recursos hu-manos) vão ser selecionados segundo oscritérios estabelecidos no plano de geren-ciamento de recursos humanos.

Os recursos são todas as pessoas,materiais de consumo e equipa-mentos necessários para a realiz-ação da atividade.

Na escolha dos recursos, o gerente de projetodeve atentar para diversos fatores, dentreeles,

• disponibilidade do recurso,

• custo,

• capacitação (profissionais),

• qualidade (equipamentos e materiais).

Os recursos se subdividem nas seguintescategorias:

• mão de obra (profissionais),

• materiais,

• equipamentos.

São exemplos de recursos

• pintores,

• areia,

• computadores,

• veículos,

• papel,

• programadores.

Dinheiro não deve ser considerado recurso.O capital e o custo de uma atividade estãoagregados ao custo dos recursos nela en-volvidos, a não ser que se esteja tratando dedinheiro físico (notas e moedas) que vão serempregados como recurso físico no projeto(revestir uma parede de moedas para decor-ar um escritório, por exemplo).

457/641

458/641

1.78Alocar Recursos nasAtividades (21)

Após serem determinados os recursos queserão empregados no projeto, é preciso queesses recursos sejam atribuídos a cadaatividade do projeto. É um processo trabal-hoso e demorado, mas é a base de todo o cál-culo de orçamentos e custos do projeto, bemcomo a única maneira de gerenciar a dispon-ibilidade/alocação de cada recurso do pro-jeto, calcular os estoques e gerenciar o re-curso humano do projeto.

Alocar recursos nas atividades exige exper-iência do gerente de projeto. Para isso, o ex-ecutivo deve contar com o apoio e a exper-iência de todos os envolvidos no projeto, an-alisar outros projetos e consultar dadoshistóricos.

A alocação de recursos pode também ser cal-culada através de dados estatísticos e ensaiosem pequena escala (piloto).

460/641

1.79Criar o Plano deGerenciamento de Pessoal(22)

Nesse momento é criado o plano de geren-ciamento de pessoal, onde todos os recursosalocados são apresentados, incluindo polític-as de RH, remuneração e treinamento, bon-ificação, organogramas, matrizes de re-sponsabilidades, diretórios do time do pro-jeto, etc.

Maiores detalhes sobre o plano de geren-ciamento de recursos humanos podem serencontrados no capítulo das áreas do geren-ciamento de projetos (Parte III).

1.80Inter-relacionar asAtividades e DefinirPrecedências (Diagramade Rede) (23)

O objetivo desta etapa do projeto é associaras atividades, estabelecendo precedênciaspara que atividades interdependentes sejamidentificadas e o cronograma do projeto sejadeterminado.

Uma atividade que comece ou finalize antesque outra atividade possa começar é cha-mada predecessora. Uma atividade que de-penda do início ou do final de outra atividadeé chamada sucessora.

Além das dependências, as atividades podemter atrasos ou adiantamentos intencional-mente provocados, de modo a permitir umintervalo de tempo entre a predecessora e a

sucessora, ou até mesmo uma sobreposiçãoentre elas.

1.80.1Definições

Para se definir o inter-relacionamento entreas atividades de um projeto, é importanteque se definam alguns parâmetros import-antes relativos ao cronograma do projeto.São eles:

• o início do projeto,

• o término do projeto,

• o início da atividade,

• o término da atividade,

• os calendários,

• os feriados e dias especiais.

Início do Projeto - É a data de início doprojeto, isto é, o primeiro dia da primeiraatividade a ser desenvolvida. Normalmente,é definida no objetivo do projeto (projetoscalculados do início para o fim), mas pode

463/641

ser calculada a partir da data de término doprojeto (projetos calculados do fim para oinício).

Término do Projeto - É a data de términodo projeto, isto é, o último dia da últimaatividade a ser desenvolvida. Normalmente,é calculada pelo projeto (projetos calculadosdo início para o fim), mas pode ser definida(projetos calculados do fim para o início).

Início da Atividade - É a data e a hora emque a atividade se inicia. Pode ser um dadofixo do projeto ou calculada em consequên-cia de suas atividades predecessoras.

Término da Atividade - É a data e a horaem que a atividade termina. Normalmente, écalculada a partir da data de início da ativid-ade e de sua duração.

Calendários - Os calendários são utilizadospara determinar e selecionar os dias de tra-balho, ou folga, do projeto. Os calendáriostambém devem ser utilizados para indicar

464/641

horas específicas de trabalho para um de-terminado recurso.

Feriados e Dias Especiais - Devem sersempre inseridos para que não ocorram er-ros no gerenciamento das atividades. Diascom expediente especial (véspera de Natal eAno Novo, etc.), além de dias em que nãoserão desenvolvidas atividades no projetodeverão ser considerados dias especiais, ouferiados, no projeto.

Um projeto pode ter datas especiais paradiferentes participantes do projeto, taiscomo férias, dispensas, etc.

1.80.2Restrições de Datas nasAtividades

As atividades podem ter diversos tipos de re-strições quanto ao início ou ao término desua execução. Essas restrições devem ser as-sociadas aos tipos de interdependênciasentre as atividades. São elas as seguintes:

465/641

• atividade que se inicia o mais rápidopossível (as soon as possible);

• atividade que se inicia o mais tardepossível (as late as possible);

• atividade que se inicia não antes de umdeterminado dia (start no earlier than);

• atividade que se inicia não depois deum determinado dia (start no laterthan);

• atividade que se inicia obrigatoria-mente em uma data (must start on);

• atividade que se conclui, obrigatoria-mente, em uma data (must finish on).

1.80.3Tipos deInter-relacionamentos

As atividades podem ser inter-relacionadasde várias formas. As principais formas deinter-relacionamento são:

466/641

• término para início – TI (finish to start– FS);

• início para início – II (start to start –SS);

• término para término – TT (finish tofinish – FF);

• início para término – IT (start to finish– SF).

Término para Início (Finish to Start –FS) - A atividade sucessora somente se ini-cia com o término da atividade prede-cessora. Exemplo: O telhado de uma casasomente pode ser construído quando asparedes tiverem sido erguidas.

Figura 4.8 – Relação de Término para Início (TI ou

FS)

467/641

Início para Início (Start to Start – SS) -A atividade sucessora somente se inicia como início da atividade predecessora. Essa re-lação faz com que duas atividades ocorramsimultaneamente e resulta, na maioria dasvezes, em economia de tempo e dinheiro. Porexemplo, ao instalar uma rede decomputadores, pode-se programar o inícioda instalação física dos cabos com a in-stalação lógica dos computadores para queocorram simultaneamente.

Figura 4.9 – Relação de Início para Início (II ou SS)

Término para Término (Finish to Fin-ish – FF) - A atividade sucessora somentetermina com o final da atividade prede-cessora. Essa relação faz com que as ativid-ades se finalizem sincronizadas. Por exem-plo, um computador somente pode ser

468/641

considerado pronto quando as cópias de se-gurança dos dados tiverem sido realizadas.Isso significa que a atividade de preparo docomputador ficará pendente até que as cópi-as dos dados de segurança estejam prontas.

Figura 4.10 – Relação de Término para Término

(TT ou FF)

Início para Término (Start to Finish –SF) - Relação pouco usual. Ocorre quando ofim de uma atividade depende do início deuma atividade anterior. Funciona de formainversa à relação Término para Início. É util-izado para substituições de procedimentosou equipamentos. Por exemplo, umaempresa está substituindo sua centralelétrica antiga por outra mais moderna. Acentral antiga deve permanecer funcionandoaté que a central nova esteja em pleno

469/641

funcionamento. O problema não consiste emdesligar a central antiga, mas, sim, em fazercom que a central nova funcionecorretamente.

Figura 4.11 – Relação de Início para Término (IT ou

SF)

1.80.4Defasagem e Adiantamentoentre as Atividades

Outro aspecto fundamental para o entendi-mento dos inter-relacionamentos entre asatividades em um projeto é o conceito de de-fasagem e adiantamento.

Diversas atividades em um projeto necessit-am de um intervalo de tempo após a realiza-ção de sua predecessora, não podendo se ini-ciar logo após a atividade anterior como, por

470/641

exemplo, as atividades de secagem, envelhe-cimento, amadurecimento, etc., que necessit-am de um tempo mínimo de espera para oprosseguimento do projeto. Atividades de es-pera são dadas, na maioria das vezes, emdurações corridas, incluindo as horas em queo projeto não trabalha (sábados, domingos,feriados, noites, etc.).

Figura 4.12 – Relacionamento entre atividades in-

cluindo defasagens (atrasos)

Os adiantamentos funcionam inversamenteaos atrasos. Seu objetivo é adiantar o crono-grama do projeto, favorecendo a realizaçãode atividades em paralelo. A técnica de re-duzir a duração do projeto através dos adian-tamentos é denominada Paralelismo ou fasttracking

471/641

Figura 4.13 – Relacionamento entre atividades adiantadas

entre si

1.80.5Diagrama de Rede

O inter-relacionamento entre as atividadesdo projeto compõe um todo organizado, de-nominado diagrama de rede, ou vulgarmenteconhecido como rede PERT (ProgramEvaluation and Review Technique). O dia-grama de rede evidencia os inter-relaciona-mentos entre as atividades no projeto global.

O diagrama de rede tem sua origem no meiomilitar, com uma associação entre a marinhae as empresas Lockheed & Booz e Allen &Hamilton, em 1958, no desenvolvimento dosprojetos de construção da série de

472/641

submarinos atômicos Polaris do governonorte-americano.

As vantagens do diagrama de rede são asseguintes:

• simples entendimento;

• interdependência entre as atividadesbem-definida.

As desvantagens do diagrama de rede são asseguintes:

• apresenta relatórios muito extensos;

• não mostra uma relação visual entre asdurações das atividades;

• é de difícil manipulação.

Existem dois tipos de diagramas de rede, quesão:

• AOA (Activity on Arrow) - ap-resenta o diagrama com atividades rep-resentadas por setas que ligam um es-tado inicial a um estado final. Éempregado principalmente quando segerenciam projetos sem o computador.

473/641

Figura 4.14 – Rede PERT AOA

• AON (Activity on Node) - ap-resenta as atividades nos nós entre assetas. É a visualização mais comum atu-almente, por ser gerada automatica-mente pela maioria dos softwares degerenciamento de projetos.

Figura 4.15 – Rede PERT AON

1.80.6Diagrama de Gantt

474/641

Outra forma muito comum de representaçãográfica para cronogramas é o diagrama deGantt, ou diagrama de barras. O diagramautiliza barras horizontais, colocadas dentrode uma escala de tempo. O comprimento re-lativo das barras determina a duração daatividade. As linhas conectando as barras in-dividuais em um Diagrama de Gantt re-fletem as relações entre as atividades.

O diagrama de Gantt é a mais antiga técnicade administração de projetos. Foi criado porHenry Gantt no início do século, com o ob-jetivo de atender a fins militares eestratégicos.

Figura 4.16 – Diagrama de Gantt

475/641

As principais vantagens do Diagrama deGantt são as seguintes:

• simples entendimento;

• visualização de atrasos com facilidade;

• escala de tempo bem definida.

Suas principais desvantagens são asseguintes:

• inadequação para grandes projetos;

• difícil visualização de dependências;

• vaga descrição de como o projeto reagea alterações de escopo.

O diagrama de Gantt é a visualização-padrãoda maioria dos softwares de gerenciamentode projetos.

476/641

1.81Fazer a Conciliação dosRecursos Superalocadosou Indisponíveis (24)

Após terem sido concluídos o cálculo da dur-ação das atividades, a alocação de recursos eos inter-relacionamentos entre as atividades(etapas 19, 21 e 23), é necessário verificar senenhum recurso está alocado em quantidadesuperior ao limite máximo disponível paraaquele período.

A figura a seguir mostra o recurso João emconflito nas atividades A e B (supondo queele não está alocado parcialmente nessasatividades, o que retiraria o conflito).

Figura 4.17 – Recurso João superalocado nas ativid-

ades A e B

Existem diversas formas de se conciliar o re-curso superalocado na figura anterior.Dentre as mais importantes, podem-sedestacar as seguintes:

• substituição do recurso por outro sim-ilar que esteja disponível;

• troca da escala de trabalho do recursosuperalocado;

• realização de trabalho em regime dehoras-extras;

• nivelamento ou redistribuição derecursos.

1.81.1Substituição do Recurso porOutro que Esteja Disponível

Significa substituir o recurso em conflito dealocação por outro que possua,

478/641

aproximadamente, a mesma qualificaçãopara realizar o trabalho e que estejadisponível no período.

Figura 4.18 – Recurso João substituído pelo recurso

Roberto na atividade B

Tabela 4.1 – Vantagens e desvantagens da substitu-

ição de recursos

1.81.2Troca da Escala de Trabalho

479/641

Significa fazer com que o recurso superalo-cado trabalhe em uma jornada maior dur-ante o período problemático e folgue posteri-ormente, formando um banco de horas detrabalho.

Figura 4.19 – Recurso João trabalhando em escala

especial na semana 01 e folgando na se-

mana 02

480/641

Tabela 4.2 – Vantagens e desvantagens da troca da

escala de trabalho

1.81.3Regime de Trabalho emHoras-Extras

Significa fazer com que o recurso superalo-cado trabalhe em regime de horas-extrasdurante o período em que está sendo super-alocado, sendo remunerado de forma difer-enciada por esse esforço.

Figura 4.20 – Recurso João trabalhando em regime

de horas-extras na semana 01

481/641

Tabela 4.3 – Vantagens e desvantagens do trabalho

em horas-extras

1.81.4Nivelamento de Recursos

É a forma mais comum de se resolveremproblemas que envolvem alocação de re-cursos. Consiste em atrasar as atividades se-gundo critérios de prioridades, restrições ouduração previamente determinados, demodo a retirar o sincronismo que possa exi-stir entre as atividades que possuem recursossuperalocados. O nivelamento normalmenteatrasa o término do projeto.

O algoritmo utilizado para o nivelamento derecursos é mostrado a seguir.

482/641

Figura 4.21 – Algoritmo do nivelamento de recursos

483/641

Como exemplo de nivelamento de recursos,tem-se o diagrama de Gantt.

Figura 4.22 – Diagrama de Gantt do projeto antes e

depois do nivelamento

Tabela 4.4 – Vantagens e desvantagens do nivela-

mento de recursos

484/641

1.81.5Conclusão

É importante ressaltar que não existe umaestratégia correta para se conciliarem os re-cursos. Cada caso deve ser estudado isolada-mente e, em projetos complexos, a análisecorreta da melhor técnica de conciliação derecursos pressupõe o uso de praticamente to-das as estratégias.

485/641

1.82Calcular o CaminhoCrítico (CPM) (25)

Esta etapa é a responsável por determinar ocaminho crítico do projeto que é constituídopelas atividades mais importantes do pro-jeto. Qualquer atraso nas atividades do cam-inho crítico implica um atraso no término doprojeto. A duração do caminho crítico inter-fere diretamente na duração do projeto.

O caminho crítico também é defin-ido como o caminho com a menorfolga de tempo possível (usual-mente zero) e determina a dur-ação do projeto.

As atividades que compõem o caminhocrítico são chamadas atividades críticas e,se atrasadas, causam um atraso na execuçãodo projeto. As modificações de tempo ematividades não críticas não têm efeito sobre adata de término do projeto.

Alguns softwares de gerenciamento de proje-tos permitem que se determinem caminhoscríticos que não necessariamente tenhamfolga zero. Nesse caso, é possível se estabele-cerem outras regras para o caminho crítico,como por exemplo identificar como críticatoda atividade que tenha folga menor do quetrês dias.

1.82.1Definições Importantes

Para que se compreenda melhor o caminhocrítico, é importante que se conheçam algu-mas definições. São elas as seguintes:

• início mais cedo de uma atividade;

• início mais tarde de uma atividade;

• término mais cedo de uma atividade;

• término mais tarde de uma atividade;

• folga livre (individual);

• folga total.

487/641

Início mais cedo de uma atividade - É adata de início mais otimista da atividade,sem que tenha ocorrido nenhum atraso, to-dos os passos anteriores tenham sido realiza-dos adequadamente e todas as interde-pendências com as predecessoras,respeitadas.

Início mais tarde de uma atividade - Éa data de início mais pessimista da ativid-ade, sem que, no entanto, o projeto seja pre-judicado no todo, isto é, é a última data emque se pode iniciar a atividade sem se preju-dicar o projeto.

Término mais cedo de uma atividade -É a data de término mais otimista para aatividade, não utilizando nenhuma folga.

Término mais tarde de uma atividade -É a última data para o término da atividadesem comprometer o término do projeto.

488/641

Folga Total - É a folga de tempo de umaatividade que não provoca nenhum atraso noprojeto, podendo, no entanto, alterar asatividades sucessoras, desde que essas nãosejam atividades críticas. Quando umaatividade que possui folga total utiliza toda asua folga para realizar o trabalho, ela força,automaticamente, que todas as atividadesdiretamente sucessoras a ela se tornematividades críticas (folga zero), pois a folgaindividual de cada uma delas foi utilizadapela predecessora na realização de seutrabalho.

O valor da folga total é dado pela diferençaentre o início mais tarde e o término maistarde da atividade, ou seja,

489/641

Figura 4.23 – Folga total para a atividade B é de 5

dias, para a C, de 3, para a D, de 2, en-

quanto a folga para as atividades A e E é

zero

Folga Livre ou Individual - É a folga detempo de uma atividade de modo a não pro-vocar nenhum atraso na atividade sucessora,independentemente dessa atividade ser ounão crítica.

O valor da folga livre é dado pela diferençaentre o início mais cedo da atividade su-cessora e o término mais cedo da atividadepredecessora, ou seja,

490/641

Figura 4.24 – Diagrama de Gantt e folga livre ou in-

dividual de 2 dias para a atividade B, de 1

dia para a atividade C e de 2 dias para a

atividade D

Finalmente, após se determinarem todas asdatas e folgas, pode-se construir o caminho

491/641

crítico, destacando-se a cadeia de atividadesque apresenta menor folga ou folga zero.

Figura 4.25 – Caminho crítico de um projeto (A e E

são críticas)

492/641

1.83Desenvolver oCronograma do Projeto(26)

Esta etapa tem como objetivo determinar ex-atamente qual a data de início e término decada atividade, uma vez que os recursos, asdurações e as interdependências já estãoestabelecidos.

O cronograma do projeto pode ser ap-resentado de diferentes formas, porém asmais comuns são:

• Diagrama de rede,

• Tabelas com listas de atividades,

• Gráfico de Gantt,

• Gráfico de marcos ou etapas.

Os detalhes que suportam o cronogramatambém são produzidos nessa etapa, como,por exemplo, a tabela de alocação dos

recursos e reservas de contingência, dentreoutros.

494/641

1.84Criar o Plano deGerenciamento de Prazos(27)

Logo após a criação do cronograma, é im-portante que se estabeleça um plano de ger-enciamento de prazos, uma vez que todos osprocedimentos de controle do tempo no pro-jeto passam a ser fundamentais depois de es-tabelecido o cronograma.

Maiores detalhes sobre o plano de geren-ciamento de prazos podem ser obtidos nocapítulo sobre as áreas do gerenciamento deprojetos, apresentado anteriormente.

1.85Calcular o Custo dasAtividades e do Projeto(Orçamento) (28)

Custo é a quantidade de capitalnecessária para se realizar umaatividade ou um projeto.

O custo de uma atividade é calculado como asoma dos custos dos recursos envolvidos naatividade com os custos indiretos da ativid-ade (custos de supervisão, etc.).

1.85.1Custos de Recursos

Existem duas formas de se atribuírem custosa um recurso:

• custo por empreitada (custo por uso);

• custo variável por hora de trabalho.

O custo por empreitada é utilizado para re-cursos que irão cobrar por um determinado

trabalho, independentemente do tempo quese gaste para fazê-lo. Também é utilizadopara materiais que serão consumidos peloprojeto.

O custo variável por hora de trabalho é at-ribuído a recursos que serão remuneradospor hora trabalhada, podendo, inclusive, in-cluir os custos decorrentes de horas-extras.Para recursos do tipo equipamentos, o custopor hora deve ser o valor da depreciação dobem ou do aluguel por hora de utilização.

Como exemplo, pode-se contratar um engen-heiro para fazer o cálculo estrutural de umaobra e ele ser remunerado pelo trabalho real-izado (custo por empreitada).

Outro exemplo é quando um operário trabal-har em um projeto complexo e grande, sendoremunerado através de seu salário mensal. Ocusto desse operário deve ser incluído noprojeto como custo variável por hora de tra-balho. O custo por hora é encontrado pela di-visão do salário mensal pelas horas

497/641

trabalhadas no mês, sem deixar de consider-ar os efeitos de produtividade do recurso.

1.85.2Custos Indiretos

Outra parte do custo da atividade muito importantesão os custos indiretos, provenientes dainfraestrutura administrativa e de staff do projeto.Todos os funcionários da supervisão, daadministração, bem como todos os custos deinstalações físicas do projeto, precisam serincluídos como custo indireto.

1.85.3Estimativa de Custos porPacotes de Trabalho

O WBS pode ser usado para estimativas decustos das fases do projeto e até de todo oprojeto. O custo da fase é a soma dos custosdas atividades a ela pertencentes. O custototal do projeto é a soma dos custos de suasfases. Esse processo também é conhecidocomo Bottom Up estimating.

498/641

Figura 4.26 – WBS como ferramenta para o cálculo

do custo do projeto

1.85.4Orçamento

Orçamentos são as atribuições financeirasdos recursos necessários para se completar oprojeto, normalmente expressos em unid-ades monetárias. A maioria dos orçamentosé dada através de tabelas, como a exibida aseguir.

499/641

Figura 4.27 – Exemplo de orçamento distribuído

por atividade e por tipo de custo

1.85.5Fluxo de Caixa

Uma das formas mais importantes de se an-alisarem os custos dos projetos é através dofluxo de caixa, ou fluxo de desembolso doprojeto. Ele associa os custos de cada ativid-ade ao cronograma do projeto, permitindoque se analisem o desembolso médio e ocusto médio de cada atividade do projeto. Étambém conhecido como cost baseline.

500/641

Figura 4.28 – Exemplo de fluxo de caixa de um

projeto

501/641

1.86Criar Planos deCustos, Riscos e Aquisições(29, 30 e 31)

Essas etapas têm como objetivo finalizar osplanos restantes do projeto, uma vez que to-das as informações necessárias para essesplanos já estão disponíveis; e é necessárioque se tenha esses planos para que o planodo projeto seja estabelecido. Conforme jávisto, esses planos têm como objetivo admin-istrar e controlar determinadas áreas do pro-jeto de maneira formal, descrevendo os pro-cedimentos que serão utilizados para geren-ciar os custos, os riscos e os suprimentos doprojeto.

Maiores detalhes sobre os planos de geren-ciamento de custos, riscos e suprimentos po-dem ser obtidos no capítulo sobre as áreasdo gerenciamento de projetos, apresentadoanteriormente.

503/641

1.87Desenvolver o Plano deGerenciamento do Projeto(32)

Esta etapa tem como objetivo desenvolverum documento formal que será utilizadopara gerenciar e controlar a execução do pro-jeto, sendo distribuído conforme estabele-cido no plano de gerenciamento dascomunicações.

O Plano Global do Projeto deve conter:

• a visão geral dos objetivos, metas eescopo do projeto de uma maneira re-sumida e macro para atender aos altosexecutivos do projeto (pequena in-trodução do assunto);

• o objetivo detalhado do projeto paraatender ao gerente do projeto e ao timedo projeto;

• o nome e as responsabilidades do ger-ente e do time principal do projeto (mat-riz de responsabilidades);

• o organograma do projeto;

• estudo técnico da solução a ser adot-ada pelo projeto;

• aspectos contratuais quanto à parti-cipação de elementos externos aoprojeto;

• Estrutura Analítica do Projeto ouWork Breakdown Structure (WBS);

• cronogramas;

• diagrama de Gantt;

• diagrama de rede;

• principais marcos com suas datas;

• utilização de recursos pelo projeto (re-latório com as funções);

• orçamento, análise de custos e fluxosde caixa;

505/641

• necessidade de contratação e treina-mento de pessoal;

• formas previstas de avaliação dos ín-dices de qualidade e desempenho a ser-em atingidos pelo projeto;

• potenciais obstáculos a serem en-frentados pelo projeto e possíveissoluções;

• lista de pendências;

• planos das áreas de conhecimento:

• Plano de Gerenciamento de Escopo;

• Plano de Gerenciamento de Prazos(Tempo);

• Plano de Gerenciamento de Custos;

• Plano de Gerenciamento da Qualidade;

• Plano de Gerenciamento de RecursosHumanos;

• Plano de Gerenciamento dasComunicações;

• Plano de Gerenciamento de Riscos;

506/641

• Plano de Gerenciamento deAquisições.

A maioria dos softwares utilizados para ogerenciamento de projetos facilita muito acriação do plano de gerenciamento do pro-jeto, uma vez que a maior parte das inform-ações aqui necessárias já foi calculada poreles em etapas anteriores.

507/641

1.88Aprovação do Plano deGerenciamento do Projeto(33)

Após ter sido criado o plano do projeto,torna-se necessária a aprovação formal doplano operacional por todos os envolvidos,incluindo clientes, fornecedores e outros ele-mentos da organização. Essa aprovação deveser realizada através de uma reunião e pos-terior aprovação por escrito, autorizando oinício da execução do projeto.

No caso de não aprovação é preciso que oplano do projeto seja revisto, caso essa açãoseja possível. Caso contrário, o projeto podeser abortado ou redefinido (passo 33A -Rever viabilidade do projeto ou abortar).

1.89Arquivar o Plano deGerenciamento do Projetono Livro Geral do Projeto(Linha de Base) (34)

O plano do projeto e todos os seus docu-mentos complementares devem ser arquiva-dos no livro geral do projeto para posteriorutilização como base de referência(baseline).

FASE DEEXECUÇÃO EFASE DECONTROLE

1.90Executar o Pacote deTrabalho (Atividades) (35)

A execução do projeto consiste na realizaçãodas atividades previstas no plano do projeto.A execução é feita através da realização dospacotes de trabalho (work package). O pa-cote de trabalho é considerado concluídoquando ocorre a entrega (delivery). A en-trega é qualquer resultado do trabalho quepode ser facilmente medido pelo projeto.Tem as seguintes características:

• facilmente mensurável;

• tangível pelos executantes;

• conclusão identificável de maneirasimples e direta.

A finalização de todos os pacotes de trabalhoe a realização de todas as entregas do projetorepresentam a conclusão do projeto.

É fundamental ressaltar que a ex-ecução dos pacotes de trabalhomaterializa todo o planejamentodo projeto e, portanto, todas asfalhas cometidas em etapas an-teriores ficam evidentes durante aexecução.

512/641

1.91Executar AtividadesAuxiliares: Aquisições,Recursos Humanos,Comunicações e Qualidade(36)

Em paralelo à execução dos pacotes de tra-balho, uma série de atividades é necessáriapara garantir que os processos de controle ereplanejamento sejam eficazes.

Baseado nos processos estabelecidos noPMBOK, podem ser estabelecidos osseguintes processos, por área:

Comunicações – Durante a execução doprojeto, é importante que as informações se-jam distribuídas aos interessados no prazo ena profundidade desejada, conforme es-tabelecido no plano de comunicações. Alémdisso, todas as atividades relacionadas ao

gerenciamento das expectativas dos in-teressados devem ser realizadas.

Recursos Humanos – Três dos quatroprocessos de recursos humanos descritos noPMBOK são desenvolvidos nesta etapa. Amobilização da equipe permite com que to-dos os recursos humanos necessários para oprojeto estejam disponíveis e prontos para otrabalho. O desenvolvimento do time é real-izado através de treinamento presencial, outreinamento “on the job”, políticas de premi-ação por resultados e atividades que poten-cializam o trabalho das pessoas como umtime. Além disso, todas as atividades rela-cionadas ao gerenciamento da equipe sãorealizadas também.

Qualidade – Nessa etapa também é im-portante garantir que os resultados específi-cos do projeto estejam de acordo com ospadrões de qualidade estabelecidos. Agarantia de qualidade faz essa avaliação, bem

514/641

como identifica causas de resultados insatis-fatórios e meios para eliminá-los.

Aquisições – Parte do processo deaquisições é realizada na execução do pro-jeto, incluindo solicitação de respostas dosfornecedores e a escolha dos fornecedores,conforme estabelecido no plano de geren-ciamento de aquisições.

515/641

1.92Realizar a Análise deValor Agregado paraAvaliação de Desempenho

(37)13

Existem diversas formas de se avaliar odesempenho de um projeto, incluindo anál-ise de variância e tendências, porém a anál-ise de valor agregado é uma das mais pre-cisas e poderosas técnicas disponíveis.

A análise de valor agregado (Earned ValueAnalysis) é a responsável pelo acompan-hamento financeiro de todo o projeto. Elatem como objetivo detalhar os custos do pro-jeto de forma a acompanhar com precisão asevoluções do seu custo.

Valor agregado é um conceito prático esimples que tem foco na relação entre os cus-tos reais consumidos e o trabalho realizado


no projeto. O objetivo está no desempenhoreal obtido com o que foi gasto, ou seja, oque foi obtido pelo projeto em relação aogasto financeiro para atingir aquele res-ultado. O conceito de valor agregado requerque as medidas de despesa-desempenho se-jam estabelecidas dentro de um cronogramafísico do projeto. Então, através da relaçãoentre o valor agregado e o valor planejado dotrabalho dentro do tempo pode dar maiorprecisão ao controle do que apenas controlesfinanceiros ou de prazos isolados. Flemminge Green propõem que o valor agregado fun-ciona como um tipo de “alarme”, permitindoao gerente de projeto avaliar se está consum-indo mais dinheiro para realizar uma de-terminada tarefa, ou se está apenas gastandomais naquele momento porque o desenrolardo projeto está sendo acelerado. Isso per-mitirá que sejam tomadas ações corretivas epreventivas com a devida antecedência.

517/641

1.92.1Conceitos14

Dentro da análise de valor agregado, é im-portante que se conheçam alguns termoscomuns, listados a seguir.

Conceitos de orçamento, custos reais evalor agregado

BCWS ou COTA (custo orçado do tra-balho agendado) – Valor que indica a par-cela do orçamento que deveria ser gasta,considerando o custo de linha da base daatividade, atribuição ou recurso. O COTA écalculado como os custos de linha de base di-vididos em fases e acumulados até a data destatus, ou data atual. É o custo provenientedo orçamento. O PMI utiliza a sigla PV(Planned Value) para representar o BCWS.

BCWP ou COTR (custo orçado do tra-balho realizado) - Valor que indica a par-cela do orçamento que deveria ser gasta,considerando o trabalho realizado até o

518/641



momento e o custo de linha de base para aatividade, atribuição ou recurso. O COTR écalculado como o percentual da atividaderealizada multiplicado pelo seu orçamento. OCOTR também é denominado valoragregado. O PMI utiliza a sigla EV (EarnedValue) para representar o BCWP.

ACWP ou CRTR (custo real do tra-balho realizado) - Mostra os custos reaisincidentes para o trabalho já realizado porum recurso ou atividade, até a data de status,ou data atual do projeto. O PMI utiliza a siglaAC (Actual Cost) para representar o ACWP.

519/641

Figura 5.1 – Exemplo gráfico do BCWS, BCWP e

ACWP ao longo do tempo para um de-

terminado projeto.

Conceitos de análises de variações decusto e prazo

CV ou VC (variação do custo) - É a difer-ença entre o custo previsto para atingir onível atual de conclusão (BCWP) e o custoreal (ACWP), até a data de referência. Se CVfor positiva, o custo do trabalho agregado es-tará aquém do valor realmente gasto (custoreal); se for negativa, a atividade está

520/641

agregando um valor inferior ao que se gastouno trabalho e, continuada essa tendência sig-nificará que o projeto tem uma grande prob-abilidade de ser concluído com um gasto su-perior ao orçado. É traduzido oficialmentepelo PMI como VC ou variação de custos.

SV ou VP (variação de prazos) - É adiferença, em termos de custo, entre o ValorAgregado (BCWP) e a agenda de linha debase (BCWS). Se SV for positiva, o projetoestará adiantado; se for negativa, o projetoestará atrasado. É traduzido oficialmentepelo PMI como VP ou variação de prazos.

TV ou VT (variação de tempo) - É adiferença, em termos de tempo, entre o prev-isto pelo projeto e o realizado. É encontradograficamente pela projeção da curva deBCWS e BCWP, encontrando a data em queo BCWS agrega o mesmo valor de BCWP. Adiferença entre a data de referência e essa

521/641

data representa o atraso ou adiantamento doprojeto. É traduzido oficialmente pelo PMIcomo VT ou variação de tempo.

Figura 5.2 – Análise de Valor Agregado com as de-

terminações de CV, SV e TV

Conceitos de índices de desempenho

SPI ou IDP (índice de desempenho deprazos) – É a divisão entre o valor agregado(COTR) e a agenda da linha de base (COTA).Se o IDP for menor que 1, indica que o pro-jeto está atraso. Se o IDP for maior que 1,

522/641

indica que o projeto está adiantado. Se o IDPfor igual a 1, indica que o projeto está exata-mente no prazo. O IDP mostra a taxa de con-versão do valor previsto em valor agregado.

CPI ou IDC (índice de desempenho decustos) – É a divisão entre o valor agregado(COTR) e custo real (CRTA). Se o IDC formenor que 1, indica que o projeto estágastando mais do que o previsto. Se o IDCfor maior que 1, indica que o projeto estácustando abaixo do orçamento. Se o IDC forigual a 1, indica que o projeto está exata-mente no orçamento. O IDC mostra qual aconversão entre os valores gastos e os valoresagregados no projeto.

523/641

Figura 5.3 – Avaliação dos índices de desempenho

de prazo e custo

1.92.2Exemplo

Para melhor diferenciar o gerenciamento porvalor agregado do gerenciamentotradicional, tem-se um exemplo de um pro-jeto que custe $60 e tenha 4 meses de prazopara execução. Supondo que o gasto do cap-ital seja linear, tem-se um consumo de $15(COTA ou BCWS) em cada mês.

524/641

No final do terceiro mês, o gerente de projetocalcula os gastos do projeto e chega a umtotal de $30 (CRTR ou ACWP). Uma análisefinanceira isolada evidencia que o projeto es-tá $15 abaixo dos gastos previstos (45-30).Isso poderia representar uma percepção deeconomia para o projeto. A grande perguntaa ser feita agora é “Será que todos os 30 fo-ram convertidos em resultados para oprojeto?”

Figura 5.4 – Análise Custo x Tempo Tradicional

Com a análise de valor agregado, torna-senecessária a inserção de um novo dado: os

525/641

ganhos físicos reais ou valor agregado(COTR ou BCWP). Supondo-se que, para osdados anteriormente mencionados, osprodutos obtidos no final do terceiro mêsagregam $25, ou seja, somente $25 deproduto foram produzidos (COTR ouBCWP).

Figura 5.5 – Análise de Valor Agregado

Essa terceira dimensão permite concluir queo projeto está com trabalhos atrasados, umavez que foram agregados trabalhos de apenas$25 dos $45 previstos para esses três meses,estando abaixo do planejado em $20, ouseja, o projeto está atrasado em trabalho em

526/641

$20 (VA ou SV). Essa conclusão é de funda-mental importância, pois proporciona con-clusões diferentes das obtidas pelo geren-ciamento tradicional. Outra conclusão é queo projeto consumiu $30 para agregarsomente $25. Isso representa que, além doatraso nos prazos de execução, tem-se umaumento nos custos do projeto em $5 nesseperíodo (VC ou CV).

Ao se calcularem os índices de desempenho,tem-se que o IPA ou SPI é de 0,555 (55,5%).Isso significa que apenas 55,5% do tempogasto está sendo transformado em resulta-dos, 44,5% do tempo está sendo desper-diçado. Com relação ao índice de desem-penho de custos (IPC ou CPI), tem-se umvalor de 0,833 (83,3%). Isso significa que83,3% do dinheiro gasto foi convertido emresultados e 16,7% do dinheiro está sendodesperdiçado.

527/641

1.93Executar o Controle deEscopo, Tempo, Custos,Qualidade, RH,Comunicação, Riscos eAquisições (38)

Esta etapa tem como objetivo avaliar cadauma das áreas do projeto de modo isolado,procurando identificar variações de forma apossibilitar o controle

1.94Executar o ControleIntegrado de Mudanças(39)

Esta etapa é o centro de todo o processo decontrole do projeto. Seu objetivo é garantirque o projeto está sendo realizado conformeo plano e, no caso de mudanças nele,garantir que elas são benéficas para oprojeto.

Os objetivos do controle geral das mudançassão:

• manter a integridade das linhas debase de desempenho estabelecidas noplano;

• coordenar as mudanças através dasáreas do projeto, garantindo que o todoseja beneficiado. Por exemplo, um atra-so na realização de uma determinadaatividade pode influenciar diretamente

nos custos, nos riscos, na qualidade,etc., do projeto.

É no controle geral das mudanças que o ger-ente do projeto é exigido em seu limite, umavez que o nível de esforço do projeto está emsua plenitude, e é necessária uma avaliaçãoglobal de todos os fatos e suas consequênciaspara que o projeto não entre em um processorápido de degeneração e descontrole.

Praticamente toda a equipe que planejou oprojeto é exigida nessa fase para que se con-siga estabelecer um sistema de controle demudanças.

530/641

1.95Todos os TrabalhosForam Concluídos? (40)

Esta etapa verifica se todos os pacotes de tra-balho foram executados e se todas as entre-gas foram efetuadas. Caso os trabalhos ten-ham sido concluídos, o projeto vai para afase de finalização. Caso contrário, o próx-imo pacote de trabalho deve ser realizado(retorno à etapa 35).

FASE DEENCERRAMENTO

1.96Auditar e Validar oResultado do Projeto como Cliente / Patrocinador(41)

Esta etapa tem como objetivo avaliar o res-ultado do projeto junto ao cliente ou patro-cinador para obter o aceite do projeto.

Na maioria das vezes, a validação dos res-ultados é feita através de auditoria. A audit-oria pode ser definida como o exameanalítico e pericial que segue o desenvolvi-mento de projetos, de modo a avaliar se oresultado obtido está em conformidade como previsto nas suas definições, sendo umsubsídio técnico para o aceite do projeto.

Diversas organizações internacionais são es-pecializadas em auditar projetos de grandeporte, especialmente para órgãos e empresas

do governo, organizações militares emultinacionais.

Lewis propôs um relatório de auditoriasimples para projetos pequenos e simples.Sua elaboração e utilização são fáceis ediretas. O modelo de auditoria simplificado émostrado a seguir.

534/641

Figura 6.1 – Modelo de formulário simplificado para

auditoria de projetos

O produto desse processo é um documentode aceite formalizado pelo cliente ou patro-cinador, garantindo que os produtos do pro-jeto foram atingidos, encerrando a

535/641

responsabilidade direta dos executantes sobo projeto, a não ser em projetos com garantiacontratual estabelecida.

536/641

1.97Discutir as FalhasCometidas Durante oProjeto para Servirem deBase a Futuros Projetos(42)

Com base na auditoria do projeto, deverãoser discutidas as falhas cometidas, de formaa possibilitar o aprendizado para que, emprojetos futuros, essas falhas não voltem aocorrer, e os envolvidos estejam mais capa-citados. Todas as discussões e conclusõesacertadas entre os envolvidos devem ser re-gistradas no livro geral do projeto.

1.98Encerrar os ContratosPendentes (43)

Antes de se concluir o projeto, é importanteque todos os contratos criados durante ostrabalhos sejam liquidados, com exceção doscontratos que se referem a serviços posteri-ores ao projeto, tais como serviços degarantia e manutenção. Essa etapa evita quependências relativas ao projeto sejam manti-das após seu término.

1.99Desmobilizar o Time ea Estrutura do Projeto (44)

Antes de se concluir o projeto, é importanteque todo o time seja desmobilizado, bemcomo toda a estrutura de escritórios, equipa-mentos e administração do projeto. Em pro-jetos que envolvem um número elevado derecursos humanos durante sua execução, amaioria deles é desmobilizada imediata-mente após o término dos serviços, paraevitar um aumento nos custos relativos àequipe.

1.100Finalizar o Livro doProjeto e Ter o ProjetoConcluído (45 e 46)

Depois de todas as discussões sobre o pro-jeto, o livro geral do projeto deve ser con-cluído, levando a assinatura dos envolvidos.O livro geral do projeto deve ser arquivadona biblioteca da empresa, ou em outra áreapredefinida para arquivamento de projetos.

2. QUESTÕESPARAREVISÃO

1. Quem deve preparar o Termo deAbertura? Justifique.

2. Diferencie a Declaração de Escopo doTermo de Abertura.

3. Diferencie pacote de trabalho de di-cionário da WBS.

4. Explique os dois mecanismos maisutilizados na redução de prazos emprojetos.

5. Explique como a adição de recursosem uma atividade pode ou não reduzirsua duração.

6. Quais são as principais técnicas pararesolver problemas de alocação derecursos?

7. O que deve estar contido no plano degerenciamento de riscos?

8. Qual a importância do controle integ-rado de mudanças?

9. Qual a importância da auditoria nosprojetos?

542/641

3. PALAVRACRUZADA

544/641

- ANEXO I – UMANOVA VISÃO DO

PMBOK® GUIDE 2000

Trabalho apresentado em novembro de 2001

durante o 29th Annual Project ManagementInstitute Seminars & Symposium em

Nashville. Original em inglês.

Esse trabalho serviu como base para asmudanças propostas pelo PMI para o

PMBOK 4ª Edição, onde o capítulo 3 é ap-resentado por grupo de processos e não por

área de conhecimento.

A New Approach to PMBOK® Guide2000

Ricardo Viana Vargas, PMP

Introduction

This work puts forward a new approach to

PMBOK® Guide in which the thirty-nineprocesses are organized in five groups: initi-ation, planning, executing, controlling andclosing process. This arrangement suggests achronologically structured, more didacticview, which has been successfully tested intwo PM classes in Brazil, instead of theformer organization in nine KnowledgeAreas. This approach is also useful to PMPexam preparation where two hundred ques-tions are divided into process groups ratherthan knowledge areas.

PMBOK® Guide 2000

The PMBOK® Guide is nowadays the mostimportant reference document about theProject Management Body of Knowledge. Itwas defined in 1987 as "all those topics, sub-ject areas and intellectual processes whichare involved in the application of soundmanagement principles to ... projects". Theguide is distributed by PMI, free of charge,with more than 640,000 copies placed in cir-culation worldwide (March 2001). As estab-lished in the guide, "the primary purpose ofthis document is to identify and describe that

subset of the PMBOK® which is generally ac-cepted. Generally accepted means that theknowledge and practices described are ap-plicable to most projects of the time, andthat there is widespread consensus about

their value and usefulness" (PMBOK®

Guide, 2000 Edition). According to the pur-pose of the guide, it is essential to have a lo-gical and coherent organization directlyaimed at the process groups in order to

547/641

facilitate the understanding of the chrono-logy of Project Management processes (Ex-hibit 01). However, it does not mean that theknowledge areas should be considered of lessimportance, as they are crucial for the under-standing of the multidisciplinary mechan-isms related to project management.

Exhibit 01 – PMBOK®

based on knowledge areas as op-

posed to PMBOK®

based on processes groups

Project Management Process Groups

548/641

The PMBOK® Guide organizes the ProjectManagement Processes in five groups: initi-ating processes, planning processes, execut-ing processes, controlling processes and clos-ing processes. All thirty-nine processes aredivided into these five groups and inter-twined by the results that they achieve (Ex-hibit 02). The fact that the five processgroups are also interlinked creates a dynamicnet of processes that are repeated and com-bined in each phase of the project, and con-sequently originates a process which is notdiscrete and overlaps itself in differentphases and levels of the project.

549/641

Exhibit 2 – Thirty-nine processes divided into five groups

New Structure of PMBOK®'Guide

The PMBOK® Guide suggested here re-defines and reorders the processes in newchapter groups. The first two chapters of part1 (The Project Management Framework) are

550/641

unchanged. A chapter 3 is now built from theintroductions of the nine chapters of thesecond part, relating each of the knowledgeareas and its principal processes, without de-tailing any process. The previous chapter 3,which describes the processes of administra-tion, will now be chapter 4 and will be in thesecond part of the guide called “The ProjectManagement Process Groups”. All thirty-nine processes will have now been distrib-uted in agreement with the phases of theproject in which they are used.

The greatest change would be to place the in-troductory chapters of each knowledge areain a third chapter which gives an overall viewof all the processes within each area. Theformer chapter 3 then becomes chapter 4,providing details about Project Managementprocess groups. However, the specification ofeach process group (initiating, planning, ex-ecuting, controlling and closing), which usedto be denominated 3.3.X, becomes the

551/641

introduction of chapters 5 to 9. The newtable of contents is systematized below:

Section I-The Project ManagementFrameworkChapter 1 Introduction1.1. Purpose of This Guide1.2. What is a Project?1.3. What is Project Management?1.4. Relationship to Other ManagementDisciplines1.5. Related EndeavorsChapter 2 Project Management Context2.1. Project Phases and the Project Live Cycle2.2. Project Stakeholders2.3. Organizational Influences2.4. Key General Management Skills2.5. Social-Economic-EnvironmentalInfluencesChapter 3 Project Management KnowledgeAreas3.1. Project Integration Management3.2. Project Scope Management

552/641

3.3. Project Time Management3.4. Project Cost Management3.5. Project Quality Management3.6. Project Human Resource Management3.7. Project Communications Management3.8. Project Risk Management3.9. Project Procurement ManagementSection II-The Project Management ProcessGroupsChapter 4 Project Management Process4.1. Project Processes4.2. Process Groups4.3. Process Interactions (introduction only)4.4. Customizing Process Interactions4.5. Mapping of Project ManagementProcessChapter 5 Initiating Process5.1. InitiationChapter 6 Planning Process6.1. Scope Planning6.2. Scope Definition6.3. Activity Definition

553/641

6.4. Resource Planning6.5. Activity Sequencing6.6. Activity Duration Estimating6.7. Cost Estimating6.8. Risk Management Planning6.9. Schedule Development6.10. Cost Budgeting6.11. Quality Planning6.12. Organizational Planning6.13. Staff Acquisition6.14. Communications Planning6.15. Risk Identification6.16. Qualitative Risk Analysis6.17. Quantitative Risk Analysis6.18. Risk Response Planning6.19. Procurement Planning6.20. Solicitation Planning6.21. Project Plan DevelopmentChapter 7 Executing Process7.1. Project Plan Execution7.2. Quality Assurance7.3. Team Development

554/641

7.4. Information Distribution7.5. Solicitation7.6. Source Selection7.7. Contract AdministrationChapter 8 Controlling Process8.1. Performance Reporting8.2. Scope Verification8.3. Scope Change Control8.4. Schedule Control8.5. Cost Control8.6. Quality Control8.7. Risk Monitoring and Control8.8. Integrated Change ControlChapter 9 Closing Process9.1. Contract Closeout9.2. Administrative ClosureSection III-AppendicesSection IV – Glossary and Index

With this table of contents a new PMBOK®can easily be built beginning with the re-ordering of the conventional processes

555/641

without losing any part of the original, thatis, without the omission of any of the originalcontent.

Process Interactions

All 39 processes are linked by their inputsand outputs. In the New Approach to

PMBOK® Guide the system for numberingthe processes serves to focus on the processgroups and not the knowledge areas. Thismakes the focus of each of the processes con-tinuous for a period of time while it is not ne-cessarily linked to one of the nine knowledgeareas.

The numeration of the inputs, tools andtechniques and outputs of the conventionalPMBOK® is given according to a sequenceof numerals in which the first number of thesequence represents the knowledge area, thesecond number, the sequence of the processwithin the knowledge area, the third, the

556/641

type of data (inputs, tools and techniques oroutputs) and the fourth is the sequential ofdata within the type (Exhibit 03).

Exhibit 3 – Nomenclature of the conventional PMBOK®

and example of the first Tools and Techniques of the Integ-

ration Process “Project Plan Development” denominated

“Project planning methodology”

In the New Approach to PMBOK® Guide, thenumeration of the inputs, tools and tech-niques and outputs is given by a sequence ofnumerals similar to that of the conventional

PMBOK®, although the first number of the

557/641

sequence represents the process group, thesecond number, the sequence of the processwithin the process group, the third, the typeof data (inputs, tools and techniques or out-puts) and the fourth is the sequential of thedata within the type (Exhibit 04 and 05).

Exhibit 4 – Nomenclature of the New Approach to

PMBOK®

Guide and example of the first Tools and Tech-

niques of the Integration Process “Project Plan Develop-

ment” denominated “Project planning methodology”

558/641

Exhibit 5 – Example of the new numbering system for in-

puts, tools and techniques and outputs for the Integration

Process “Project Plan Development” and a comparison with

the conventional PMBOK®

numbering system

Results Achieved in Pilot TrainingCourses Using the New Structure

With a view to evaluating the New Approach

to PMBOK® Guide, an experiment with twothirty-student classes of Project Manage-ment was held in a multinational IT

559/641

company in Brazil, according to the specific-ations below:

• 100% of the evaluated participants be-longed to the same company• 80% of the participants in each groupwere engineers (24 in each group)• 20% of the participants in each grouphad a degree in Administration (06 ineach group)• 100% of the participants were un-

aware of the existence of PMBOK®

Guide and considered their knowledgeof Project Management to be low or null.• The instructor was the same for bothclasses and the time and weekdays ofthe training were the same for both witha lag of 1 week between the classes. Theinstructor prepared a very similar teach-ing methodology for each of the twogroups, including the same exercisesand tests.

560/641

In order to select the participants for eachgroup, an equal division based on their pro-fessional backgrounds was part of the chosenprocedure. A forty question test coveringProject Management in general was also ap-plied for the purpose of having groups as ho-mogeneous as possible and therefore avoid-ing flaws in the evaluation. Each group at-tended a 32-hour training program covering

the PMBOK® processes with no absence.The first group's course followed the ap-proach and order of the conventional

PMBOK® in which the subjects are dividedinto knowledge areas, whereas the secondgroup was exposed to the New Approach to

PMBOK®, having the subjects divided intoprocesses.

At the end of the program a new forty-ques-tion test on Project Management was admin-istered to the two groups. The resultsachieved were as follows:

561/641

Group A-Conventional PMBOK® GuideAverage: 26.97Standard Deviation: 3.56 (13.2%)Highest score: 32Lowest score: 22Median: 26.5Mode: 26

Group B-New Approach to PMBOK® GuideAverage: 32.63Standard Deviation: 2.51 (7,70%)Highest score: 37Lowest score: 28Median: 33Mode: 30

The evaluation results suggest that The New

Approach to PMBOK® led to an increase ofabout 20% in the final scores, with lowerstandard deviation. They also suggest signi-ficant gains when taken into considerationthe questionnaire filled out by the

562/641

participant, which reveals that the major dif-

ficulty concerning the present PMBOK® isits analytical structure aimed at being usedas reference material rather than as a meansof initial learning.

After the results had been tabulated, all par-ticipants were invited to evaluate the twoversions as a group. This evaluation shows

that the New Approach to PMBOK® holdsthe following advantages:

• It makes the reading of PMBOK® se-quential, avoiding explaining and ana-lyzing future process groups in previousphases of the guide.• The visualization of the relationbetween the processes becomes easier asthe new structure clearly identifies therelation between certain succeeding pro-cess inputs and previous processoutputs.

563/641

• The new structure does not leave outany of the content or standards previ-ously established by the original

PMBOK® Guide.These results suggest an apparent gain ac-cording to the scores obtained by these parti-cipants, although the study must bedeepened with other groups and other com-panies to produce a working result that ismore scientifically proven

Conclusions

This New Approach to the PMBOK® Guidedoes not come as a substitute for the original

PMBOK® Guide, but as a new view of theprocesses. Its objective is to facilitate profes-sional’s learning of the Project ManagementBody of Knowledge. Professionals who arenot familiar with Project Management andthose who are preparing for the PMP examare the target public of the suggested

564/641

approach. A unique problem must be con-sidered in regard to the numbering system.

In the New Approach to the PMBOK® Guide,all of the entrance elements, tools, and exitsfor each process are numbered according tothe phase of the project and not accordingthe knowledge area, which could create somediscomfort in those professionals whoalready know and use the conventional

PMBOK® Guide with a certain level ofconfidence.

References

1. A Guide to the Project Management Body of

Knowledge. Upper Darby: Project Management Insti-

tute, 1996.

2. A Guide to the Project Management Body of

Knowledge. Newton Square: Project Management In-

stitute, 2000.

565/641

3. BERG, Cyntia A. PMBOK® Guide 2000: Hot Line

to Project Knowledge. Sylva: Project Management In-

stitute – Publishing Division, 2001.

566/641

- ANEXO II –RESPOSTAS DAS

PALAVRAS CRUZADAS

570/641

571/641

572/641

573/641

- ANEXO III –TRADUÇÃO DOINGLÊS PARA O

PORTUGUÊS DOSPRINCIPAIS TERMOSBaseado no PMBOK Guide ® 4a Edição,

onde o glossário completo está disponível

574/641

Accept – Aceitar

Acceptance – Aceitação

Acceptance Criteria – Critérios deaceitação

Acquire Project Team – Contratar oumobilizar a equipe do projeto

Activity – Atividade

Activity Attributes – Atributos daatividade

Activity Code – Código da atividade

Activity Definition – Definição daatividade

Activity Description (DA) – Descrição daatividade

Activity Duration – Duração da atividade

Activity Duration Estimating – Estim-ativa de duração da atividade

Activity Identifier – Identificador daatividade

Activity List – Lista de atividades

Activity Resource Estimating – Estim-ativa de recursos da atividade

Activity Sequencing – Sequenciamentode atividades

Activity-on-Arrow (AOA) – Atividade naseta (ANS)

Activity-on-Node (AON) – Atividade nonó (ANN)

Actual Cost (AC) – Custo real (CR)

Actual Cost of Work Performed(ACWP) – Custo real do trabalho realizado(CRTR)

Actual Duration – Duração real

Actual Finish Date (AF) – Data detérmino real (TR)

Actual Start Date (AS) – Data de inícioreal (IR)

Analogous Estimating – Estimativaanáloga

Application Area – Área de aplicação

576/641

Apportioned Effort (AE) – Esforço dis-tribuído (ED)

Approval – Aprovação

Approve – Aprovar

Approved Change Request – Solicitaçãode mudança aprovada

Arrow – Seta

Arrow Diagramming Method (ADM) –Método do diagrama de setas (MDS)

As-of Date – Até a presente data

Assumptions – Premissas

Assumptions Analysis – Análise daspremissas

Authority – Autoridade

Backward Pass – Caminho de volta

Bar Chart – Gráfico de barras

Baseline – Linha de base

Baseline Finish Date – Data de base detérmino

577/641

Baseline Start Date – Data de base deinício

Bill of Materials (BOM) – Lista de preçode materiais (LPM)

Bottom-up Estimating – Estimativa"bottom-up"

Brainstorming – Brainstorming [Técnica]

Budget – Orçamento

Budget at Completion (BAC) – Orça-mento no término (ONT)

Budgeted Cost of Work Performed(BCWP) – Custo orçado do trabalho realiz-ado (COTR)

Budgeted Cost of Work Scheduled(BCWS) – Custo orçado do trabalhoagendado (COTA)

Buffer – Buffer

Buyer – Comprador

Calendar Unit – Unidade de calendário

Change Control – Controle de mudanças

578/641

Change Control Board (CCB) – Comitêde controle de mudanças (CCM)

Change Control System – Sistema decontrole de mudanças

Change Request – Solicitação de mudança

Chart of Accounts – Plano de contas

Charter – Termo de abertura

Checklist – Lista de verificação

Claim – Reclamação

Close Project – Encerrar o projeto

Closing Processes – Processos deencerramento

Code of Accounts – Código de contas

Co-location – Agrupamento

Common Cause – Causa comum

Communication – Comunicação

Communication Management Plan –Plano de gerenciamento das comunicações

579/641

Communications Planning – Planeja-mento das comunicações

Compensation – Compensação

Component – Componente

Configuration Management System –Sistema de gerenciamento de configuração

Constraint – Restrição

Contingency – Contingência

Contingency Allowance – Provisão paracontingências

Contingency Reserve – Reserva paracontingências

Contract – Contrato

Contract Administration – Adminis-tração de contrato

Contract Closure – Encerramento docontrato

Contract Management Plan – Plano degerenciamento de contratos

580/641

Contract Statement of Work (SOW) –Declaração do trabalho (DT) do contrato

Contract Work Breakdown Structure(CWBS) – Estrutura analítica do projetocontratado (EAPC)

Control – Controle

Control Account (CA) – Conta de con-trole (CC)

Control Account Plan (CAP) – Plano decontas de controle (PCC)

Control Chart – Gráfico de controle

Control Limits – Limites de controle

Controlling – Controlar

Corrective Action – Ações corretivas

Cost – Custo

Cost Baseline – Linha de base dos custos

Cost Budgeting – Orçamentação

Cost Control – Controle de custos

Cost Estimating – Estimativa de custos

581/641

Cost Management Plan – Plano de ger-enciamento de custos

Cost of Quality (COQ) – Custo da qualid-ade (CDQ)

Cost Performance Index (CPI) – Índicede desempenho de custos (IDC)

Cost Variance (CV) – Variação de custos(VC)

Cost-Plus-Fee (CPF) – Custo mais remu-neração (CMR)

Cost-Plus-Fixed-Fee (CPFF) Contract –Contrato de custo mais remuneração fixa(CMRF)

Cost-Plus-Incentive-Fee (CPIF) Con-tract – Contrato de custo mais remuneraçãode incentivo (CMRI)

Cost-Plus-Percentage of Cost (CPPC) –Custo mais percentual do custo (CMPC)

Cost-Reimbursable Contract – Contratode custos reembolsáveis

Crashing – Compressão

582/641

Create WBS (Work Breakdown Struc-ture) – Criar EAP (Estrutura analítica doprojeto)

Criteria – Critérios

Critical Activity – Atividade crítica

Critical Chain Method – Método da ca-deia crítica

Critical Path – Caminho crítico

Critical Path Method (CPM) – Métododo caminho crítico (CPM)

Current Finish Date – Data de términoatual

Current Start Date – Data de início atual

Customer – Cliente

Data Date (DD) – Data dos dados (DD)

Date – Data

Decision Tree Analysis – Análise daárvore de decisão

Decompose – Decompor

Decomposition – Decomposição

583/641

Defect – Defeito

Defect Repair – Reparo de defeito

Deliverable – Produto

Delphi Technique – Técnica Delphi

Dependency – Dependência

Design Review – Revisão de projeto

Develop Project Charter – Desenvolver otermo de abertura do projeto

Develop Project Management Plan –Desenvolver o plano de gerenciamento doprojeto

Develop Project Team – Desenvolver aequipe do projeto

Direct and Manage Project Execution– Orientar e gerenciar a execução do projeto

Discipline – Disciplina

Discrete Effort – Esforço distinto

Document – Documento

Documented Procedure – Procedimentodocumentado

584/641

Dummy Activity – Atividade fantasma

Duration (DU or DUR) – Duração (DUou DUR)

Early Finish Date (EF) – Data de términomais cedo (TMC)

Early Start Date (ES) – Data de iníciomais cedo (IMC)

Earned Value (EV) – Valor agregado (VA)

Earned Value Management (EVM) –Gerenciamento de valor agregado (GVA)

Earned Value Technique (EVT) – Téc-nica do valor agregado (TVA)

Effort – Esforço

Enterprise – Empresa

Enterprise Environmental Factors –Fatores ambientais da empresa

Estimate – Estimativa

Estimate at Completion (EAC) – Estim-ativa no término (ENT)

585/641

Estimate to Complete (ETC) – Estim-ativa para terminar (EPT)

Event – Evento

Exception Report – Relatório de exceções

Execute – Executar

Executing – Execução

Executing Processes – Processos deexecução

Execution – Execução

Expected Monetary Value (EMV) Ana-lysis – Análise do valor monetário esperado(VME)

Expert Judgment – Opinião especializada

Failure Mode and Effect Analysis(FMEA) – Análise de modos e efeitos defalha (FMEA)

Fast Tracking – Paralelismo

Finish Date – Data de término

Finish-to-Finish (FF) – Término paratérmino (TT)

586/641

Finish-to-Start (FS) – Término para iní-cio (TI)

Firm-Fixed-Price (FFP) Contract –Contrato de preço fixo garantido (PFG)

Fixed-Price or Lump-Sum Contract –Contrato de preço fixo ou preço global

Fixed-Price-Incentive-Fee (FPIF) Con-tract – Contrato de preço fixo com remu-neração de incentivo (PFRI)

Float – Folga

Flowcharting – Elaboração defluxogramas

Forecasts – Previsões

Forward Pass – Caminho de ida

Free Float (FF) – Folga livre (FL)

Functional Manager – Gerente funcional

Functional Organization – Organizaçãofuncional

Funds – Fundos

Gantt Chart – Gráfico de Gantt

587/641

Goods – Bens

Grade – Grau

Ground Rules – Regras básicas

Hammock Activity – Atividadesumarizadora

Historical Information – Informaçõeshistóricas

Human Resource Planning – Planeja-mento de recursos humanos

Imposed Date – Data imposta

Influence Diagram – Diagrama deinfluência

Influencer – Influenciador

Information Distribution – Distribuiçãodas informações

Initiating Processes – Processos deiniciação

Initiator – Iniciador

Input – Entradas

Inspection – Inspeção

588/641

Integral| – Integral

Integrated – Integrado

Integrated Change Control – Controleintegrado de mudanças

Invitation for Bid (IFB) – Convite paralicitação (CONV)

Issue – Problema

Knowledge – Conhecimento

Knowledge Area Process – Processo deárea de conhecimento

Knowledge Area, Project Management– Área de conhecimento, Gerenciamento deprojetos

Lag – Espera

Late Finish Date (LF) – Data de términomais tarde (TMT)

Late Start Date (LS) – Data de início maistarde (IMT)

Latest Revised Estimate – Última estim-ativa revisada

589/641

Lead – Antecipação

Lessons Learned – Lições aprendidas

Lessons Learned Knowledge Base –Base de conhecimento de lições aprendidas

Level of Effort (LOE) – Nível de esforço(NDE)

Leveling – Nivelamento

Life Cycle – Ciclo de vida

Log – Registro

Logic – Lógica

Logic Diagram – Diagrama lógico

Logical Relationship – Relacionamentológico

Manage Project Team – Gerenciar aequipe do projeto

Manage Stakeholders – Gerenciar aspartes interessadas

Master Schedule – Cronograma mestre

Materiel – Material

590/641

Matrix Organization – Organizaçãomatricial

Methodology – Metodologia

Milestone – Marco

Milestone Schedule – Cronograma demarcos

Monitor – Monitorar

Monitor and Control Project Work –Monitorar e controlar o trabalho do projeto

Monitoring – Monitoramento

Monitoring and Controlling Processes– Processos de monitoramento e controle

Monte Carlo Analysis – Simulação deMonte Carlo

Near-Critical Activity – Atividade quasecrítica

Network – Rede

Network Analysis – Análise de rede

Network Logic – Lógica de rede

Network Loop – Loop de rede

591/641

Network Open End – Terminação abertana rede

Network Path – Caminho de rede

Networking – Networking [Técnica]

Node – Nó

Objective – Objetivo

Operations – Operações

Opportunity – Oportunidade

Organization – Organização

Organization Chart – Organograma

Organizational Breakdown Structure(OBS) – Estrutura Analítica Organizacional(EAO)

Organizational Process Assets – Ativosde processos organizacionais

Original Duration (OD) – Duração ori-ginal (DO)

Output – Saídas

Parametric Estimating – Estimativaparamétrica

592/641

Pareto Chart – Diagrama de Pareto

Path Convergence – Convergência decaminhos

Path Divergence – Divergência decaminhos

Percent Complete (PC or PCT) – Per-centual completo (PC ou PCT)

Perform Quality Assurance (QA) –Realizar a garantia da qualidade (GQ)

Perform Quality Control (QC) – Realiz-ar o controle da qualidade (CQ)

Performance Measurement Baseline –Linha de base da medição de desempenho

Performance Reporting – Relatório dedesempenho

Performance Reports – Relatórios dedesempenho

Performing Organization – Organizaçãoexecutora

Phase – Fase

593/641

Plan Contracting – Planejar contratações

Plan Purchases and Acquisitions –Planejar compras e aquisições

Planned Finish Date (PF) – Data detérmino planejada (TP)

Planned Start Date (PS) – Data de inícioplanejada (IP)

Planned Value (PV) – Valor planejado(VP)

Planning Package – Pacote deplanejamento

Planning Processes – Processos deplanejamento

Portfolio – Portfólio

Portfolio Management – Gerenciamentode portfólios

Position Description – Descrição decargo

Practice – Prática

594/641

Precedence Diagramming Method(PDM) – Método do diagrama de precedên-cia (MDP)

Precedence Relationship – Relação deprecedência

Predecessor Activity – Atividadepredecessora

Preventive Action – Ação preventiva

Probability and Impact Matrix – Matrizde probabilidade e impacto

Procedure – Procedimento

Process – Processo

Process Group – Grupo de processos

Procurement Documents – Documentosde aquisição

Procurement Management Plan –Plano de gerenciamento de aquisições

Product – Produto

Product Life Cycle – Ciclo de vida doproduto

595/641

Product Scope – Escopo do produto

Product Scope Description – Descriçãodo escopo do produto

Program – Programa

Program Management – Gerenciamentode programas

Program Management Office (PMO) –Escritório de programas

Progressive Elaboration – Elaboraçãoprogressiva

Project – Projeto

Project Calendar – Calendário de projeto

Project Charter – Termo de abertura doprojeto

Project Communications Management– Gerenciamento das comunicações doprojeto

Project Cost Management – Geren-ciamento de custos do projeto

596/641

Project Human Resource Management– Gerenciamento de recursos humanos doprojeto

Project Initiation – Iniciação do projeto

Project Integration Management –Gerenciamento de integração do projeto

Project Life Cycle – Ciclo de vida doprojeto

Project Management (PM) – Geren-ciamento de projetos (GP)

Project Management Body of Know-

ledge (PMBOK®) – Conjunto de conheci-mentos em gerenciamento de projetos

Project Management Information Sys-tem (PMIS) – Sistema de informações dogerenciamento de projetos (SIGP)

Project Management Knowledge Area– Área de conhecimento em gerenciamentode projetos

Project Management Office (PMO) –Escritório de projetos

597/641

Project Management Plan – Plano degerenciamento do projeto

Project Management Process – Pro-cesso de gerenciamento de projetos

Project Management Process Group –Grupo de processos de gerenciamento deprojetos

Project Management Professional

(PMP®) – Profissional de gerenciamento deprojetos

Project Management Software – Soft-ware de gerenciamento de projetos

Project Management System – Sistemade gerenciamento de projetos

Project Management Team – Equipe degerenciamento de projetos

Project Manager (PM) – Gerente de pro-jetos (GP)

Project Organization Chart – Organo-grama do projeto

598/641

Project Phase – Fase do projeto

Project Process Groups – Grupos de pro-cessos do projeto

Project Procurement Management –Gerenciamento de aquisições do projeto

Project Quality Management – Geren-ciamento da qualidade do projeto

Project Risk Management – Geren-ciamento de riscos do projeto

Project Schedule – Cronograma doprojeto

Project Schedule Network Diagram –Diagrama de rede do cronograma do projeto

Project Scope – Escopo do projeto

Project Scope Management – Geren-ciamento do escopo do projeto

Project Scope Management Plan –Plano de gerenciamento do escopo doprojeto

599/641

Project Scope Statement – Declaraçãodo escopo do projeto

Project Sponsor – Patrocinador doprojeto

Project Stakeholder – Partes interessadasno projeto

Project Summary Work BreakdownStructure (PSWBS) – Estrutura analíticado resumo do projeto (EARP)

Project Team – Equipe do projeto

Project Team Directory – Lista da equipedo projeto

Project Team Members – Membros daequipe do projeto

Project Time Management – Geren-ciamento de tempo do projeto

Project Work – Trabalho do projeto

Projectized Organization – Organizaçãopor projeto

600/641

Qualitative Risk Analysis – Análise qual-itativa de riscos

Quality – Qualidade

Quality Management Plan – Plano degerenciamento da qualidade

Quality Planning – Planejamento daqualidade

Quantitative Risk Analysis – Análisequantitativa de riscos

Requirements Traceability Matrix(RTM) – Matriz de Rastreamento deRequisitos (MRR)

Regulation – Regulamento

Reliability – Confiabilidade

Remaining Duration (RD) – Duraçãorestante (DR)

Request for Information – Solicitação deinformações

Request for Proposal (RFP) – Solicit-ação de proposta (SDP)

601/641

Request for Quotation (RFQ) – Solicit-ação de cotação (SDC)

Request Seller Responses – Solicitar re-spostas de fornecedores

Requested Change – Mudança solicitada

Requirement – Requisito

Reserve – Reserva

Reserve Analysis – Análise das reservas

Residual Risk – Risco residual

Resource – Recurso

Resource Breakdown Structure (RBS)– Estrutura analítica dos recursos (EAR)

Resource Calendar – Calendário derecurso

Resource Histogram – Histograma derecursos

Resource Leveling – Nivelamento derecursos

Resource Planning – Planejamento derecursos

602/641

Resource-Constrained Schedule – Cro-nograma restrito por recursos

Resource-Limited Schedule – Crono-grama limitado por recursos

Responsibility Assignment Matrix(RAM) – Matriz de responsabilidades (MR)

Result – Resultado

Retainage – Retenção

Rework – Retrabalho

Risk – Risco

Risk Acceptance – Aceitação dos riscos

Risk Avoidance – Prevenção de riscos

Risk Breakdown Structure (RBS) –Estrutura analítica dos riscos (EAR)

Risk Category – Categoria de risco

Risk Database – Banco de dados de riscos

Risk Identification – Identificação deriscos

Risk Management Plan – Plano de ger-enciamento de riscos

603/641

Risk Management Planning – Planeja-mento do gerenciamento de riscos

Risk Mitigation – Mitigação de riscos

Risk Monitoring and Control – Monit-oramento e controle de riscos

Risk Register – Registro de riscos

Risk Response Planning – Planejamentode respostas a riscos

Risk Transference – Transferência deriscos

Role – Função

Rolling Wave Planning – Planejamentoem ondas sucessivas

Root Cause Analysis – Análise da causa-raiz

Schedule – Cronograma

Schedule Activity – Atividade docronograma

Schedule Analysis – Análise docronograma

604/641

Schedule Compression – Compressão docronograma

Schedule Control – Controle docronograma

Schedule Development – Desenvolvi-mento do cronograma

Schedule Management Plan – Plano degerenciamento do cronograma

Schedule Milestone – Marco docronograma

Schedule Model – Modelo de cronograma

Schedule Network Analysis – Análise derede do cronograma

Schedule Performance Index (SPI) –Índice de desempenho de prazos (IDP)

Schedule Variance (SV) – Variação deprazos (VPR)

Scheduled Finish Date (SF) – Data detérmino agendada (TA)

605/641

Scheduled Start Date (SS) – Data de iní-cio agendada (IA)

Scope – Escopo

Scope Baseline – Linha de base do escopo

Scope Change – Mudanças do escopo

Scope Control – Controle do escopo

Scope Creep – Aumento do escopo

Scope Definition – Definição do escopo

Scope Planning – Planejamento do escopo

Scope Verification – Verificação doescopo

S-Curve – Curva S

Secondary Risk – Risco secundário

Select Sellers – Selecionar fornecedores

Seller – Fornecedor

Sensitivity Analysis – Análise desensibilidade

Service – Serviço

606/641

Should-Cost Estimate – Estimativa decustos exequíveis

Simulation – Simulação

Skill – Habilidade

Slack – Folga

Special Cause – Causa especial

Specification – Especificação

Specification Limits – Limites deespecificação

Sponsor – Patrocinador

Staffing Management Plan – Plano degerenciamento de pessoal

Stakeholder – Partes interessadas

Standard – Norma

Start Date – Data de início

Start-to-Finish (SF) – Início para término(IT)

Start-to-Start (SS) – Início para início (II)

Statement of Work (SOW).– Declaraçãodo trabalho (DT)

607/641

Strengths, Weaknesses, Opportunit-ies, and Threats (SWOT) Analysis –Análise dos pontos fortes e fracos, opor-tunidades e ameaças

Subnetwork – Sub-rede

Subphase – Subfase

Subproject – Subprojeto

Successor – Sucessor

Successor Activity – Atividade sucessora

Summary Activity – Atividade de resumo

System – Sistema

Target Completion Date (TC) – Dataalvo para término (AT)

Target Finish Date (TF) – Data alvo paratérmino (AT)

Target Schedule – Cronograma alvo

Target Start Date (TS) – Data alvo parainício (AI)

Task – Tarefa

Team Members – Membros da equipe

608/641

Technical Performance Measurement– Medição de desempenho técnico

Technique – Técnica

Template – Modelo

Threat – Ameaça

Three-Point Estimate – Estimativa detrês pontos

Threshold – Limite

Time and Material (T&M) Contract –Contrato por tempo e material

Time-Now Date – Data atual

Time-Scaled Schedule Network Dia-gram – Diagrama de rede do cronogramacom escala de tempo

Tool – Ferramenta

Total Float (TF) – Folga total (FT)

Total Quality Management (TQM) –Gerenciamento da qualidade total (GQT)

Trend Analysis – Análise das tendências

Triggers – Gatilhos

609/641

Triple Constraint – Restrição tripla

User – Usuário

Validation – Validação

Value Engineering (VE) – Engenharia devalor (EV)

Variance – Variação

Variance Analysis – Análise da variação

Verification – Verificação

Virtual Team – Equipe virtual

Voice of the Customer – Voz do cliente

War Room – Sala de comando

Work – Trabalho

Work Authorization – Autorização dotrabalho

Work Authorization System – Sistemade autorização do trabalho

Work Breakdown Structure (WBS) –Estrutura analítica do projeto (EAP)

610/641

Work Breakdown Structure Compon-ent – Componente da estrutura analítica doprojeto

Work Breakdown Structure Diction-ary – Dicionário da estrutura analítica doprojeto

Work Item – Item de trabalho

Work Package – Pacote de trabalho

Work Performance Information – In-formações sobre o desempenho do trabalho

Workaround – Solução alternativa

611/641

BIBLIOGRAFIA

1. A Guide to the Project Management

Body of Knowledge. 4a Edição NewtonSquare: Project Management Institute,2008.

2. ADAMS, John R. & CAMPBELL, Bry-an W. Roles and Responsibilities of TheProject Manager. Upper Darby: ProjectManagement Institute, 1982.

3. ADAMS, John R., BILBRO, C.Richard and STOCKERT, Timothy C. AnOrganization Development Approach toProject Management. Upper Darby:Project Management Institute, 1989.

4. BODDIE, John e METZGER, PhilipW. Managing a Programming Project.London: Prentice Hall, 1997.

5. BLOCK, Thomas R. & FRAME, J.Davidson. The Project Office. MenloPark: Crisp Publications, 1998.

6. BRANDON JR, Daniel M. Imple-menting Earned Value Easily and Effect-ively in Project Management Journal,vol 29/2. Philadelphia, 1998.

7. BURKE, Rory. Project Management:Planning and Control. New York: JohnWiley & Sons, 1994.

8. CABLE, Dwayne & ADAMS, John R.Organizing for Project Management.Upper Darby: Project Management In-stitute, 1982.

9. CAVENDISH, Penny & MARTIN,Martin D. Negotiating & Contractingfor Project Management. Upper Darby:Project Management Institute, 1982.

10. CLELAND, David I. Project Man-agement: Strategic Design and

613/641

Implementation. New York, McGraw-Hill, 1999.

11. CLELAND, David, BURSIC, KarenM., PUERZER, Richard & VLASAK,Yaroslav. Project Management Case-book, Upper Darby: Project Manage-ment Institute, 1997.

12. _________. Project managementCasebook: Instructor’s Manual. UpperDarby: Project Management Institute,1997.

13. CRAWFORD, J. Kent. The StrategicProject Office: A Guide to ImprovingOrganizational Performance. NewYork: Marcel Drekker, 2002.

14. Creative Tools Memory Jogger, The.Lawrence: Goal/QPC: 1998.

15. DINSMORE, Paul C., MARTIN,Martin C. & HUETTEL, Gary T. TheProject Manager’s Work Environment:Coping with Time and Stress. Upper

614/641

Darby: Project Management Institute,1985.

16. DOBSON, Michael S. The Juggler’sGuide to Managing Multiple Projects.Philadelphia: Project Management In-stitute, 1999.

17. EISNER, Howard. Essentials of Pro-ject and Systems Engineering Manage-ment. New York: John Wiley & Sons,1996.

18. FLAPPER, Simme Douwe P.,FORTUIN Leonard and STOOP, Paul P.M. Towards Consistent PerformanceManagement Systems. InternationalJournal of Operations & productionsManagement, vol 16 no 7, UniversityPress, 1996.

19. FLEMING, Quentin W. Cost/Sched-ule Control Systems Criteria. RevisedEdition. Chicago: Irwin ProfessionalPublishing, 1992.

615/641

20. FLEMING, Quentin W. eKOPPELMAN, Joel M. Earned ValueProject Management. Upper Darby:Project Management Institute, 1997.

21. FOGARTY, Richard. Payment byEarned Value. The College of Perform-ance Management Journal “The Meas-urable News”, 1999.

22. Future of Project Management, The.Newtown Square: Project ManagementInstitute, 1999.

23. GALBRAITH, Jay R. Designing Or-ganizations: An Executive Briefing onStrategy, Structure and Process. SanFrancisco: Jossey-Bass Publishers, 1995.

24. GALBRAITH, Jay R. Designing Or-ganizations: An Executive Briefing onStrategy, Structure and Process. SanFrancisco: Jossey-Bass Publishers, 1995.

616/641

25. GOLDRATT, Eliyahu M. CriticalChain. Great Barrington: The NorthRiver Press, 1997.

26. GREEN, Don. Project ControlThrough Earned Value. Long Beach:29th Annual Project Management Insti-tute Seminars & Symposium, 1998.

27. IRELAND, Lewis R. Quality Man-agement for Projects and Programs.Upper Darby: Project Management In-stitute, 1991.

28. KAPLAN, Robert S. New Systems forMeasurement and Control. The Engin-eering Economist, vol 36, no 3, 1991.

29. KELLEY, Robert M. Planning Tech-niques (Basic and Advanced): A Graph-ic, Self-Checking Planning Method. Ket-tering: Kelley Communications Develop-ment, 1988.

30. KENNY, Graham and DUNK Alan S.The Utility of Performance Measures:

617/641

Production Manager’s Perceptions.IEEE Transactions on EngineeringManagement, vol 36 no 1, 1989.

31. KERZER, Harold. Project Manage-ment: A systems approach to planning

scheduling and controlling. 6a ed. NewYork: Van Nostrand Reinhold, 1998.

32. KERZNER, Harold. In Search of Ex-cellence in Project Management: Suc-cessful Practices in High PerformanceOrganizations. New York: VanNostrand Reinhold, 1998.

33. KLIEM, Ralph L. & LUDIN, Irwin S.Tools and Tips for Today’s ProjectManager. Newtown Square: ProjectManagement Institute, 1999.

34. LEWIS, James P. Fundamentals ofProject Management. New York: Ama-com, 1997.

618/641

35. LEWIS, James P. Project Planning,Scheduling & Control. Chicago: IrwinProfessional Publishing, 1995.

36. LOCK, Dennis. Project Manage-ment. New York: John Wiley & Sons,1996.

37. MARTIN, Martin D., TEAGARDEN,C. Claude & LAMBRETH, Charles F.Contract Administration for The Pro-ject Manager. Upper Darby: ProjectManagement Institute, 1983.

38. MAYER, Margery. The Virtual Edge:Embracing Technology for DistributedProject Team Success. Newtown Square:Project Management Institute, 1998.

39. Memory Jogger II, The. Lawrence:Goal/QPC, 1994.

40. MEREDITH, Jack R. & MANTELJR., Samuel J. Project Management: AManagerial Approach. New York: JohnWiley and Sons, 1995.

619/641

41. MINTZBERG, Henry. Criando Or-ganizações Eficazes: Estruturas emCinco Configurações. São Paulo: Atlas:1995.

42. MULCANY, Rita. What Makes aProject Manager Successful? San Anto-

nio:33th Project Management InstituteAnnual Seminars and Symposium:2002.

43. PAGNOCELLI, Dernizo &VASCONCELOS FILHO, Paulo. SucessoEmpresarial Planejado. Rio de Janeiro:Qualitymark Ed., 1992.

44. PINTO, Jeffrey K. & TRAILER, Jef-frey W. Leadership Skills for ProjectManagers. Newtown Square: ProjectManagement Institute, 1998.

45. PMI Book of Project ManagementForms, The. Upper Darby: Project Man-agement Institute, 1997.

620/641

46. PMI Project Management FactBook, The. Newtown Square: ProjectManagement Institute, 1999.

47. Project Management Memory Jog-ger. Lawrence: Goal/QPC: 1997.

48. SANDERS, Norman. Stop WastingTime: Computer-Aided Planning andControl. London: Prentice Hall, 1991.

49. SCHUYLER, John R. Decision Ana-lysis in Projects: Learn to Make Faster,More Confident Decisions. UpperDarby: Project Management Institute,1996.

50. SHTUB, Avraham & BARD, Jonath-an F., GLOBERSON, Shlomo. ProjectManagement-Engineering, Technologyand Implementation. New Jersey:Prentice Hall, 1994.

51. Team Memory Jogger, The.Lawrence: Goal/QPC and Oriel Incor-porated: 1995.

621/641

52. THIRY, Michael. Value Manage-ment Practice. Newton Square: ProjectManagement Institute, 1997.

53. VALERIANO, Dalton L. Gerênciaem Projetos: Pesquisa, Desenvolvi-mento e Engenharia. São Paulo: Mak-ron Books, 1998.

54. VARGAS, Ricardo V. Análise de Val-or Agregado em Projetos. 4ª Edição.Rio de Janeiro: Brasport, 2005.

55. VARGAS, Ricardo V. Microsoft Of-fice Project 2007. Rio de Janeiro: Bras-port, 2008.

56. VARGAS, Ricardo V. ManualPrático do Plano de Projeto 4ª Edição.Rio de Janeiro: Brasport, 2009.

57. VASCONCELLOS, Paulo Filho &PAGNOCELLI, Dernizo. Sucesso Em-presarial Planejado. Rio de Janeiro:Qualitymark Editora, 1992.

622/641

58. VERMA, Vijay K. Human ResourceSkills for the Project Manager vol. 2.Upper Darby: Project Management In-stitute, 1995.

59. _________. Managing the ProjectTeam vol. 3. Upper Darby: Project Man-agement Institute, 1995.

60. _________. Organizing Projectsfor Success vol. 1. Upper Darby: ProjectManagement Institute, 1995.

61. WESTNEY, Richard E. StrategicProject Planner. New York: Amoco Cor-poration and Westney Consultants In-ternational, 1995.

62. WIDEMAN, R. Max. A Frameworkfor Project and Program ManagementIntegration. Upper Darby: Project Man-agement Institute, 1991.

63. _________. Project & ProgramRisk Management: A Guide toManaging Project Risks &

623/641

Opportunities. Upper Darby: ProjectManagement Institute, 1992.

64. WISNER, Joel D. and FAWCETT,Stanley E. Linking Firm Strategy toOperating Decision through Perform-ance Measurement. Production and In-ventory Management Journal – ThirdQuarter, 1991.

624/641

ÍNDICE

REMISSIVO

ACWP 196, 198

Adams 114

Adequação à Cultura

Estimativa 159

Alternativas

Modelo de pontuação e ponderação 161

Seleção 160

Análise de Valor Agregado 195, 199

Aquisições

Plano de Gerenciamento de 191

Atividades

de Resumo 170

Defasagem 178

Executivas 169

Início 175

Lista 169

Marcos 169

Relacionamento entre 175

Restrições de Datas 176

Término 175

Cronograma 67

Definição 65

Duração 66

Recursos 66

BCWP 196, 199

BCWS 196, 198

Cable 112

Calendários 176

Caminho Crítico

Definição 185

Cervantes 133

Cleland 2, 5, 6, 10, 84, 85

Compressão de duração 172

Conflitos

Administração 135

626/641

Conseqüências

Estimativa 159

Contratos 97, 98, 101, 130, 202

Contratos

Encerramento 202

Tipos 97

Controle Geral das Mudanças 200

Controle Integrado das Mudanças 52, 53

COTA 196

COTR 196

CPI 198, 200

Crashing 172

Cronograma

Desenvolvimento 188

CRTR 196

Custos

Cálculo de 189

Estimativa 159

Estimativa por pacotes de trabalho 190

Fluxo de Caixa 191

627/641

Indiretos 190

Orçamento 190


CV 196

Declaração de Escopo 62, 162, 163, 164

Declaração de Escopo

Aprovação 164

Desempenho

Estimativa 159

Diagrama de Gantt 180, 181, 184, 185, 188

Diagrama de Gantt

Desvantagens 180

Vantagens 180

Diagrama de rede

AOA (Activity on Arrow) 179

Diagrama de Rede 175, 188

Diagrama de Rede

AON (Activity on Node) 179

Dicionário da EAP 167

Dobson 125

628/641

Documento de Requisitos 60

EAP 56, 57, 165, 166, 167, 168, 169, 190, 192

EAP

Características 166

Decomposição 167

Técnica Botton-Up 168

Criação 59

Earned Value Analysis 195

Emissor 84

Encerramento 148, 201

Equipes 83

Escopo

Controlar 60

Definir 59

Planejamento de 59

Escritório do Projeto 117

Estrutura Analítica do Projeto 56, 192

Estrutura de Projetos 111

Estrutura Funcional 109

Estrutura Matricial Balanceada 115

629/641

Estrutura Matricial Forte 116

Estrutura Matricial Leve 113

Fase de Controle 32

Fase de Encerramento 32

Fase de Execução 32, 52, 53, 148

Fase de Iniciação 32, 146

Fase de INICIAÇÃO 149

Fase de Planejamento 32, 147, 165

Feriados 176

Flemming 195

Folga livre 187

Folga Livre 187

Folga total 187

Folga Total 187

Galbraith 79, 144

Garcián 69

Gerenciamento da integração 151

Gerenciamento da Integração 44, 51, 52

Gerenciamento da Integração

630/641

Mindmap 51

Gerenciamento da Qualidade 45, 76, 77, 78

Gerenciamento da Qualidade

Mindmap 76

Gerenciamento das aquisições 101

Gerenciamento das Aquisições 45, 97, 99, 101

Gerenciamento das Aquisições

Mindmap 99

Gerenciamento das Comunicações 45, 84, 86, 89

Gerenciamento das Comunicações

Mindmap 86

Gerenciamento de Custos 45, 71, 73

Gerenciamento de Custos

Mindmap 71

Gerenciamento de Escopo 44, 57, 58, 59, 63, 163, 168

Gerenciamento de Escopo

Mindmap 58

Gerenciamento de Recursos Humanos 45, 80, 81, 83

Gerenciamento de Recursos Humanos

Mindmap 80

631/641

Gerenciamento de Riscos 45, 90, 91, 92, 95

Gerenciamento de Riscos

Mindmap 91

Gerenciamento de Tempo 44, 68

Gerenciamento de Tempo

Mindmap 65

Gerente de Projeto 151

Gerente de Projeto

Habilidades 125

Selecionando 128

Gráfico de Gantt 188

Green 195

Inter-relacionamentos

Tipos de 176

Ireland 74

Kerzner 9, 14, 16, 19, 20, 57, 85, 105, 136, 144

Kliem 128

Lewis 144

Linha de base 197

Livro Geral do Projeto 151, 156, 159, 193

632/641

Max Beerbohm 18

Meredith 5, 25

Mintzberg 85

Modelo Geral para o Gerenciamento de Projetos 143

Modelo Organizacional 108

obstáculos 18, 56, 125, 192

Orçamento 14, 15, 17, 32, 45, 55, 68, 70, 75, 151, 196,

198

Pacote de Trabalho 165, 170, 194

PERT 172, 179, 180

PERT

Análise de 172

Pinto 128

Plano do Projeto

Aprovação 192

Plano Global do Projeto 52, 55, 191

PMBOK 34, 51, 58, 65, 71, 76, 80, 86, 91, 99, 106, 144,

194

PMBOK Guide

Mindmap 49

633/641

PMBOK Guide 4a Edição

Processos 47

PMI 2, 12, 31

Portfólios 7

Posner 64

Problema ou Oportunidade 149

Problemas de Variáveis Abertas 150

Problemas de Variáveis Fechadas 150

Program Evaluation and Review Technique 179

Programas 7

Project Office 117

1.1Projeto 5

Alternativas 156

Causas de Fracasso 18

Entregas 155

Início do 175

Justificativa 154

Objetivo 153

Produtos 155

Término do 175

634/641

benefícios 12, 17, 18, 24, 90

Exemplos de 6

Projetos

Ciclo de Vida 12, 24, 25, 31, 33, 57, 70, 74, 79, 135, 145

Fases 7, 17, 24, 27, 31, 32, 33, 34, 52, 59, 65, 71, 76,

80, 81, 86, 88, 92, 99, 145, 165, 167, 168, 190, 196

Mitos 20

Sucesso 4, 5, 9, 10, 14, 15, 16, 18, 19, 51, 79, 82, 125,

128, 132, 157

Valor 25, 27, 28, 37, 70, 168, 189, 197, 198

Qualidade

Garantia 77

Planejamento 76

Receptor 84

Recursos

Alocação 174

Conciliação 181

Custos de 189

Desmobilização 202

Horas-Extras 183

Matriz de Atribuição de Responsabilidades 173

Nivelamento de 183

635/641

Seleção de 173

Substituição 181

Troca da Escala 182

recursos humanos 173

Requisitos

Coleta 59

Requisitos do Projeto

Documento de 60

Matriz de 62

Plano de 61

Responsabilidade Profissional

Definição 137

Subdivisões 138

Riscos

Estimativa 159


Sandburg 117

Sanders 144

Santayana 57

Schtub 144

636/641

Scope Statement 62

SPI 197, 200

Subprojetos 7

SV 197

Tempo

Estimativa 158, 159


Controle 67

Temporariedade 12

Termo de Abertura 52, 54

Thamhain & Wilemon 64

Tocqueville 110

Tom Peters 2

Trabalhos

Conclusão 200

Trailer 128

TV 197

Verma 51, 79, 116

Wideman 12, 13, 28, 90

637/641

William James 20

Work Breakdown Structure 56, 192

Youker 108

Mindmap

Definição 49

PERT

Análise de 172

1 Cleland, David. Project management Casebook, Project

Management Institute, Philadelphia: 1997 e MEREDITH,

Jack R. & MANTEL JR., Samuel J. Project Management: A

Managerial Approach. New York: John Wiley and Sons,

1995 e exemplos do autor.

2 KERZNER, Harold. In Search of Excellence in Project

Management: Successful Practices in High Performance

Organizations. New York: Van Nostrand Reinhold, 1998.

3 Em muitos casos existem diferentes interpretações do

conceito de fase e de grupo de processos. Neste livro o con-

ceito de fase será utilizado para significar tanto os grupos de

processo do PMBOK® Guide quanto os conceitos de fases

638/641




específicas de um projeto (por exemplo: design, construção,

testes). Portanto, o termo “Grupo de Processos de Iniciação”

e “Fase de Iniciação” são considerados sinônimos neste

livro.

4 Esse produto é normalmente denominado EMV ou valor

monetário esperado do risco.

5 Optou-se nesse caso por utilizar o inglês Performance no

lugar de Desempenho devido à popularidade do acrônimo

PCT.

6 © Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK®

Guide) – 4a Edição. Material Reproduzido com autorização e permissão do PMI.

7 Esse artigo foi apresentado no PMI Global Congress em

Nashville – Tennessee – EUA e serviu como base para a

nova estrutura do PMBOK® Guide 4ª edição, onde o ter-

ceiro capítulo faz o papel didático de apresentar os pro-

cessos dentro das fases (grupos de processo) e não dentro

das áreas de conhecimento.

8 A numeração se inicia do número 4 para referenciar o

capítulo 4 do PMBOK Guide 4a Edição original.

9 Até a terceira edição do PMBOK esses planos eram “Saí-

das” explicitas dos seus respectivos processos. Na quarta

639/641







edição, alguns desses planos foram omitidos das “Saídas”,

sendo substituídos pelo termo “Documentação do projeto”.

Essa alteração não significa que esses planos não são im-

portantes para o sucesso do projeto. Para fins didáticos, to-

dos os planos são explicados dentro de sua respectiva área

de conhecimento.

10 Até a terceira edição do PMBOK Guide o Plano de Geren-

ciamento de Cronograma era destacado como uma saída

dos processos. Na quarta edição ele passou a ser parte da

saída documentos do projeto.

11 Existem várias outras técnicas para a seleção de altern-

ativas, dentre elas podem ser destacadas a Classificação

Comparativa de Alternativas, onde alternativas são com-

paradas uma a uma de modo a avaliar qual delas recebe

mais pontos se confrontada com todas as demais altern-

ativas. Outra técnica extremamente poderosa e eficiente é o

processo de análise hierárquica ou AHP (Analytical Hier-

archy Process) onde os critérios são hierarquizados e trans-

formados em um modelo matemático de comparação.

12

640/641




13 Baseado em VARGAS, Ricardo V. Análise de Valor

Agregado em Projetos – 4ª Edição. Rio de Janeiro, Bras-

port, 2008.

14 Neste capítulo optou-se por manter a nomenclatura ori-

ginal oficial dos termos adotados na análise de valor

agregado (BCWS, BCWP, ACWP). O PMI, buscando facilitar

a memorização dos termos para o exame PMP®, simpli-

ficou esses termos como PV, EV e AC, respectivamente.

641/641




gerenciamento de projetos - ricardo vargas

Documents

portflio e riscos

informtica e finanas

fase e grupo

pmbok para o portugus

todos os processos e

publicados em portugus

programa e portflio

brasport livros e multimdia