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

pmi - pmbok - gerenciamento de projetos -, Notas de estudo de Cultura

PMBOK Gerenciamento de Projetos

Tipologia: Notas de estudo

2010

Compartilhado em 22/10/2010

andril-serotnik-10
andril-serotnik-10 🇧🇷

5

(2)

30 documentos

1 / 151

Documentos relacionados


Pré-visualização parcial do texto

Baixe pmi - pmbok - gerenciamento de projetos - e outras Notas de estudo em PDF para Cultura, 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 português do PMBOK 2000. É uma tradução livre, não oficial e sem o compromisso de que o texto em português é correto o suficiente para responder a qualquer questão do exame PMP. Todos os direitos autorais de tradução pertencem ao Project Management Institute Headquarters. Quando houver a publicação pelo PMI HQ da versão oficial da PMBOK 2000 português esta versão será retirada da internet. 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 Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 3 Capítulo 1 Introduçã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.1 PROPÓ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: Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 6 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.3 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. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 7 O conhecimento sobre gerência de projetos pode ser organizado de muitas formas. Este documento está estruturado em duas seções principais e 12 capítulos como descrito abaixo: 1.3.1 A Estrutura de Gerência de Projetos Seção I, A Estrutura de Gerência de Projetos, fornece uma estrutura básica para compreensão do assunto gerência de projetos. O Capítulo 1, Introdução, define os termos chaves e apresenta uma visão geral do resto do documento. O Capítulo 2, O Contexto da Gerência de Projetos, descreve o ambiente no qual o projeto opera. A equipe de gerência do projeto devem compreender este contexto amplo – o gerenciamento das atividades diárias do projeto é necessário mas não suficiente. O Capítulo 3, Os Processos da Gerência de Projetos, apresenta uma visão geral da interação entre os diversos processos de gerência de projetos. O entendimento destas interações é essencial para a compreensão do material apresentado do Capítulo 4 até o 12. 1.3.2 As Áreas de Conhecimento da Gerência de Projetos Seção II, As Áreas de Conhecimento da Gerência de Projetos, descreve os conhecimentos e práticas em gerência de projetos em termos dos processos que as compõem. Estes processos foram organizados em nove áreas de conhecimentos como descrito abaixo e como ilustrado na Figura 1-1. O Capítulo 4, Gerência da Integração do Projeto, descreve os processos necessários para assegurar que os diversos elementos do projeto sejam adequadamente coordenados. Ele é composto pelo desenvolvimento do plano do projeto, execução do plano do projeto e controle integrado de mudanças. O Capítulo 5, Gerência do Escopo do Projeto, descreve os processos necessários para assegurar que o projeto contemple todo o trabalho requerido, e nada mais que o trabalho requerido, para completar o projeto com sucesso. Ele é composto pela iniciação, planejamento do escopo, detalhamento do escopo, verificação do escopo e controle de mudanças do escopo. O Capítulo 6, Gerência do Tempo do Projeto, descreve os processos necessários para assegurar que o projeto termine dentro do prazo previsto. Ele é composto pela definição das atividades, seqüenciamento das atividades, estimativa da duração das atividades, desenvolvimento do cronograma e controle do cronograma. O Capítulo 7, Gerência do Custo do Projeto , descreve os processos necessários para assegurar que o projeto seja completado dentro do orçamento previsto. Ele é composto pelo planejamento dos recursos, estimativa dos custos, orçamento dos custos e controle dos custos O Capítulo 8, Gerência da Qualidade do Projeto, descreve os processos necessários para assegurar que as necessidades que originaram o desenvolvimento do projeto serão satisfeitas. Ele é composto pelo planejamento da qualidade, garantia da qualidade e controle da qualidade. O Capítulo 9, Gerência dos Recursos Humanos do Projeto, descreve os processos necessários para proporcionar a melhor utilização das pessoas envolvidas no projeto. Ele é composto pelo planejamento organizacional, montagem da equipe e desenvolvimento da equipe. O Capítulo 10, Gerência das Comunicações do Projeto, descreve os processos necessários para assegurar que a geração, captura, distribuição, armazenamento e pronta apresentação das informações do projeto sejam feitas de forma adequada e no tempo certo. Ele é composto pelo planejamento das comunicações, distribuição das informações, relato de desempenho e encerramento administrativo. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 8 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 9. Gerência dos Recursos Humanos do Projeto 8. Gerência da Qualidade do Projeto 7. Gerência do Custo do Projeto 7 12. Gerência das Aquisições do Projeto 10. 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 Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 11 Capítulo 2 O Contexto da Gerência de 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.1 FASES DO PROJETO E O CICLO DE VIDA DO PROJETO 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ínuos1. . O conjunto das fases de um projeto é conhecido como ciclo de vida do projeto. 2.1.1 Caracterí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 Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 12 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.2 Caracterí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 tracking2. 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-1. ■ 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. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 13 Ainda que muitos ciclos de vida de projeto apresentem nomes de fases similares com resultados de trabalho similares, poucos são idênticos. Embora a maioria tenha quatro ou cinco fases, alguns chegam a ter nove ou mais. Mesmo numa mesma área de aplicação, temos variações significativas – numa organização, o ciclo de vida para desenvolvimento de software pode ter uma única fase de design, enquanto em outra, pode apresentar duas fases, uma para especificação funcional e outra para design detalhado. Subprojetos, dentro dos projetos, podem ter ciclos de vida separados. Por exemplo, uma empresa de arquitetura contratada para projetar um novo prédio de escritórios estará inicialmente envolvida com a fase de definições do contratante, quando da elaboração do projeto, e com a fase de implementação, quando fornecendo suporte à construção. O projeto de desenho arquitetônico, no entanto, terá sua própria série de fases desde a especificação conceitual, passando pela definição e implementação, até o encerramento. O arquiteto pode, ainda, tratar o design do prédio e o suporte à construção como projetos separados com suas próprias fases. 2.1.3 Ciclos de Vida Representativos dos Projetos Os seguintes ciclos de vida foram selecionados para ilustrar a diversidade de abordagens em uso. Os exemplos apresentados são típicos; eles não são nem recomendados nem preferidos. Em cada caso, o nome das fases e os principais subprodutos são aqueles descritos pelo autor para cada uma das figuras. Aquisição pelo Sistema de Defesa. A instrução 5000.2 do Departamento de Defesa Americano, em sua revisão final, abril de 2000 , descreve uma série de fases e marcos para o processo de aquisição, como ilustrado na Figura 2-2. ■ Conceituação e desenvolvimento tecnológico – estudos de alternativas conceituais para encontrar a missão solicitada. Desenvolvimento de subsistemas/componentes e demonstração conceitual/ tecnológica dos novos conceitos do sistema. Termina com a seleção da arquitetura de sistema e a maturidade tecnológica a ser usada. ■ Desenvolvimento de sistema e demonstração – integração do sistema; redução de risco; demonstração dos modelos de engenharia desenvolvidos; desenvolvimento e testes iniciais de operação e avaliações. Encerra com a demonstração do sistema no ambiente operacional. ■ Produção e operação – início de produção em pequena escala (LRIP) ; desenvolvimento completo da capacidade de fabricar; as fases sobrepõem os processos contínuos de operação e suporte. Figura 2-1. Exemplo Genérico de Ciclo de Vida Nível de Custo e Pessoal Fase Inicial Fases Intermediárias (uma ou mais) Fase Final Início Tempo Fim Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 16 2.2 AS PARTES ENVOLVIDAS DO PROJETO Os partes envolvidas são indivíduos e organizações diretamente envolvidos no projeto, ou aqueles cujos interesses podem ser afetados, de forma positiva ou negativa, no decorrer do projeto ou mesmo após sua conclusão; podem, também, exercer influências no projeto e seus resultados. A equipe de gerência do projeto deve identificar as partes envolvidas, conhecer suas necessidades e expectativas e, então, gerenciar e influenciar os requisitos de forma a garantir o sucesso do projeto. A identificação das partes envolvidas geralmente é tarefa difícil. Por exemplo, um trabalhador da linha de montagem, cujo emprego depende do resultado de um projeto de design de um novo produto, seria uma parte envolvida? Em todo projeto existem alguns partes envolvidas principais: ■ Gerente do projeto - indivíduo responsável pela gerência do projeto. ■ Cliente - indivíduo ou organização que fará uso do produto do projeto. Podem existir múltiplas camadas de clientes. Por exemplo, os clientes de um novo produto farmacêutico incluem os médicos que o prescrevem, os pacientes que o tomam e as companhias de seguro que pagam por ele. Em muitas áreas de aplicação, clientes e usuários são sinônimos, enquanto em outras clientes refere-se à entidade que comprou o resultado do projeto e usuários são aqueles quem usarão diretamente o produto do projeto. ■ Organização executora - empresa cujos funcionários estão mais diretamente envolvidos na execução do projeto. ■ Membros da equipe do projeto – o grupo que realiza o trabalho do projeto ■ Patrocinador - indivíduo ou grupo, dentro da organização executora, que provê os recursos financeiros, em dinheiro ou espécie, para o projeto. Existem diferentes nomes e categorias de partes envolvidas do projeto - interno e externo, proprietários e acionistas, fornecedores e empreiteiros, membros da equipe do projeto e seus familiares, agências do governo, agências de publicidade, cidadãos, intermediadores permanentes ou temporários e a sociedade em geral. O ato de se dar nome, ou de se agrupar os partes envolvidas, é um excelente auxílio para se identificar que tipo de indivíduos ou organizações se auto-definem como partes envolvidas. Os papéis e responsabilidades dos partes envolvidas podem se sobrepor como no caso de uma firma de engenharia que financia, ao mesmo tempo que desenvolve o projeto de uma fábrica. Desenvolvimento do Processo Figura 2-4. Ciclo de Vida Representativo de um Projeto Farmacêutico, segundo Murphy Fonte de Droga Candidatos Selecionados Investigação Pré-clínica IND Arquivo IND Processo de Patente Descoberta Investigação Desenvolvimento Pré-clínico Dez ou mais Anos Submissão para Registro Atividade Pós-submissão Arquivo NDA Atividade Pós-registro A P R O V A Ç Ã O Estabilidade de Formulação Toxicologia Metabolismo Testes Clínicos Fase 1 Testes Clínicos Fase 2 Testes Clínicos Fase 3 Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 17 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 Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 18 ■ 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.3 INFLUÊ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.1 Sistemas 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. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 21 2.3.4 Escritó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.4 PRINCIPAIS HABILIDADES DA ADMINISTRAÇÃO GERAL 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 Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 22 Executivo Chefe Gerente Funcional Gerente Funcional Gerente Funcional Pessoal Pessoal Pessoal Pessoal Pessoal Pessoal Pessoal Figura 2-9. Organização Matricial Fraca Coordenação do Projeto (As caixas pretas representam os funcionários alocados em atividades de projetos.) Pessoal Pessoal Executivo Chefe Gerente Funcional Gerente Funcional Gerente Funcional Pessoal Pessoal Pessoal Pessoal Pessoal Pessoal Pessoal Figura 2-10. Organização Matricial Balanceada Coordenação do Projeto (As caixas pretas representam os funcionários alocados em atividades de projetos.) Pessoal Gerente do Projeto Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 23 Executivo Chefe Gerente Funcional Gerente Funcional Gerente Funcional Pessoal Pessoal Pessoal Pessoal Pessoal Pessoal Pessoal Figura 2-11. Organização Matricial Forte Coordenação do Projeto (As caixas pretas representam os funcionários alocados em atividades de projetos.) Pessoal Pessoal Gerente de Gerentes de Projetos Gerente de Projetos Gerente de Projetos Gerente de Projetos Executivo Chefe Gerente Funcional Gerente Funcional Gerente Funcional Pessoal Pessoal Pessoal Pessoal Pessoal Pessoal Figura 2-12. Organização Composta Coordenação do Projeto A (As caixas pretas representam os funcionários alocados em atividades de projetos.) Pessoal Gerente de Gerentes de Projetos Gerente de Projetos Gerente de Projetos Gerente de Projetos Pessoal Pessoal Coordenação do Projeto B Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 26 Política e poder são usados aqui no sentido positivo. Pfeffer [5] define poder como “a capacidade potencial de influenciar comportamento, de modificar o curso dos acontecimentos, de vencer resistências, e conseguir que as pessoas façam coisas que de outra forma não fariam”. De forma similar Eccles [6] afirma que “política é conseguir ações coletivas de um grupo de pessoas que podem ter interesses bastante diferentes. É ter a capacidade de usar conflito e desordem de forma criativa”. O sentido negativo, é claro, deriva do fato de que tentativas de conciliar estes interesses resultam em lutas de poder e jogos organizacionais que podem, eventualmente, conduzir a uma completa improdutividade. 2.5 INFLUÊNCIAS SÓCIO-ECONÔMICAS E AMBIENTAIS Como a administração geral, as influências sócio-econômicas incluem uma ampla gama de assuntos e questões. A equipe de gerência do projeto necessita estar atenta, uma vez que as condições e tendências atuais nesta área podem ter um grande efeito nos seus projetos: uma pequena alteração sócio-econômica, pode se traduzir, usualmente com uma defasagem de tempo, numa verdadeira revolução dentro do projeto. Dentre as diversas influências sócio- econômicas potenciais, algumas categorias principais, que freqüentemente afetam os projetos, são descritas de forma breve a seguir. 2.5.1 Regulamentos e Padrões A International Organization for Standardization (ISO) diferencia regulamentos e padrões da seguinte forma: ■ Um padrão é um “documento aprovado por um organismo reconhecido que provê, pelo uso comum e repetitivo, regras, diretrizes ou características de produtos, processos ou serviços cuja obediência não é obrigatória.” Existem inúmeros padrões em uso, cobrindo todas as áreas, desde a estabilidade térmica dos fluidos hidráulicos até o tamanho dos disquetes de computador. ■ Um regulamento é um “documento que estabelece características de produtos, processos e serviços, incluindo condições administrativas aplicáveis, cuja obediência é obrigatória.” Códigos de obras são exemplos de regulamentos. ■ Deve-se tomar cuidado ao se discutir regulamentos e padrões visto que há uma extensa área nebulosa entre ambos, por exemplo: ■ Padrões freqüentemente iniciam como diretrizes, que descrevem uma abordagem preferencial, e mais tarde, com a adoção generalizada, se transformam num regulamento de fato (por exemplo, o uso do Método do Caminho Crítico para definir o cronograma dos principais projetos de construção civil). ■ A obediência pode ser mandatória em diversos níveis (por exemplo, por uma agência governamental, pela gerência da organização executora ou pela equipe de gerência do projeto). Para muitos projetos, regulamentos e padrões (por qualquer definição) são bem conhecidos e os planos de projeto podem refletir seus efeitos. Em outros casos, a influência é desconhecida e incerta e deve ser considerada na Gerência de Riscos do Projeto descrita no capítulo 11. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 27 2.5.2 Internacionalização À medida que mais e mais organizações se engajam em trabalhos que ultrapassam as fronteiras nacionais, o mesmo acontece com os seus projetos. Adicionalmente aos conceitos tradicionais de escopo, custo, tempo e qualidade, a equipe do projeto deve considerar as diferenças de fuso horário, feriados nacionais e regionais, solicitações de viagem para reuniões face a face, logística de teleconferência e as inconstantes diferenças políticas. 2.5.3 Influências Culturais Cultura é a “totalidade dos padrões de comportamento transmitidos socialmente, artes, crenças, costumes e outros produtos do trabalho e pensamento humano” [8]. Todo projeto deve funcionar dentro do contexto de uma ou mais normas culturais. Esta área de influência inclui práticas políticas, econômicas, demográficas, educacionais, éticas, étnicas, religiosas, e outras áreas de costumes, crenças e atitudes que afetam a forma como as pessoas e organizações interagem. 2.5.3 Sustentabilidade Social – Econômico e ambiental Virtualmente, todo projeto é planejado e implementado em um contexto social, econômico e ambiental e tem impactos negativos e/ou positivos, intencionais ou não. As organizações estão aumentando a responsabilidade sobre os impactos resultantes do projeto (i.e. a destruição de locais arqueológicos em um projeto de construção de estrada), bem como os efeitos dos projetos nas pessoas, na economia e no ambiente muito depois de terem sido concluídos ( i. e. uma rodovia pode facilitar o acesso e a destruição de ambiente ainda primitivo. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 29 Capítulo 3 Os Processos da Gerência de Projetos Gerência de projetos é um esforço interativo – uma ação, ou a falta de ação numa área, usualmente afeta também outras áreas. As interações podem ser diretas e claras, ou podem ser incertas e sutis. Por exemplo, uma mudança de escopo quase sempre afeta o custo do projeto. Entretanto, ela pode ou não afetar o moral da equipe e a qualidade do produto. Estas interações freqüentemente exigem balanceamento entre os objetivos do projeto – consegue-se uma melhoria numa área somente através do sacrifício de desempenho em outra. Balanceamentos específicos de performance podem variar de projeto a projeto e de organização a organização. Uma gerência de projetos satisfatória requer uma administração efetiva dessas interações. Muitos praticantes de gerência de projetos referem a um conjunto de três restrições como a estrutura de trabalho para avaliar as demandas concorrentes. O conjunto das três restrições é freqüentemente descrito como um triângulo onde cada lado ou ângulo representa um dos parâmentos a ser gerenciado pela equipe de projeto. Para auxiliar no entendimento da natureza da integração na gerência de projetos, e para enfatizar a importância da própria integração, este documento descreve a gerência de projetos em termos de seus processos e de suas interações. Este capítulo apresenta uma introdução ao conceito de gerência de projetos como um conjunto de processos interligados, fornecendo assim um fundamento essencial para o entendimento das descrições dos processos contidas nos Capítulos 4 até o 12. Ele inclui as principais seções que se seguem: 3.1 Processos de um Projeto 3.2 Grupos de Processos 3.3 Interações entre os Processos 3.4 Adaptação das Interações entre os Processos 3.5 Mapeamento dos Processos de Gerencia de Projeto 3.1 PROCESSOS DOS PROJETOS Os projetos são compostos de processos. Um processo é “uma série de ações que geram um resultado”[1]. Os processos dos projetos são realizados por pessoas, e normalmente se enquadram em uma das duas categorias: Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 32 É importante notar que as exatas entradas ou saídas de um processo dependem da fase na qual elas estão tratadas. Embora a Figura 3-3 tenha sido desenhada considerando fases e processos distintos, num projeto real haverá muitas sobreposições. O processo de planejamento, por exemplo, deve não somente fornecer detalhes do trabalho a ser feito, para assegurar a correta execução da fase atual, como também fornecer alguma descrição preliminar do trabalho a ser desenvolvido nas fases subsequentes. Este detalhamento progressivo é freqüentemente conhecido como planejamento por ondas sucessivas (em inglês rolling wave planning), indicando que o planejamento é um processo interativo e continuo O envolvimento das partes interessadas nas fases do projeto geralmente aumenta a probabilidade de satisfazer os requisitos do cliente e realizar uma compra interna ou o compartilhamento da propriedade do projeto do projeto entre as partes interessadas que são, freqüentemente, críticas para o sucesso do projeto. 3.3 INTERAÇÕES ENTRE OS PROCESSOS Num grupo de processos, os processos individuais são ligados por suas entradas e saídas. Considerando-se estas ligações, podemos descrever cada processo em termos de: ■ Entradas – documentos ou itens documentáveis que influenciarão o processo. ■ Ferramentas e técnicas – mecanismos aplicados às entradas para criar as saídas. ■ Saídas – documentos ou itens documentáveis resultantes do processo. Os processos de gerência de projetos, que são comuns à maioria dos projetos na maioria das áreas de aplicação, estão listados aqui e descritos em detalhe do Capítulo 4 até o 12. Os números entre parênteses, após os nomes dos processos, identificam o capítulo e a seção onde ele é descrito. As interações entre os processos aqui ilustradas, são também típicas na maioria dos projetos, na maioria das áreas de aplicação. A Seção 3.4 discute a customização das descrições dos processos e de suas interações. 3.3.1 Processos De Iniciação A Figura 3-4 ilustra o único processo deste grupo de processos. ■ Iniciação (5.1) – obter o comprometimento da organização para o início da próxima fase do projeto. 3.3.2 Processos De Planejamento O planejamento é de fundamental importância num projeto, porque executar um projeto implica em realizar algo que não tinha sido feito antes. Como conseqüência, existem relativamente mais processos nessa seção. Entretanto, o número de processos não significa que a gerência de projetos é principalmente planejamento – a quantidade de planejamento elaborada deve estar de acordo com o escopo do projeto e com a utilidade da informação desenvolvida. Planejar é um esforço contínuo durante toda a vida do projeto. Processos de Iniciação 5.1 Iniciação Para os Processos de Planejamento (Figura 3-5) ESCOPO Figura 3-4. Relacionamentos entre os Processos de Iniciação Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 33 Os relacionamentos entre os processos de planejamento são mostrados na Figura 3-5 (este diagrama é uma explosão da elipse denominada “processos de planejamento” da Figura 3-1). Estes processos estão sujeitos a freqüentes interações antes da complementação do plano. Por exemplo, se a data inicialmente prevista para o término for inaceitável, os recursos do projeto, o custo, ou mesmo o escopo podem necessitar de redefinição. Além disto, o planejamento não é uma ciência exata – duas equipes distintas, podem gerar planos muito diferentes para o mesmo projeto. Processos essenciais. Alguns dos processos de planejamento têm dependências bem definidas, que fazem com que eles sejam executados essencialmente na mesma ordem, na maioria dos projetos. Por exemplo, as atividades devem ser definidas antes do estabelecimento do seu cronograma e custo. Estes processos essenciais de planejamento podem interagir várias vezes durante qualquer fase de um projeto. Eles incluem: Processos Facilitadores 5.2 Planejamento do Escopo 5.3 Detalhamento do Escopo 6.1 Definição das Atividades 7.1 Planejamento dos Recursos 6.2 Sequenciamento Das Atividades 7.2 Estimativa dos Custos 7.3 Orçamento dos Custos 8.1 Planejamento da Qualidade 10.1 Planejamento das Comunicações 11.2 Identificação dos Riscos 11.3 Análise Qualitativa dos Riscos 9.1 Planejamento Organizacional 9.2 Montagem da Equipe 12.1 Planejamento das Aquisições 12.2 Preparação das Aquisições Dos Processos de Iniciação (Figura 3-4) Dos Processos de Controle (Figura 3-7) Para os Processos de Execução (Figura 3-6) Figura 3-5. Relacionamentos entre os Processos de Planejamento Processos de Planejamento Processos Essenciais 11.1 Planejamento da Gerência de Risco 6.3 Estimativa da Duração Das Atividades 6.4 Desenvolvimento do Cronograma 11.4 Análise Quantificativa dos Riscos 11.5 Planejamento de Resposta a Riscos Escopo Recursos Humanos Recursos Humanos Qualidade Comunicação Risco Risco Risco Risco Aquisição Aquisição Escopo Tempo Tempo Tempo Custo Custo Custo Tempo Custo Integração 4.1 Desenvolvimento do Plano do Projeto Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 34 ■ Planejamento do Escopo (5.2) – desenvolver uma declaração escrita do escopo, como base para futuras decisões no projeto. ■ Detalhamento do escopo (5.3) – subdividir os principais subprodutos do projeto em componentes menores e mais manuseáveis. ■ Definição das Atividades (6.1) – identificar as atividades específicas que devem ser realizadas para produzir os diversos subprodutos do projeto. ■ Seqüenciamento das Atividades (6.2) – identificar e documentar as dependências entre as atividades. ■ Estimativa da Duração das Atividades (6.3) – estimar o número de períodos de trabalho (prazos) que serão necessários para completar as atividades individuais. ■ Desenvolvimento do Cronograma (6.4) – criar o cronograma do projeto a partir da análise da seqüência das atividades, suas durações, e as necessidades de recursos. ■ Planejamento da Gerência de Risco (11.1) – Decidir como abordar e planejar a gerência de risco no projeto. ■ Planejamento dos Recursos (7.1) – determinar que recursos (pessoas, equipamentos, materiais, etc.) devem ser utilizados, e em que quantidades, para a realização das atividades do projeto. ■ Estimativa dos Custos (7.2) – desenvolver uma aproximação (estimativa) dos custos dos recursos que são necessários para completar as atividades do projeto. ■ Orçamento dos Custos (7.3) – alocar a estimativa dos custos globais aos pacotes individuais de trabalho. ■ Desenvolvimento do Plano do Projeto (4.1) – agregar os resultados dos outros processos de planejamento construindo um documento coerente e consistente. Processos facilitadores. As interações entre os demais processos de planejamento são mais dependentes da natureza do projeto. Por exemplo, em alguns projetos pode haver sido identificado apenas um pequeno risco ou mesmo nenhum, até que a maioria do planejamento tenha sido concluído e a equipe reconheça que as metas de custo e prazo são por demais ousadas, envolvendo assim um risco considerável. Ainda que estes processos facilitadores sejam realizados intermitentemente, e à medida que são necessários, durante o planejamento do projeto, eles não são opcionais. Eles incluem: ■ Planejamento da Qualidade (8.1) – identificar os padrões de qualidade relevantes para o projeto e determinar como satisfazê-los. ■ Planejamento Organizacional (9.1) – identificar, documentar, e atribuir papéis, responsabilidades e relações hierárquicas no projeto. ■ Montagem da Equipe (9.2) – conseguir que os recursos humanos necessários sejam designados e alocados ao projeto. ■ Planejamento das Comunicações (10.1) – determinar as necessidades da ■ As partes envolvidas quanto à informação e comunicação: quem necessita de qual informação, quando necessita e como a informação será fornecida. ■ Identificação dos Riscos (11.2) – determinar os riscos prováveis do projeto e documentar as características de cada um. ■ Análise Qualitativa dos Riscos (11.3) – analisar qualitativamente os riscos e condições para priorizar seus efeitos nos objetivos do projeto. ■ Análise Quantitativa dos Riscos (11.4) – mensurar a probalidade e impacto dos riscos e estimar suas implicações nos objetivos do projeto. ■ Planejamento de Resposta a Riscos (11.5) – desenvolver procedimentos e técnicas para aumentar as oportunidades e para reduzir ameaças de riscos para os objetivos do projeto. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 37 3.3.5 Processos de Encerramento A Figura 3.8 ilustra como interagem os processos que se seguem: ■ Encerramento dos Contratos (12.6) – completar e liquidar o contrato, incluindo a resolução de qualquer item pendente. ■ Encerramento Administrativo (10.4) – gerar, reunir e disseminar informações para formalizar o término da fase ou projeto, incluindo avaliações do projeto e compilação das lições aprendidas para uso em planejamentos de futuros projetos ou fases. 3.4 ADAPTAÇÕES NAS INTERAÇÕES DE PROCESSOS Os processos identificados e as interações ilustradas na Seção 3.3 satisfazem os testes gerais de aceitação – eles se aplicam à maioria dos projetos durante a maior parte do tempo. Entretanto, nem todos os processos serão necessários, e nem todas as interações se aplicam, em todos os projetos. Por exemplo: ■ Uma organização que faz amplo uso da contratação de terceiros, pode explicitar exatamente onde , no processo de planejamento, cada contratação deve ocorrer. ■ A ausência de um processo não significa que ele não deve ser executado. A equipe de gerência do projeto deve identificar e gerenciar todos os processos que são necessários para assegurar o sucesso do projeto. ■ Os projetos que são dependentes de recursos únicos (desenvolvimento de software comercial, biofarmacêuticos,etc) podem definir papéis e responsabilidades mesmo antes da detalhamento do escopo, uma vez que o que pode ser feito depende dos recursos disponíveis. ■ Algumas saídas de processos podem ser predefinidas como restrições. Por exemplo, a administração pode definir uma data de término fixa, em vez de permitir que ela seja determinada pelo processo de planejamento. Uma data de conclusão imposta pode aumentar o risco do projeto, adicionar custos e compeometer a qualidade. ■ Grandes projetos podem necessitar de maiores detalhes. Por exemplo, a identificação de riscos pode ser subdividida para focalizar separadamente os riscos de custo, riscos de prazo, riscos técnicos, e riscos de qualidade. ■ Em subprojetos e projetos menores, gasta-se um pequeno esforço nos processos cujas saídas já tenham sido definidas ao nível do projeto ( por exemplo, um subcontratado pode ignorar os riscos explicitamente assumidos pelo contratante) ou nos processos que tenham apenas uma utilidade marginal (pode não existir um plano de comunicação formal para um projeto de quatro pessoas). Dos Processos de Controle (Figura 3-7) Figura 3-8. Relacionamentos entre os Processos de Encerramento Processos de Encerramento 12.6 Encerramento dos Contratos 10.4 Encerramento Administrativo Aquisição Comunicação Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 38 Grupos de Processos Áreas de Conhecimento Iniciação Planejamento Execução Controle Encerramento 4. Gerência de Integração do Projeto 4.1 Desenvolvimento do Plano do Projeto 4.2 Execução do Plano do Projeto Controle Integrado de Mudanças 5. Gerência de Escopo do Projeto 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ça de Escopo 6. Gerência de Tempo do Projeto 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. Gerência de Custo do Projeto 7.1 Planejamento dos Recursos 7.2 Estimativa dos Custos 7.2 Orçamento dos Custos 7.4 Controle de Custo 8. Gerência da Qualidade do Projeto 8.1 Planejamento da Qualidade 8.2 Garantia da Qualidade 8.3 Controle da Qualidade 9. Gerência de Recursos Humanos do Projeto 9.1 Planejamento Organizacional 9.2 Montagem da Equipe 9.3 Desenvolvimento da Equipe 10. Gerência de Comunicação do Projeto 10.1 Planejamento das Comunicações 10.2 Distribuição das Informações 10.3 Relato de Desempenho 10.4 Encerramento Administrativo 11. Gerência de Risco do Projeto 11.1 Planejamento da Gerência de Risco 11.2 Identificação dos Riscos 11.3 Análise Qualitativa dos Riscos 11.4 Análise quantitativa dos Riscos 11.5 Planejamento de Respostas a Riscos 11.6 Controle e Monitoração dos Riscos 12. Gerência de Aquisição do Projeto 12.1 Planejamento das Aquisições 12.2 Preparação das Aquisições 12.3 Pedido de propostas 12.4 Seleção de Fornecedores 12.5 Administração dos Contratos 12.6 Encerramento dos Contratos 3.5 Mapeamento dos Processos de Gerencia de Projeto A figura 3-9 apresenta o mapeamento dos trinta e nove processos de gerência de projeto em cinco grupos de processos de gerencia de projeto: iniciação, planejamento, execução, controle e encerramento e nas nove áreas de conhecimento de gerência de projeto descritas nos capítulos 04 a 12. Esse diagrama não é de modo algum exclusivo, mas indica geralmente onde o processo de gerência de projeto encaixa tanto nos grupos de processos de gerência de projeto quanto nas áreas de conhecimento de gerência de projeto. Figura 3.9 Mapeamento dos Processos de Gerência de Projeto em Grupos de processos e Áreas de Conhecimento Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 41 Capítulo 4 Gerenciamento da Integração do Projeto O Gerenciamento da Integração do Projeto inclui os processos requeridos para assegurar que os diversos elementos do projeto estão adequadamente coordenados. Ela envolve fazer compensações entre objetivos e alternativas eventualmente concorrentes, a fim de atingir ou superar as necessidades e expectativas. Enquanto todos os processos de gerência de projetos são de alguma maneira integrados, os processos descritos neste capítulo são por natureza integrativos. A Figura 4-1 fornece uma visão geral dos seguintes processos principais: 4.1 Desenvolvimento do Plano do Projeto - agregar os resultados dos outros processos de planejamento construindo um documento coerente e consistente. 4.2 Execução do Plano do Projeto - levar a cabo o projeto através da realização das atividades nele incluídas. 4.3 Controle Integrado de Mudanças – coordenar as mudanças através do projeto inteiro. Estes processos interagem uns com os outros e também com os processos das demais áreas de conhecimento. Cada processo pode envolver esforço de um ou mais indivíduos ou grupos de indivíduos dependendo das necessidades do projeto. Cada processo geralmente ocorre pelo menos uma vez em cada fase do projeto. Embora os processos sejam aqui apresentados como elementos discretos e interfaces bem definidas, na prática eles podem se sobrepor e interagir de outras maneiras . As interações entre os processos são discutidas no Capitulo 3. Os processos, ferramentas, e técnicas usadas para integrar os processos de gerência de projetos são o foco deste capítulo. Por exemplo, a gerência de integração do projeto começa quando uma estimativa de custo é necessária para um plano de contingência ou quando os riscos associados com várias alternativas de recursos humanos precisam ser definidas. Entretanto, para um projeto ser completado com sucesso, a integração, da mesma forma, deve também ocorrer em diversas outras áreas: ■ O trabalho do projeto deve ser integrado com as operações continuadas da organização executora ■ O escopo do produto e o escopo do projeto devem ser integrados (as diferenças entre o escopo do produto e do projeto é abordada na introdução do Capítulo 5). Uma das técnicas usadas tanto para integrar os vários processos quanto para medir o desempenho do projeto desde a iniciação até a conclusão é a gerência de valor agregado (Earned Value Management - EMV). EMV será discutido nesse apítulo como uma metodologia de integração de projeto, enquanto valor agregado (erned value – EV), a técnica será discutida em outros capítulos como ferramenta para medir o desempenho contra o plano do projeto. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 44 Por exemplo, se a data na qual uma pessoa chave estará disponível para o projeto é incerta, a equipe pode assumir uma data de início específica. As premissas geralmente envolvem certo grau de risco. 4.1.2 Ferramentas e Técnicas para o Desenvolvimento do Plano do Projeto .1 Metodologia de planejamento de projetos. Uma metodologia de planejamento de projetos é uma abordagem estruturada usada para guiar a equipe do projeto durante o desenvolvimento do plano. Ela pode ser simples como formulários padrões e modelos (papel ou eletrônico, formal ou informal) ou tão complexa como uma série de simulações requeridas (por exemplo, análise de risco de prazos utilizando a técnica Monte Carlo). A maioria das metodologias de planejamento de projetos fazem uso de uma combinação de ferramentas “hard” como software de gerência de projetos, e outras “soft” como reuniões facilitadoras de início de projeto. .2 Habilidades e conhecimentos das partes envolvidas. Cada parte envolvida tem habilidades e conhecimentos que podem ser úteis no desenvolvimento do plano do projeto. A equipe de gerência do projeto deve criar um ambiente no qual as partes envolvidas possam contribuir apropriadamente (veja também a Seção 9.3, Desenvolvimento da Equipe). Quem irá contribuir, qual será cada contribuição e quando, tudo isso irá variar ao longo do projeto. Por exemplo: ■ Num projeto de construção sob um contrato na modalidade preço total (lump sum), o engenheiro de custo profissional terá maior contribuição aos objetivos de lucro, durante a preparação da proposta, quando a quantidade do contrato está sendo determinada. ■ Num projeto onde a equipe é definida a priori, os colaboradores individuais podem contribuir significativamente para o alcance dos objetivos de custo e prazo, revendo as estimativas de duração e esforço com racionalidade. .3 Sistema de informação de gerenciamento de projetos. Um sistema de informações de gerência de projetos consiste de ferramentas e técnicas usadas para reunir, integrar, e disseminar as saídas dos outros processos de gerência de projetos. Ele é usado para suportar todos os aspectos, desde a iniciação até o encerramento, e pode incluir sistemas manuais e automatizados. .4 Gerência de Valor Agregado (EVM) – uma técnica usada para integrar o escopo, cronograma e recursos do projeto e para medir e reportar o desempenho do projeto do início ao encerramento. Discussões mais detalhadas sobre EVM podem ser encontradas na seção 7.4.2.3. 4.1.3 Saídas do Desenvolvimento do Plano do Projeto .1 Plano do projeto. O plano do projeto é um documento aprovado formalmente, usado para gerenciar e controlar a execução do projeto. O cronograma do projeto lista as datas planejadas para a execução das atividades e para encontrar os marcos identificados no plano do projeto. O plano de projeto e o cronograma devem ser distribuídos de acordo com o que foi definido no plano de gerência de comunicações (por exemplo, a gerência da organização executora pode solicitar cobertura ampla com pouco detalhe, enquanto um empreiteiro pode exigir bastante detalhe num único item. Em algumas áreas de aplicação, o termo plano integrado do projeto é usado para referenciar este documento. Uma clara distinção deve ser feita entre o plano do projeto e os “baselines” de medidas de desempenho do projeto. O plano do projeto é um documento, ou uma coleção de documentos, para o qual são esperadas mudanças na medida em que mais informações se tornam disponíveis no decorrer no projeto. As medidas básicas de desempenho usualmente mudarão apenas intermitentemente e assim mesmo apenas em reposta a uma mudança aprovada de escopo do trabalho ou de subproduto. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 45 Há várias maneiras de organizar e apresentar o plano do projeto, o qual, de uma maneira geral, inclui todos os seguintes itens (esses itens são descritos em mais detalhes em outros lugares neste manual): ■ Project Charter3 ■ Descrição da abordagem ou estratégia da gerência de projetos (um sumário dos planos de gerência individuais das outras área de conhecimento). ■ Declarações de escopo que incluem os objetivos e os subprodutos do projeto. ■ Estrutura Analítica do Projeto (EAP) até o nível onde o controle deve ser exercido, como um documento de base do escopo. ■ Estimativas de custos, datas programadas para início e fim das atividades e atribuições de responsabilidade para cada subproduto do EAP no nível para o qual o controle pode ser exercido. ■ Documentos base de medicão de desempenho para escopo técnico, cronograma e custo- i. e. baseline do escopo (cronograma do projeto) e baseline de custo (orçamento na fase de tempo do projeto). ■ Principais marcos e suas datas previstas. ■ Mão de obra chave ou necessária e sua expectativa de custo e/ou esforço. ■ Plano de gerência do risco, incluindo: principais riscos, incluindo restrições e premissas , e as respostas planejadas para cada um deles, quando apropriado. ■ Planos auxiliares de gerenciamento, denominados: ♦ Plano de gerência do escopo (seção 5.2.3.3) ♦ Plano de gerência do cronograma (seção 6.4.3.3) ♦ Plano de gerência do Custo (seção 7.2.3.3) ♦ Plano de gerência de qualidade (seção 8.1.3.1) ♦ Plano de gerência de recurso (seção 9.1.3.2) ♦ Plano de gerência de comunicação (seção 10.1.3.1) ♦ Plano de resposta a risco (seção 11.5.3.1) ♦ Plano de gerência de terceirização (seção 12.1.3.1) Cada um desses planos pode ser incluído, se necessário, e com o detalhamento requerido para cada projeto específico. ■ Questões por resolver e decisões pendentes. Outras saídas do planejamento do projeto devem ser incluídas no plano formal de acordo com as necessidade do projeto específico. Por exemplo, um plano de projeto para um projeto de grande porte incluirá um diagrama da organização do projeto. .2 Detalhes de suporte. Os detalhes de suporte para o projeto incluem: ■ Saídas dos outros processos de planejamento não incluídas no plano do projeto. ■ Informação ou documentação adicional gerada durante o desenvolvimento do plano do projeto (por exemplo, restrições e premissas que não eram conhecidas previamente). ■ Documentação técnica como históricos de todos os requisitos, especificações e desenhos conceituais. ■ Documentação sobre padrões relevantes. ■ Especificações do início do planejamento do desenvolvimento do projeto. Este material deve ser organizado de maneira a facilitar o seu uso durante a execução do plano do projeto. 3 Documento fomal emitido por um executivo externo ao projeto reconhecendo a existência do mesmo e a autoridade do gerente designado. Contém os requisitos chaves que o projeto deve alcançar e uma breve descrição do seu produto. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 46 4.2 EXECUÇÃO DO PLANO DO PROJETO A execução é o processo básico de realização do plano do projeto – pois é nele que a grande maioria do orçamento do projeto será gasta. Neste processo, o gerente e a equipe de gerência do projeto devem coordenar e direcionar as diversas interfaces técnicas e organizacionais do projeto. Além disto, é o processo mais diretamente afetado pela área de aplicação do projeto, pois é exatamente nele que o produto do projeto é criado. O desempenho contra o baseline do projeto deve ser continuamente monitorado e então as ações corretivas podem ser tomadas baseadas no desempenho real contra o plano do projeto. Previsões periódicas do custo final e resultados do cronograma serão usadas para suportar a análise. 4.2.1 Entradas para a Execução do Plano do Projeto .1 Plano do projeto. O plano do projeto é descrito na Seção 4.1.3.1. Os planos de gerência auxiliares (plano de gerência de escopo, plano de gerência de risco, plano de gerência de aquisições, planos de configuração, etc.) e as medidas básicas de desempenho são entradas chave para a execução do plano do projeto. .2 Detalhes de suporte. Os detalhes de suporte são descritos na Seção 4.1.3.2. .3 Políticas organizacionais. As políticas organizacionais são descritas na Seção 4.1.1.3. Qualquer uma das organizações envolvidas no projeto pode ter políticas formais e informais que podem afetar a execução do plano do projeto. .4 Ações preventivas. Ação preventiva é qualquer coisa que reduz a probabilidade das conseqüências potenciais dos eventos de risco do projeto. .5 Ações corretivas. Ação corretiva é qualquer ação tomada com o objetivo de alterar o desempenho futuro do projeto de maneira a compatibilizá-lo com o seu plano. A ação corretiva aparece como saída em diversos processos de controle. Aqui aparece como entrada, fechando assim o círculo de “feedback” necessário para assegurar a efetiva gerência do projeto. 4.2.2 Ferramentas e Técnicas para a Execução do Plano do Projeto .1 Habilidades da administração geral. Habilidades da administração geral tais como liderança, comunicação, e negociação são essenciais para uma efetiva execução do plano do projeto. As habilidades da administração geral são descritas na Seção 2.4. .2 Habilidades técnicas e conhecimento do produto. A equipe do projeto deve apresentar um conjunto de habilidades e conhecimentos sobre o produto do projeto. As habilidades necessárias são definidas como parte do planejamento (especialmente no planejamento de recursos, Seção 7.1) e são providas durante o processo de alocação de pessoal. .1 Habilidades da adm. geral .2 Habilidades técnicas e conhecimento do produto .3 Sistema de autorização do trabalho .4 Reuniões de rev. de status .5 Sistema de informação de gerenciamento de projetos .6 Procedimentos organizacionais Ferramentas e Técnicas .1 Plano do projeto .2 Detalhes de suporte .3 Políticas organizacionais .4 Ações corretivas .1 Resultados do trabalho .2 Requisições de mudança . Saídas Entradas Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 49 Em muitos casos, a organização executora tem um sistema de controle de mudanças que pode ser utilizado diretamente pelo projeto. Entretanto, se não existir um sistema disponível, a própria equipe de gerência do projeto deve desenvolver um. Muitos sistemas de controle de mudança incluem um grupo responsável para aceitar ou rejeitar propostas de mudança. As regras e responsabilidades desse grupo são claramente definidas dentro do sistema de controle de mudança e aceitas por todas as partes envolvidas. As organizações variam por definições da diretoria; entretanto, algumas ocorrências comuns são configuration control board (ccb), enginerring review board (erb), technical review board ( trb), technical assessment board (tab) e uma variedade de outras. O sistema de controle de mudança deve, também, incluir procedimentos para que possam ser aprovadas sem previa revisão, por exemplo, como resultado de emergências. Tipicamente, um sistema de controle de mudança deve permitir aprovações automáticas de categorias definidas de mudanças. Essa mudanças devem, ainda, ser documentadas e apreendidas e então a avaliação do baseline pode ser documentada. .2 Gerência de Configuração. A gerência de configuração é um qualquer procedimento documentado usado para aplicar orientação e supervisão técnica administrativa com o objetivo de: ■ Identificar e documentar as características físicas funcionais de um item ou sistema ■ Controlar qualquer mudança que venha ocorrer nessas características. ■ Registrar e relatar a mudança e seu estágio de implementação. ■ Auditar os itens e sistemas para verificar o atendimento aos requisitos. Em muitas áreas de aplicação, a gerência de configuração é um subconjunto do sistema de controle de mudanças e é usado para assegurar que a descrição do produto do projeto está correta e completa. Já em algumas outras áreas de aplicação, o termo gerência de configuração é usado para designar um sistema rigoroso de controle de mudanças. 3 Medidas de desempenho. Técnicas de medida de desempenho tais como o “valor do trabalho realizado”4 (descrito na Seção 10.3.2.4) auxiliam a avaliar quando as variâncias do plano exigem uma ação corretiva. .4 Planejamento adicional. Os projetos raramente são executados exatamente de acordo com o plano. Mudanças programadas podem requerer novas estimativas ou mesmo revisões de custo, modificação na seqüência das atividades, cronogramas, requisitos de recursos, análise de alternativas de resposta a riscos, ou outros ajustes no plano do projeto. .5 Sistema de informação de gerenciamento de projetos. Os sistemas de informações de gerenciamento de projetos são descritos na Seção 4.1.2.3. 4.3.3 Saídas do Controle Integrado de Mudanças .1 Atualizações no plano do projeto. Atualização no plano do projeto é uma modificação qualquer no plano ou nos detalhes de suporte (descritos na Seção 4.1.3.1 e 4.1.3.2, respectivamente). As partes envolvidas envolvidos devem ser notificados, se necessário. .2 Ações corretivas. As ações corretivas são descritas na Seção 4.2.1.5. .3 Lições aprendidas. As causas das variâncias, as razões por trás das ações corretivas tomadas, e outros tipos de aprendizado prático, devem ser documentados integrando um banco de dados histórico não só para o projeto em andamento, mas para os demais projetos da organização executora. O banco de dados é, também, a base para a gerência do conhecimento. 4 Importante método de medida de desempenho do projeto. Compara simultaneamente o trabalho planejado, com o que foi realizado, para avaliar como o projeto está, em termos de prazo e custo. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 51 Capítulo 5 Gerenciamento do Escopo do Projeto A Gerência do Escopo do Projeto abrange os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho necessário, para complementar de forma bem sucedida o projeto (1). A preocupação fundamental compreende definir e controlar o que está, ou naõ, incluído no projeto. A Figura 5-1 fornece uma visão geral dos principias processos da gerência do escopo do projeto: 5.1 Iniciação – autorizar o projeto ou fase. 5.2 Planejamento do Escopo – desenvolver uma declaração escrita do escopo como base para decisões futuras do projeto. 5.3 Detalhamento do escopo – subdividir os principais subprodutos do projeto em componentes menores e mais manejáveis. 5.4 Verificação do Escopo – formalizar a aprovação do escopo do projeto. 5.5 Controle de Mudanças do Escopo – controlar as mudanças no escopo do projeto. Estes processos interagem uns com os outros e também com os processos das demais áreas de conhecimento. Cada processo pode envolver esforço de um ou mais indivíduos ou grupos de indivíduos dependendo das necessidades do projeto. Cada processo geralmente ocorre pelo menos uma vez em cada fase do projeto. Embora os processos sejam aqui apresentados como elementos discretos e interfaces bem definidas, na prática eles podem se sobrepor e interagir de outras maneiras . As interações entre os processos são discutidas no Capitulo 3. No contexto de projeto, o termo escopo deve se referir a : • Escopo do produto – aspectos e funções que caracterizam um produto ou serviço. • Escopo do projeto – o trabalho que deve ser feito com a finalidade de fornecer um produto de acordo com os aspectos e as funções especificados. Os processos, ferramentas e técnicas usados para gerenciar o escopo do projeto são o foco deste capítulo. Os processos, ferramentas e técnicas usados para gerenciar o escopo do produto variam conforme a área de aplicação e são usualmente definidos como parte do ciclo de vida do projeto (o ciclo de vida do projeto é discutido na Seção 2.1). Um projeto geralmente produz um único produto, mas esse produto pode incluir elementos subsidiários, cada um deles com seu próprio, mas interdependente, escopo de produto. Por exemplo, um novo sistema de telefonia geralmente inclui quatro elementos subsidiários – hardware, software, treinamento e implementação. O escopo do projeto é mensurado contra o plano do projeto, enquanto o escopo do produto é mensurado contra os requisitos do produto. Ambos os tipos de gerenciamento de escopo devem ser bem integrados para garantir que o trabalho do projeto resulte na entrega do produto especificado. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 52 .1 Entradas .1 Estrutura Analítica do Projeto (WBS) .2 Relatórios de performance .3 Requisições de mudança .4 Plano de gerência do escopo .2 Ferramentas e Técnicas .1 Sistema de controle de mudanças do escopo .2 Medição da performance .3 Planejamento adicional .3 Saídas .1 Mudanças do escopo .2 Ações corretivas .3 Lições aprendidas .4 Baseline ajustado .1 Entradas .1 Resultados do trabalho .2 Documentação do produto .3 Estrutura Analítica do Projeto (WBS) .4 Declaração do Escopo .5 Plano do Projeto .2 Ferramentas e Técnicas .1 Inspeção .3 Saídas .1 Aceitação formal .1 Entradas .1 Declaração do escopo .2 Restrições .3 Premissas .4 Saídas de outros planejamentos .5 Informações históricas .2 Ferramentas e Técnicas .1 Modelos de Analítica do Projeto (Work Breakdown Structure templates) .2 Decomposição .3 Saídas .1 Estrutura Analítica do Projeto (Work Breakdown Structure - WBS) .2 Alterações na Declaração do Escopo .1 Entradas .1 Descrição do produto .2 Project charter .3 Restrições .4 Premissas .2 Ferramentas e Técnicas .1 Análise do produto .2 Análise de custo/benefício .3 Identificação de alternativas .4 Avaliação especializada .3 Saídas .1 Declaração do escopo .2 Detalhes de suporte .3 Plano de gerência do escopo .1 Entradas .1 Descrição do produto .2 Plano estratégico .3 Critérios para seleção do projeto .4 Informações históricas .2 Ferramentas e Técnicas .1 Métodos de seleção do projeto .2 Avaliação especializada .3 Saídas .1 Project charter ( Mapa do projeto) .2 Gerente do projeto identificado e designado .3 Restrições .4 Premissas Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 55 Quando um projeto é executado sob contrato, o contrato assinado servirá, geralmente, como o project charter para o vendedor. .2 Gerente do projeto identificado e designado. Em geral, o gerente do projeto deve ser identificado e designado o mais cedo possível. O gerente do projeto deve ser sempre designado antes do início da execução do plano do projeto (descrito na Seção 4.2) e preferencialmente muito antes que o planejamento do projeto seja feito ( os processos de planejamento do projeto estão descritos na Seção 3.3.2). .3 Restrições. As restrições são fatores que limitarão as opções da equipe de gerência do projeto. Por exemplo, um orçamento pré-definido é uma restrição que na maioria das vezes limita as opções da equipe com relação a escopo, pessoal e prazos. Quando um projeto é desenvolvido sob contrato, as cláusulas contratuais serão geralmente restrições. Outro exemplo é uma exigência de que o produto do projeto seja sustentável do ponto de vista social, econômico e ambiental, o que trará repercussões no escopo, na equipe e no prazo do projeto. .4 Premissas. Ver Seção 4.1.1.5. 5.2 Planejamento do Escopo O planejamento do escopo é o processo de elaborar e documentar progressivamente o trabalho do projeto (escopo do projeto) produzindo o produto do projeto. O planejamento do escopo começa com as entradas iniciais da descrição do produto, project charter, e a definição inicial das restrições e premissas. Note que a descrição do produto incorpora requisitos do produto que refletem as necessidades dos clientes e o desenho do produto que suporta os seus requisitos. As saídas do planejamento do escopo são a declaração do escopo e o plano de gerenciamento do escopo. As equipes do projeto desenvolvem múltiplas declarações de escopo que deverão ser apropriadas para o seu nível de decomposição do trabalho do projeto. 5.2.1 Entradas para o Planejamento do Escopo .1 Descrição do Produto. A descrição do produto é discutida na Seção 5.1.1.1. .2 Project Charter. O project charter é descrito na Seção 5.1.3.1. .3 Restrições. As restrições estão descritas na Seção 5.1.3.3. .4 Premissas. As premissas estão descritas na Seção 4.1.1.5. Entradas Ferramentas e Técnicas Saídas .1 Descrição do produto .2 Project charter .3 Restrições .4 Premissas .1 Análise do produto .2 Análise de custo/benefício .3 Identificação de alternativas .4 Avaliação especializada .1 Declaração do escopo .2 Detalhes de suporte .3 Plano de gerenciamento do escopo Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 56 5.2.2 Ferramentas e Técnicas para o Planejamento do Escopo .1 Análise do produto. A análise do produto envolve desenvolver um melhor entendimento do produto do projeto. Isso inclui técnicas como a análise de decomposição do produto, engenharia de sistemas, engenharia de valor, análise de valor, análise de funções e desdobramento da função qualidade. .2 Análise de custo/benefício. A análise de custo/benefício envolve estimar custos tangíveis e intangíveis (outlays – gastos) e benefícios (returns - receitas) das várias alternativas de projeto e produto e, então, usar medidas financeiras tais como retorno de investimento ou período de reembolso para avaliar a qualidade relativa das alternativas identificadas. .3 Identificação de alternativas. Este é um termo genérico para qualquer técnica usada para gerar diferentes abordagens do projeto. Existem várias técnicas de gerenciamento freqüentemente usadas aqui, sendo as mais comuns o “brainstorming” e o “lateral thinking” (pensamento lateral). .4 Avaliação especializada. A avaliação especializada está descrita na Seção 5.1.2.2. 5.2.3 Saídas do Planejamento do Escopo .1 Declaração do escopo. A declaração do escopo fornece a documentação que servirá de base para tomada de decisões futuras no projeto e para confirmar ou desenvolver um entendimento comum do escopo entre as partes envolvidas. Com o progresso do projeto, a declaração do escopo pode necessitar ser revisada ou refinada para refletir as mudanças aprovadas no escopo do projeto. A declaração do escopo deve conter, tanto diretamente ou através de referência a outros documentos, os seguintes itens: • Justificativa do projeto – os requisitos do negócio que o projeto pretende atender. A justificativa do projeto fornece as bases para avaliar futuras compensações entre alternativas. • Produto do projeto – breve sumário da descrição do produto (a descrição do produto é discutida na Seção 5.1.1.1). • Subprodutos do projeto – uma lista de nível sumário dos subprodutos que uma vez entregues total e satisfatoriamente indicam o término do projeto. Por exemplo, os principais subprodutos para um projeto de desenvolvimento de software devem conter o código de trabalho do computador, um manual do usuário e um tutorial interativo. Quando conhecidas, as exclusões devem ser identificadas. Entretanto qualquer item não incluído explicitamente, está excluído implicitamente. • Objetivos do projeto – critérios quantificáveis que devem ser encontrados no projeto para que ele seja considerado um sucesso. Os objetivos do projeto devem incluir, no mínimo, custo, cronograma e medidas de qualidade. Os objetivos do projeto devem ter um atributo (por exemplo, custo), uma medida (por exemplo, US$ dólar) e um valor absoluto ou relativo (por exemplo, menos que 1,5 milhões). Objetivos não quantificáveis (por exemplo, “satisfação dos clientes”) representam alto risco para um término com sucesso. .2 Detalhes de suporte. Os detalhes de suporte para a declaração do escopo devem ser documentados e organizados de forma a facilitar seu uso por outros processos de gerenciamento. Os detalhes de suporte devem sempre incluir a documentação de todas as premissas e restrições identificadas. Outros detalhes a serem incluídos variam conforme a área de aplicação. .3 Plano de gerenciamento do escopo. Este documento descreve como o escopo do projeto será gerenciado e como as mudanças no escopo serão integradas ao projeto. Ele também deve conter uma avaliação da estabilidade esperada do escopo do projeto (isto é, a probabilidade, a freqüência e a proporção da mudança). O plano de gerenciamento do escopo deve também conter uma descrição clara sobre como as mudanças no escopo serão identificadas e classificadas (isto é particularmente difícil - e por isso absolutamente essencial - quando as características do produto estão ainda sendo elaboradas). Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 57 Um plano de gerenciamento do escopo pode ser formal ou informal, muito detalhado ou bastante amplo, dependendo das necessidades do projeto. Ele é um componente do plano geral do projeto (descrito na Seção 4.1.3.1). 5.3 Detalhamento do escopo O detalhamento do escopo representa a subdivisão dos principais subprodutos do projeto (conforme identificados na declaração do escopo) em componentes menores e mais manejáveis para se ter condição de : • Melhorar a precisão das estimativas de custo, tempo e recursos. • Definir um baseline para medir e controlar o desempenho. • Facilitar a atribuição clara de responsabilidades. Um adequado detalhamento do escopo é um aspecto crítico para o sucesso do projeto. ”Quando existe um detalhamento pobre do escopo, pode ser esperado um custo final do projeto mais alto por causa de inevitáveis mudanças que quebram o ritmo do projeto, causam retrabalho, comprometem o prazo e diminuem a produtividade e o moral da força de trabalho”[3]. 5.3.1 Entradas para o Detalhamento do Escopo .1 Declaração do escopo. A declaração do escopo está descrita na Seção 5.2.3.1. .2 Restrições. As restrições estão descritas na Seção 5.1.3.3. Quando um projeto é executado sob contrato, as restrições definidas pelas cláusulas contratuais são freqüentemente considerações importantes durante o detalhamento do escopo. .3 Premissas. As premissas estão descritas na Seção 4.1.1.5. .4 Outras saídas de planejamento. As saídas dos processos de outras áreas de conhecimento devem ser revistas quanto a possíveis impactos no detalhamento do escopo do projeto. .5 Informações históricas. As informações históricas sobre projetos anteriores devem ser consideradas durante o detalhamento do escopo. Devem ser especialmente úteis as informações sobre erros e omissões de outros projetos. 5.3.2 Ferramentas e Técnicas para o Detalhamento do Escopo .1 Modelos de estrutura analítica do projeto (work breakdown structure templates). Uma estrutura analítica do projeto - EAP, descrita na Seção 5.3.3.1) de um projeto anterior pode ser usada como modelo em um novo projeto. Embora cada projeto seja único, EAP’s podem, freqüentemente, ser “reusadas” uma vez que a maioria dos projetos se assemelha a um outro, em algum aspecto. Por exemplo, a maioria dos projetos de uma determinada organização terá ciclos de vida de projeto iguais ou similares e, conseqüentemente, terá os subprodutos requeridos iguais , ou similares, para cada fase. Entradas Saídas Técnicas e Ferramentas .1 Modelos de estrutura analítica do projeto (WBS templates) .2 Decomposição .1 Estrutura analítica do projeto (WBS) .2 Atualizações na declaração do escopo .1 Declaração do escopo .2 Restrições .3 Premissas .4 Saídas de outro planejamento .5 Informações históricas Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 60 está na EAP está fora do escopo do projeto. Com relação à declaração do escopo, a EAP é freqüentemente usada para criar ou ratificar o entendimento comum do escopo do projeto. Cada nível descendente representa um incremento no detalhamento da descrição dos elementos do projeto. A Seção 5.3.2.2 descreve as abordagens mais comuns para elaboração de uma EAP. Uma EAP é, normalmente, apresentada em um formato conforme ilustrado nas Figuras 5-2, 5-3, e 5-4; entretanto a EAP não deve ser confundida com o método de apresentação – o desenho de uma lista não estruturada de atividades em um formato de diagrama não faz disto uma EAP. A cada item da EAP é, geralmente, designado um identificador único; estes identificadores podem fornecer uma estrutura para a totalização hierárquica de custos e recursos. Os itens nos níveis mais baixos da EAP são, freqüentemente, referenciados como pacotes de trabalho (work packages) especialmente nas organizações que seguem as práticas de gerenciamento pelo “earned value”. Estes pacotes de trabalho podem ainda ser decompostos em uma EAP de subprojeto. Geralmente, este tipo de abordagem é usado quando o gerente do projeto está atribuindo uma parte do trabalho para outra organização, e esta outra organização deve planejar e gerenciar o escopo num nível mais Usina para Tratamento de Água Projeto Construção Desenhos civis Desenhos arquitetônicos Desenhos estruturais Desenhos mecânicos Desenhos HVAC Desenhos hidráulicos Desenhos de instrumentalização Desenhos elétricos Headworks Bacia de aeração Estação de extração de dejetos Unidade de tratamento de ar Unidade de sedimentos Esta EAP é somente ilustrativa. Não é intenção representar o escopo completo de nenhum projeto específico, nem esta é a única forma de organizar uma EAP para este tipo de projeto. Figura 5-4. Exemplo de uma Estrutura Analítica de Projeto para uma Usina de Tratamento de Água Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 61 detalhado do que necessita o gerente do projeto na estrutura principal. Estes pacotes de trabalho podem ser mais tarde desdobrados no plano do projeto e cronograma, como descrito nas Seções 5.3.2.2 e 6.1.2.1. As descrições dos componentes de trabalho são, freqüentemente, armazenadas em um dicionário EAP. Um dicionário EAP inclui, tipicamente, descrições de pacotes de trabalho, assim como outras informações de planejamento, tais como prazos, orçamentos e pessoal designado. A EAP não deve ser confundida com outros tipos de estruturas de decomposição usadas para apresentar informações do projeto. Outras estruturas comumente usadas em algumas áreas de aplicação são: • Estrutura analítica do projeto - contratual (Contractual EAP - CEAP), que é usada para definir o nível de informação que o vendedor fornecerá para o comprador. A CEAP geralmente possui menos detalhes que a EAP usada pelo vendedor para gerenciar o seu próprio trabalho. • Estrutura de decomposição organizacional (Organizational Breakdown Structure - OBS), que é usada para relacionar que elementos de trabalho foram designados para quais unidades da organização. • Estrutura de decomposição de recurso (Resource Breakdown Structure – RBS), que é uma variação da OBS, e é usada, tipicamente, quando os elementos de trabalho são designados para indivíduos. • Lista de Materiais (Bill of Materials – BOM), que apresenta uma visão hierárquica de montagens físicas, submontagens e componentes necessários para fabricar um produto industrializado. • Estrutura de decomposição do projeto (Project Breakdown Structure – PBS), que é, fundamentalmente, o mesmo que a própria EAP. O termo PBS é mais utilizado nas áreas de aplicação onde o termo EAP é, incorretamente, usado para referenciar uma Lista de Materiais (BOM). 5.4 Verificação do Escopo A verificação do escopo é o processo de formalização do aceite do escopo do projeto pelas partes envolvidas (patrocinador, cliente, usuário, etc). Isto exige uma revisão dos produtos e resultados do trabalho para garantir que tudo foi completado correta e satisfatoriamente. Se o projeto terminar prematuramente, o processo de verificação do escopo deve estabelecer e documentar o nível e a extensão do que foi concluído . A verificação do escopo difere do controle da qualidade (descrito na Seção 8.3) já que a verificação é fundamentalmente relacionada com a aceitação dos resultados do trabalho, enquanto o controle da qualidade preocupa-se fundamentalmente com a exatidão dos mesmos resultados. Estes processos normalmente são executados em paralelo. Assim para o mesmo trabalho executado busca-se tanto a exatidão quanto a aceitação do escopo. Entradas Saídas Ferramentas e Técnicas .1 Resultados do trabalho .2 Documentação do produto .3 Estrutura analítica do projeto .4 Declaração do escopo .5 Plano do projeto .1 Inspeção .1 Aceitação formal Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais – www.pmimg.org.br 62 5.4.1 Entradas para a Verificação do Escopo .1 Resultados do trabalho. Os resultados do trabalho – quais subprodutos foram total ou parcialmente completados – são saídas da execução do plano do projeto (discutido na Seção 4.2) .2 Documentação do produto. Os documentos produzidos para descrever os produtos do projeto devem estar disponíveis para revisão. Os termos usados para descrever esta documentação (planos, especificações, documentação técnica, desenhos etc) variam de acordo com a área de aplicação. .3 Estrutura analítica do projeto. A EAP auxilia no desenvolvimento do escopo e deve ser utilizada quando da verificação do trabalho do projeto (Ver Seção 5.3.3.1). .4 Declaração do escopo. A declaração do escopo define alguns detalhes do escopo e deve ser verificada (Ver Seção 5.2.3.1). .5 Plano do projeto. O plano do projeto está descrito na Seção 4.1.3.1. 5.4.2 Ferramentas e Técnicas para a Verificação do Escopo .1 Inspeção. A inspeção inclui atividades - tais como medição, exames e testes - realizadas para determinar se os resultados estão de acordo com os requisitos. As inspeções recebem denominações diversas: são chamadas de revisões, revisões de produto, auditoria, e ensaios (walk-throughs); em algumas áreas de aplicação esses termos têm significados específicos. 5.4.3 Saídas da Verificação do Escopo .1 Aceitação formal. A documentação de que o cliente ou patrocinador aceitou o produto ou o subproduto da fase do projeto deve ser preparada e distribuída. Tal aceitação pode ser condicional, especialmente no fim de uma fase. 5.5 Controle de Mudanças do Escopo O controle de mudanças do escopo consiste em (a) influenciar os fatores que criam mudanças no escopo para garantir que as mudanças sejam discutidas e combinadas (b) determinar que uma mudança no escopo ocorreu, e (c) gerenciar as mudanças efetivas quando ocorrerem. O controle das mudanças do escopo deve se integrar aos demais processos de controle (controle de prazo, controle de custo, controle de qualidade, e outros, como discutido na Seção 4.3). Entradas Ferramentas e Técnicas Saídas .1 Estrutura analítica do projeto .2 Relatórios de desempenho .3 Requisições de mudança .4 Plano de gerenciamento do escopo .1 Sistema de controle de mudanças do escopo .2 Medição do desempenho .3 Planejamento adicional .1 Mudanças do escopo .2 Ações corretivas .3 Lições aprendidas .4 Baseline ajustado Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 65 Capítulo 6 Gerenciamento do Prazo do Projeto O Gerenciamento do Prazo do Projeto inclui os processos necessários para assegurar que o projeto será implementado no prazo previsto. A Figura 6-1 fornece uma visão geral dos processos para criar o cronograma do projeto: 6.1 Definição das Atividades – identificar as atividades específicas que devem ser realizadas para produzir os diversos subprodutos do projeto. 6.2 Seqüenciamento das Atividades – identificar e documentar as relações de dependência entre as atividades. 6.3 Estimativa da Duração das Atividades - estimar a quantidade de períodos de trabalho que serão necessários para a implementação de cada atividade. 6.4 Desenvolvimento do Cronograma - analisar a seqüência das atividades, sua duração, e os requisitos de recursos para criar o cronograma do projeto. 6.5 Controle do Cronograma - controlar as mudanças no cronograma do projeto. Estes processos interagem uns com os outros e também com os processos das demais áreas de conhecimento. Cada processo pode envolver esforço de um ou mais indivíduos ou grupos de indivíduos dependendo das necessidades do projeto. Cada processo geralmente ocorre pelo menos uma vez em cada fase do projeto. Embora os processos sejam aqui apresentados como elementos discretos e interfaces bem definidas, na prática eles podem se sobrepor e interagir de outras formas não descritas aqui . As interações entre os processos são discutidas no Capitulo 3. Em alguns projetos, especialmente os menores, o seqüenciamento das atividades, as estimativas das durações e o desenvolvimento do cronograma estão tão vinculados que podem ser tratados como um único processo (podem ser realizados por um único indivíduo, durante um curto intervalo de tempo ). Esses processos são aqui apresentados como processos distintos porque as ferramentas e técnicas são diferentes para cada um. 6.1 Definição das Atividades A definição das atividades envolve identificar e documentar as atividades específicas que devem ser realizadas com a finalidade de produzir os diversos níveis de subprodutos identificados na EAP. Está implícito neste processo está a necessidade de definir aquelas atividades voltadas para o alcance dos objetivos do projeto. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 66 Figura 6-1. Visão Geral da Gerência do Tempo do Projeto 6.1 Definição das Atividades Gerenciamento do Prazo do Projeto 6.2 Sequenciamento das Atividades 6.3 Estimativa da Duração das Atividades .1 Entradas .1 Estrutura Analítica do Projeto - EAP .2 Declaração do escopo 3 Informações históricas .4 Restrições .5 Premissas .6 Avaliação especializada .2 Ferramentas e Técnicas .1 Decomposição .2 Modelos .3 Saídas .1 Lista de atividades .2 Detalhes de suporte 3 Atualizações na EAP .1 Entradas .1 Lista de atividades .2 Descrição do produto 3 Dependências mandatórias .4 Dependências arbitradas .5 Dependências externas .6 Marcos .2 Ferramentas e Técnicas .1 Método do diagrama de precedência - PDM .2 Método do diagrama de flecha - ADM) .3 Método do diagrama condicional .4 Modelos de rede .3 Saídas .1 Diagrama de rede do projeto .2 Atualizações na lista de atividades .1 Entradas 1 Lista de atividades .2 Restrições 3 Premissas .4 Necessidade de recursos .5 Capabilidade dos recursos .6 Informações históricas .7 Riscos identificados .2 Ferramentas e Técnicas .1 Avaliação especializada .2 Estimativas por analogia .3 Durações estimadas quantitativamente .4 Tempo de reserva (contingência) .3 Saídas .1 Estimativas da duração das atividades .2 Bases das estimativas .3 Atualizações na lista de atividades 6.4 Desenvolvimento do Cronograma .1 Entradas .1 Diagrama de rede do projeto .2 Estimativas de duração das atividades .3 Necessidades de recursos .4 Descrição do quadro de recursos .5 Calendários .6 Restrições .7 Premissas .8 Adiantamentos e atrasos .9 Plano de gerenciamento de riscos .10 Atributos das atividades .2 Ferramentas e Técnicas .1 Análises matemáticas .2 Compressão da duração .3 Simulação .4 Heurística de nivelamento de recursos .5 Softwares de gerenciamento de projeto .6 Estrutura de codificação .3 Saídas .1 Cronograma do projeto .2 Detalhes de suporte .3 Plano de gerenciamento do cronograma .4 Atualização dos recursos necessários 6.5 Controle do Cronograma .1 Entradas .1 Cronograma do projeto .2 Relatórios de desempenho 3 Requisições de mudança .4 Plano de gerenciamento do cronograma .2 Ferramentas e Técnicas .1 Sistema de controle de mudanças do cronograma .2 Medição de desempenho .3 Planejamento adicional .4 Softwares de gerência de projeto .5 Análises de variações .3 Saídas .1 Atualizações no cronograma .2 Ações corretivas .3 Lições aprendidas Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 67 6.1.1 Entradas para a Definição das Atividades .1 Estrutura analítica do projeto. A EAP é a principal entrada para a definição das atividades (ver Seção 5.3.3.1 para mais detalhes sobre EAP). .2 Declaração do escopo. A justificativa e os objetivos do projeto contidos na declaração do escopo devem ser considerados, explicitamente, durante a definição das atividades (ver Seção 5.2.3.1 para mais detalhes sobre a declaração do escopo). .3 Informações históricas. As informações históricas (que atividades foram requeridas em projetos anteriores semelhantes) devem ser consideradas na definição das atividades do projeto .4 Restrições. As restrições são fatores que limitarão as opções da equipe de gerência do projeto; um exemplo seria a atribuição de durações máximas para as atividades. .5 Premissas. Ver Seção 4.1.1.5. .6 Avaliação especializada. A avaliação especializada é discutida nas Seções 5.1.2.2 e 6.3.2.1. 6.1.2 Ferramentas e Técnicas para a Definição das Atividades .1 Decomposição. Dentro do contexto da definição das atividades, a decomposição significa subdividir os pacotes de trabalho do projeto em componentes menores e mais manejáveis com a finalidade de fornecer melhor controle do gerenciamento. A técnica da decomposição está descrita com mais detalhes na Seção 5.3.2.2. A principal diferença entre a decomposição aqui descrita e a do Detalhamento do Escopo é que aqui as saídas são descritas como atividades em vez de subprodutos (itens tangíveis). Em algumas áreas de aplicação, a EAP e a lista de atividades são desenvolvidas paralelamente. .2 Modelos (Templates). Uma lista de atividades (descrita na Seção 6.1.3.1), ou uma parte de uma lista de atividades de projetos anteriores, é freqüentemente utilizada como modelo ou referência para um novo projeto. As atividades nos modelos de referência podem conter também uma lista dos tipos de recursos e suas necessidades de esforço em horas, identificação dos riscos, resultados esperados, e outras informações descritivas. 6.1.3 Saídas da Definição das Atividades .1 Lista de atividades. A lista de atividades deve incluir todas as atividades que serão realizadas no projeto. Deve ser organizada como um extensão da EAP para assegurar que esta está completa e que não inclui qualquer atividade que não seja requerida como parte do escopo do projeto. Assim como a EAP, a lista de atividades .1 Decomposição .2 Modelos Ferramentas e Técnicas .1 Estrutura Analítica do Projeto (EAP) .2 Declaração do escopo .3 Informações históricas .4 Restrições .5 Premissas .6 Avaliação especializada .1 Lista de atividades .2 Detalhes de suporte .3 Atualizações na EAP Saídas Entradas Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 70 .2 Método do diagrama de flecha (ADM - Arow Diagramming Method). Este é um método de construção de diagrama de rede que utiliza setas para representar as atividades e as conecta por meio de nós que representam as dependências (ver também seção 6.2.3.1). A Figura 6.3 apresenta um diagrama simples de rede utilizando o ADM. Esta técnica é também chamada de atividade na flecha (AOA - Activity-on-arrow) e, embora menos predominante que o PDM, é ainda a técnica escolhida em algumas áreas de aplicação. O ADM utiliza apenas relações de dependência do tipo fim/início e, às vezes, necessita da criação de atividades “fantasmas” para definir corretamente o relacionamento lógico. O ADM pode ser feito manualmente ou no computador. .3 Método do diagrama condicional (CDM - Conditional diagramming method). As técnicas de diagramação tais como GERT (Graphical Evaluation and Review Technique - Avaliação Gráfica e Técnicas de Revisão) e modelos de Sistemas Dinâmicos (System Dynamics) permitem atividades não seqüenciais como “lops” (por exemplo, um teste deve ser repetido mais de uma vez) ou desvios condicionados (por exemplo, a atualização de desenho que é necessária apenas se a inspeção detectar erros). Nem o PDM nem o ADM permitem “loops” ou desvios condicionados. .4 Modelos de rede. Redes padronizadas podem ser utilizadas para auxiliar na preparação do diagrama de rede do projeto. Podem incluir todo o projeto ou apenas uma parte. Partes dae uma rede são, freqüentemente, referenciadas como subnets ou fragnets. Subnets são especialmente úteis quando o projeto inclui várias características idênticas ou bastante similares tais como pisos na construção de prédios comerciais, pesquisas clínicas em projetos de pesquisas farmacêuticas ou módulos de programas em projetos de softwares. 6.2.3 Saídas do Seqüenciamento das Atividades .1 Diagrama de rede do projeto. Um diagrama de rede de projeto é um esquema de apresentação das atividades do projeto e dos relacionamentos lógicos (dependências) entre elas. As Figuras 6-2 e 6-3 ilustram duas diferentes abordagens utilizadas para desenhar um diagrama de rede do projeto. O diagrama de rede de um projeto pode ser elaborado manualmente ou no computador. Pode incluir detalhes de todo o projeto ou ter uma ou mais atividades sumarizadas (hammocks). O diagrama deve ser acompanhado por uma descrição sumária que descreva a abordagem básica do seqüenciamento. Qualquer seqüência não usual deve ser amplamente descrita. Os diagramas de rede do projeto freqüentemente são chamados de gráficos de PERT. Historicamente, o PERT (Program Evaluation and Review Technique) foi um tipo específico de diagrama de rede (ver Seção 6.4.2.1) Figura 6-3. Desenho do Diagrama Lógico de Rede Usando o Método de Diagramação por Flecha A linha tracejada representa uma atividade fantasma Início Fim Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 71 .2 Atualizações da lista de atividades. Da mesma maneira que o processo de definição das atividades pode gerar atualizações na EAP, a preparação do diagrama de rede do projeto pode revelar situações em que uma atividade deve ser dividida ou mesmo redefinida com a finalidade de diagramar corretamente o relacionamento lógico. 6.3 Estimativa da Duração das Atividades A estimativa de duração das atividades é o processo de gerar as durações das atividades para entrada do cronograma, a partir das informações do escopo do projeto e dos recursos disponíveis. As entradas para as estimativas de duração se originam tipicamente da pessoa, ou grupo dentro da equipe do projeto, para quem a natureza da atividade específica é mais familiar. A estimativa é, freqüentemente, constr5uida de forma progressiva, e o processo considera a qualidade e a disponibilidade dos dados de entrada. Assim, pode-se assumir que a estimativa vai progressivamente se tornando mais precisa e com uma qualidade conhecida. A pessoa ou grupo da equipe do projeto que estiver mais familiarizada com a natureza de uma atividade específica deve fazer ou, no mínimo, aprovar a estimativa. Estimar a quantidade ou número de períodos de trabalho exigidos para implementar uma atividade, freqüentemente, requererá também considerações relativas ao tempo de espera (elapsed time). Por exemplo, se a cura do concreto requererá 4 dias de elapsed time, isso pode requerer dois ou quatro períodos de trabalho baseados em a) em qual dia da semana será iniciado e b) se os fins de semana serão, ou não, tratados como períodos de trabalho. A maioria dos softwares que desenvolvem cronograma tratam esse problema automaticamente, através do uso de calendários alternativos de períodos de trabalho. Embora a duração total do projeto possa também ser estimada, utilizando-se as ferramentas e técnicas apresentadas aqui, ela é mais apropriadamente calculada na saída do desenvolvimento do cronograma (descrito na Seção 6.4). A equipe do projeto pode considerar a duração do projeto uma distribuição probabilística (usando técnicas de probabilidade) ou uma estimativa unívoca (usando técnicas determinísticas) 6.3.1 Entradas para a Estimativa da Duração das Atividades .1 Lista de atividades. A lista de atividades está descrita na Seção 6.1.3.1 .2 Restrições. As restrições estão descritas na Seção 6.1.1.4. .3 Premissas. As premissas estão descritas na Seção 4.1.1.5. Um exemplo seria estabelecer as durações máximas a partir dos períodos de revisões de progresso. Por exemplo, a duração máxima ser dois períodos de revisão. .4 Necessidade de recursos. As necessidades de recursos estão descritos na Seção 7.1.3.1. A duração da maioria das atividades será significativamente influenciada pelos recursos a elas designadas. Por exemplo, duas pessoas trabalhando juntas podem ser capazes de Entradas Saídas Técnicas e Ferramentas .1 Avaliação especializada .2 Estimativas por analogia .3 Durações estimadas quantitativamente .4 Tempo de reserva (contingência) .1 Estimativas de duração das atividades .2 Bases para a estimativa .3 Atualizações da lista de atividades .1 Lista de atividade .2 Restrições .3 Premissas .4 Necessidade de recursos .5 Capabilidade dos recursos .6 Informações históricas .7 Riscos identificados Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 72 completar uma atividade de desenho na metade do tempo que levariam para fazê-lo individualmente. Por outro lado, uma pessoa trabalhando meio expediente em uma atividade, geralmente levará , no mínimo, duas vezes o tempo que gastaria trabalhando o expediente completo. Entretanto, na medida em que se incorporam mais recursos, os projetos podem sofrer sobrecarga de comunicação que reduz a produtividade e acarreta um crescimento menor na produção, quando comparada com o aumento de recursos. .5 Capabilidade dos recursos. A duração da maioria das atividades será significativamente influenciada pela capabilidade dos recursos humanos e materiais a elas designados. Por exemplo, se dois recursos, um sênior e outro junior, forem alocados em tempo integral numa equipe, espera-se que na maioria das vezes o recurso sênior seja capaz de realizar uma determinada atividade em menos tempo que o júnior. .6 Informações históricas. As informações históricas das durações mais prováveis de muitas categorias das atividades geralmente estão disponíveis em uma ou mais das seguintes fontes: • Arquivos de projeto - as organizações envolvidas no projeto, podem manter registros de projetos anteriores que sejam suficientemente detalhados para auxiliar o desenvolvimento da estimativa de duração das atividades. Em algumas áreas de aplicação, os membros individuais podem manter registros. • Estimativa de durações em bases de dados comerciais - informações históricas estão freqüentemente disponíveis comercialmente. Estas bases de dados tendem a ser especialmente úteis quando as durações não são dependentes do conteúdo presente do trabalho (por exemplo, quanto tempo leva a cura do concreto, quanto tempo uma agência governamental geralmente leva para responder a certos tipos de requisição). • Conhecimento da equipe do projeto - os membros individuais da equipe do projeto podem lembrar-se de estimativas ou dados reais anteriores. Embora essas referências possam ser úteis, geralmente são menos confiáveis que os resultados documentados. .7 Riscos identificados. A equipe do projeto considera também os riscos identificados (ver Seção 11.2) quando está produzindo as estimativas de duração das atividades, uma vez que os riscos (ameaças ou oportunidades) podem ter uma significante influência na duração. A equipe do projeto analisa o efeito dos riscos e considera a sua incorporação ou não (e em que extensão) no baseline da duração de cada atividade. São incluídos os riscos com alta probabilidade ou impacto. 6.3.2 Ferramentas e Técnicas para a Estimativa da Duração das Atividades .1 Avaliação especializada. A avaliação especializada está descrita na Seção 5.1.2.2. As durações, geralmente, são difíceis de estimar, por causa do número de fatores que podem influenciá-las (por exemplo, nível dos recursos, produtividade dos recursos). A avaliação especializada baseada em informações históricas deve ser usada sempre que possível. Se tal conhecimento especializado não está disponível, as estimativas são inerentemente incertas e arriscadas (ver capítulo 11, Gerência do Risco do Projeto). .2 Estimativas por analogia. Nas estimativas por analogia, também chamadas de estimativas de cima para baixo (top-down), usam-se os valores reais de durações de projetos anteriores ou similares para estimar a duração de uma atividade futura. Ela é freqüentemente utilizada para estimar a duração do projeto quando existe uma quantidade limitada de informações detalhadas sobre ele (por exemplo, nas fases iniciais do projeto). Estimativas por analogia são uma forma de avaliação especializada (descrita na Seção 6.3.2.1). As estimativas por analogia são mais confiáveis quando (a) as atividades anteriores são semelhantes de fato e não apenas na aparência e (b) os indivíduos que preparam as estimativas têm o conhecimento especializado necessário. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 75 classificação posterior das atividades planejadas de uma forma conveniente para os usuários. A classificação da EAP também é um atributo importante que permite um adequado ordenamento e classificação das atividades. 6.4.2 Ferramentas e Técnicas para o Desenvolvimento do Cronograma .1 Análise Matemática. Envolve calcular datas teóricas de início e término para todas as atividades do projeto, sem considerar qualquer limitação no quadro de recursos. As datas resultantes não são o cronograma, mas indicam os períodos de tempo dentro dos quais as atividades devem ser programadas dado as limitações de recursos e outras restrições conhecidas. As técnicas de análise matemática mais amplamente conhecidas são: • Método de Caminho Crítico (CPM Critical Path Method). Calcula de forma determinística, uma data única mais cedo e mais tarde, de início e de término para cada atividade, baseado na seqüência lógica especificada da rede e em uma duração estimada única. O enfoque do CPM é o cálculo da flutuação com a finalidade de determinar quais as atividades têm a menor flexibilidade no cronograma. Os principais algoritmos do CPM são freqüentemente utilizados em outros tipos de análises matemáticas. • GERT – Graphical Evaluation and Review Technique. Permite o tratamento probabilístico tanto para a rede lógica quanto para as estimativas de duração das atividades (por exemplo, algumas atividades podem ser executadas por completo, algumas apenas em parte, e outras mais de uma vez). • PERT – Program Evaluation and Review Technique. Usa uma rede seqüencial e uma estimativa de duração por média ponderada para calcular as durações das atividades. Embora existam diferenças superficiais, o PERT difere do CPM fundamentalmente por que usa distribuição de médias (valor esperado) em vez da estimativa mais provável, originalmente usado no CPM (ver figura 6.4). O PERT propriamente dito é atualmente muito pouco utilizado, embora as estimativas similares do PERT (PERT-like) sejam freqüentemente usadas nos cálculos de CPM. .2 Compressão da duração. A compressão da duração é um caso especial de análise matemática que procura alternativas para reduzir o prazo do projeto sem alterar o seu escopo (por exemplo, satisfazer datas impostas ou outros objetivos de prazo). A compressão de duração inclui técnicas tais como: • Colisão (Crashing) - quais compensações de custo e prazo são analisados para determinar como obter a maior compressão para o mínimo aumento de custo. As colisões nem sempre produzem alternativas viáveis e freqüentemente resultam em aumento de custo. • Caminho Rápido (Fast tracking) - realizar em paralelo atividades que normalmente seriam feitas em seqüência ( por exemplo, começar a escrever o código de um projeto de software antes que o desenho esteja completo, ou começar construir a fundação de uma usina de processamento de petróleo antes de se alcançar 25 porcento da solução de engenharia do processo (engenering point). O caminho rápido freqüentemente resulta em retrabalho e usualmente aumenta o risco. .3 Simulações. A simulação envolve o cálculo de múltiplas durações de projeto com diferentes grupos de premissas nas atividades. A técnica mais comum é a Análise Monte Carlo, na qual uma distribuição de resultados prováveis é definida para cada atividade e utilizada para calcular a distribuição dos resultados prováveis para o projeto inteiro (Veja também a Seção 11.4.2.4). Além disso, análises “what-if” podem ser feitas utilizando a rede de lógica para estimular a geração de diferentes cenários, como atrasar a entrega de um componente principal, estender prazos específicos de engenharia, ou introduzir fatores externos (tais como greve, ou mudanças nos trâmites legais). Os resultados das simulações “what-if” podem ser usadas para avaliar a viabilidade do cronograma sob condições adversas, e preparar planos de resposta/contingência para enfrentar ou mesmo resolver o impacto de situações inesperadas. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 76 .4 Heurística de nivelamento dos recursos. As análises matemáticas freqüentemente produzem um cronograma preliminar de datas mais cedo que requer, durante certos períodos de tempo, mais recursos do que a disponibilidade real que estão disponíveis, ou requer alterações inviáveis nos níveis de recursos de recursos previstos. As heurísticas tais como “alocar os recursos escassos primeiramente para as atividades do caminho crítico” podem ser aplicadas para desenvolver um cronograma que reflita tal restrição. O nivelamento dos recursos freqüentemente resulta numa duração maior para o projeto do que o cronograma preliminar. Esta técnica é algumas vezes chamada de “Método Baseado em Recursos” (Resource-based Method), especialmente quando implementada com otimização computadorizada. A realocação de recursos das atividades mais críticas para as críticas é uma forma comum de retroceder o prazo, ou tanto quanto possível, à sua duração global originalmente prevista. Utilização de horas- extras, fins de semana, ou turnos múltiplos deve também ser consideradas para a redução das atividades críticas. Aumento de produtividade baseados no uso de diferentes tecnologia e/ou automação (automatic welding, electrical pipe cutters, etc) são outras maneiras de reduzir as durações que haviam estendido o cronograma preliminar. O “caminho rápido”, quando aplicável (como descrito na Seção 6.4.2.2.) é outra possibilidade de redução de duração total do projeto. Alguns projetos podem ter um recurso finito e crítico, exigindo que este recurso seja programado tornando-se como referência a data final do projeto, isto é, conhecido como programação de recurso. Critical Chain é uma técnica que modifica o cronograma do projeto tendo em vista os recursos limitados. .5 Softwares de gerência de projeto. Os softwares de gerência de projeto são amplamente usados no desenvolvimento do cronograma. Outros softwares, interagindo direta ou indiretamente com os softwares de gerenciamento de projetos, podem complementar as necessidades das outras áreas de conhecimento. Esses produtos automatizam os Mais curta Mais longa Mais baixa Mais alta (usada nos cálculos originais do CPM) Figura 6-4. Cálculo da duração PERT para uma atividade única Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 77 cálculos das análises matemáticas e do nivelamento dos recursos e, conseqüentemente, permitem uma rápida avaliação sobre diversas alternativas de cronograma. São amplamente utilizados para imprimir ou apresentar as saídas do desenvolvimento do cronograma. .5 Estrutura de codificação. As atividades devem ter uma estrutura de códigos que permitirá classificações e extrações em diferentes atributos designados às atividades, tais como responsável, área geográfica ou período, fase do projeto, nível de programação, tipo de atividade, e classificação EAP. 6.4.3 Saídas do Desenvolvimento do Cronograma .1 Cronograma do projeto. O cronograma do projeto inclui, para cada atividade, no mínimo as datas de início e de término esperado para cada atividade detalhe (Nota: o cronograma do projeto se mantém preliminar até que os recursos designados tenham sido confirmados. Isto usualmente deverá acontecer no mais tardar até a conclusão do Desenvolvimento do Plano do Projeto, Seção 4.1.) O Cronograma do projeto pode ser apresentado de forma sumarizada (“master schedule”) ou em detalhes. Embora possa ser apresentado na forma tabular, ele é mais freqüentemente apresentado na forma gráficagraficamente utilizando-se um ou mais dos seguintes formatos: • Diagrama de rede do projeto acrescido das informações de datas (ver Figura 6.5). Estes gráficos usualmente apresentam tanto a lógica do projeto quanto o caminho crítico das atividades (ver Seção 6.2.3.1 para mais informações sobre diagramas de rede do projeto). Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 80 .2 Relatórios de desempenho. Os relatórios de desempenho discutidos na Seção 10.3.3.1 fornecem informações sobre o desempenho do cronograma tais como que datas planejadas foram alcançadas e quais não foram. Podem também alertar a equipe de projeto para questões que poderão causar problemas no futuro. .3 Requisições de mudança. As requisições de mudanças podem ocorrer de muitas formas – oral ou escrita, direta ou indiretamente, iniciadas internamente ou externamente, e legalmente impostas ou opcionais. As mudanças podem exigir uma dilatação do cronograma ou mesmo permitir que ele seja encurtado. .4 Plano de gerencia do cronograma. O plano de gerência do cronograma está descrito na Seção 6.4.3.3. 6.5.2 Ferramentas e Técnicas para o Controle do Cronograma .1 Sistema de controle de mudanças do cronograma. Um sistema de controle de mudanças do cronograma define os procedimentos pelos quais o cronograma do projeto pode ser mudado. Isto inclui papéis de trabalho, sistemas de acompanhamento, e níveis de aprovação necessários para autorizar as mudanças. O controle de mudanças do cronograma deve estar articulado com o sistema integrado de controle de mudanças descrito na Seção 4.3. .2 Medição de desempenho. As técnicas de medição de desempenho, descritas na Seção 10.3.2, ajudam a determinar a magnitude de quaisquer variações que ocorram. Uma parte importante do controle de mudanças no cronograma é decidir se a variação do cronograma exige uma ação corretiva. Por exemplo, um grande atraso em uma atividade que não é crítica pode ter um efeito pequeno no projeto global, enquanto pequenos atrasos em atividades críticas ou “quase” críticas podem requerer ações imediatas. .3 Planejamento adicional. Poucos projetos se desenvolvem exatamente de acordo com o plano. Mudanças em perspectiva podem requerer estimativas de duração de atividades novas ou revisadas, modificações na seqüência das atividades ou análise de cronogramas alternativos. .4 Softwares de gerência de projeto. Os softwares de gerência de projeto estão descritos na Seção 6.4.2.5. A capacidade dos softwares de gerência de projetos em acompanhar datas planejadas versus datas reais e prever os efeitos de mudanças no cronograma, reais ou potenciais, torna-os uma ferramenta útil para o controle do cronograma. .5 Análise de variações. O desempenho das análises das variações durante o processo de monitoramento do cronograma é um elemento chave para o controle do prazo. A comparação das datas objetivo com as datas de início e fim previstas/reais fornece uma valiosa informação para a detecção de desvios e para a implementação de soluções corretivas no caso de atrasos. A variação de folgas é também um componente de planejamento essencial para se avaliar o desempenho do prazo do projeto. Uma atenção especial deve ser tomada nas atividades críticas e “quase críticas” (analizando-se os dez caminhos “quase críticos” por ordem de suas folgas). 6.5.3 Saídas do Controle do Cronograma 1 Atualizações do cronograma. Uma atualização no cronograma é qualquer modificação nas informações de prazos que são utilizadas para gerenciar o projeto. As partes envolvidas afetadas devem ser notificadas. As atualizações do cronograma podem ou não requerer ajustes em outros aspectos do plano geral do projeto. Revisões são uma categoria especial de atualização do cronograma. As revisões são mudanças nas datas de início e término no cronograma aprovado do projeto. Essas datas são geralmente revisadas apenas em resposta a mudanças no escopo ou nas estimativas. Em alguns casos, os atrasos no cronograma podem ser tão severos que é necessário um Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 81 replanejamento (rebaselining) para a manutenção de dados realísticos que venham medir o desempenho. Entretanto, é preciso cuidado antes do replanejamento, uma vez que se perderão dados históricos em relação ao cronograma do projeto. O replanejamento deve ser usado somente como o último recurso para o controle do cronograma; a atribuição de novos objetivos de prazo deve ser a forma normal para se conduzir uma revisão de cronograma. .2 Ações corretivas. A ação corretiva é tudo aquilo que é feito para compatibilizar o desempenho futuro do cronograma com o plano do projeto. Ações corretivas na área de gerência do tempo freqüentemente envolvem presteza: ações especiais tomadas para garantir a conclusão da atividade no prazo ou com o mínimo de atraso possível. As ações corretivas freqüentemente requerem uma análise de causas-raiz para identificar a causa real da variação, possibilitando que a recuperação do atraso possa ser planejada e executada para atividades programadas à frente no projeto e não apenas diretamente naquelas que causaram o desvio. .3 Lições aprendidas. As causas das variações, as razões “por trás” da ações corretivas tomadas, e outros tipos de lições aprendidas do controle do cronograma, devem ser documentadas para que se tornem parte de um banco de dados histórico tanto para o projeto em curso quanto para outros projetos da organização executora. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 83 Capítulo 7 Gerenciamento do Custo do Projeto O Gerenciamento do Custo do Projeto inclui os processos necessários para assegurar que o projeto será concluído dentro do orçamento aprovado. A Figura 7-1 fornece uma visão geral dos principais processos: 7.1 Planejamento dos Recursos – determinar quais recursos (pessoas, equipamentos, materiais) e em que quantidade devem ser usados para executar as atividades do projeto. 7.2 Estimativa dos Custos – desenvolver uma aproximação (estimativa) dos custos dos recursos necessários para executar as atividades do projeto. 7.3 Orçamentação dos Custos – alocar as estimativas de custos globais aos itens individuais de trabalho. 7.4 Controle dos Custos – controlar as mudanças no orçamento do projeto. Estes processos interagem-se mutuamente e com os processos das outras áreas de conhecimento. Cada processo pode envolver o esforço de um ou mais indivíduos ou grupos de indivíduos dependendo das necessidades do projeto. Cada processo ocorre, geralmente, pelo menos uma vez em cada fase do projeto. Embora os processos sejam aqui apresentados como elementos discretos e com interfaces bem definidas, na prática eles podem sobrepor-se e interagir de formas aqui não especificadas. As interações entre os processos estão discutidas de forma detalhada no Capítulo 3. A gerência do custo do projeto consiste, fundamentalmente, nos custos dos recursos necessários à implementação das atividades do projeto. Entretanto, a gerência do custo do projeto deve, também, considerar os efeitos das decisões do projeto no custo de utilização do produto do projeto. Por exemplo, limitar o número de revisões do projeto pode reduzir os custos do projeto à custa de um aumento no custo de operação do cliente. Esta visão mais ampla da gerência do custo do projeto é, freqüentemente, chamada de custo do ciclo de vida (life-cycle costing). As técnicas de custo de ciclo de vida e engenharia de valor são usadas para reduzir custo e prazo, melhorar qualidade e desempenho e otimizar a tomada de decisão. Em muitas áreas de aplicação, prever e analisar a perspectiva de desempenho financeiro do produto do projeto é feita fora do ambiente do projeto. Em outras (por exemplo, projetos de negócios financeiros), a gerência do custo do projeto também inclui esse trabalho Quando essas previsões e análises estão incluídas, a gerência do custo do projeto inclui processos adicionais e um diversas técnicas de administração geral tais como previsão de retorno do investimento, fluxo de caixa, análises de retorno, entre outras. A gerência do custo do projeto deve considerar as necessidades de informações das partes envolvidas do projeto – diferentes interessados podem avaliar os custos do projeto de maneiras diferentes e em diferentes momentos. Por exemplo: o custo de aquisição de um item pode ser medido quando de sua contratação, da ordem de compra, da entrega, do armazenamento ou do registro para fins contábeis. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 86 .3 Declaração do escopo. A declaração do escopo ( descrita na Seção 5.2.3.1) contém a justificativa e os objetivos do projeto devendo ambas ser consideradas, explicitamente, durante o planejamento de recursos. .4 Descrição do quadro de recursos. O conhecimento de quais recursos (pessoas, equipamentos, materiais) estão potencialmente disponíveis é necessário para o planejamento dos recursos. A quantidade de detalhes e o nível de especialização na descrição do quadro de recursos variará. Por exemplo, durante as primeiras fases de um projeto de design de engenharia, o quadro pode incluir “engenheiros júnior e sênior”, apenas em termos gerais. Entretanto, durante as últimas fases do mesmo projeto, o quadro pode ser limitado àqueles indivíduos que têm conhecimento significativo sobre o projeto como resultado de terem trabalhado nas fases iniciais. .5 Políticas organizacionais. As políticas da organização, relativas tanto ao quadro de pessoal quanto a aluguel ou compra de suprimentos e equipamentos, devem ser consideradas durante o planejamento dos recursos. .6 Estimativas de duração das atividades. Estimativas de prazo (descrito na Seção 6.3.3.1). 7.1.2 Ferramentas e Técnicas para o Planejamento dos Recursos .1 Avaliação especializada. A avaliação especializada freqüentemente será requerida para avaliar as entradas deste processo. Tal conhecimento específico pode ser obtido de qualquer grupo ou indivíduo com conhecimento ou treinamento especializado e está disponível a partir de muitas fontes, incluindo: • Outras unidades da organização executora. • Consultores. • Profissionais e associações técnicas. • Grupos industriais. .2 Identificação de alternativas. A identificação das alternativas é discutida na Seção 5.2.2.3. .3 Software de gerenciamento de projetos. Um software de gerenciamento de projetos tem a capacidade de auxiliar na organização do quadro de recursos, Dependendo da sofisticação do software, pode se trabalhar com disponibilidades, taxas e calendários de recursos. 7.1.3 Saídas do Planejamento dos Recursos .1 Recursos requeridos. A saída do processo de planejamento dos recursos é a descrição de que tipos de recursos são necessários e em que quantidade para cada elemento no nível mais baixo da EAP. Esses recursos serão obtidos através da montagem da equipe (descrita na Seção 9.2) ou contratação (descrita no Capítulo 12 ). 7.2 Estimativa dos Custos A estimativa dos custos envolve desenvolver uma aproximação (estimativa) dos custos dos recursos necessários para completar as atividades do projeto. Na busca de uma aproximação dos custos, a pessoa responsável pela estimativa considera as causas de variação da estimativa final, a fim de melhor gerenciar o projeto. Quando o projeto é realizado sob contrato, devem ser tomados cuidados para distinguir custos estimados de preço. A estimativa dos custos envolve elaborar uma avaliação quantitativa dos resultados prováveis - quanto custará para a organização o fornecimento do produto ou serviço envolvido? O preço é uma decisão de negócio – quanto a organização cobrará pelo produto ou serviço – que usa as estimativas de custo apenas como uma entre várias considerações. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 87 A estimativa dos custos inclui identificar e considerar várias alternativas de custo. Por exemplo: na maioria das áreas de aplicação, considera-se amplamente que o trabalho adicional durante a fase de projeto (design) tem o potencial de redução do custo na fase de produção. O processo de estimativa dos custos deve considerar se o custo do trabalho adicional na fase de projeto será contrabalançado pela economia esperada. 7.2.1 Entradas para a Estimativa dos Custos .1 Estrutura Analítica do Projeto. A EAP está descrita na Seção 5.3.3.1. Ela é usada para organizar a estimativa dos custos e assegurar que todo o trabalho identificado foi estimado. .2 Necessidades de recursos. As necessidades de recursos estão descritas na Seção 7.1.3.1. .3 Taxas de recursos. O indivíduo ou grupo que elabora a estimativa deve ter o conhecimento das taxas unitárias (por exemplo, custo horário de pessoal, custo do volume de material por metro cúbico) de cada recurso com a finalidade de calcular os custos do projeto. Se as taxas reais não forem conhecidas, deve se usar estimativas para as mesmas. .4 Estimativas da duração das atividades. As estimativas de duração das atividades (descrita na Seção 6.3) afetarão as estimativas dos custos de qualquer projeto no qual o orçamento considera os custos de financiamento (por exemplo, taxas de juros). .5 Publicações de estimativas. Dados de custos estimados disponíveis comercialmente. .6 Informações históricas. As informações de custos referentes a diversas categorias de recursos freqüentemente estão disponíveis em uma ou mais das seguintes fontes: • Arquivos de projetos – as organizações envolvidas no projeto podem conter em seus arquivos resultados de projetos anteriores, os quais, sendo suficientemente detalhados, auxiliarão na elaboração da estimativa dos custos. Em algumas áreas de aplicação, os próprios membros da equipe podem possuir tais registros. • Base de dados comerciais - informações históricas usualmente estão disponíveis comercialmente. • Conhecimento da equipe do projeto - os membros individuais da equipe de projeto podem lembrar-se de dados reais ou estimativas anteriores. Embora essas memórias possam ser úteis, geralmente são menos confiáveis do que os resultados documentados. .7 Plano de contas. O plano de contas descreve a estrutura de codificação utilizada pela organização para reportar as informações financeiras para o seu sistema contábil. As estimativas do custo do projeto devem ser alocadas na categoria contábil correta. .8 Riscos. A equipe do projeto considera as informações de risco (ver Seção 11.2.3.1) quando está produzindo as estimativas de custo, uma vez que os riscos (sejam ameaças ou oportunidades) podem ter um significativo impacto no custo. A equipe do projeto considera os reflexos dos efeitos do risco quando incluindo as estimativas de custo para cada atividade. Entradas .1 Estrutura analítica do projeto - EAP .2 Necessidade de recursos .3 Taxas de recursos .4 Estimativas da duração da s atividades .5 Publicações de estimativas .6 Informações históricas .7 Plano de contas .8 Riscos Técnicas e Ferramentas .1 Estimativas por analogia .2 Modelagem paramétrica .3.Estimativas de baixo para cima (Bottom-up) .4 Ferramentas computadorizadas .5 Outros métodos de estimativas de custo .1 Estimativas de custo .2 Detalhes de suporte .3 Plano de gerência do custo Saídas Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 88 7.2.2 Ferramentas e Técnicas para a Estimativa dos Custos .1 Estimativas por analogias. Nas estimativas por analogia, também chamadas de estimativas top-down, usam-se os custos reais de projetos anteriores similares como base para a estimativa do custo do projeto corrente. É freqüentemente usada na estimativa dos custos totais do projeto quando existe uma quantidade limitada de informações detalhadas sobre o projeto (por exemplo, nas fases iniciais). As estimativas por analogia são uma forma de avaliação especializada (descrita na Seção 7.1.2.1). As estimativas por analogia são geralmente menos dispendiosas que outras técnicas, mas, também, freqüentemente menos precisas. São mais confiáveis quando (a) os projetos anteriores são semelhantes de fato e não apenas na aparência (b) os indivíduos ou grupos que estão preparando as estimativas possuem o expertize necessário. .2 Modelagem paramétrica. No modelo paramétrico utilizam-se características do projeto (parâmetros) em modelos matemáticos para prever os custos do projeto. Os modelos podem ser simples (as construções residenciais custarão um certo valor por unidade de área construída) ou complexos (um modelo de custos de desenvolvimento de software usa 13 fatores de ajuste com 5 a 7 pontos a serem analisados em cada um deles). Tanto o custo quanto a precisão do modelo paramétrico variam amplamente. Serão provavelmente mais confiáveis quando (a) as informações históricas usadas no desenvolvimento do modelo forem precisas, (b) os parâmetros usados no modelo forem prontamente quantificáveis, e (c) o modelo for escalonável (por exemplo, quando ele funcionar bem tanto para grandes projetos quanto para projetos menores). .3 Estimativas de baixo para cima (Bottom-up). Esta técnica envolve estimar o custo das atividades individuais dos pacotes de trabalho, depois sumarizá-los ou agregá-los para obter a estimativa total do projeto. O custo e a precisão das estimativas botton-up são influenciados pelo tamanho e complexidade das atividades individuais dos pacotes de trabalho: atividades menores aumentam tanto o custo quanto a precisão do processo de estimativa. A equipe de gerenciamento do projeto deve pesar o aumento da precisão contra o custo adicional. .4 Ferramentas computadorizadas. As ferramentas computadorizadas tais como softwares de gerência de projeto e planilhas (spreadsheets) são amplamente utilizadas no apoio à estimativa dos custos. Tais produtos podem simplificar o uso das ferramentas descritas acima e, portanto, agilizar as análises entre várias alternativas de custo. .5 Outros métodos de estimativas de custo. Por exemplo, análise de propostas de vendedores 7.2.3 Saídas da Estimativa dos Custos .1 Estimativas de custo. As estimativas de custo são avaliações quantitativas dos prováveis custos dos recursos requeridos para a implementação das atividades do projeto. Podem ser apresentadas de forma detalhada ou sumarizadas. Os custos devem ser estimados para todos os recursos que serão contabilizados no projeto. Isto inclui, mas não está limitado a mão-de-obra, materiais, suprimentos, e categorias especiais tais como efeitos inflacionários ou reserva de custo. As estimativas de custos são geralmente expressas em unidades monetárias (dólar, euros, yen, etc.) com a finalidade de facilitar comparações tanto internamente no projeto quanto entre projetos. Em alguns casos, as estimativas poderão ser obtidas usando outras unidades de medida tais como homens-hora ou homens-dia, com os seus custos estimados, para facilitar o apropriado controle gerencial. As estimativas de custo geralmente também levam em conta aspectos do plano de respostas aos riscos, tais como planos de contingência. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 91 • Monitorar o desempenho do custo para detectar e entender as variações do plano. • Assegurar que todas as mudanças apropriadas estão registradas corretamente no baseline de custo. • Informar as partes envolvidas afetadas sobre as mudanças autorizadas • Atuar no sentido de manter os custos esperados dentro de limites aceitáveis O controle de custo inclui pesquisar os “porquês” das variações, tanto positivas quanto negativas. Deve estar fortemente integrado com os outros processos de controle (o controle de mudança de escopo, o controle do cronograma, o controle da qualidade, e outros, conforme discutido na Seção 4.3). Por exemplo, uma resposta inadequada para variações do custo pode causar problemas de qualidade ou de prazo, ou produzir, mais adiante no projeto, um nível de risco inaceitável. 7.4.1 Entradas para o Controle dos Custos .1 Baseline do custo. O baseline do custo está descrito na Seção 7.3.3.1. .2 Relatórios de desempenho. Os relatórios de desempenho (discutidos na Seção 10.3.3.1) fornecem informações sobre o escopo do projeto e o desempenho do custo, tais como quais orçamentos estão sendo cumpridos e quais não estão. Os relatórios de desempenho também podem alertar a equipe do projeto para questões que podem causar problemas no futuro. .3 Requisições de mudança. As requisições de mudança podem ocorrer de muitas formas - oral ou escrita, direta ou indiretamente, iniciada externa ou internamente, e legalmente imposta ou opcional. As mudanças podem exigir um aumento no orçamento ou viabilizar a sua redução. .4 Plano de gerenciamento de custo. O plano de gerenciamento de custo está descrito na Seção 7.2.3.3. 7.4.2 Ferramentas e Técnicas para o Controle dos Custos .1 Sistema de controle de mudanças de custo. O sistema de controle de mudanças de custo define os procedimentos pelos quais o baseline de custo pode ser alterado. Inclui manuais, sistemas de acompanhamento e os níveis de aprovação necessários para autorizar as mudanças. O sistema de controle de mudanças de custo deve estar integrado com o sistema de controle integrado de mudanças discutido na Seção 4.3. .2 Medição de desempenho. As técnicas de medição de desempenho, descritas na Seção 10.3.2, auxiliam na avaliação da magnitude de qualquer variação que ocorra. A análise do valor do trabalho realizado (Earned Value), descrita na Seção 10.3.2.4,é especialmente útil para o controle dos custos. Uma parte importante do controle dos custos é determinar o que está causando a variação e decidir se aquela variação requer uma ação corretiva. Entradas Ferramentas e Técnicas Saídas .1 Baseline do custo .2 Relatórios de desempenho .3 Requisições de mudança .4 Plano de gerenciamento de custo .1 Sistema de controle de mudanças de custo .2 Medição de desempenho .3 Earned Value Management (EVM) .4 Planejamento adicional .5 Ferramentas computadorizadas .1 Estimativas de custo revisadas .2 Atualizações do orçamento .3 Ações corretivas .4 Estimativa para conclusão .5 Fechamento do projeto .6 Lições aprendidas Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 92 .3 Gerenciamento de Valor Agregado. Todos os Planos de Controle Contábil do gerenciamento do valor agregado devem medir continuamente o desempenho do projeto através do relacionamento de três variáveis independentes: 1) O Valor Planejado [VP], que representa o trabalho físico programado para execução, incluindo o valor estimado deste trabalho (anteriormente denominado Custo Orçado do Trabalho Planejado [COTP] ), comparado como 2) Valor Agregado [VA], que é o trabalho físico realmente executado, incluindo o valor estimado para esse trabalho (anteriormente denominado Custo Orçado do Trabalho Executado [COTE] ), e com o 3) Custo Real [CR], gasto para atingir o Valor Agregado. O relacionamento entre 2) Valor Agregado menos 1) Valor Planejado representa a Variação de Prazo [VP]. O relacionamento entre 2) Valor Agregado menos 3) Custo Real representa a Variação de Custo [VC] do projeto. Veja também a Seção 10.3.2.4. .3 Planejamento adicional. Poucos projetos se desenvolvem exatamente conforme o planejado. Mudanças em perspectiva podem exigir uma estimativa nova ou uma revisão de custos ou, ainda, exigir uma análise quanto a abordagens alternativas. .4 Ferramentas computadorizadas. As ferramentas computadorizadas, tais como softwares de gerenciamento de projeto e planilhas são freqüentemente utilizadas para acompanhar o custo planejado versus o custo real, e para prever os efeitos das mudanças de custo. 7.4.3 Saídas do Controle dos Custos .1 Estimativas de custo revisadas. As estimativas de custo revisadas são modificações nas informações de custo utilizadas para gerenciar o projeto. As partes envolvidas afetadas devem ser notificadas. As estimativas de custo revisadas podem requerer ou não ajustes em outros aspectos do plano geral do projeto. .2 Atualizações do orçamento. As atualizações do orçamento são uma categoria especial das estimativas de custo revisadas. As atualizações do orçamento são mudanças no baseline aprovado. Esses números são normalmente revisados apenas em resposta a mudanças no escopo. Em alguns casos, as variações de custo podem ser tão severas que um replanejamento (rebaselining) seja necessário com a finalidade de possibiliatar uma medição realística do desempenho. .3 Ações corretivas. Uma ação corretiva é qualquer ação tomada no sentido de ajustar o desempenho futuro esperado com o plano do projeto. .4 Estimativa para a conclusão (Estimate at Completion). A estimativa para a conclusão (EAC) é uma previsão do mais provável custo total do projeto baseada no desempenho do projeto e nas quantificações de risco, descritas na Seção 11.4.3.. As técnicas mais comuns de previsão são algumas variações do: • EAC = custo real até a data mais uma nova estimativa para todo o trabalho restante. Essa abordagem é mais freqüentemente usada quando o desempenho passado revela que as premissas da estimativa original eram bastante imperfeitas, ou que não são mais relevantes, devido a mudanças nas condições atuais. Fórmula: EAC = CRTR + ETC • EAC = custo real até a data, mais o orçamento restante (BAC – COTR). Essa abordagem é mais freqüentemente usada quando as variações correntes são vistas como atípicas e a expectativa da equipe de gerenciamento do projeto é que tais variações não se repetirão no futuro. Fórmula: EAC = CRTR + BAC - COTR • EAC = custo real até a data, mais o orçamento restante do projeto (BAC – COTR) modificado por um fator de desempenho, freqüentemente o índice de desempenho acumulado de custo (IPC). Essa abordagem é mais freqüentemente usada quando as variações correntes são vistas como típicas para variações futuras. Fórmula: EAC = (CRTR + (BAC – COTR)/IPC), sendo este IPC o índice acumulado Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em janeiro de 2002 PMI Capítulo de Minas Gerais - www.pmimg.org.br 93 Cada uma destas abordagens pode ser a abordagem correta para um dado projeto e alertará a equipe de gerenciamento sempre que as previsões de custo na conclusão do projeto (EAC) se mostrarem além das tolerâncias aceitáveis. .5 Fechamento do projeto. Devem ser estabelecidos processos e procedimentos para o encerramento ou cancelamento dos projetos. Num exemplo americano, o Statement of Position (SOP 98-1 publicado pelo American Institute of Certified Public Accountants- AICPA) exige que, no caso de um projeto de tecnologia de informação fracassado, todos os custos sejam registrados no trimestre em que o projeto é cancelado. 6 Lições aprendidas. As causas das variações, as razões por trás das ações corretivas tomadas e outros tipos de lições aprendidas durante o controle de custos, devem ser documentadas de forma a se tornarem-se parte da base de dados históricos a ser utilizada tanto no projeto corrente como em outros projetos da organização executora (veja a Seção 4.3.3.3). Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 PMI Capítulo de Minas Gerais - www.pmimg.org.br 97 • Satisfação do cliente - entender, gerenciar e influenciar as necessidades de forma que as expectativas do cliente sejam atendidas. Isso requer a combinação de conformidade com requisitos (o projeto deve produzir o que foi dito que produziria) com adequação ao uso (o produto ou serviço produzido deve satisfazer as reais necessidades). • Prevenção ao invés de inspeção - o custo da prevenção de erros é sempre muito menor que o custo para corrigi-los, como demonstrado pela inspeção. • Responsabilidade da gerência - o sucesso exige a participação de todos os membros da equipe, mas permanece como responsabilidade da gerência fornecer os recursos necessários para sua efetivação. • Processos dentro de fases – o ciclo repetitivo de planejar-desenvolver,-checar-agir (PDCA) descrito por Deming e outros é bastante similar à combinação de fases e processos discutida no Capítulo 3, Gerenciamento dos Processos do Projeto. Além do mais, as iniciativas de melhoria da qualidade desenvolvidas pela organização executora (por exemplo, Gestão da Qualidade Total, Melhoria Contínua e outras) podem melhorar tanto o gerenciamento do projeto quanto a qualidade do produto do projeto. Entretanto, existe uma diferença importante que deve merecer particular atenção da equipe de gerenciamento do projeto - a natureza temporária do projeto faz com que os investimentos na melhoria na qualidade do produto, especialmente a prevenção de defeitos e avaliação, devem, freqüentemente, ficar a cargo da organização executora, uma vez que o projeto pode não durar o suficiente para colher as recompensas. 8.1 PLANEJAMENTO DA QUALIDADE O planejamento da qualidade envolve identificar que padrões de qualidade são relevantes para o projeto e determinar como satisfazê-los. Ele é um dos processos facilitadores chave do planejamento do projeto (ver Seção 3.3.2, Processos do Planejamento) e deve ser executado de forma regular e em paralelo com os outros processos de planejamento do projeto. Por exemplo, mudanças no produto do projeto, necessárias para atender os padrões de qualidade identificados, podem exigir ajustes no prazo ou no custo ou, ainda, a qualidade desejada do produto pode exigir uma análise detalhada do risco de um problema identificado. Antes do desenvolvimento das séries ISO 9000, as atividades aqui descritas como planejamento da qualidade eram amplamente discutidas como parte da garantia da qualidade. As técnicas de planejamento da qualidade discutidas aqui são aquelas mais freqüentemente empregadas nos projetos. Existem muitas outras que podem ser úteis em determinados projetos ou em algumas áreas de aplicação. A equipe do projeto deve, também, estar atenta a um dos princípios fundamentais da moderna gerência de qualidade - a qualidade é planejada, não inspecionada. Entradas Ferramentas e Técnicas Saídas .1 Políticas de qualidade .2 Declaração do escopo .3 Descrição do produto .4 Padrões e regulamentações .5 Saídas de outros processos .1 Análise de custo/benefício .2 Benchmarking .3 Fluxogramação .4 Desenho de experimentos .5 Custo da Qualidade .1 Plano de gerenciamento da qualidade .2 Definições operacionais .3 Checklists .4 Entradas para outros processos Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 PMI Capítulo de Minas Gerais - www.pmimg.org.br 98 8.1.1 Entradas para o Planejamento da Qualidade .1 Políticas de qualidade. As políticas de qualidade podem ser definidas como “as intenções e direcionamentos globais de uma organização com relação à qualidade, expressos formalmente pela alta gerência” [4]. Na maioria das vezes, as políticas de qualidade da organização podem ser adotadas pelo projeto “na sua forma original”. Entretanto, se na organização faltarem políticas formais de qualidade, ou se o projeto envolver múltiplas organizações (como as joint-venture), a equipe de gerenciamento do projeto deve desenvolver suas próprias políticas de qualidade para o projeto. Seja qual for a origem das políticas de qualidade, a equipe de gerenciamento do projeto é responsável por garantir que as partes envolvidas no projeto estejam plenamente conscientes dela (por exemplo, através da distribuição adequada das informações, como descrito na Seção 10.2). .2 Declaração do escopo. A declaração do escopo (descrita na Seção 5.2.3.1) é a entrada chave para o planejamento da qualidade, uma vez que ela documenta os principais subprodutos do projeto bem como os objetivos do projeto que servem para definir importantes requisitos das partes envolvidas. 3 Descrição do produto. Embora os elementos da descrição do produto (descritos na Seção 5.1.1.1) possam estar incorporados na declaração do escopo, a descrição do produto conterá, na maioria das vezes, detalhes de questões técnicas e outros aspectos, que podem afetar o planejamento da qualidade. .4 Padrões e regulamentos. A equipe de gerenciamento do projeto deve considerar os padrões e regulamentos específicos da área de aplicação que possam afetar o projeto. A Seção 2.5.1 discute os conceitos de padrões e regulamentos. .5 Outras saídas dos processos. Além da declaração do escopo e da descrição do produto, os processos das outras áreas de conhecimento podem produzir saídas que devem ser consideradas como parte do planejamento da qualidade. Por exemplo, o planejamento das aquisições (descrito na Seção 12.1) pode identificar as exigências de qualidade dos contratantes que devem estar refletidas em todo o plano de gerenciamento da qualidade. 8.1.2 Ferramentas e Técnicas para o Planejamento da Qualidade .1 Análise de custo/benefício. Os processos de planejamento da qualidade devem considerar as relações de custo/benefício, como descrito na Seção 5.2.2.2. O principal benefício do atendimento dos requisitos de qualidade é um menor retrabalho, o que significa maior produtividade, menores custos e aumento da satisfação das partes envolvidas. O principal custo do atendimento dos requisitos de qualidade é o gasto associado às atividades de gerenciamento da qualidade do projeto. É um axioma da disciplina de gerência da qualidade que os benefícios superam os custos. .2 Benchmarking. O Benchmarking envolve comparar as práticas reais ou planejadas do projeto com as de outros projetos, para gerar idéias de melhoria e fornecer um padrão pelo qual se possa medir o desempenho. Os outros projetos podem estar dentro da organização executora ou fora dela. Podem, ainda, estar dentro da mesma área de aplicação ou em outra área. .3 Fluxogramação. Um fluxograma é qualquer diagrama que mostre como os vários elementos de uma sistema se relacionam. As técnicas de fluxogramação comumente usadas no gerenciamento da qualidade são: • Diagrama de Causa e Efeito: também conhecido como Diagrama de Ishikawa ou Diagrama Espinha de Peixe, que ilustra como as diversas causas e sub-causas estão relacionadas com a criação de problemas ou efeitos potenciais. A Figura 8.2 é um exemplo de um diagrama de causa e efeito genérico. • Fluxogramas de Sistema ou Processo, que mostram como os diversos elementos do sistema se interagem. A Figura 8.3 é um exemplo de um fluxograma de processo para revisão de projeto. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 PMI Capítulo de Minas Gerais - www.pmimg.org.br 99 A fluxogramação pode auxiliar a equipe do projeto a antecipar os problemas de qualidade e onde esses problemas podem ocorrer e, por conseguinte, auxiliar na elaboração de abordagens para lidar com os mesmos. .4 Desenho de experimentos. O desenho de experimentos é um método estatístico que auxilia a identificar que fatores provavelmente influenciam determinadas variáveis. A técnica é mais freqüentemente aplicada ao produto do projeto (por exemplo, os projetistas do setor automobilístico podem desejar determinar que combinações de suspensão e pneus produzirão as mais vantajosas características de locomoção a um custo razoável). Essa técnica pode, também, aplicar-se às questões da gerência de projeto, tais como os balanceamentos entre prazo e custo. Por exemplo, embora os engenheiros senior sejam mais caros que os engenheiros junior, espera-se, também, que os primeiros completem o trabalho num menor prazo. Um “experimento” bem projetado (neste caso, computando os custos e prazos das diversas combinações de engenheiros senior e junior) permitirá, na maioria das vezes, determinar uma solução ótima, para uma quantidade relativamente limitada de casos. .5 Custo da Qualidade. O custo da qualidade refere-se ao custo total de todos os esforços empreendidos para atingir a qualidade do produto/serviço, e inclui todo o trabalho para garantir a conformidade com os requisitos, bem como todo o trabalho resultante da não conformidade com os requisitos. Existem três tipos de custos: custos de prevenção, custos de avaliação e custos de falha, onde o último é desmembrado em custos de falha interna e externa. 8.1.3 Saídas do Planejamento da Qualidade .1 Plano de gerenciamento da qualidade. O plano de gerenciamento da qualidade deve descrever como a equipe de gerenciamento do projeto irá implementar suas políticas de qualidade. Na terminologia ISO 9000, ele deve descrever o sistema de qualidade do projeto: “a estrutura organizacional, responsabilidades, procedimentos, processos e recursos necessários para implementar o gerenciamento da qualidade” [5]. O plano de gerenciamento da qualidade é entrada para o plano geral do projeto (descrito na seção 4.1, Desenvolvimento do Plano do Projeto) e deve endereçar o controle da qualidade, a garantia da qualidade e a melhoria da qualidade do projeto. O plano de gerenciamento da qualidade pode ser formal ou informal, muito detalhado ou bastante amplo, tendo como base as necessidades do projeto. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 PMI Capítulo de Minas Gerais - www.pmimg.org.br 102 planejadas ou casuais, podendo ser conduzidas tanto por auditores da própria organização, devidamente treinados, quanto por terceiros, tais como agências de registro de sistemas de qualidade. 8.2.3 Saídas da Garantia da Qualidade .1 Melhoria da qualidade. A melhoria da qualidade inclui a tomada de ações para aumentar a efetividade e a eficiência do projeto para proporcionar benefícios adicionais para as partes envolvidas no projeto. Na maioria dos casos, implementar as melhorias de qualidade exigirá a preparação de requisições de mudanças ou a tomada de ação corretiva e será gerenciada de acordo como os procedimentos do controle geral de mudanças, como descrito na Seção 4.3. 8.3 CONTROLE DA QUALIDADE O controle da qualidade envolve monitorar os resultados específicos do projeto para determinar se eles estão de acordo com os padrões de qualidade relevantes e identificar formas de eliminar as causas dos resultados insatisfatórios. Deve ser executado ao longo do projeto. Os resultados do projeto incluem tanto os resultados do produto quanto os resultados do gerenciamento do projeto, tais como desempenho do custo e do prazo. O controle da qualidade é normalmente executado pelo Departamento de Controle da Qualidade ou unidade organizacional similar, embora isso não seja uma exigência. A equipe de gerenciamento do projeto deve ter conhecimento prático de controle estatístico da qualidade, especialmente sobre as técnicas de amostragem e probabilidade, para auxiliá-la na avaliação das saídas do controle da qualidade. Dentre outros assuntos, ela deve saber a diferença entre: • Prevenção (manter os erros fora dos processos) e inspeção (manter os erros fora das mãos do cliente). • Amostragem por atributo (o resultado está conforme ou não) e amostragem por variável (os resultados são distribuídos numa escala contínua que mede o grau de conformidade). • Causas especiais (eventos não usuais) e causas aleatórias (variações normais do processo). • Tolerâncias (o resultado é aceitável se está dentro de um intervalo específico de tolerância) e limites de controle (o processo está sob controle se o resultado está dentro dos limites de controle). Entradas Saídas Técnicas e Ferramentas .1 Inspeção .2 Cartas de controle .3 Diagramas de Pareto .4 Amostragem estatística .5 Fluxogramação .6 Análise de tendências .1 Melhoria da qualidade .2 Decisões de aceitação .3 Retrabalho .4 Checklists preenchidos .5 Ajustes no processo .1 Resultados do trabalho .2 Plano de gerenciamento da qualidade .3 Definições operacionais .4 Checklists . Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 PMI Capítulo de Minas Gerais - www.pmimg.org.br 103 8.3.1 Entradas para o Controle da Qualidade .1 Resultados do trabalho. Os resultados do trabalho (descritos na Seção 4.2.3.1 ) incluem tanto os resultados dos processos quanto os resultados do produto. As informações sobre os resultados esperados ou planejados (do plano do projeto) devem estar disponíveis juntamente com as informações dos resultados apurados. .2 Plano de gerenciamento da qualidade. O plano de gerenciamento da qualidade é descrito na Seção 8.1.3.1. .3 Definições operacionais. As definições operacionais são descritas na Seção 8.1.3.2. .4 Checklists (Lista de verificações). Os checklists são descritos na Seção 8.1.3.3. 8.3.2 Ferramentas e Técnicas para o Controle de Qualidade .1 Inspeção. A inspeção inclui as atividades tais como medir, examinar e testar, executadas para determinar se os resultados estão em conformidade com os requisitos. As inspeções podem ser conduzidas em qualquer nível (por exemplo, os resultados de uma simples atividade podem ser inspecionados ou o produto final do projeto pode ser inspecionado). As inspeções são chamadas, de forma variada, revisões, revisões de produto, auditorias e acompanhamentos (walkthroughs); em algumas áreas de aplicação estes termos possuem um significado específico e limitado. .2 Cartas de controle. As cartas de controle são gráficos que apresentam os resultados de um processo ao longo do tempo. São utilizadas para determinar se o processo está “sob controle” (por exemplo, existem diferenças nos resultados devido a variações aleatórias ou existem ocorrências de eventos não usuais cujas causas devem ser identificadas e corrigidas?). Quando um processo está sob controle, ele não deve ser ajustado. O processo pode ser modificado para proporcionar melhorias, mas ele não deve ser ajustado quando está sob controle. As cartas de controle podem ser usadas para monitorar qualquer tipo de variável de saída. Embora mais freqüentemente utilizadas no acompanhamento de atividades repetitivas, tais como lotes de fabricação, as cartas de controle podem, também, ser empregadas para monitorar as variações de custo e prazo, volume e freqüência de mudanças no escopo, erros nos documentos do projeto ou outros resultados do gerenciamento para ajudar a determinar se o processo de gerenciamento do projeto está sob controle. A Figura 8.4 é uma carta de controle do desempenho do prazo do projeto. .3 Diagramas de Pareto. O diagrama de Pareto é um histograma, ordenado por freqüência de ocorrência, que mostra quantos resultados foram gerados por tipo ou categoria de causa identificada (veja Figura 8.5). A ordenação por freqüência é utilizada para direcionar as ações corretivas - a equipe do projeto deve tomar ações para corrigir, primeiro, os problemas que estão causando a maior quantidade de defeitos. Os diagramas de Pareto estão, conceitualmente, relacionados à Lei de Pareto que afirma que uma quantidade consideravelmente pequena de causas irá, tipicamente, produzir a grande maioria dos problemas ou defeitos. Ela é comumente referenciada como princípio de 80/20, onde 80 por cento dos problemas se devem a 20 por cento das causas. .4 Amostragem estatística. A amostragem estatística envolve escolher para inspeção uma parte da população alvo (por exemplo, escolher aleatoriamente dez plantas de engenharia de uma lista de setenta e cinco). Uma amostragem apropriada normalmente reduz os custos de controle da qualidade. Existe um corpo significativo de conhecimento sobre amostragem estatística; em algumas áreas de aplicação é necessário que a equipe de gerenciamento do projeto esteja familiarizada com a variedade de técnicas de amostragem. Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 PMI Capítulo de Minas Gerais - www.pmimg.org.br 104 5 Fluxogramação. A fluxogramação é descrita na Seção 8.1.2.3. A fluxogramação é usada no controle da qualidade para auxiliar na análise dos problemas. .6 Análise de tendência. A análise de tendência envolve a utilização de técnicas matemáticas para prever resultados futuros com base nos resultados históricos. A análise de tendência é normalmente empregada para monitorar: • Desempenho técnico - quantos erros ou defeitos foram identificados, quantos permanecem sem correção. • Desempenho de custo e prazo - quantas atividades, por período, foram concluídas com variações significativas. 8.3.3 Saídas do Controle da Qualidade .1 Melhoria da qualidade. A melhoria da qualidade é descrita na Seção 8.2.3.1. .2 Decisões de aceitação. Os itens inspecionados serão aceitos ou rejeitados. Os itens rejeitados podem exigir retrabalho (descrito na Seção 8.3.3.3)..3 Retrabalho. O retrabalho é uma ação tomada para adequar os itens com defeito, ou em não conformidade, aos requisitos ou especificações. O retrabalho, especialmente aquele não antecipado, é causa freqüente de atrasos no projeto, na maioria das áreas de aplicação. A equipe do projeto deve empreender o máximo de esforço para minimizar o retrabalho. .4 Checklists preenchidos. Veja na Seção 8.1.3.3. Quando os checklists são utilizados, aqueles preenchidos devem fazer parte dos registros do projeto. .5 Ajustes no processo. Os ajustes no processo envolvem a tomada de ações corretivas ou preventivas imediatas como resultado das medições do controle de qualidade. Em alguns casos, os ajustes no processo podem necessitar ser tratados conforme os procedimentos do controle geral de mudança, como descrito na Seção 4.3. Limite superior de controle Limite inferior de controle Em todos as cartas de controle, o eixo dos X consiste de número de amostras (usualmente o tempo das amostras). As cartas de controle têm três linhas comuns: I. Uma linha central, designada com um “X”, que representa a média(X) dos dados processados. II. Uma linha na parte superior designando o limite superior de controle (LSC), representada a uma certa distância acima da linha do centro, mostrando a faixa superior dos dados. III. Uma linha na parte inferior designando o limite inferior de controle (LIC), que mostra a faixa mais baixa dos dados. Os pontos fora de LSC e LIC são indicadores que o processo está fora de controle e/ou é instável. Figura 8.4.. Carta de Controle do Desempenho do Cronograma do Projeto _
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved