Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas

PMBOK 2000 Portugues, Manuais, Projetos, Pesquisas de Informática

Documento completo sobre a Gerencia de Projetos - Guia PMBOK

Tipologia: Manuais, Projetos, Pesquisas

Antes de 2010

Compartilhado em 30/08/2008

elisa-duarte-5
elisa-duarte-5 🇧🇷

1 documento

1 / 151

Toggle sidebar

Esta página não é visível na pré-visualização

Não perca as partes importantes!

bg1
Belo Horizonte, 31 de janeiro de 2002
Senhores (as) Gerentes de Projeto,
O PMI através do PMBOK 2000 promoveu uma atualização da versão
publicada em 1996, buscando, dentre outros objetivos, acrescentar novas
matérias que refletem o crescimento e a prática no campo do Gerenciamento
de Projetos em todo o mundo. Para conhecer mais detalhes sobre as
modificações, veja “Preface to the 2000 Edition”, página “IX” da versão
original.
O Capítulo de Minas Gerais do PMI, norteado pelos mesmos objetivos e
compromissos da tradução anterior, divulga nesta data uma versão não
oficial em português do PMBOK 2000.
Agradecemos, em especial, ao mesmo grupo de colaboradores da versão 1996
(Antonio José Soares, PMP, Márcio Tibo, PMP, Katia P. Thomaz, PMP e
Darcilene Magalhães) que levou ao fim mais essa empreitada.
Agradecemos ainda a todos aqueles nos honraram com comentários e
apreciações sobre a versão anterior. Envie sua contribuição para o endereço
pmimg@aec.com.br . Torne-se um colaborador desse empreendimento.
Atenciosamente,
Diretoria do PMIMG
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45
pf46
pf47
pf48
pf49
pf4a
pf4b
pf4c
pf4d
pf4e
pf4f
pf50
pf51
pf52
pf53
pf54
pf55
pf56
pf57
pf58
pf59
pf5a
pf5b
pf5c
pf5d
pf5e
pf5f
pf60
pf61
pf62
pf63
pf64

Pré-visualização parcial do texto

Baixe PMBOK 2000 Portugues e outras Manuais, Projetos, Pesquisas em PDF para Informática, somente na Docsity!

Belo Horizonte, 31 de janeiro de 2002

Senhores (as) Gerentes de Projeto,

O PMI através do PMBOK 2000 promoveu uma atualização da versão

publicada em 1996, buscando, dentre outros objetivos, acrescentar novas

matérias que refletem o crescimento e a prática no campo do Gerenciamento

de Projetos em todo o mundo. Para conhecer mais detalhes sobre as

modificações, veja “Preface to the 2000 Edition”, página “IX” da versão

original.

O Capítulo de Minas Gerais do PMI, norteado pelos mesmos objetivos e

compromissos da tradução anterior, divulga nesta data uma versão não

oficial em português do PMBOK 2000.

Agradecemos, em especial, ao mesmo grupo de colaboradores da versão 1996

(Antonio José Soares, PMP, Márcio Tibo, PMP, Katia P. Thomaz, PMP e

Darcilene Magalhães) que levou ao fim mais essa empreitada.

Agradecemos ainda a todos aqueles nos honraram com comentários e

apreciações sobre a versão anterior. Envie sua contribuição para o endereço

pmimg@aec.com.br. Torne-se um colaborador desse empreendimento.

Atenciosamente,

Diretoria do PMIMG

Capítulo 1

IntroduçãoIntrodução^ IntroduçãoIntrodução

O Universo de Conhecimento em Gerência de Projetos (PMBOK) é uma denominação que representa todo o somatório de conhecimento dentro da profissão de gerência de projetos. Como qualquer outra profissão - advocacia, medicina e contabilidade - o conjunto de conhecimentos baseia-se na contribuição daqueles profissionais e estudantes que aplicam esses conhecimentos no dia a dia, desenvolvendo-os. Este Conjunto Completo de Conhecimentos em Gerência de Projetos (Full PMBOK) inclui os conhecimentos já comprovados através de práticas tradicionais que são amplamente utilizadas, assim como conhecimentos de práticas mais inovadoras e avançadas que têm tido uma aplicação mais limitada, incluindo tanto material publicado ou não. Este capítulo define e explica uma série de termos característicos da área apresentando também uma visão geral do resto do documento. Ele inclui as seguintes seções: 1.1 Propósito deste Manual 1.2 O que é um Projeto? 1.3 O que é Gerência de Projetos 1.4 Relacionamento com Outras Disciplinas de Gerência 1.5 Empreendimentos Relacionados

1.11.11.11.1 PROPÓSITO DESTE MANUALPROPÓSITO DESTE MANUALPROPÓSITO DESTE MANUALPROPÓSITO DESTE MANUAL

Gerência de projeto é uma profissão emergente. O propósito principal deste documento é identificar e descrever aquela parte do PMBOK que é geralmente aceita. O termo “geralmente aceita” significa, neste caso, que os conhecimentos e práticas descritos são aplicáveis à maioria dos projetos, na maioria das vezes, e que há um consenso amplamente difundido sobre seu valor e utilidade. Geralmente aceita não significa, entretanto, que os conhecimentos e práticas descritos são ou devem ser praticados uniformemente em todos os projetos; a equipe de gerência do projeto é sempre responsável pela escolha daquilo que é mais apropriado para um projeto específico. Este documento pretende também fornecer uma terminologia comum, dentro da profissão e práticas, para a linguagem oral e escrita sobre Gerência de Projetos. A Gerência de Projeto é uma profissão relativamente nova e, embora haja uma razoável concordância, dentro da comunidade de projetos, acerca daquilo que é feito, existe relativamente pouco consenso quanto aos termos usados. Este documento provê uma referência básica para qualquer profissional interessado na profissão de Gerência de Projetos. Entre outras categorias inclui:

1.2.11.2.1 1.2.11.2.1 TemporárioTemporárioTemporárioTemporário

Temporário significa que cada projeto tem um início e um fim muito bem definidos. Chega-se ao fim do projeto quando os seus objetivos foram alcançados ou quando torna-se claro que os objetivos do projeto não serão ou não poderão mais ser atingidos ou a necessidade do projeto não existe mais. O projeto é então encerrado. Temporário não significa que a sua duração é curta; muitos projetos duram vários anos. Em todos os casos, entretanto, a duração do projeto é finita; projetos não são esforços continuados. Além disto, o termo temporário geralmente não se aplica ao produto ou serviço criado pelo projeto. Os projetos podem freqüentemente ter impactos sociais, econômicos e ambientais, intencionais ou não, que excedem em duração aos próprios projetos. A maioria dos projetos são empreendidos para criar um resultado duradouro. Por exemplo, um projeto para erigir um monumento nacional criará um resultado que deverá durar séculos. Uma série de projetos e/ou projetos complementares em paralelo podem ser requeridos para alcançar um objetivo estratégico. Os objetivos de projeto e de operações continuadas são fundamentalmente diferentes. O objetivo de um projeto é alcançar o objetivo proposto e encerrar o projeto. O objetivo de uma operação continuada não projetizada é normalmente sustentar o negócio .. Um projeto é fundamentalmente diferente porque ele termina quando seus objetivos propostos são alcançados, enquanto as operações continuadas (não projetos), quando atingem seus objetivos, criam um novo grupo de objetivos e o trabalho continua. A natureza temporária dos projetos se aplica também a outros aspectos dos empreendimentos:  (^) A oportunidade ou os nichos de mercado são usualmente temporários – a maioria dos projetos têm um espaço de tempo limitado para produzir seus produtos e serviços  A equipe do projeto normalmente é desmontada após o projeto – os projetos em sua maioria são conduzidos por uma equipe que tem o único compromisso daquele projeto. Ao término do projeto, a equipe é liberada e os membros realocados em outras atividades.

1.2.21.2.2^ 1.2.21.2.2^ Produto,Produto,Produto,Produto,^ Serviço ouServiço ouServiço ouServiço ou^ ResultadoResultadoResultadoResultado^ ÚnicoÚnicoÚnicoÚnico

Os projetos envolvem o desenvolvimento de algo que nunca foi feito antes, e que é, portanto, único. Um produto ou serviço pode ser único, mesmo considerando que já tenha sido desenvolvida uma infinidade de produtos/serviços em sua categoria. Por exemplo, muitos e muitos edifícios já foram construídos, mas cada nova unidade lançada, é única – com um proprietário diferente, projeto próprio, localização específica, construtor diferente, e assim por diante. A presença de fatores repetitivos não muda a característica intrínseca de unicidade do esforço global do trabalho do projeto. Por exemplo:  Um projeto para desenvolver um novo tipo de avião comercial pode requerer uma série de protótipos  Um projeto para liberação à população de um novo medicamento, pode requerer milhares de doses da droga para distribuição em testes clínicos  A construção de um conjunto habitacional pode incluir centenas de unidades individuais  (^) O desenvolvimento de um projeto (i. e., abastecimento de água e saneamento) pode ser implementado em cinco áreas geográficas.

1.2.31.2.3 1.2.31.2.3 Elaboração ProgressivaElaboração ProgressivaElaboração ProgressivaElaboração Progressiva

Elaboração progressiva é a característica de projeto que integra os conceitos de temporário e único. Como o produto de cada projeto é único, as características peculiares que o distinguem devem ser progressivamente elaboradas. Progressivamente significa “proceder por etapas; continuar de forma determinada, por incrementos”

enquanto elaboradas significa “trabalhadas com cuidado e detalhe; desenvolvidas por completo” [1]. Estas características que distinguem os produtos a serem construídos, são amplamente definidas bem cedo no projeto, e se tornam mais explícitas e detalhadas assim que a equipe adquire uma melhor e mais completa percepção do produto. A elaboração progressiva das características do produto necessita ser cuidadosamente coordenada com a correta definição do escopo do projeto, especialmente se o projeto é desenvolvido sob contrato. Quando adequadamente definido, o escopo do projeto – que define todo o trabalho a ser realizado no projeto – deve permanecer constante, ainda que as características do produto estejam sendo elaboradas progressivamente. O relacionamento entre o escopo do produto e o escopo do projeto é discutido mais à frente na introdução do Capítulo 5. Os dois exemplos seguintes ilustram o conceito de elaboração progressiva em duas áreas de aplicação diferentes. Exemplo 1. Uma fábrica de processamento químico começa com o processo de engenharia definindo as características do processo. Estas características são usadas para projetar as principais unidades de produção. Esta informação, por sua vez, torna-se a base para o design de engenharia que define o leiaute detalhado da fábrica e as características mecânicas das unidades de processo e das instalações auxiliares. Como resultado obtêm-se desenhos de engenharia que são desdobrados para produzir desenhos de fabricação (isometria de construção). Durante a construção, uma série de interpretações e adaptações são feitas, quando necessárias, e submetidas à aprovação formal. Esta “elaboração” posterior é também transposta para desenhos do que realmente foi construído (“as built design”). Durante as fases de teste e manutenção, novas transformações são freqüentemente realizadas sob a forma de ajustes finais. Exemplo 2. O produto de um projeto de desenvolvimento econômico pode ser inicialmente definido como: “Desenvolver a qualidade de vida dos residentes de baixa renda de uma comunidade X”. De acordo com os procedimentos de projeto, os produtos devem ser descritos mais especificadamente como, por exemplo: “Disponibilizar acesso a alimento e água para 500 residentes de baixa renda da comunidade X”. A próxima etapa da elaboração progressiva poderia ser focada no crescimento da produção e comercialização agrícola, com o fornecimento de agua caindo para a segunda prioridade a ser iniciada apenas quando o componenete agricola estiver bem encaminhado.

1.31.31.31.3 O QUE É GERÊNCIA DE PROJETOS?O QUE É GERÊNCIA DE PROJETOS?O QUE É GERÊNCIA DE PROJETOS?O QUE É GERÊNCIA DE PROJETOS?

Gerência de Projetos é a aplicação de conhecimentos, habilidades, e técnicas para projetar atividades que visem atingir os requerimentos do projeto. O Gerenciamento do Projeto é acompanhado através do uso de processos tais como: iniciação, planejamento, execução, controle e encerramento. A equipe de projeto gerência o trabalho do projeto e o trabalho tipicamente envolve:  Demandas concorrentes: escopo, tempo, risco e qualidade  (^) Partes envolvidas com diferentes necessidades e expectativas  Identificação de requerimentos É importante notar que muitos processos dentro da gerência de projetos são naturalmente iterativos. Isto é, em parte, devido a existência e a necessidade da elaboração progressiva no projeto durante todo o ciclo de vida do projeto.; i. e. quanto mais você conhece acerca do seu projeto, melhor você é capaz de gerenciá -lo. O termo gerência de projetos é algumas vezes usado para descrever uma abordagem organizacional para gerenciamento dos processos operacionais contínuos. Esta abordagem, mais conhecida como gerência por projetos , trata muitos aspectos dos serviços continuados como projetos, objetivando aplicar também a eles, os conceitos de gerência de projetos. Embora seja óbvio que o conhecimento de gerência de projetos é essencial para uma organização que aplica a gerência por projetos, uma discussão detalhada dessa abordagem, está fora do escopo deste documento.

O Capítulo 11, Gerência dos Riscos do Projeto , descreve os processos que dizem respeito à identificação, análise e resposta a riscos do projeto. Ele é composto pelo Planejamento da Gerência de Risco, identificação dos riscos, análise qualitativa de riscos, análise quantitativa de riscos , desenvolvimento das respostas aos riscos e controle e monitoração de riscos. O Capítulo 12, Gerência^ das Aquisições^ do Projeto , descreve os processos necessários para a aquisição de mercadorias e serviços fora da organização que desenvolve o projeto. Ele é composto pelo planejamento das aquisições, preparação das aquisições, obtenção de propostas, seleção de fornecedores, administração dos contratos e encerramento do contrato.

Gerência de Projetos

4. Gerência da Integração do Projeto 6. Gerência do Tempo **do Projeto

  1. Gerência dos Recursos Humanos do Projeto
  2. Gerência da Qualidade do Projeto
  3. Gerência do Custo do Projeto** 7 **12. Gerência das Aquisições do Projeto
  4. Gerência das Comunicações** do Projeto 11. Gerência dos Riscos do Projeto

4.1 Desenvolvimento do Plano do Projeto 4.2 Execução do Plano do Projeto 4.3 Controle Integrado de

12.1 Planejamentos das Aquisições 12.2 Preparação das Aquisições

12.4 Seleção de Fornecedores 12.5 Administração dos Contratos 12.6 Encerramento do Contrato

5.1 Iniciação 5.2 Planejamento do Escopo 5.3 Detalhamento do Escopo 5.4 Verificação do Escopo 5.5 Controle de Mudanças do Escopo

6.1 Definição das Atividades 6.2 Sequenciamento das Atividades 6.3 Estimativa da Duração das Atividades 6.4 Desenvolvimento do Cronograma 6.5 Controle do Cronograma

7.1 Planejamento dos Recursos 7.2 Estimativa dos Custos 7.3 Orçamento dos Custos

7.4 Controle dos Custos

8.1 Planejamento da Qualidade 8.2 Garantia da Qualidade 8.3 Controle da Qualidade

9.1 Planejamento Organizaçional 9.2 Montagem da Equipe 9.3 Desenvolvimento da Equipe

10.1 Planejamento das Comunicações 10.2 Distribuição das Informações 10.3 Relato de Desempenho 10.4 Encerramento Administrativo

11.1 Planejamento da Gerência de Riscos

Figura 1-1. Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos

5. Gerência do Escopo do Projeto

11.2 Identificação dos Riscos 11.3 Análise Qualitativa de Riscos

11.5 Desenvolvimento de Resposta a Riscos 11.6 Controle e Monitoração de Riscos

11.4 Análise Quntitativa de Riscos

12.3 Obtenção de Propostas

1.41.4 RELACIONAMENTO 1.41.4RELACIONAMENTORELACIONAMENTORELACIONAMENTO COMCOMCOMCOM OUTRASOUTRASOUTRASOUTRAS

DISCIPLINAS GERENCIAISDISCIPLINAS GERENCIAISDISCIPLINAS GERENCIAISDISCIPLINAS GERENCIAIS

A maior parte do conhecimento necessário para gerenciar projetos é quase específico da disciplina gerência de projetos (como exemplo cita-se a análise de caminho crítico e a estrutura de divisão do trabalho (WBS)). Entretanto, o PMBOK, na verdade, perpassa outras disciplinas de gerência como ilustrado na Figura 1-2. A Administração geral engloba o planejamento, a organização, a alocação de pessoas, a execução e o controle das atividades de uma empresa em funcionamento. A administração geral também inclui disciplinas de suporte tais como , leis, planejamentos estratégicos, logística e gerenciamento de recursos humanos. O PMBOK intercepta a administração geral em muitas áreas – comportamento organizacional, previsão financeira, e técnicas de planejamento, para citar algumas delas. A Seção 2.4 apresenta uma discussão mais detalhada da administração geral. Áreas de Aplicação são categorias de projetos que têm elementos comuns, mas que não estarão presentes, necessariamente, em todos os projetos. As áreas de aplicação são usualmente definidas em termos de:  Departamentos funcionais e disciplinas de suporte, tais comolegal, gerência de produção e de inventário, marketing, logística e pessoal.  Elementos técnicos , tais como desenvolvimento de software, engenharia de abastecimento de água e saneamento, engenharia de construção.  Gerência especializada, tais como contratos com governo, desenvolvimento comunitário ou desenvolvimento de um novo produto.  Grupos de indústria, tais como automotiva, química, agricultura ou financeira. O Apêndice E inclui uma discussão mais detalhada das áreas de aplicação em gerência de projetos.

O Universo de Conhecimentos da Gerência de Projetos

Conhecimentos e Práticas da Gerência de Projetos geralmente aceitas

Conhecimentos e Práticas da Gerência Geral

Conhecimentos e Práticas das Áreas de Aplicação

Esta figura é uma visão conceitual desses relacionamentos As sobreposições mostradas não são proporcionais

Figura 1-2. Relacionamento da Gerência de Projetos com Outras Disciplinas da Administração

Capítulo 2

O Contexto da GerênciaO Contexto da Gerência^ O Contexto da GerênciaO Contexto da Gerência

de Projetosde Projetosde Projetosde Projetos

Tanto os projetos quanto a gerência de projetos se inserem num ambiente bem mais amplo do que o Projeto propriamente dito. A equipe de gerência do projeto deve compreender este contexto mais amplo - a gerência das atividades diárias do projeto é necessária mas não é suficiente para o seu sucesso. Este capítulo descreve os principais aspectos de contexto da Gerência de Projetos não abordados em outras partes deste documento. Os tópicos aqui incluídos são: 2.1 Fases do Projeto e O Ciclo de Vida do Projeto 2.2 Partes envolvidas do Projeto 2.3 Influências da Organização 2.4 Principais Habilidades da Administração Geral 2.5 Influências Sócio-econômica e Ambiental

2.12.12.12.1 FASES DO PROJETO E O CICLO DE VIDA DOFASES DO PROJETO E O CICLO DE VIDA DOFASES DO PROJETO E O CICLO DE VIDA DOFASES DO PROJETO E O CICLO DE VIDA DO

PROJETOPROJETOPROJETOPROJETO

Como os projetos possuem um caráter único, a eles está associado um certo grau de incerteza. As organizações que desenvolvem projetos usualmente dividem-nos em várias fases visando um melhor controle gerencial e uma ligação mais adequada de cada projeto aos seus processos operacionais contínuos^1.. O conjunto das fases de um projeto é conhecido como ciclo de vida do projeto.

2.1.12.1.1^ 2.1.12.1.1^ Características das Fases do ProjetoCaracterísticas das Fases do ProjetoCaracterísticas das Fases do ProjetoCaracterísticas das Fases do Projeto

Cada fase do projeto é marcada pela conclusão de um ou mais produtos da fase (deliverables). Um subproduto é um resultado do trabalho (work product), tangível e verificável, tal como um estudo de viabilidade, um design detalhado ou um protótipo. Os subprodutos do projeto e também as fases, compõem uma seqüência lógica, criada para assegurar uma adequada definição do produto do projeto. A conclusão de uma fase é geralmente marcada pela revisão dos principais subprodutos e pela avaliação do desempenho do projeto tendo em vista (a) determinar se o projeto deve continuar na sua próxima fase e (b) detectar e corrigir erros a um custo aceitável. Estas revisões de fim de fase são comumente denominadas saídas de fase (phase exits), passagens de estágio (stage gates) ou pontos de término ( kill points).

(^1) Tradução do termo inglês “ongoing operations” representando todas as atividades de caráter repetitivo e contínuo ou

seja, não caracterizadas como projeto

Cada fase normalmente inclui um conjunto de subprodutos específicos projetados com o objetivo de estabelecer um controle gerencial desejado. A maioria destes itens estão relacionados com o principal subproduto da fase. As fases, tipicamente, adotam nomes provenientes destes itens: levantamento de necessidades, desenho ou especificação (design), implementação ou construção, testes documentação (text), implantação ou inauguração (start-up), manutenção (turnover), e outros, se apropriados. Alguns ciclos de vida de projeto representativos são descritos na Seção 2.1.3.

2.1.22.1.2 2.1.22.1.2 Características Do Ciclo De Vida Do ProjetoCaracterísticas Do Ciclo De Vida Do ProjetoCaracterísticas Do Ciclo De Vida Do ProjetoCaracterísticas Do Ciclo De Vida Do Projeto

O ciclo de vida do projeto serve para definir o início e o fim de um projeto. Por exemplo, quando uma organização identifica uma oportunidade dentro de sua linha de atuação, normalmente ela solicita um estudo de viabilidade para decidir se deve criar um projeto. O ciclo de vida do projeto determina se o estudo de viabilidade constituirá a primeira fase do projeto ou se deve ser tratado como um projeto à parte. A definição do ciclo de vida do projeto também determina os procedimentos de transição para o ambiente de operação que serão incluídos ao final do projeto, distinguindo- os dos que não serão. Desta forma, o ciclo de vida do projeto pode ser usado para ligar o projeto aos processos operacionais contínuos da organização executora. A seqüência de fases, definida pela maioria dos ciclos de vida de projeto, tais como “solicitações” para “design”, “construção para operações” ou “especificação” para “manufatura”, geralmente envolve alguma forma de transferência de tecnologia ou hand- off,. Os subprodutos oriundos de uma fase normalmente são aprovados antes do início da próxima fase. Entretanto, quando os riscos são considerados aceitáveis, a fase subsequente pode iniciar antes da aprovação dos subprodutos da fase precedente. Esta prática de sobreposição de fases é usualmente chamada de fast tracking^2. Os ciclo de vida dos projetos geralmente definem:  Que trabalho técnico deve ser realizado em cada fase (por exemplo, o trabalho do arquiteto deve fazer parte da fase de definição ou da fase de execução?).  (^) Quem deve estar envolvido em cada fase (por exemplo, Implementadores que necessitam ser envolvidos com levantamento de requisitos e especificação). As descrições do ciclo de vida de projeto podem ser genéricas ou detalhadas. Descrições muito detalhadas podem conter uma série de formulários, diagramas e checklists para prover estrutura e consistência. Estas abordagens detalhadas são freqüentemente chamadas de metodologias de gerência de projeto. A maioria das descrições do ciclo de vida de projeto apresentam algumas características em comum:  O custo e a quantidade de pessoas integrantes da equipe são baixos no início do projeto, sofre incrementos no decorrer do mesmo e se reduzem drasticamente quando seu término é vislumbrado. Este modelo é ilustrado na Figura 2-.  (^) No início do projeto, a probabilidade de terminá-lo com sucesso é baixa e, portanto, o risco e a incerteza são altos. Normalmente a probabilidade de sucesso vai aumentando à medida que o projeto caminha em direção ao seu término.  A capacidade das partes envolvidas de influenciar as características finais do produto do projeto e o seu custo final, é alta no início e vai se reduzindo com o andamento do projeto. Isto acontece, principalmente, porque o custo de mudanças e correção de erros geralmente aumenta à medida que o projeto se desenvolve. Deve-se tomar cuidado para distinguir ciclo de vida de projeto de ciclo de vida do produto. Por exemplo, um projeto para lançar no mercado um novo computador de mesa é somente uma fase ou estágio do ciclo de vida deste produto.

(^2) Compressão do cronograma do projeto pela superposição de atividades que normalmente estariam em sequência.

 Suporte – essa fase é parte do ciclo de vida do produto, mas é certamente um gerenciamento contínuo. Vários projetos podem ser conduzidos durante essa fase para desenvolver capacidades e correção de defeitos, etc. Construçãol. Adaptado por Morris [1] descreve o ciclo de vida de construção como ilustrado na Figura 2-3 :  Viabilidade - formulação do projeto, estudos de viabilidade e formulação e aprovação da estratégia. Uma decisão de continuidade (go/no-go) do projeto faz parte da finalização desta fase.  Planejamento e Projeto - projeto básico, custo e cronograma, termos e condições contratuais, e planejamento detalhado. A maioria dos contratos são fechados ao final desta fase.  Produção - fabricação, entrega, obras civis, instalação e teste. As instalações estão substancialmente completas ao final desta fase.  Adaptação e Lançamento - teste final e manutenção. As instalações estão em plena operação ao final desta fase. Indústria Farmacêutica. Murphy [2] descreve o ciclo de vida do projeto para desenvolvimento de um novo produto farmacêutico nos EUA, como ilustrado na Figura 2-4 :  Investigação e Seleção - inclui pesquisa básica e aplicada para identificação de candidatos para testes pré-clínicos.  Desenvolvimento Pré-clínico - inclui testes de laboratório e animal para determinar a eficácia e segurança da droga. Inclui também a preparação e o registro de “Investigação de Nova Droga” (IND - Investigational New Drug).  Desenvolvimento do(s) Registro(s) - inclui os testes das Fases Clínicas I, II e III, assim como a preparação e registro do “Pedido de Nova Droga” (NDA - New Drug Application).  Atividade Pós-submissão - inclui o trabalho adicional necessário para suportar a revisão do NDA pelo órgão responsável pelo controle de remédios nos Estados Unidos - o FDA (Federal and Drug Administration).

Processos entram nos Marcos A, B ou C (ou dentro das fases Programa fora do orçamento anual quando isso fizer sentido, mas não depois do Marco B

Passo Único ou Evolução para Capacidade Total A B C

Oportunidades Tecnológicas e Necessidades dos Usuários

IOC

Concepção e Desenvolvimento Tecnológico

Produção e Operação

Desenvolvimento de Sistema e Demonstração

Suporte

MNS ORD

Relacionamento para Requisitos do Processo

Todos validados por JROC

Pré-Contratação deSistemas

Contratação de Sistemas (Engenharia, Desenvolvimento, Demonstração, LRIP, e Produção)

Manutenção e Sustentabilidade

Figura 2-2. Representação do Ciclo de Vida para Aquisição da Defesa, por US DODI 5000. (Versão Final da Coordenação, Abril 2000)

Desenvolvimento de Software. Existem muitos modelos do ciclo de vida de software em uso tais como o modelo em cascata. Muench e outros [3] descreve um modelo espiral de desenvolvimento de software com quatro ciclos e quatro quadrantes, como ilustrado na Figura 2-5 :  Ciclo de prova de conceito (proof-of-concept) - captura os requerimentos de negócio, define objetivos para a prova de conceito, produz um desenho conceitual do sistema, projeta e constrói a prova de conceito, produz planos de teste de aceitação, conduz análises de risco e faz recomendações.  Primeiro ciclo de implementação - produz os requerimentos do sistema, define objetivos para a primeira implementação, produz o desenho lógico do sistema, projeta e constrói a primeira implementação, produz planos de teste do sistema, avalia a primeira implementação e faz recomendações.  (^) Segundo ciclo de implementação - produz os requerimentos dos subsistemas, define objetivos para a segunda implementação, produz o desenho físico do sistema, constrói a segunda implementação, produz planos de teste do sistema, avalia a segunda implementação e faz recomendações.  Ciclo final - completa os requerimentos, produz o desenho final do sistema, constrói a implementação final, conduz os testes de unidade, de subsistema, de sistema e de aceitação.

Figura 2-3. Ciclo de Vida Representativo de um Projeto de Contrução Segundo Morris

Decisão de

“GO”

Principais

Contratos

Negociados

Instalação

Praticariente

Completa

Plena

Operação

ESTÁGIO I ESTÁGIO II ESTÁGIO III ESTÁGIO IV

VIABILIDADE PLANEJAMENTO

e DESIGN

PRODUÇÃO ADAPTAÇÃO

e LANÇAMENTO

  • Projeto Básico
  • Custo e Cronograma
  • Termos e Condições Contratuais
  • Planej. Detalhado
  • Formulação do Projeto
  • Estudos de Viabilidade
  • Projeto Estratégico e Aprovação
  • Fabricação
  • Entrega
  • Obras Civis
  • Instalação
  • Teste
  • Teste Final
  • Manutenção

Percentual Completado

Gerenciar as expectativas dos partes envolvidas pode ser uma tarefa difícil porque, freqüentemente, os partes envolvidas possuem objetivos diferentes que podem entrar em conflito. Por exemplo:  O gerente de um departamento que solicitou o desenvolvimento de um novo sistema de informação gerencial, pode desejar um custo baixo, o projetista de sistema pode dar ênfase à excelência técnica, enquanto a empresa de programação contratada pode estar mais interessada na maximização de lucros.

Avaliar Identificar

Construir Projetar

Avaliação

Avaliação

Teste

Liberação

Operação e Suporte à Produção

Requisitos da Unidade Requisitos do Subsistema Requisitos do Sistema Requisitos do Negócio

Análise de Risco

Prova de Conceito Primeira Construção

Segunda Construção

Construção Final

Projeto Conceitual Projeto Lógico Projeto Físico

Projeto Final

Figura 2-5. Ciclo de Vida Representativo de Desenvolvimento de Software, segundo Muench

 O vice-presidente de pesquisa de uma empresa de eletrônica pode definir o sucesso de um novo produto em relação à tecnologia moderna, o vice-presidente de manufatura pode defini-lo em razão de práticas universais e o vice-presidente de marketing pode estar inicialmente preocupado com a quantidade de novas funcionalidades.  O proprietário de um projeto de desenvolvimento de um imóvel pode estar interessado no controle do prazo, o governo local pode desejar maiores receitas em taxas, uma organização de proteção do meio ambiente pode estar interessada na redução de impactos ambientais adversos, enquanto a vizinhança pode Ter a expectativa de transferência do local do projeto. Em geral, divergências entre os partes envolvidas devem ser resolvidas em favor do cliente. Isto, entretanto, não significa que as necessidades e expectativas dos demais partes envolvidas devam ou possam ser desconsideradas. Encontrar soluções apropriadas para tais divergências pode tornar-se um dos principais desafios do gerente de projetos.

2.32.32.32.3 INFLUÊNCIAS DA ORGANIZAÇÃOINFLUÊNCIAS DA ORGANIZAÇÃOINFLUÊNCIAS DA ORGANIZAÇÃOINFLUÊNCIAS DA ORGANIZAÇÃO

Os projetos fazem, tipicamente, parte de uma organização maior - corporações, agências do governo, instituições de saúde, organismos internacionais, associações profissionais e outros. Mesmo que o projeto seja a organização (joint ventures, parcerias) o projeto é ainda influenciado pela organização ou organizações que o estabeleceu. A maturidade da organização com respeito a sistemas de gerência de projeto, cultura, estilo, estrutura organizacional e escritório de gerência de projetos podem, também, influenciar o projeto. As seções seguintes descrevem os principais aspectos destas organizações estruturais maiores que, provavelmente, irão influenciar o projeto.

2.3.12.3.1 2.3.12.3.1 Sistemas da OrganizaçãoSistemas da OrganizaçãoSistemas da OrganizaçãoSistemas da Organização

Organizações orientadas a projeto são aquelas cujas operações consistem, basicamente, de projetos. Estas organizações se enquadram em duas categorias:  Organizações cujas receitas se originam primariamente do desenvolvimento de projetos para terceiros - empresas de arquitetura, empresas de engenharia, consultores, empreiteiros, etc.  Organizações que adotaram o modelo de gerência por projeto (veja Seção 1.3). Estas organizações tendem a ter sistemas de gerenciamento voltados para a gerência de projetos. Por exemplo, seus sistemas financeiros são, freqüentemente, projetados especificamente para contabilizar, acompanhar e relatar múltiplos projetos. Organizações não orientadas a projeto freqüentemente carecem de sistemas de gerenciamento projetados para suportar as necessidades dos projetos de forma efetiva e eficiente. A ausência de sistemas orientados a projetos normalmente dificulta a tarefa de gerenciamento de cada projeto. Em alguns casos, as organizações não orientadas a projeto têm departamentos, ou outras unidades administrativas, operando por projetos com sistemas de suporte adequados. A equipe de gerência do projeto deve estar bastante consciente da forma como os sistemas da organização afetam o projeto. Por exemplo, se a organização recompensa seus gerentes funcionais pelas horas de sua equipe alocadas a projeto, as equipes do projeto podem precisar implementar controles que assegurem que as pessoas alocadas ao projeto estão, efetivamente, trabalhando no projeto.

Por exemplo, quando o desenvolvimento de um novo produto é empreendido em uma organização com estrutura funcional pura, a fase de design é normalmente chamada de “projeto de design” e inclui somente o pessoal do departamento de engenharia. Se questões sobre a manufatura vêem à tona, elas sobem na estrutura hierárquica até a chefia do departamento que consulta a chefia do departamento de manufatura. A chefia do departamento de engenharia então transmite as respostas descendo na estrutura hierárquica até o gerente de projeto de engenharia. Do outro lado do espectro, se encontra a organização com estrutura projetizada como mostrado na Figura 2-8. Numa organização com estrutura projetizada, os membros das equipes freqüentemente trabalham juntos, num mesmo local físico. Neste tipo de estrutura, a maioria dos recursos da organização está envolvida em projetos e os gerentes de projeto têm grande autoridade e independência. Organizações com estrutura projetizada normalmente possuem unidades organizacionais denominadas departamentos. Entretanto, estes departamentos ou se reportam diretamente ao gerente de projeto, ou fornecem serviços de suporte aos diversos projetos existentes. Organizações com estrutura matricial como mostrado nas Figuras 2-9 a 2-11 são uma mistura das características funcional e projetizada. As estruturas matriciais fracas mantêm muitas características da organização com estrutura funcional e o papel do gerente de projeto é mais o de um coordenador ou despachante do que o de um gerente propriamente dito. De modo similar, as estruturas matriciais fortes têm muitas características da organização com estrutura matricial - gerentes de projeto, com considerável autoridade, dedicados ao projeto e pessoal administrativo alocado em tempo integral ao projeto. Na maioria das organizações modernas existem todos estes tipos de estrutura, em diferentes níveis, como mostrado na Figura 2-12. Por exemplo, mesmo numa organização com estrutura fundamentalmente funcional, pode ser necessário criar uma equipe especial de projetos para empreender um projeto de caráter crítico. Esta equipe pode ter muitas das características de um projeto numa organização projetizada. A equipe pode incluir pessoal em tempo integral proveniente de diferentes departamentos funcionais; pode desenvolver seu próprio conjunto de procedimentos operacionais e pode ainda trabalhar fora do padrão hierárquico estabelecido.

Figura 2-7. Organização Funcional

Pessoal Pessoal (As caixas pretas representam os funcionários alocados em atividades de projetos.)

Pessoal

Executivo Chefe

Gerente Funcional

Gerente Funcional

Gerente Funcional

Pessoal (^) Pessoal

Pessoal

Pessoal

Pessoal

Coordenação do Projeto

Pessoal

2.3.42.3.42.3.42.3.4 Escritório de ProjetoEscritório de ProjetoEscritório de ProjetoEscritório de Projeto

Existe um leque de usos para o qual é constituído um escritório de projeto. Um escritório de projeto pode operar em um continuo fornecimento de funções de suporte para os gerentes de projeto na forma de treinamento, software, padrões, etc. Tornando-o realmente responsável pelos resultados do projeto.

2.42.4 PRINCIPAIS HABILIDADES DA ADMINISTRAÇÃO^ 2.42.4PRINCIPAIS HABILIDADES DA ADMINISTRAÇÃOPRINCIPAIS HABILIDADES DA ADMINISTRAÇÃOPRINCIPAIS HABILIDADES DA ADMINISTRAÇÃO

GERALGERALGERALGERAL

A administração geral é um tema amplo que trata de vários aspectos da gerência de processos continuados de uma empresa. Dentre outros tópicos, inclui:  Contabilidade e finanças, marketing e vendas, pesquisa e desenvolvimento, fabricação e distribuição.  Planejamento estratégico, planejamento tático e planejamento operacional.  Estruturas organizacionais, comportamento organizacional, administração de pessoal, compensação, benefícios, e planos de carreira.  Gerência das relações de trabalho através de motivação, delegação, supervisão, desenvolvimento de equipes, gerência de conflitos e outras técnicas.  Auto gerenciamento através da gerência do tempo pessoal, gerência de stress e outras técnicas As habilidades da gerência de projetos se fundamentam em muitos dos conceitos da administração geral. Estas habilidades gerais são freqüentemente essenciais para o gerente de projeto. Em um dado projeto, ter habilidades em algumas áreas da administração geral pode ser um pré-requisito. Esta seção descreve as principais habilidades da administração geral que tendem a influenciar fortemente a maioria dos projetos , e que não serão tratadas em outra parte do PMBOK.

Figura 2-8. Organização Projetizada

(As caixas pretas representam os funcionários alocados em atividades de projetos.)

Coordenação do Projeto

Executivo Chefe

Gerente de Projetos

Pessoal

Gerente de Projetos

Gerente de Projetos

Pessoal

Pessoal

Pessoal

Pessoal

Pessoal

Pessoal

Pessoal

Pessoal