FUNDAMENTOS DE GERENCIAMENTO DE PROJETOS

Transcrição

1 FUNDAMENTOS DE GERENCIAMENTO DE PROJETOS

2 Sumário Conceitos de Gerenciamento de Projetos...5 O QUE É UM PROJETO?...7 GERENCIAMENTO DE PROJETOS...10 Processos de Iniciação...21 Processo de Planejamento...28 Execução, Monitoramento e Controle do Projeto...83 RELATÓRIO DE STATUS DO PROJETO...94 Projeto...94 Data...94 Número...94 Principais Entregas realizadas...94 % completo do projeto REALIZADO...94 % completo do projeto PLANEJADO...94 Valor Planejado (PV)...94 Custo Real (AC)...94 Valor Agregado (EV)...94 Orçamento do Projeto (BAC)...94 Data de Término prevista...94 Copyright Compass International Knowledge Center 2

3 Indicadores...94 Anterior...94 Atual...94 Sinalizador...94 Variação de Custo (CV)...94 Variação de Prazo (SV)...94 Performance de Custo (CPI)...94 Performance de Prazo (SPI)...94 Estimativa de Custo no Término (EAC)c...94 Estimativa de Prazo no Término (EAC)t...94 Ações Corretivas...94 FORMULÁRIO DE SOLICITAÇÃO DE MUDANÇA NO PROJETO...98 Projeto...98 Data da Solicitação...98 Número...98 Solicitante...98 Descrição da Mudança...98 Justificava para a Mudança...98 Impactos no projeto e medidas para mitigação dos impactos Escopo Tempo Custo Qualidade...98 Copyright Compass International Knowledge Center 3

4 Riscos do projeto Aprovador...98 Data da Aprovação...98 Encerramento do Projeto Copyright Compass International Knowledge Center 4

5 Conceitos de Gerenciamento de Projetos Será a atual preocupação das empresas com o tema gestão de projetos um mero modismo? Alguns indicadores observados no contexto empresarial atual nos levam a crer que não. Conseqüência de uma volatilidade cada vez mais acentuada de mercados que aparecem e desaparecem da noite para o dia, a instabilidade econômica, característica no passado de períodos sazonais, hoje é uma realidade com a qual as organizações precisam conviver. Este cenário torna a competição cada vez mais acirrada e agressiva e faz com que os riscos incorporados aos negócios adquiram dimensões desproporcionais. Neste contexto, os recursos consumidos pelas empresas para realizar suas estratégias tornam-se cada vez mais importantes e precisam ser geridos com o máximo de eficiência. Instrumento indispensável para o crescimento e sobrevivência no volátil mercado atual, a capacidade de inovação é outro importante fator crítico de sucesso. Inovar, diferentemente de apenas inventar, pressupõe um processo estruturado de estudos técnicos e financeiros até a transformação em aplicações que trarão resultados efetivos para a organização geradora da inovação. Isto é, inovação no meio empresarial é transformação de idéias em negócios. O papel dos projetos neste contexto Se analisarmos como as organizações estruturam seus planos estratégicos, veremos que as ações ou iniciativas estratégicas que realizam seus objetivos estratégicos de crescimento são de fato materializadas através da execução de projetos. O lançamento de novos produtos, a expansão para uma nova área de negócios, mudanças estruturais, como o aumento de capacidade de produção ou da produtividade de algum setor da organização devem ser conduzidas por meio de projetos. Copyright Compass International Knowledge Center 5

6 Realização de objetivos estratégicos através de projetos Portanto, pode-se afirmar que o alcance dos objetivos estratégicos de uma organização ocorre na medida do sucesso de seus projetos estratégicos. Ou seja, a eficácia de um planejamento estratégico organizacional está diretamente relacionada à eficácia de seus projetos estratégicos. Porém, os resultados dos projetos que são realizados atualmente não são nada satisfatórios. Segundo pesquisa de 2004 publicada pelo Standish Group, instituto de pesquisas americano, apenas 34% dos projetos realizados foram considerados concluídos com sucesso. Apesar de o conceito de sucesso em projetos não ser simples de ser definido, como veremos posteriormente, fica evidente a necessidade de melhoria no desempenho dos projetos conduzidos nas organizações. Algumas perguntas que dificilmente encontrarão respostas dão uma idéia da dimensão de recursos envolvidos: Quantos projetos terminam fora do prazo? Quanto custa o atraso? Quantos projetos terminam acima do orçamento? Quanto é gasto a mais? Quantos projetos terminam sem completar o escopo? Que perdas são geradas pelo que deixa de ser realizado por projetos que não completam seus escopos? Qual o custo da não-conformidade? Qual o custo do cliente insatisfeito? Da perda de um cliente? Pode-se concluir, então, que a preocupação com o gerenciamento de projetos de forma metodológica para a obtenção de resultados estratégicos não é um mero modismo ou onda passageira, mas uma necessidade real. Project Management Institute - PMI A busca da melhoria no desempenho de projetos teve um marco importante no final da década de 60. Neste ano foi criado o Project Management Institute. Instituição não governamental sem fins lucrativos situada na Pensilvânia, Estados Unidos, e que tem como missão fomentar a atividade de gerenciamento de projetos. O PMI tem abrangência internacional e está organizado em mais de 200 sucursais chamadas de Chapters, distribuídos em 125 países. Atualmente existem cerca de afiliados que têm acesso, através do site do PMI, a documentos, artigos e informações sobre gerenciamento de projetos. A filiação pode ser feita, mediante o pagamento de uma taxa no site: Guia PMBOK 1 Project Management Body Of Knowledge O PMI tem, também, a responsabilidade de publicar o Conjunto de Conhecimentos em Gerenciamento de Projetos que está em sua quarta edição, lançada em O Guia PMBOK, como é conhecido, é um guia de referência básica de conteúdo para profissionais de gerenciamento de projetos e contribui para a divulgação de uma terminologia e vocabulário, comuns ao ambiente de projetos. É construído a partir da contribuição de descrições de BOAS PRÁTICAS resultantes de experiências 1 PMBOK é marca registrada de Project Management Institute. Copyright Compass International Knowledge Center 6

7 de profissionais do mundo inteiro que as encaminham a comitês responsáveis por consolidá-las em um documento estruturado. O guia está organizado em 9 áreas de conhecimento: gerenciamento do escopo, gerenciamento do tempo, gerenciamento dos custos, gerenciamento da qualidade, gerenciamento dos recursos humanos, gerenciamento das comunicações, gerenciamento dos riscos, gerenciamento das aquisições e gerenciamento da integração do projeto, que serão abordadas posteriormente e cujo domínio é considerado essencial para um bom gerenciamento de projetos. Certificação PMP 2 Project Management Professional Outra atribuição do PMI é certificar profissionais em gerenciamento de projetos. A certificação PMP é concedida aos aprovados em um teste de 200 questões de múltipla escolha que procura avaliar o candidato nas áreas de conhecimento do Guia PMBOK e em situações práticas do dia-a-dia do gerenciamento de projetos. Para habilitar-se a fazer a prova é necessário comprovar horas de experiência prática em projetos, para quem possui graduação superior, e horas para profissionais de nível técnico e pagar uma taxa de 525 dólares americanos para não afiliados ao PMI, e 425 para afiliados. Além da certificação PMP o PMI também tem outras certificações relacionadas ao tema gerenciamento de projetos, a saber: PgMP (Program Management Professional) demonstra conhecimento e experiência na condução de programas. PMI-RMP (Risk Management Professional) demonstra conhecimento e experiência em gerenciamento de riscos de projetos. PMI-SP (Schedulling Professional) demonstra conhecimento e experiência em gerenciamento de cronogramas de projetos. CAPM (Certified Associate of Project Management) demonstra conhecimento em gerenciamento de projetos. Para profissionais que ainda não têm tempo de experiência suficiente para serem certificados como PMP. O QUE É UM PROJETO? O senso geral utiliza o termo projeto para referir-se a atividades da vida cotidiana tais como: projeto de vida; uma intenção futura; desenhos, plantas, com instruções para construção ou montagem de estruturas, enfim, aplicações das mais diversas e livres. Para este estudo, vamos considerar o conceito de projeto, de forma tecnicamente restrita, como: o todo de um esforço, ou empreendimento, temporário para criar um 2 PMP, PgMP, PMI-RMP, PMI-SP e CAPM são marcas registradas de Project Management Institute. Copyright Compass International Knowledge Center 7

8 produto, serviço ou resultado exclusivo. Envolve todo o processo desde a identificação da demanda até a entrega do produto, serviço ou resultado final. Conceituar projeto tecnicamente é importante para que possamos reconhecê-los no contexto do dia-a-dia, distinguindo-os das rotinas operacionais e aplicarmos técnicas de gerenciamento específicas para obter melhores resultados. O Guia PMBOK define projeto como um esforço temporário para criar um produto, serviço ou resultado exclusivo. Temporário Significa que, comparado com operações de rotina, um projeto tem início e fim definidos antes do início de sua execução. PLANO A B Obj t D 0 Janela de TEMPO D Deadline Produtos, Serviços ou Resultados exclusivos Mesmo que haja algumas semelhanças, os resultados dos projetos apresentam diferenças. Prédios com o mesmo número de andares, mesmo desenho de planta, executados pela mesma construtora, etc., terão resultados únicos, uma vez que seus processos de construção serão diferentes, suas orientações em relação ao sol serão diferentes, suas fundações terão dimensões diferentes, pois estarão em posições de terreno diferentes, etc. A árvore de decisão, ao lado, representa o processo de escolhas de alternativas em um projeto. A ponderação de prós e contras em cada ponto de decisão é um processo de TRADE-OFF (conceito da economia no qual nenhuma alternativa possui apenas vantagens nem apenas desvantagens) A B C D E F G H I J K L M N O P Q R S T U V X Y W Z A1 B1 C1 D1 E1 É Probabilístico (Não é Determinístico) Tem Risco (incerteza) No senso comum, a palavra projeto carrega a idéia de plano para futuro, previsão. Possui sempre uma carga de incerteza de que acontecerá o Copyright Compass International Knowledge Center 8

9 esperado, ou planejado. Esta característica torna o papel do gerenciamento do projeto mais relevante, pois atua exatamente para reduzir a taxa de desvio entre planejado e executado. o fator crítico de sucesso de um projeto reside na capacidade de realização de atividades através das pessoas. Determinados tipos de operações são intensivos em máquinas ou equipamentos, mas em projetos os ativos principais são, de fato, as pessoas que o realizam. Elaboração Progressiva (em Etapas Fases) As características anteriormente apresentadas conduzem a esta terceira característica de qualquer projeto: não se conhece cabalmente o que será o projeto assim que o mesmo se inicia. Com o passar do tempo, o conhecimento que se tem dele aumenta. Para lidar com essa característica, que traz incerteza e indefinição para qualquer projeto, costuma-se utilizar o recurso prático de segmentá-lo em etapas ou fases para melhorar a capacidade de gerenciamento e aumentar as chances de sucesso do projeto. O princípio analítico de que partes menores são mais facilmente gerenciáveis vale muito em projetos. A divisão das fases que marcarão o processo do projeto deve ser feita de acordo com a melhor conveniência do gerenciamento e irá variar de acordo com a característica específica de cada projeto. Recursos limitados Nas rotinas do dia-a-dia, os recursos são renovados para mantê-los em funcionamento permanente. Em um projeto os recursos financeiros e humanos têm limites definidos pelo tempo de sua duração, pelo escopo e pela qualidade do resultado esperado. O conceito de limitação pressupõe Copyright Compass International Knowledge Center 9

10 quantificação e é diferente do conceito de escassez, pois recursos escassos são insuficientes para alcançar os resultados planejados. Precisa de Administração Específica As técnicas de gestão operacional não são suficientes para dar conta das dificuldades próprias dos projetos. As características dos projetos tornam as ações de planejamento, programação e controle mais críticas e complexas, exigindo, portanto, técnicas e ferramentas específicas. Outra maneira de definir o conceito de projetos é através da comparação com as características das operações rotineiras. Projetos x Operações Decisões Irreversíveis x Decisões Reversíveis Projetos, por sua natureza temporária, existem durante uma janela de tempo limitada. Isso torna as decisões tomadas no âmbito do projeto muito mais críticas, pois, na maioria das vezes, não há tempo suficiente para reverter suas conseqüências. Variáveis Exógenas x Variáveis Endógenas Na operação os fatores que influenciam mais fortemente seu desempenho são oriundos de dentro do ambiente operacional, e, portanto mais passíveis de controle. O projeto sofre influência intensiva de fatores ou agentes externos à equipe do projeto. Fluxo de Caixa Negativo x Fluxo de Caixa Positivo A menos que um ambiente operacional esteja passando por uma crise financeira, o montante das receitas geradas supera o de despesas no período de tempo do ciclo de operação. Projetos são empreendimentos que geram despesas que só poderão ser cobertas quando seus produtos criados gerarem os resultados esperados e conseqüentemente as receitas. Mesmo que de forma indireta, como no caso dos projetos de modificações estruturais desenvolvidos dentro das empresas. Por essa razão torna-se quase que na totalidade dos casos obrigatória a redução do período de existência do projeto (ciclo de vida). GERENCIAMENTO DE PROJETOS Segundo o Guia PMBOK, gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O grande desafio começa em ser capaz de gerenciar e não apenas executar ou, como é comum ouvir-se, tocar o projeto. O gerenciamento, que queremos tratar aqui, pressupõe um processo estruturado e, preferencialmente, com a aplicação de um método, ou metodologia. O gerenciamento de projetos implica em levantar necessidades, e identificar prioridades entre ESCOPO, TEMPO e CUSTO. Copyright Compass International Knowledge Center 10

11 Priorizar escopo, tempo e custo significa que há uma dificuldade intrínseca de projetos em atender plena e simultaneamente as três dimensões principais de um projeto, uma vez que projetos são carregados de incertezas geradoras de desvios. Cada projeto tem uma relação de prioridades diferente destas variáveis. Em um determinado projeto o vetor prioritário, ou FATOR CRÍTICO DE SUCESSO, (também conhecido como DRIVER do projeto, ou seja, fator direcionador) será o custo, ou seja, todas as outras variáveis deverão ser subordinadas ao cumprimento dos objetivos e metas de custo do projeto. Em outro, poderá ser o tempo, significando que as outras variáveis serão dimensionadas para que o projeto cumpra o prazo previsto. Projetos de um mesmo tipo, a construção de uma casa, por exemplo, podem ter prioridades diferentes. Vamos analisar três casos como exemplo. Primeiro caso: o cliente precisa se mudar até uma data específica porque terá que entregar o apartamento que ocupa no momento. A prioridade do projeto será o tempo. É provável que próximo da data marcada para a mudança do cliente, se o projeto estiver atrasado, seja necessário aumentar o custo para cumprir o prazo. Talvez o escopo tenha que ser suprimido em alguns elementos que não sejam essenciais à mudança do cliente, pois o prazo é o vetor menos flexível. Segundo caso: o cliente do projeto possui um montante determinado de recursos financeiros e precisa construir uma casa que se encaixe neste valor. Como nesse caso a prioridade é o custo, é provável que o cronograma tenha que ser estendido em função do limite de orçamento. Da mesma forma o escopo, se houver necessidade, tenha que ser cortado, naquilo que não impeça o funcionamento básico da residência. Terceiro caso: o cliente do projeto deseja uma casa com especificações tais como: número de quartos, banheiros, salas, salão de jogos, piscina com características específicas, etc. Nesse caso, o cronograma, assim como o orçamento, na dinâmica incerta do projeto, provavelmente, tenha que ser aumentado para cumprir os requisitos de escopo. Porém, estabelecer prioridades não significa descuido ou abandono das variáveis que não são a prioritária, pelo contrário. O bom desempenho no conjunto das variáveis de restrição do projeto aumenta a probabilidade de sucesso no vetor prioritário e consequentemente do projeto. A prioridade de objetivos, porém, não é facilmente identificável. O primeiro impulso dos principais interessados é desejar que todas as demandas, variáveis, objetivos, ou vetores, sejam atendidos igualmente. O que é, quase sempre, inviável. Dada a natureza da atividade projeto, extremamente volátil e carregada de incertezas. O responsável pelo projeto deve procurar identificar o vetor prioritário lançando mão de sequências de perguntas nas quais sejam postas hipóteses de situações limites entre pares de vetores para que possa, gradativamente, identificar as prioridades. Por exemplo, se numa situação limite, para que o escopo seja completado for necessária uma extensão do prazo, e isto for aceitável, é um indício de que escopo tem prioridade sobre prazo. Copyright Compass International Knowledge Center 11

12 Os requisitos, portanto, não são simplesmente passados pelo demandante ao gerente do projeto. É necessária uma construção conjunta, na qual o gerente do projeto fará sugestões, alertará acerca de impossibilidades técnicas, mostrará conseqüências de opções escolhidas pelo demandante, etc. A descrição deste modelo de relacionamento fica melhor representada pela expressão inglesa: COMAKERSHIP (Processo de relacionamento de parceria para elaboração conjunta). Deste relacionamento desdobra-se, também, a equação da qualidade do serviço. Na qual a qualidade percebida está diretamente relacionada à qualidade esperada pelo cliente e a qualidade daquilo que é entregue, ou seja, ofertado. A qualidade esperada reflete a expectativa do cliente que é formada por diversos fatores relacionados ao perfil racional e emocional do cliente. Dependem do background cultural e educacional do cliente, das suas experiências anteriores com projetos, e com projetos de mesma natureza, do ambiente sob o qual ele está vivendo no momento do relacionamento com o projeto, enfim de uma série de fatores que compõem um quadro de expectativa sob a qual o executor do projeto, o gestor do projeto, não tem domínio. Tem, apenas, influência desde o momento em que começa o relacionamento pessoal para a condução do projeto. Esta equação confirma o caráter subjetivo que permeia toda relação de consumo, seja de um produto, seja de prestação de um serviço, no caso, da realização de um projeto. Não há como extrair totalmente este ingrediente subjetivo. Portanto, mesmo que utilizemos métodos para traduzir requerimentos e desejos e expectativas em fatos e dados sempre haverá uma parcela considerável de subjetividade. A interdependência entre as variáveis significa que quando há a alteração dimensional de uma delas implica na modificação de pelo menos mais uma delas. E, uma vez definidas as dimensões adequadas de escopo, tempo e custo do projeto, a qualidade do projeto será a medida de cumprimento destas dimensões dentro dos limites de tolerância dos demandantes do projeto.

13 Quando um projeto tem sucesso? A avaliação do sucesso de um projeto deve ser vista por duas perspectivas bem distintas: do processo do projeto e do produto do projeto. Perspectivas de sucesso de um projeto Na perspectiva do processo de projeto são observados os aspectos de eficiência do processo. Ou seja, se os requisitos de conformidade do processo do projeto foram atendidos. Esta dimensão está ligada à organização executora do projeto. As perdas de eventuais e desvios nos planos de projeto afetarão diretamente o desempenho operacional da organização executora. Já na perspectiva do produto do projeto são observados os aspectos da eficácia. Isto é, se o resultado do projeto foi entregue dentro dos requisitos de conformidade do cliente. A avaliação é feita pelo cliente do projeto na sua perspectiva. Portanto, um projeto pode ser eficiente e não ser eficaz e vice-versa. Eficácia sem eficiência, ou seja, sucesso apenas para o cliente e processo de projeto com níveis de desvio elevados, estará gerando, em médio ou longo prazo, desequilíbrio de consumo de recursos da organização executora do projeto. Eficiência sem eficácia resultará em insatisfação do cliente, porque o produto do projeto não atenderá seus requisitos. Projeto planejado e gerenciado x projeto tocado Ao receber o encargo de realizar um empreendimento, o impulso natural de todos nós, seres humanos, é começar a executar as atividades que nos parecem necessárias, imediatamente. Vencer este impulso e seguir um processo estruturado ou metodológico de concepção e elaboração de um plano para só então executá-lo requer um comportamento programado para tal. A transformação de um mero tocador de projetos para um verdadeiro gerente de projetos profissional tem como premissa básica esse perfil de trabalho. Na execução Copyright Compass International Knowledge Center 13

14 sem planejamento a probabilidade de re-trabalho e desperdício de recursos é maior gerando, em geral, a extensão do tempo e o estouro dos custos. A presunção de profissionais de gerenciamento de projetos, que adotam boas práticas, é de que o tempo dedicado ao planejamento seja inversamente proporcional ao acréscimo de tempo de execução por excesso de retrabalho, ociosidade, etc. Projeto planejado e gerenciado X Projeto tocado O Gerente do Projeto Em primeiro lugar, vale ressaltar que gerente do projeto, aqui, não é o nome de um título formal de cargo administrativo. É a designação do responsável pelo gerenciamento do projeto. Responsável pelo seu sucesso ou fracasso, mesmo quando lhe forem impostas condições absolutamente desfavoráveis. Hoje, há profissionais cujo cargo é Gerente de Projetos. Significa que este profissional tem como missão institucional gerenciar projetos. É comum, porém, que profissionais que ocupam os mais diversos cargos sejam designados, em determinado momento de suas vidas profissionais, como responsáveis por um projeto. Neste momento o profissional passa a ser o gerente deste projeto. São atribuições comuns ao gerente do projeto: Entrega do produto do projeto Formação e construção da equipe do projeto Elaboração dos planos do projeto Direção da execução do projeto Monitoramento e controle do projeto Medição da performance do projeto Relacionamento com os stakeholders do projeto Determinação de ações corretivas e preventivas Gerenciamento do escopo, tempo, custos, qualidade, recursos humanos, riscos, comunicações e aquisições do projeto Promoção e manutenção da integração e coesão dos componentes do projeto Copyright Compass International Knowledge Center 14

15 O Gerente do Projeto deve ter autoridade suficiente para realizar suas atribuições. Esta autoridade, no âmbito do projeto, é concedida pelo patrocinador do projeto. Sem autoridade suficiente o Gerente do Projeto terá dificuldades em incorporar os recursos necessários ao cumprimento dos objetivos do projeto. Perfil e competências do Gerente do Projeto Historicamente o Gerente do Projeto vem sendo escolhido para a função de gerenciar o projeto por suas competências tecnológicas da área de conhecimento no qual o projeto será conduzido. Nos projetos de engenharia, o gerente do projeto é escolhido naturalmente por ser engenheiro, nos de tecnologia da informação, por ser analista de sistemas, e assim por diante. Pressionado pela exigência por resultados, vem ocorrendo uma modificação nestes requisitos. Pode-se considerar que até da metade dos anos 80, exigia-se do gerente do projeto em torno de 20% de competências comportamentais, ou gerenciais, e 80% de competências técnicas ou tecnológicas especialistas. Hoje, a relação considera apropriada para um melhor desempenho das funções de gerenciamento de projetos gira em torno de 20% de competências técnicas e tecnológicas e 80% de competências comportamentais. Esse processo de mudança resulta, também, da constatação de que os fatores que contribuem mais significativamente para os fracassos dos projetos são de ordem gerencial e não técnica. Processos de Gerenciamento de Projetos Como processo é um conjunto de atividades inter-relacionadas capazes de gerar resultados, o gerenciamento de projetos pode ser estruturado em processos específicos. Na verdade, os efetivos ganhos de eficiência na realização de projetos ocorrem quando projetos são gerenciados seguindo processos. O PMI, no Guia PMBOK, define cinco grupos de processos: Iniciação Planejamento Execução Monitoramento e Controle Encerramento Cada grupo de processos contém um conjunto de processos capazes de gerar os resultados esperados do projeto. O Guia PMBOK relaciona os processos utilizados por profissionais e organizações no mundo inteiro para gerenciar seus projetos. Estes processos por terem demonstrado sua efetividade são considerados BOAS PRÁTICAS. Cada organização, porém, deverá identificar dentre os processos, ou boas práticas, disponíveis, quais serão adequados aos seus projetos especificamente. Copyright Compass International Knowledge Center 15

16 Grupos de Processos de Gerenciamento de Projetos - Fonte: Guia PMBOK, 2008 Os grupos de processos não são fases do projeto. Processos são genéricos, ou seja, aplicam-se a todo e qualquer projeto e repetem-se ao longo do ciclo de vida do projeto. Por exemplo, o processo de iniciação ocorre quando o projeto é autorizado e quando cada fase do projeto tem sua autorização de início. O processo de planejamento é o pensar no que será feito em cada fase. Seu principal objetivo é elaborar o plano de gerenciamento do projeto. Em cada fase do projeto, este plano deve ser consultado e executado no processo de execução. Os processos de encerramento ocorrerão toda vez que uma parte do projeto for concluída, ou seja, realizada uma entrega. O processo de monitoramento e controle ocorre desde que as primeiras ações do projeto são realizadas até o seu término. Os grupos de processos de gerenciamento do projeto apresentam interações entre si ao longo do ciclo de vida do projeto. Ciclo de Vida e Processos de Gerenciamento de Projetos Esquematicamente, podemos identificar momentos do projeto nos quais os processos ocorrem com mais intensidade, ou têm entregas marcantes. Por exemplo: o processo de iniciação, quando ocorre no início do projeto, gera o documento de abertura do projeto (Project Charter, ou Termo de Abertura), o processo de planejamento ocorre mais intensamente quando está se preparando o Plano de gerenciamento do projeto, ou Plano de Gerenciamento do Projeto que será a base de referência (baseline) para o processo de execução das atividades do projeto. O ciclo de vida de cada projeto é identificado de acordo com suas fases específicas, ou seja, um projeto de construção de uma casa terá fases próprias de projetos de construção de casas, e seu ciclo de vida será descrito tipicamente pelas fases: fundações, estrutura, alvenaria, instalações, telhado, acabamento e limpeza. Já um projeto de desenvolvimento de um sistema de tecnologia da informação poderá ter seu ciclo de vida típico como: levantamento de requisitos, análise, programação, instalação e homologação. Copyright Compass International Knowledge Center 16

17 Os processos de gerenciamento têm como finalidade gerenciar (planejando, monitorando e controlando) como serão realizadas as atividades necessárias à concretização do produto do projeto. Em cada fase específica do projeto, poderão ser rodados os processos de gerenciamento. Esta distinção é útil para uma melhor definição da natureza do trabalho que efetivamente estará sendo realizado a cada momento, se de gerenciamento ou de elaboração do produto do projeto. Desenvolvimento do Projeto O modelo a seguir representa o desenvolvimento de um projeto desde a identificação da necessidade de realização do projeto, a partir de um problema ou do aproveitamento de uma oportunidade. As setas descrevem as interações entre os processos e a lógica de elaboração progressiva com o carregamento de dados e informações nos componentes do plano que será executado, monitorado, controlado e encerrado. Copyright Compass International Knowledge Center 17

18 Copyright Compass International Knowledge Center 18

19 Copyright Compass International Knowledge Center 19

20 Áreas de Conhecimento Integração Escopo Tempo Custos Qualidade Recursos Humanos Comunicações Riscos Aquisições Grupos de Processos de Gerenciamento de Projetos (Guia PMBOK, 2008) Iniciação Planejamento Execução Monitoramento e Controle Encerramento Desenvolver o Desenvolver o Orientar e Monitorar e Encerrar o Termo de Plano de Gerenciar a Controlar o Projeto ou Fase Abertura do Gerenciamento Execução do Trabalho do Projeto do Projeto Projeto Projeto Controle Integrado de Mudanças Identificar as Partes Interessadas Coletar Requisitos Definir o Escopo Criar EAP Definir as Atividades Seqüenciar as Atividades Estimar os Recursos Estimar a Duração das Atividades Desenvolver o Cronograma Estimar os Custos Definir o Orçamento Planejar a Qualidade Desenvolver o Plano de Recursos Humanos Planejar as Comunicações Planejar o Gerenciamento dos Riscos Identificar os Riscos Realizar a Análise Qualitativa dos Riscos Realizar a Análise Quantitativa dos Riscos Planejar Respostas aos Riscos Planejar as Aquisições Realizar a Garantia da Qualidade Mobilizar a Equipe do Projeto Desenvolver a Equipe do Projeto Gerenciar a Equipe do Projeto Distribuir as Informações Gerenciar as Expectativas das Partes Interessadas Conduzir as Aquisições Verificar o Escopo Controlar o Escopo Controlar o Cronograma Controlar os Custos Realizar o Controle da Qualidade Reportar o Desempenho Monitorar e Controlar os Riscos Administrar as Aquisições Encerrar as Aquisições Copyright Compass International Knowledge Center 20

21 Processos de Iniciação Uma vez tomada a decisão de realizar o projeto, é necessário constituí-lo formalmente. Segundo o Guia PMBOK, o grupo de processo iniciação é o processo que define e autoriza o projeto ou uma fase projeto. O grupo de processo de iniciação do projeto é composto por dois processos: desenvolver o termo de abertura do projeto e identificar stakeholders. DESENVOLVER O TERMO DE ABERTURA DO PROJETO O Termo de Abertura do Projeto (project charter), tem como missão principal autorizar formalmente a realização do projeto. Define os principais elementos do projeto suficientes para indicar os objetivos, o porquê da realização do projeto (justificativas), a contextualização do projeto na organização, enfim o que é o projeto. Para cumprir sua missão essencial, um Termo de Abertura pode conter apenas informações essenciais, tais como um nome para o projeto e uma breve descrição. Este seria um extremo de um Termo de Abertura de um projeto com o mínimo de informações disponíveis no momento de sua constituição formal (autorização por quem de direito). No outro extremo poderíamos ter um Termo de Abertura com o máximo de informações capazes de descrever elementos integrantes do projeto que auxiliarão o entendimento do que representa o projeto. Um Termo de Abertura com muitas informações permitirá que, durante seu processo de autorização (aprovação) este conjunto de informações sejam validadas pelo patrocinador (sponsor - principal signatário da autorização) e pelo cliente do projeto. Aquele que dará o aceite formal no produto (resultado) do projeto. Nome ou Título do Projeto Longe de ser uma mera formalidade, a denominação do projeto é um elemento de comunicação que pode cumprir um papel importante na divulgação do projeto para a organização executora e para stakeholders. Pode ser composto apenas com uma forma resumida de descrever o resultado principal do projeto, como: Desenvolvimento e Instalação de Sistema de Gestão Integrada ou utilizar um slogan que sirva de instrumento de marketing para o projeto. Associados ao nome podem ser desenvolvidos identidade visual, logomarcas e outros elementos de comunicação para o projeto. Copyright Compass International Knowledge Center 21

22 Cliente do Projeto Indivíduo que dá o aceite formal no resultado (produto) do projeto. Pode não ser, e em geral não é, o usuário final do produto. Também não é, necessariamente, quem paga pelo projeto. O foco da identificação deste importante stakeholder é o de garantir que o projeto não fique impedido de ser encerrado por indefinição de quem tenha autoridade e competência formal para dar o de acordo formal na principal entrega do projeto. A boa prática recomenda que se busque identificar o indivíduo ao invés da designação de um setor, ou diretoria, ou até mesmo uma empresa, para evitar que caso haja uma mudança na estrutura de pessoal, isso gere impasses na entrega do produto do projeto e impeça o encerramento formal do projeto. Gerente do Projeto O Termo de Abertura deve designar e atribuir autoridade formal ao responsável pela realização do projeto. Na prática, o próprio gerente do projeto, já indicado conduz o desenvolvimento do documento a partir de informações fornecidas pelos principais stakeholders do projeto. Patrocinador (Sponsor) O termo patrocinador dá a conotação de que este stakeholder seja apenas quem provê recursos financeiros e libera recursos para o projeto, mas ele tem um papel muito mais abrangente. Dá suporte e cobertura política ao projeto, tem o poder de decisão quanto às prioridades do projeto e é o principal agente autorizador de mudanças no projeto. Pode exercer, ao mesmo tempo, o papel de cliente. Um patrocinador forte (com poder na organização) e atuante pode ser decisivo ao sucesso do projeto. Descrição do Projeto Apresentação sumária do projeto. Deve ser sucinta para permitir uma visão geral do que é o projeto. Se forem necessárias mais informações a recomendação é que sejam postas em anexos a fim de que não torne o documento extenso. De modo geral, informações em projetos devem ser postas de forma a serem entendidas o mais rápido possível. Justificativa do Projeto (Problema/Oportunidade) Um projeto consome recursos, a cada dia, mais escassos, portanto o porquê de sua realização deve ficar bem claro no documento que registra sua constituição. Um projeto cuja justificativa é forte tende a ter mais apoio da organização executora e consequentemente menos dificuldade em obter os recursos necessários à sua execução. Se a organização executora utiliza um processo de seleção e priorização de projetos para tomar a decisão de executar ou não projetos, a princípio, as razões que justificam o empreendimento já devem ter sido apresentadas. Mas a justificativa para a realização do projeto vai além da decisão de executá-lo. Serve como fator de motivação para a equipe do projeto, como argumento em Copyright Compass International Knowledge Center 22

23 negociações com stakheolders e para o patrocinador defendê-lo política e financeiramente. Uma boa justificativa para um projeto deve estar relacionada aos benefícios que ele trará para a organização que podem ser tangíveis ou intangíveis, em forma de solução de um problema ou do aproveitamento de uma oportunidade. Justificativas baseadas na solução de problemas tendem a ser mais facilmente aceitas do que aquelas que propõem o aproveitamento de oportunidades porque, em geral, o problema já existe e já está causando efeitos reais, enquanto que a oportunidade, por natureza, é potencial, carrega mais risco. Neste campo a recomendação, também é de objetividade e síntese. Se forem necessários dados adicionais ou mais detalhados devem vir em anexos ao Termo de Abertura. Produto do Projeto O resultado principal que será gerado pelo projeto deve ficar bem claro a fim de evitar expectativas além da capacidade de realização do projeto. O produto do projeto é a principal entrega produzida pelo projeto. Pode ser um objeto, por exemplo, um projeto de construção de uma residência. A residência pronta para morar seria o produto do projeto. Um serviço, que seria entregue por um projeto de consultoria. O produto gerado pelo projeto estaria materializado no relatório com as recomendações da consultoria. O produto de um projeto pode ser um estado modificado, que seria obtido pela execução de um projeto de modificação de um layout de um ambiente de trabalho. Deve ser quantificável. O produto do projeto deve ser identificado e tangibilizado de tal forma que, ao final, permita a verificação de que de fato foi entregue e a avaliação da adequação ao que foi proposto em seu início. A indefinição do produto do projeto pode levar às partes interessadas no projeto criarem expectativas diferentes em relação àquilo que o projeto efetivamente estaria configurado para entregar e causar conflitos, frustrações e prejuízos. Objetivos e Metas do Projeto O objetivo mais amplo do projeto, a intenção do projeto, seu requisito maior, suas prioridades, devem ser expressas em objetivos quantificáveis que permitam sua verificação e avaliação do seu desempenho e seus resultados. Devem ser expressos no tempo verbal infinitivo: realizar, entregar, desenvolver. Se o objetivo de desempenho do projeto descreve o quê o projeto fará, a meta descreve o quanto. Ou seja, a meta é a quantificação de um objetivo. A medida do desempenho do projeto. Pode haver mais de uma meta para um mesmo objetivo, mas não deve haver objetivo que não comporte a atribuição de pelo menos uma meta. Para o objetivo principal do projeto, relacionado à principal entrega, é recomendável que se estabeleçam metas nas três principais dimensões do projeto: escopo, tempo Copyright Compass International Knowledge Center 23

24 e custo. A determinação de objetivos e metas pode seguir a hierarquia das fases e entregas do projeto. No Termo de Abertura, porém, dado que o projeto está no processo de iniciação, os objetivos tendem a ficar em âmbito mais geral, sendo, posteriormente, detalhados. Metas devem refletir os compromissos assumidos pelo projeto, portanto, podem ser referenciados a elementos ainda não definidos no momento da redação do Termo de Abertura, mas que serão elaborados no planejamento do projeto. Por exemplo: meta de não ultrapassar o orçamento do projeto. Meta de não ultrapassar o cronograma aprovado. Metas relacionadas ao escopo podem vincular necessidades postas na Declaração do Trabalho (Statement Of Work SOW - documento que formula as necessidades postas ao projeto emitido pelos demandantes do projeto), que se tornarão especificações de escopo. Por exemplo, no projeto de uma escola: número de salas de aula, número de laboratórios, etc. As metas serão o referencial de comparação para a avaliação do projeto ao seu término. Medirão, portanto, seu desempenho e seu sucesso. Estimativa de Custos A finalidade de elaborar uma estimativa de custos ainda no processo de iniciação é tentar dimensionar em ordem de grandeza os custos gerais do projeto. Pode ser uma forma de confirmar uma faixa de valor que tenha sido enunciada em um estudo de viabilidade financeira, quando da decisão de realizar ou não o projeto, ou de dar a primeira idéia do quanto o projeto poderá custar. Neste caso, poderá resultar na decisão de não continuar com a realização do projeto. É sempre importante lembrar que, seguindo um princípio geral da administração, quanto mais cedo, mais próximo da origem, tomar-se a decisão de interromper um processo que não esteja conforme, mais econômica será esta decisão para a organização. A idéia de validação da viabilidade é um pressuposto que permeia todo o processo de iniciação do projeto. Durante o processo de iniciação do projeto deve-se procurar confirmar ou não a decisão de realização do projeto. Por convenção, que pode variar de acordo com cada organização, a expectativa de precisão desta estimativa é de -50% a +100% do orçamento final que será apurado no processo de planejamento do projeto. A consulta a dados históricos de projetos anteriores semelhantes é um recurso de apoio no processo de estimativa de custos do projeto. Porém, se a base histórica não possuir referências semelhantes, pode-se solicitar apoio a um fornecedor que as tenha ou que possa elaborar uma estimativa. Além do apoio neste momento, este fornecedor figurará como potencial executor de partes do projeto, no caso de dificuldades da organização executora. Funciona, portanto como mitigador de riscos. Copyright Compass International Knowledge Center 24

25 Estimativa de Prazo Infelizmente, a maioria dos projetos conduzidos hoje em dia, não são iniciados a partir de um planejamento, mas de uma reação a uma necessidade, portanto os prazos dos projeto são estabelecidos, e não estimados. O deadline, ou prazo de término do projeto já faz parte da demanda. Dessa forma, pode ser classificado como uma restrição imposta. Esta imposição influenciará o modelo de programação do cronograma do projeto no processo de planejamento que terá que ser feito para trás. Ou seja, a partir da data final estabelecida, programar as etapas do projeto. No caso de não haver esta imposição, o prazo pode ser estimado considerando-se referências históricas de projetos semelhantes, como recomendado para custos. Autorização Salvo regimentos organizacionais específicos, o principal stakeholder autorizador do projeto é o patrocinador (sponsor). No caso de outros membros da organização executora participarem da autorização, suas assinaturas serão necessárias à aprovação do Termo de Abertura do Projeto. O processo de aprovação do Termo de Abertura pode consumir um tempo considerável em idas e vindas para análises e avaliações, porém é importante ressaltar que um projeto não deve ser autorizado com dúvidas quanto às suas finalidades. Por outro lado, é altamente recomendável que não se comece a realizar, ou seja, tomar decisões ou consumir recursos por conta do projeto, sem que o processo de autorização formal esteja concluído. STAKEHOLDERS (Partes Interessadas) DO PROJETO Segundo o dicionário Random House: detentores (holders) da aposta (stake). Partes interessadas é a tradução mais encontrada para essa palavra no contexto de gerenciamento de projetos. Significa: todo indivíduo, entidade, enfim qualquer pessoa física ou jurídica que de alguma forma tenha relacionamento, seja atingida ou impactada pelo projeto. Pode influenciar ou ser influenciada pelo projeto. No decorrer do projeto ou mesmo após seu encerramento. A equipe de gerenciamento do projeto tem que identificar os stakeholders, partes interessadas tanto internas quanto externas à organização executora de maneira a determinar os requisitos e expectativas dessas partes. Uma vez identificadas, uma análise deve ser feita para se determinar estratégias de gerenciamento dessas partes interessadas. As etapas envolvidas em uma análise de partes interessadas são: Identificação de partes interessadas: desenvolver uma lista com nomes dos interessados chaves do projeto, sua função, órgão ou empresa. Em alguns casos, podem ser identificados e listados grupos de interessados que tenham um mesmo perfil ou participação no projeto. Copyright Compass International Knowledge Center 25

26 Classificação de partes interessadas: cada interessado da lista é identificado por um código (por exemplo, por letras maiúsculas) e é feita uma avaliação em relação a seu poder de influenciar o projeto e seu interesse. Além disso, avalia-se se o interesse é positivo ou negativo. Elaboração de estratégia: para cada interessado ou grupo de interessados são desenvolvidas estratégias de relacionamento e comunicação. O gráfico abaixo apresenta um exemplo de classificação de partes interessadas que leva em conta o poder e o interesse de cada interessado ou grupo de interessados. Análise dos Stakeholders (Partes Interessadas do Projeto) A informação resultante da análise pode ser consolidada em um registro de partes interessadas (quadro na próxima página). Esse registro é primeiramente elaborado no início do projeto e deve ser mantido atualizado durante todo o ciclo de vida do projeto. Certas informações relacionadas a uma ou mais das partes interessadas podem ser muito sensíveis para serem incluídas no registro de partes de interessadas que será tornado público como um documento do projeto. A equipe de gerenciamento de projeto deve avaliar cada caso e decidir que nível de detalhe será incluído no registro e que informação merece divulgação restrita. Em razão dos stakeholders influenciarem positiva ou negativamente o projeto e, consequentemente, seus objetivos, eles são uma fonte primária de riscos ao projeto. Copyright Compass International Knowledge Center 26

27 Figura 1 - Registro de Partes Interessadas Registro dos Stakeholders (Partes Interessadas do Projeto) Conclusão do processo de iniciação do projeto Como foi visto, no processo de iniciação são coletadas informações preliminares e levantadas questões gerais relacionadas à capacidade de realização do projeto. Considera-se que na iniciação faz-se um planejamento de alto nível, um planejamento macro, que define as linhas gerais do projeto capazes de fornecer o máximo de subsídios para o patrocinador (sponsor) do projeto tomar a decisão de autorizar a continuidade do trabalho em um planejamento em baixo nível que produzirá um plano de gerenciamento do projeto detalhado. Dessa forma, elementos chave, tais como premissas e restrições, deverão ser revisados, refinados, detalhados e registrados na declaração do escopo do projeto. Copyright Compass International Knowledge Center 27

28 Processo de Planejamento A conclusão do processo de iniciação indica que o projeto pode seguir em frente e pode-se, então, investir tempo e recursos na elaboração do Plano de Gerenciamento do Projeto que é a principal missão e resultado do processo de planejamento do projeto. Antes de tratarmos do trabalho que compõe o processo de planejamento, é importante refletirmos sobre algumas questões de ordem prática que estão longe de serem triviais: por que planejar? Por que dedicar esforço e tempo planejando se já poderíamos ir direto à execução do projeto? Qual o benefício de planejar se as coisas não saem exatamente como planejado? Por que elaborar um plano se a probabilidade de haver mudanças é muito alta? Isto não é perda de tempo? Não há uma resposta única, mas um posicionamento. É preciso considerar que o trabalho, esforço ou recursos, inclusive de tempo, serão menores do que os gastos com as conseqüências de uma execução sem planejamento. O posicionamento a favor do planejamento vem da presunção de que o retrabalho será menor se houver planejamento. Por re-trabalho entenda-se todo o trabalho que não poderá ser aproveitado para o resultado do projeto. Sabemos que mesmo com o planejamento existe re-trabalho em projetos, dado que é uma atividade probabilística e carregada de incerteza. Porém, a dose de planejamento não pode ser prescrita de forma genérica, mas de acordo com cada caso específico. Excesso de tempo e esforço dedicados ao planejamento pode representar mais perdas do que ganhos. O desafio, portanto, é encontrar o ponto de equilíbrio. O processo de planejamento do projeto segue uma sequência lógica necessária à elaboração do plano de gerenciamento do projeto.

29 Em primeiro lugar, define-se o escopo, que representa aquilo que será feito pelo projeto, para em seguida dimensionar-se o tempo necessário para esta realização, que por sua vez, permitirá a quantificação dos custos. Depois, virão as definições da qualidade, dos recursos humanos, da comunicação, dos riscos, enfim, dos demais parâmetros do projeto. Apesar de seguir uma lógica de elaboração progressiva, o processo de planejamento é interativo, pois seus parâmetros são correlacionados, e ao mesmo tempo, é iterativo, isto é, a definição de um elemento pode implicar na necessidade de ajuste em outro anteriormente definido. Por exemplo: durante a definição dos parâmetros da qualidade do projeto pode-se verificar que um item de escopo precisa ser modificado, gerando, assim a necessidade de redefinição do tempo e dos custos. Assim sendo, uma vez identificada a intenção de realizar o projeto, é necessário constituí-lo formalmente e definir seus principais parâmetros para uma tomada de decisão quanto à sua execução. Estes parâmetros devem ser documentados de tal forma que permitam uma avaliação quanto à capacidade do projeto em alcançar seus objetivos e gerar os benefícios para a organização executora. Uma boa documentação de um projeto é fator decisivo para seu bom gerenciamento e para ganhos de produtividade em projetos futuros desenvolvidos pela organização. É muito comum a documentação de projetos ser vista como burocracia no sentido pejorativo do termo, porém, se lembrarmos que projetos são empreendimentos que geram produtos únicos, é possível perceber a utilidade de se ter referências que diminuam o grau de ineditismo. Metodologia de Gerenciamento de Projetos A sistematização da documentação de projetos geralmente está associada ao que se denomina metodologia de gerenciamento de projetos. Que nada mais é do que a determinação de processos estruturados e conjunto de documentos recomendados para o gerenciamento de projetos com a finalidade de diminuir o grau de improviso das ações de projeto e permitir o alcance de melhores resultados à custa de menos esforço. Evidentemente durante o processo de incorporação da técnica há um esforço que pode, a princípio, ser considerado desproporcional, ou seja, estaria exigindo mais esforço para documentar do que para fazer. Isto de fato é um risco que deve ser considerado, pois os limites do que pode ser instrumento gerencial e burocracia excessiva é tênue. Há um princípio da administração, enunciado por Henry Fayol (1910), preconizando que: o controle não deve exceder o objeto controlado, isto é, não devemos gastar mais energia para gerenciar do que para fazer. Para entendermos a aplicação prática de uma metodologia de gerenciamento de projetos e a documentação associada, podemos fazer uma analogia com a natação. Um indivíduo que incorporou uma técnica de nado, depois de orientado por um treinador, passa a despender menos esforço e a obter melhores resultados em relação a quem nada por instinto, sem técnica específica. No caso da natação, quem domina a técnica chega mais rápido à outra margem com menos esforço. Copyright Compass International Knowledge Center 29

30 A idéia é de que o método de trabalho em projetos, metodologia de gerenciamento de projetos, permita o alcance de resultados efetivos com menos esforço. Pode parecer que nos primeiros projetos documentados e gerenciados segundo uma metodologia adotada, o esforço seja desproporcional, mas a tendência é de que os projetos subsequentes exijam menos esforço e gerem melhores resultados, representando o efetivo ganho de produtividade. Plano de Gerenciamento do Projeto O plano que será a base de referência para a execução do projeto deverá conter todas as orientações necessárias para completar a entregas do projeto. É composto de um conjunto de documentos dedicados ao gerenciamento do projeto. ESCOPO Declaração do ESCOPO WBS EAP Estrutura Analítica do Projeto Gráfico de Gantt TEMPO (Cronograma) Diagrama de REDE CUSTO Orçamento do projeto Sistema da Qualidade (Parâmetros e Procedimentos) Organograma do Projeto e Matriz de Responsabilidades Matriz de Comunicações Registro de Riscos (Resposta aos Riscos) Sistema de Gerenciamento de Configurações Controle Integrado de Mudanças Sistema de Documentação Sistema de Gerenciamento de Configurações É necessário definir como será realizada a identificação e documentação das características funcionais e físicas do produto e subprodutos do projeto, controle das mudanças feitas nessas características, registro e relato de cada mudança e o andamento da sua implantação, suporte à auditoria dos produtos para verificar conformidade com os requisitos. Pode definir, também, como será feita o controle de versões dos documentos do projeto. Controle Integrado de Mudanças Define os procedimentos para efetuar mudanças nas baselines do projeto ou no escopo do produto do projeto. Determina a documentação necessária, os sistemas de acompanhamento e os níveis de aprovação necessários para autorizar mudanças. Copyright Compass International Knowledge Center 30

31 Planos Subsidiários O gerenciamento do projeto e a manutenção dos elementos do projeto coesos entre si compõem a área de conhecimento integração. A boa prática recomenda que seja elaborado um plano determinando a melhor estratégia a ser adotada para gerenciar cada uma das demais áreas de conhecimento necessárias ao gerenciamento do projeto. Plano de Gerenciamento do Escopo Plano de Gerenciamento do Tempo Plano de Gerenciamento dos Custos Plano de Gerenciamento da Qualidade Plano de Gerenciamento dos Recursos Humanos Plano de Gerenciamento das Comunicações Plano de Gerenciamento dos Riscos Plano de Gerenciamento das Aquisições Além dos planos de gerenciamento das áreas de conhecimento o plano do gerenciamento do projeto deve conter alguns documentos como: contrato (quando for o caso; a definição dos objetivos e metas (se houver mudança em relação ao Termo de Abertura). É necessário, também, tratar de aspectos da organização e da forma como será conduzido o trabalho do gerenciamento do projeto. Quais processos serão utilizados no gerenciamento. Que artefatos (documentos, gráficos, tabelas, etc.) serão elaborados e como será o processo de elaboração. Como serão realizados os processos de monitoramento e controle do projeto. Outra definição importante quanto ao processo de planejamento, diz respeito às ferramentas e técnicas que serão utilizadas nos processos. Por exemplo, determinar que o processo de definição do escopo do projeto utilizará reuniões de brainstorming e entrevistas com os principais stakeholders do projeto. Linhas de Base (Baselines) de performance do projeto O plano de gerenciamento do projeto definido e aprovado será a Linha de Base de referência (baseline) a partir da qual o progresso do projeto será avaliado. Sendo assim, as variáveis definidas de escopo, tempo, custo, qualidade, recursos humanos (equipe do projeto), comunicações, riscos e aquisições serão as bases de referência do projeto como um todo. Significa que quaisquer mudanças nestas referências deverão ser tratadas como mudanças, pois gerarão impactos no projeto. Copyright Compass International Knowledge Center 31

32 COLETA DE REQUISITOS O sucesso do projeto é diretamente influenciado pela atenção na captura e gerenciamento dos requisitos do projeto e do produto. Estes requisitos precisam ser obtidos, analisados e registrados com detalhe suficientes para sem medidos uma vez que a execução do projeto se inicie. Coletar requisitos envolve definir e gerenciar as expectativas do cliente. Os requisitos serão o fundamento para o planejamento do escopo do projeto. Os requisitos podem ser categorizados em requisitos do projeto e requisitos do produto. Os requisitos do projeto podem, por sua vez, se encontrar dentro de uma das seguintes subcategorias: Requisitos relacionados com as necessidades de negócio identificadas no Termo de Abertura do Projeto (requisitos de negócio). Requisitos relacionados ao gerenciamento do projeto (requisitos de prazo, de custo e requisitos gerais de gerenciamento de projeto). Requisitos relacionados com a forma pela qual o projeto deve ser realizado, isto é, relacionados ao processo do projeto. Os requisitos do produto são aqueles que o produto do projeto precisa atender desde sua entrega ao cliente, ao final do projeto, até o fim do ciclo de vida do produto. Os requisitos coletados são então documentados em um Documento de Requisitos, e usados como referência para o planejamento e a execução do projeto. DEFINIÇÃO DO ESCOPO DO PROJETO Apesar de haver uma pretensão já posta pelos demandantes do projeto, a forma do resultado final, assim como os passos intermediários e o seu processo de elaboração, podem diferir, substancialmente. Como vimos, projetos não são atividades determinísticas, ou seja, não têm seu resultado garantido, pois são atividades que sempre carregarão uma parcela de risco, ou incerteza, são, portanto, atividades probabilísticas. Assim sendo, as escolhas possíveis acerca do projeto precisam ser feitas. Este processo faz parte da definição do escopo, tanto de produto quanto de projeto. O desafio é conseguir antever as conseqüências de cada escolha e identificar os melhores relações de custo e benefício. O escopo do projeto é o ponto de partida de todas as outras variáveis do projeto. O tempo, os custos, a qualidade, os recursos humanos necessários, etc., só poderão ser dimensionados se o escopo estiver definido. Ou seja, aquilo que é para ser feito. Copyright Compass International Knowledge Center 32

33 Todo o esforço dedicado à uma boa definição de escopo será bem empregado, pois os demais parâmetros do projeto dependem diretamente deste. Elementos necessários para definição do escopo (input) Para melhor realizar o processo de definição do escopo é recomendável que se utilize as informações que estiverem disponíveis até o momento: Histórico de projetos anteriores Declaração do trabalho Project Charter Declaração Preliminar do Escopo Ferramentas e Técnicas utilizadas no processo de definição do escopo A natureza do produto do projeto irá determinar o conjunto de ferramentas e técnicas mais adequado para realizar a definição do escopo. Brainstorming Se o projeto é inédito e requer uma contribuição criativa o brainstorming será uma técnica recomendada, pois consiste numa seção conduzida por um coordenador que estimula os participantes a terem idéias relacionadas ao objeto do projeto sem restrições de pertinência, numa primeira rodada. Ou seja sem censura que reprima a criatividade. Em seguida é feita uma avaliação da pertinência e selecionadas as idéias mais úteis ao projeto. Opinião de especialistas (presencial ou com a Técnica Delphi) É importante, sempre que possível, ouvir a opinião de especialistas sobre o tema do projeto. O método Delphi é uma técnica com algumas semelhaças ao brainstorming, porém com algumas diferenças. Ambas devem ser conduzidas por um coordenador, ou facilitador, porém no Delphi os participantes permanecem anônimos, portanto não devem estar no mesmo ambiente físico. O coordenador do processo coloca a questão a ser opinada, recolhe as contribuições de cada participante, consolida, repassa os pontos de convergência sucessivamente até o grupo chegar ao consenso. Esta técnica tornou-se especialmente útil com a facilidade da comunicação pela internet. Hoje, podemos colher a opinião de um especialista que esteja do outro lado do mundo. Modelos (templates), formulários, normas, checklists Como apoio ao processo de definição do escopo é conveniente lançar mão de quaisquer modelos, formulários ou listas de verificação que possam ajudar a lembrar de elementos a serem incluídas no escopo. Listas de verificação (Checklists) que contenham informações típicas relacionadas ao tipo do projeto funcionam como uma espécie de roteiro e ajudam, não só a não deixar de esquecer de itens importantes, como a ganhar tempo no processo. Por Copyright Compass International Knowledge Center 33

34 exemplo, em um projeto de construção de uma residência os itens: estilo arquitetônico, número de quartos, existência de piscina, etc., são típicos. Análise dos Stakeholders Não apenas os interessados principais no projeto como o cliente e o patrocinador (sponsor) têm requerimentos que devem ser considerados na composição do escopo do projeto, os demais stakeholders, também, podem sofrer impactos, possuem necessidades e expectativas que devem ser consideradas e atendidas, na medida em que não comprometam o cumprimento dos objetivos do projeto. Em um projeto de modificação de layout, um determinado setor da empresa pode ter como requerimento que o trabalho seja interrompido o menor período de tempo possível. Se este requerimento puder ser atendido sem prejudicar a relação de tempo e custo do projeto é recomendável que seja atendido, pois, a princípio, trará economia para a organização. Metodologia de Desenvolvimento de Produtos Todo projeto ao seu término entrega um produto, portanto, as diversas técnicas sistematizadas para o desenvolvimento de produtos são, na realidade, técnicas de definição de escopo. Engenharia Robusta, Engenharia Simultânea, Prototipagem, QFD Quality Funtion Deployment, etc. As principais destas técnicas foram desenvolvidas nos anos 80 e, hoje, já estão maduras em razão da aplicação intensiva com resultados expressivos em diversas áreas da economia, com literatura disponível para estudos mais aprofundados. Escopo do Produto e Escopo do Projeto A boa prática recomenda que para uma melhor organização do trabalho se dividam as informações de escopo em escopo do produto e escopo do projeto. Escopo do Produto Este primeiro escopo trata das especificações do resultado que será gerado pelo projeto na sua conclusão. Descreve como será a principal entrega do projeto. Relaciona características, funções e atributos. Deve traduzir os requerimentos postos ao projeto em especificações para o resultado. Especificar o produto do projeto significa diferenciá-lo dos demais do mesmo gênero, torná-lo, especial em suas particularidades, específico. Em um projeto de uma residência, por exemplo, residência é genérica. A especificação irá definir quantos quartos a residência terá, quantos banheiros, se terá sala de jantar separada da sala de estar, qual serão as cores, etc. Todos os requisitos que tornam a residência que será construída única. Escopo do Projeto Todo o trabalho necessário para gerar o produto do projeto com todas as suas características especificadas no escopo do produto compõem o escopo do projeto. Copyright Compass International Knowledge Center 34

35 Representa todas as entregas intermediárias necessárias para produzir a principal entrega do projeto, para completar o escopo do produto. Para cada especificação de escopo do produto haverá pelo menos uma entrega de escopo de projeto associada. Entregas (Deliverables) e Marcos (Milestones) Além do produto final ou resultado principal do projeto, ao longo do seu ciclo de vida, serão gerados subprodutos ou resultados parciais. Resultados são gerados por processos que seguem o modelo: entrada (input), processo (process) e saída (output), porém no âmbito de projetos é necessário fazer-se uma distinção entre as saídas (outputs) dos processos que não serão avaliadas e validadas por um terceiro daquelas que serão avaliadas pelo próprio executor. As primeiras, ou seja, aquelas que serão avaliadas e validadas por outro que não o próprio executor, são consideradas entregas (deliverables). Os demais resultados serão apenas saídas (outputs). Portanto, pode-se considerar que as entregas serão objeto de um controle externo ao executor. São passíveis de verificação. O próprio termo remete ao movimento de transmissão do executor para o avaliador. Assim sendo, os momentos em que ocorrem entregas do projeto servem como pontos de referência para a avaliação do progresso do próprio projeto. Estes pontos de verificação são denominados de marcos ou milestones. A expressão milestone, literalmente pedra da milha, vem da engenharia romana que usava uma pedra para marcar o percurso da estrada a cada de mil pés de um soldado romano. O conceito de marcar a distância da origem como referência é fundamental para a medição do trabalho realizado no projeto. Se a entrega prevista para ser realizada naquele momento (ponto no tempo marco milestone) tiver sido efetivada, o projeto estará dentro do cronograma. Se não, estará atrasado. Dessa forma, o escopo (o trabalho) do projeto deve ser definido pelas entregas que serão necessárias para que o projeto atenda aos seus requisitos. Copyright Compass International Knowledge Center 35

36 Critérios de aceitação do produto É necessário que as regras do jogo estejam bem claras desde o início do projeto. Estes critérios serão a referência que os demandantes do projeto utilizarão para avaliar se o projeto efetivamente cumpriu aquilo a que se propôs quanto aos seus objetivos e metas. São os limites de tolerância para a aceitação formal das entregas do projeto. Serão utilizados no processo de inspeção realizado pelo cliente, denominado no Guia PMBOK de verificação do escopo do projeto. Compara aquilo que foi estabelecido nos requerimentos com o que de fato é entregue. As metas do projeto são as referências para o estabelecimento dos critérios de aceitação. Uma meta de um projeto de desenvolvimento de um software pode prever que usuários façam acesso simultâneo sem perda de performance, e estabelecer como critério de aceitação, que se até 900 o projeto será aceito. Exclusões Específicas - Itens NÃO incluídos no escopo Procura definir itens que não serão entregues pelo projeto. Este conjunto de informações faz-se necessário porque, por melhor que seja a especificação do escopo do projeto, sempre haverá possibilidade de dúvida quanto a configuração tanto do produto do projeto quanto ao trabalho para realizá-lo. Serve, também, para identificar expectativas dos demandantes quanto a entregas, funcionalidades, atributos ou características que não foram explicitadas na Declaração do Trabalho (Statement of Work). Há projetos que, por sua natureza, podem gerar elementos de especificação considerados óbvios pelo demandante e por isso não são lançados na Declaração do Trabalho. Neste caso esta relação de itens funciona como uma lista de verificação (checklist) daquilo que efetivamente é esperado do projeto. Premissas São fatos assumidos como verdadeiros pelas partes demandantes e os realizadores do projeto. São as regras do jogo. Condições sob as quais o projeto será conduzido e que, se modificadas, influenciam a capacidade do projeto de alcançar seus resultados. Implicam, portanto, na necessidade de revisão dos parâmetros estabelecidos para o projeto. Pode-se elencar como premissas em um projeto de desenvolvimento de um sistema corporativo, por exemplo, que será necessária a autorização de acesso a membros da equipe do projeto aos sistemas da empresa. Premissas são alvos primários de riscos, porque, se atingidas, normalmente, geram alterações na estrutura do projeto e, conseqüentemente, na capacidade de atingir seus objetivos. Restrições São fatores, previamente estabelecidos, que limitam as opções do projeto. Podem ser normas organizacionais que precisam ser seguidas, regimentos, legislações, ou Copyright Compass International Knowledge Center 36

37 quaisquer obrigações relacionadas ao objeto do projeto. O regimento interno de um edifício pode restringir o trabalho que gere ruído durante o período noturno. Definição progressiva do escopo Há projetos cuja dificuldade de definição de escopo é muito grande. Isto ocorre em função do ineditismo do produto do projeto, do ambiente tecnológico ser muito volátil, que é o caso dos projetos de tecnologia da informação, ou mesmo pelas necessidades serem muito difusas em função de interesses diversos. Este grau de incerteza pode ser traduzido em função da distância entre o ponto de partida e o alvo (escopo) a ser atingido. Geometricamente percebe-se que quanto maior for esta distância maior será a possibilidade de desvio do alvo. Ou seja, uma pequena variação no início pode, dada a distância ao alvo, tornar-se grande. Portanto, a recomendação é de que se procure identificar, sempre que possível, pontos de partição do escopo total que possam ser realizados parcialmente. Ou seja, verificar se é possível dividir o projeto em partes e fechar o acordo de definição do escopo da ou das partes que possibilitem a definição de escopo com razoável grau de previsibilidade. O alvo do projeto passa a ser então B1 e não o todo Bt (total). O compromisso do projeto é entregar B1. Reduzindo o potencial de desvio. A entrega B1 será, posteriormente elemento de entrada (input) para o projeto de entrega de B2 e assim sucessivamente até completar a entrega total pretendida (Bt). Copyright Compass International Knowledge Center 37

38 A natureza integrativa do planejamento exige que áreas como escopo, tempo e custo sejam coordenadas cuidadosamente em um processo iterativo. À medida que mais informações ou características do projeto são reunidas e compreendidas, planejamento adicional pode ser necessário. O detalhamento progressivo do plano de gerenciamento do projeto é geralmente chamado de planejamento em ondas sucessivas, indicando que o planejamento e a elaboração da documentação associada são processos contínuos e repetitivos. A definição do escopo, dessa forma, permite que a demanda real do projeto, ou seja, a razão de sua realização, seja elaborada e formulada progressivamente. O processo de Verificação do Escopo Uma vez definido o escopo é necessário determinar como o cliente avaliará a sua efetiva realização. Que procedimentos serão usados para o cliente verificar, constatar se aquilo que foi proposto na declaração do escopo corresponde ao que de fato estará sendo entregue. Será a aplicação de critérios de aceitação de entregas parciais, ou intermediárias, e do produto final, definidos na declaração do escopo. ESTRUTURA ANALÍTICA DO PROJETO (EAP) (Work Breakdown Structure WBS) Os americanos costumam referir-se à EAP (WBS) como the big picture of the project, no sentido de que é uma imagem que permite a visão do todo, do conjunto completo. Possibilita uma visão holística do projeto. Que ao olhar a EAP (WBS) consegue-se enxergar tudo aquilo que o projeto irá realizar. Analisar (Estrutura Analítica) significa decompor em partes menores para melhor compreender o todo e as partes que o compõem. É exatamente essa a missão da EAP que é a principal ferramenta para o gerenciamento do escopo do projeto. A decomposição dá-se de cima para baixo, daí o termo em inglês: breakdown, a partir do projeto, que será o primeiro nível, ou nível zero, como preferem alguns autores. Por ser uma ferramenta de escopo, na EAP não aparecem atividades (ações ou tarefas), são representadas apenas entregas geradas pelo projeto (deliverables). Copyright Compass International Knowledge Center 38

39 Portanto, nela não são representadas relações de dependência temporal de execução. A hierarquia da EAP diz respeito a um todo (no nível acima) que é composto de partes (no nível abaixo). 1º Nível : Nome do Projeto 1. PROJETO 2.1 Fase Fase Fase Entrega 3.2 Entrega 3.3 Entrega 3.4 Entrega 3.5 Entrega 3.6 Entrega 4.1 PT 4.2 PT 4.3 PT 4.4 PT 4.5 PT 4.6 PT 4.7 PT 4.8 PT 4.9 PT 4.10 PT 4.11 PT 4.12 PT O segundo nível da EAP representa o ciclo de vida do projeto, pois determina a primeira partição do projeto, ou seja, suas macro-fases. 2º Nível : Ciclo de Vida do Projeto 1. PROJETO 2.1 Fase Fase Fase Entrega 3.2 Entrega 3.3 Entrega 3.4 Entrega 3.5 Entrega 3.6 Entrega 4.1 PT 4.2 PT 4.3 PT 4.4 PT 4.5 PT 4.6 PT 4.7 PT 4.8 PT 4.9 PT 4.10 PT 4.11 PT 4.12 PT Copyright Compass International Knowledge Center 39

40 3º Nível : Principais entregas do projeto 1. PROJETO 2.1 Fase Fase Fase Entrega 3.2 Entrega 3.3 Entrega 3.4 Entrega 3.5 Entrega 3.6 Entrega 4.1 PT 4.2 PT 4.3 PT 4.4 PT 4.5 PT 4.6 PT 4.7 PT 4.8 PT 4.9 PT 4.10 PT 4.11 PT 4.12 PT 1. PROJETO 2.1 Fase Fase Fase Entrega 3.2 Entrega 3.3 Entrega 3.4 Entrega 3.5 Entrega 3.6 Entrega 4.1 PT 4.2 PT 4.3 PT 4.4 PT 4.5 PT 4.6 PT 4.7 PT 4.8 PT 4.9 PT 4.10 PT 4.11 PT 4.12 PT Último Nível : Pacotes de Trabalho (menor entrega do projeto) O projeto é, então, sucessivamente sendo quebrado (break), em níveis de entregas cada vez menores até o menor nível desejado para detalhamento do escopo do projeto. Este nível é denominado no Guia PMBOK de pacote de trabalho. A decisão de até onde decompor é determinada por alguns fatores relacionados à forma pela qual o projeto será gerenciado. Novamente se apresenta uma situação de trade-off, ou seja, faz-se necessária uma avaliação de custo/benefício entre detalhar (decompor) ou não decompor. A favor da maior decomposição pesa o fato de permitir uma melhor identificação (visualização) das menores partes e com isso aumentar a previsibilidade de projeto. Porém este maior detalhamento implica em maior esforço de planejamento e posterior controle. O último nível de decomposição da EAP, ou detalhamento do projeto está relacionado ao nível de domínio e controle que se deseja exercer sobre os elementos de escopo do projeto, isto é, se for necessário que um elemento de escopo seja realizado exatamente de determinada forma, então será necessário o detalhamento. Por exemplo, em um projeto de um evento, onde a EAP for decomposta até o nível de aquisição das passagens aéreas dos participantes e não for relevante ou determinante que a entrega seja decomposta em: prospecção, seleção e contratação, isto é se os detalhes de como a entrega será realizada não forem importantes e não requererem um controle de execução das partes, não há necessidade de decompor esta entrega. Neste caso a supervisão e o controle irá até o nível de entrega das passagens aéreas. Copyright Compass International Knowledge Center 40

41 O projeto é, então, sucessivamente quebrado (break), em subprodutos cada vez menores até o menor nível desejado para detalhamento do escopo do projeto. Possíveis EAP (Estrutura Analítica do Projeto WBS Work Breakdown Structure) para um mesmo projeto. Copyright Compass International Knowledge Center 41

42 Ainda relacionado ao controle está o princípio 8/80 que recomenda que um pacote de trabalho não tenha menos do que 8 e não mais do que 80 horas de duração. O que equivale recomendar que o menor ciclo de controle do projeto não seja menor do que um dia (8 horas) e não maior do que duas semanas (2 semanas de trabalho de 40 horas) Outro fator determinante para a parada da decomposição é se a entrega será realizada por um terceiro. Mesmo que seja da própria organização executora, no caso de um setor de Marketing que irá preparar um plano de marketing para o projeto, nestes casos, o gestor do projeto figurará como um demandante de um projeto (sub-projeto) e não haverá necessidade de detalhar o como da entrega terceirizada. Decomposição dos pacotes de trabalho em atividades que formarão o diagrama de rede do projeto Formas de EAP A estruturação do projeto pode dá-se da maneira mais conveniente para os executores do projeto. Pode ser em formato de uma lista indentada ou em distribuição radial, conforme exemplos abaixo. Copyright Compass International Knowledge Center 42

43 Funções da EAP Além da missão de identificar a plenitude do trabalho do projeto, seguindo o princípio dos 100%, que determinam que 100% do trabalho do projeto deve estar representado na EAP, esta permite ou facilita a elaboração de uma série de elementos do projeto. Por sua estrutura refletir a hierarquia de construção do projeto a EAP permite, com pequenos ajustes, a elaboração do organograma do projeto. Permite a atribuição específica de responsabilidades por entregas PROJETO Gerente do Projeto Fase 2 Resp. Fase 2 Entrega A Entrega B Resp.Ent.A.A Resp.Ent.B.B PT 1 PT 2 PT 3 PT 4 R.PT 1 R. PT 2 R.PT 3 R.PT 4 A EAP pode servir como referência para uma identificação e tratamento de riscos a partir de cada entrega. Copyright Compass International Knowledge Center 43

44 Tratamento de Riscos Associados por entregas PROJETO Fase 2 Identificação de Riscos Associados por entregas Entrega Entrega PT PT PT PT Estimativas de custo tornam-se mais simples se seguirem a seqüência inversa da EAP, ou seja de baixo para cima (Bottom Up) O último nível da EAP, os pacotes de trabalho, uma vez decompostos, identificarão as atividades do projeto que é, sob o ponto de vista do processo de decomposição, a menor célula do projeto. Com as atividades identificadas será possível construir o cronograma do projeto. A EAP está diretamente relacionada à natureza do produto do projeto. Significa que projetos de mesma natureza, como por exemplo, projetos de desenvolvimento de software que utilizem a mesma metodologia, terão EAP muito parecidas, podendo, inclusive, ser aproveitadas como modelo. Dicionário da EAP (WBS) As entregas indicadas na EAP devem ser descritas de forma sucinta, portanto há a necessidade de descrevê-las de forma mais detalhada. Para isso, a boa prática recomenda que seja elaborado um dicionário, uma espécie de glossário da EAP (WBS), no qual serão detalhados os significados e os elementos mais importantes das entregas do projeto. Copyright Compass International Knowledge Center 44

45 DICIONÁRIO DA WBS Código # Responsável Data última atualização Versão # Descrição da Entrega Produto (Deliverable) Critérios de Aceitação Recursos Duração Custo Milestones (Marcos) Predecessor Sucessor Restrições Aprovador da Execução Data da Aprovação Aprovador da Entrega Data da Aprovação Modelo de Dicionário da EAP (WBS). As informações essenciais são o código e a descrição da entrega as demais, inclusive de outras áreas de conhecimento, tais como duração, custo etc., serão documentadas na sequência do processo de planejamento CRONOGRAMA DO PROJETO O desenvolvimento do cronograma do projeto envolve a definição das atividades e seu sequenciamento, a determinação dos recursos humanos e materiais necessários à realização das atividades, a estimativa da duração das atividades e o posicionamento em um calendário real em que sejam consideradas as limitações de períodos de trabalho. 1- DEFINIÇÃO DE ATIVIDADES A decomposição das entregas do último nível da EAP (pacotes de trabalho) identificará as atividades necessárias para a realização das entregas previstas pelo projeto. Estas serão as menores unidades de execução do projeto. As atividades permitirão demonstrar as mais detalhadas relações de dependência necessárias à elaboração do diagrama de rede do projeto. Copyright Compass International Knowledge Center 45

46 2- SEQUENCIAMENTO DAS ATIVIDADES Sequenciar as atividades do projeto significa determinar as relações de dependência lógica entre as atividades. A dependência lógica é uma relação de causa e efeito entre atividades na qual: a atividade PREDECESSORA é a causadora da SUCESSORA. Ou seja, a atividade SUCESSORA é determinada, influenciada, pela atividade PREDECESSORA. A dependência lógica não é uma dependência cronológica, isto é a atividade SUCESSORA pode ser realizada antes no tempo da atividade PREDECESSORA. As atividades preparação para a prova e a marcação da data da prova podem ilustrar essa diferença, pois dependendo das condições podem assumir o papel tanto de PREDECESSORA como de SUCESSORA. Copyright Compass International Knowledge Center 46

47 Tipos de dependências Dependências Obrigatórias Seguem uma lógica rígida (hard logic). Dada a natureza das atividades, a atividade sucessora depende necessariamente da predecessora. É fisicamente impossível ser invertida. Por exemplo: a pintura de uma parede depende do emboço. Dependências Facultativas Há atividades, porém que não apresentam dependência lógica entre si, mas por conveniência, ou preferência, o gestor do projeto estabelece uma relação de dependência. Também denominada de dependência arbitrada ou discricionária (soft logic), passa a existir por decisão do gestor do projeto em função de ser uma melhor composição de acordo com as melhores práticas do ramo de atividade relacionada ao projeto, ou de experiências em projetos anteriores. Por decisão gerencial, podem ser desfeitas ou invertidas. Dependências Externas Fatores externos ao projeto podem ter relacionamentos que gerem restrições à forma pela qual as atividades podem ser conduzidas. Uma aprovação governamental, por exemplo, irá limitar as atividades que dependam dela. Relações de Dependência entre atividades Copyright Compass International Knowledge Center 47

48 Todo projeto, por definição, tem início e fim definidos previamente, ou seja, um ponto de partida e outro de chegada, portanto é possível representar graficamente as atividades do projeto em sequências determinadas pelas relações de dependência entre elas em forma de uma rede. No diagrama de rede, ou diagrama de precedência (PDM Precedence Diagramming Method), são identificadas quais atividades serão executadas em série e quais serão desenvolvidas simultaneamente, ou em paralelo. Os conjuntos de atividades dependentes entre si são denominados de caminhos. Um projeto pode ter muitos caminhos, mas todos eles partirão do ponto de início e terminarão no ponto de fim do projeto. A rede acima apresenta os seguintes caminhos: Início-A-B-D-Fim; Início-A-B-E-Fim e Início-A-C-E-Fim. Copyright Compass International Knowledge Center 48

49 Exemplo da determinação das dependências entre as atividades e o consequente diagrama de rede 3- ESTIMATIVA DE RECURSOS A fim de poder calcular as durações das atividades é necessário determinar que recursos humanos, materiais e de equipamentos serão utilizados, ou seja, os recursos executores das atividades. É preciso identificar as disponibilidades de cada um dos recursos, a fim de que não haja superalocações, se o recurso é próprio da organização ou será contratado de terceiros, assim como suas capacidades de desempenho. Havendo a possibilidade do recurso a ser utilizado na realização da atividade é necessário que cada recurso seja associado, atribuído, a cada atividade, conforme figura a seguir. Copyright Compass International Knowledge Center 49

50 No caso de recursos humanos é importante identificar suas produtividades que dependem de suas competências específicas relacionadas à natureza da atividade, de suas experiências anteriores, nas suas formações e perfis profissionais. Quanto aos equipamentos é importante, na medida do possível, diferenciar a capacidade nominal, a prevista no manual, da capacidade real, ou efetiva, pois uma superestimação de desempenho pode gerar falsas expectativas que no momento da execução serão frustradas. 4- ESTIMATIVA DE DURAÇÃO DAS ATIVIDADES Uma vez que os recursos executores com suas respectivas capacidades de desempenho foram determinados, é possível estimar o tempo de duração das atividades. A duração da atividade como função da relação entre o trabalho e os recursos determinados para executá-lo faz com que o aumento do número de recursos para uma mesma quantidade de trabalho, ou esforço, gere uma redução na duração, conforme gráfico a seguir: Entretanto, esta relação matemática, na prática não se confirma, pois segue o princípio de economia dos lucros cessantes ou retornos decrescentes (Law of Diminushing Returns), que considera que o ganho de produtividade com a adição de recursos não é linear, isto é, na realidade os recursos têm competências ou capacidades diferentes, portanto gerando desempenhos diferentes. Copyright Compass International Knowledge Center 50

51 Sendo assim, estas perdas devem ser compensadas quando forem feitas as estimativas de duração das atividades. Ao realizar o processo de estimar duração das atividades é necessário determinar o grau de precisão requerido. Uma estimativa com maior precisão, se por um lado gera maior confiabilidade, por outro requer mais esforço, utilização e manipulação de mais dados e informações, portanto tem maior custo. Em casos onde não é possível obter informações mais precisas, pode-se estimar a duração por analogia, isto é, comparando com experiências anteriores. Vale ressaltar, que se deve ter o cuidado em comparar grandezas de mesma ordem e características. A melhor condição de confiabilidade para a estimativa é que seja obtida do próprio recurso escalado para executar a atividade e que sua produtividade real seja conhecida do gestor do projeto. Na impossibilidade de definição do executor o gestor do projeto terá que realizar a estimativa a partir da opinião de um especialista na matéria, de tempos padrão em função do tipo da atividade, ou de cálculos paramétricos, ou seja, a multiplicação de quantidades por produtividades. Modelos matemáticos que estabelecem correlações entre variáveis: metros por hora, montagens por dia, etc. O processo de elaboração da estimativa, entretanto, é determinante na qualidade dos esforços e tempos estimados. Uma simples solicitação de prazo pelo gestor do projeto ao executor pode esconder distorções significativas. Vale a pena analisar algumas situações típicas e seus efeitos nos parâmetros do projeto. Estimativa do Executor Neste caso, o gestor do projeto solicita ao executor que estime a duração de uma atividade. De modo geral, o executor faz uma análise superficial, pois, infelizmente, não é prática comum ter-se controles de time sheet ou apontamento de horas correlacionando período de trabalho e tarefa ou atividade de projeto. Assim, a partir Copyright Compass International Knowledge Center 51

52 apenas de uma idéia do volume de trabalho já comprometido, o executor fornece uma estimativa maior do que real para se defender de cobranças acerca do não cumprimento do compromisso. O esquema abaixo procura ilustrar esta relação. Nas estimativas fornecidas pelo executor, em geral, há a inclusão de uma margem de segurança para o cumprimento do compromisso. O executor não gosta de ter sua estimativa não confirmada, portanto é natural que queira se proteger colocando colchões (padding). Cabe ao gestor do projeto tentar identificar os excessos e negociar, com base em históricos anteriores ou outras fontes uma maior adequação. Estimativa do Gestor do Projeto Aqui o gestor do projeto estima por sua conta a duração da atividade considerando que o executor a realizará no período estabelecido e dedicará seu tempo integralmente a execução da atividade. Estimativa Conjunta Gestor do Projeto e Executor Neste caso, o gestor do projeto e o executor da atividade analisam os períodos efetivamente disponíveis e que realisticamente serão dedicados ao trabalho na atividade e negociam uma distribuição da carga de trabalho e chegam à duração da atividade. Copyright Compass International Knowledge Center 52

53 Estimativas Probabilísticas - Estimativa a partir de cálculos estatísticos que considera três valores de estimativa (Three points Estimate): a estimativa mais otimista, a mais pessimista, a mais provável. F O M P T Esta modelagem foi elaborada para aplicação em projetos no final da década de 50 durante o desenvolvimento da série de submarinos Polaris para a Marinha Americana e foi denominada de PERT (Program Evaluation and Review Technique). Este método de estimar é perfeitamente coerente com a natureza da atividade projeto que é essencialmente probabilística. Apresenta as estimativas como faixas de valores possíveis e não como um palpite certeiro que dificilmente seria cumprido. No primeiro passo, a formulação estatística soma os tempos otimistas e pessimistas ao mais provável multiplicado por 4. E = O + 4M + P 6 Esta média considera a proporção probabilística de ocorrência da mais provável e gera um efeito de compensação dos extremos estimados. Ou seja, uma estimativa que tenderia a ser muito otimista, ao aplicar a fórmula é compensada em direção a valores pessimistas, e vice e versa. E > M E = M E < M F F F O M E P T O M P T O E M P T Após esta mediação é necessário estabelecer a faixa de expectativa de precisão, ou seja, o intervalo a partir do qual será estabelecido o compromisso do projeto. No exemplo a seguir, estimativas calculadas com base na fórmula probabilística. Copyright Compass International Knowledge Center 53

54 ATIVIDADE Otimista (O) Média (M) Pessimista (P) Estimativa (E) A Determinação da data da conferência B Determinação do tema e do programa C Escolha do local D Obter palestrantes E Desenvolver material de divulgação F Obter mailling 3 4,5 9 5 G Enviar divulgação H Imprimir material para participantes 3 3,5 7 4 I Receber inscrições J Preparar KITs O intervalo de precisão é determinado pelos desvios padrões considerados. Para um desvio padrão a expectativa de cumprimento da estimativa é de 68,26%, se forem considerados dois desvios padrão, sobe para 95,46% e se forem três, para 99,73%. F 99,73 % 95,46 % 68,26 % 3s 1s 2s 1s 2s 3s T A natureza da atividade, sua complexidade, seu ineditismo, etc., será determinante para a aplicação de uma faixa maior ou menor de estimativa. Para o cálculo do desvio padrão pode ser utilizada a fórmula empírica onde: Desvio Padrão s s = P - O 6 Copyright Compass International Knowledge Center 54

55 ATIVIDADE Otimista (O) Média (M) Pessimista (P) Estimativa (E) Desvio Padrão Variância Range de Estimativa 1 s Range de Estimativa 1 s E Desenvolver material de divulgação 3,00 10,00 11,00 9,00 1,33 1, a ,00 + ou - 1,33 2 s 2 s 6,34 a 11,66 9,00 + ou - 2,66 3 s 3 s 5,01 a 12,99 9,00 + ou - 3,99 Dessa forma a estimativa de duração da atividade E estaria entre 7,67 e 10,33 dias com a precisão de 1 desvio padrão, estaria entre 6,34 e 11,66 dias com a precisão de 2 desvios padrão e entre 5,01 e 12,99 dias com a precisão de 3 desvios padrão de tolerância. Caminho Crítico O método do caminho crítico (CPM - Critical Path Method) foi uma importante contribuição para o gerenciamento de projetos, desenvolvida, no final da década de 50, pelo pessoal da companhia americana Duppont e a inglesa Remington. O conceito baseia-se no modelo de rede que identifica caminhos, que são conjuntos de atividades dependentes entre si. Dos caminhos do projeto um ou mais deles terá ou terão maior duração. Este ou estes caminhos, determinam a duração total do projeto. Este ou estes caminhos, serão considerados críticos porque qualquer atraso nele ou neles resultará em atraso do projeto. Os demais caminhos terão, portanto, menor duração. Esta diferença de duração será tratada como folga. Sendo assim o caminho crítico será aquele ou aqueles com a menor folga ou com folga igual a zero, no caso do tempo permitido ou demandado ao projeto ser igual ao tempo calculado ou estimado. Por exemplo, se o produto de um projeto precisa ser entregue no dia 30 e a estimativa calculada prevê que o projeto poderá ser entregue no dia 25. Neste caso há uma folga de projeto que será também do caminho crítico. Portanto, o caminho crítico, nesse caso será o de menor folga. Copyright Compass International Knowledge Center 55

56 É importante ressaltar que as folgas dos demais caminhos, não-críticos são recursos valiosos a serem utilizados pelo gestor do projeto e não tempo disponível para ser desperdiçado. Uma manipulação adequada das folgas de caminhos não-críticos pode gerar economias de tempo e custo significativas ao projeto, como veremos nos métodos de compressão ou redução de cronograma. Para calcular o Caminho Crítico é necessário seguir uma rotina que será descrita passo-a-passo a seguir. Antes de mais nada, é necessário definir o que são inícios mais cedo e mais tarde e términos mais cedo e mais tarde. Considerando-se o conceito de folga, onde haverá a possibilidade de executar as atividades de caminhos que não são críticos, que portanto, têm folgas, dentro de um intervalo de tempo igual a folga sem comprometer o projeto, ou seja, sem ultrapassar a duração do caminho crítico. Sendo assim estas atividades poderão começar a ser executadas em um momento mais cedo ou em um momento mais tarde no cronograma sem atrasar o projeto. Conseqüentemente, somando-se a duração estimada para a atividade teremos seus términos mais cedo e mais tarde Início mais CEDO Término mais CEDO Início mais TARDE Término mais TARDE Representação gráfica da rede com a Atividade no Nó (Activiti-on-node AON) Copyright Compass International Knowledge Center 56

57 Para o cálculo do caminho crítico é necessário analisar as atividades do projeto a fim de estabelecer as relações de dependência a fim de encontrar os caminhos da rede do projeto. Atividade A pode começar imediatamente e tem uma estimativa de duração de 3 semanas Atividade B pode começar após a atividade A ser completada e tem uma estimativa de duração de 3 semanas ATIV. A Ant. - Duração 3 Atividade C pode começar após a atividade A ser completada e tem uma estimativa de duração de seis semanas B C A A 3 6 Atividade D pode começar após a atividade B ser completada e tem uma estimativa de duração de oito semanas D E B C, D 8 4 Atividade E pode começar após a atividade C e D serem completadas e tem uma estimativa de duração de quatro semanas B 3 D 8 INÍCIO A 3 E 4 FIM 0 C 6 Em seguida, calcula-se os tempos de início e término mais cedo de cada atividade. Término Mais Cedo de B = Término Mais Cedo de A + Duração de B B 3 D INÍCIO 0 A E 4 FIM C 6 Copyright Compass International Knowledge Center 57

58 Início Mais Cedo de E (Convergência) = Término Mais Cedo da Atividade de Maior Término Mais cedo das convergentes 14 > 9 B 3 D INÍCIO 0 A E FIM C Tempo Total do Projeto Estimado Se houvesse mais tempo permitido Este valor seria diferente Por Exemplo: 20. O Projeto teria uma folga de 2 semanas Depois o cálculo dos tempos mais tarde. B 3 D INÍCIO 0 0 A E FIM C 6 Se houvesse folga total para o Projeto Apareceria aqui 3 menor que FOLGA em C 14 9 = = 5 Com isso é possível identificar o caminho crítico do projeto, que, neste caso, tem folga igual a zero. O outro caminho possui folga de 5 semanas. CAMINHOS Início-A-B-D-E-Fim Início-A-C-E-Fim Dur B 3 D INÍCIO 0 0 A E FIM C O diagrama de rede, portanto, permite identificar as relações de dependência entre as atividades e o caminho crítico do projeto. Copyright Compass International Knowledge Center 58

59 Gráfico de Gantt Cada ferramenta utilizada para o gerenciamento do projeto tem uma finalidade específica e apresenta um conjunto diferente de informações. O gráfico de barras desenvolvido pelo Engenheiro Gantt no final da década de 20 mostra a proporção de duração das atividades em uma escala de tempo. Mostra, também, os posicionamentos dos períodos de duração das atividades. Permite visualizar mais facilmente quanto de interseção há entre os momentos de realização das atividades. Atividades Atividade A Atividade B Atividade C Atividade D Atividade E Gráfico de Gantt (ou Barras) Algumas regras precisam ser respeitadas quando do desenho de um gráfico de Gantt. A escala de tempo não deve ser modificada em um mesmo desenho, pois isso geraria perda da visualização da proporção das durações. A recomendação é de que se faça gráficos diferentes para cada escala de visualização. No caso de um projeto de duração de 5 anos, poderia ser feito um gráfico em anos, outro em semestres, outro em trimestres, meses e até semanas. Da mesma forma, não se deve fazer cortes no meio do gráfico para encurtá-lo. Gráfico de Gantt (ou Barras) e Diagrama de Rede, compondo o Cronograma do Projeto Copyright Compass International Knowledge Center 59

60 Redução do Cronograma (Schedule Compression) Após a elaboração do cronograma pode-se constatar que os prazos calculados não atendem aos requisitos do projeto. Neste caso, deve-se procurar alternativas de redução do cronograma que mantenham a melhor relação de custo benefício. Fast Tracking (Paralelismo) A técnica consiste na análise de atividades do CAMINHO CRÍTICO, que foram programadas para serem executadas em seqüência linear a fim de verificar a possibilidade de passarem a ser executadas em paralelo, simultaneamente. B D E F G I Fim A C H F B D E I G Fim A C H As atividades do Caminho Crítico cujas relações de dependência são arbitradas e foram planejadas em seqüência linear por conveniência de projeto, serão os alvos primários da análise de Fast Tracking, porém as atividades com dependências obrigatórias também podem permitir um Fast Traking parcial. Ou seja uma parte da atividades poderá ser executada em paralelo ou simultaneamente. T T - FT FT Ganho de tempo com o Fast Traking O Fast Tracking tanto total quanto parcial aumenta o risco de atraso do projeto, pois aumenta a necessidade de gerenciamento. Atividades ocorrendo em paralelo, simultaneamente, exigem maior supervisão. Os pontos de autorização do início da sucessora são, em geral, difusos, isto é, são obtidos por cálculos paramétricos. Por exemplo: após 1 metro de cola aplicada será possível começar a colação do papel de parede. Pode exigir também, conforme a natureza das atividades a adição de mais recursos para executar ambas as atividades. Não é possível afirmar genericamente que isto, necessariamente, levaria a um aumento de custo, pois os ganhos com o tempo de execução podem compensar e Copyright Compass International Knowledge Center 60

61 até mesmo ultrapassarem o valor dos recursos adicionais. Por isso, tanto neste método como no seguinte, é necessária uma análise de trade-off, isto é avaliar qual opção trará mais vantagens para o projeto. Crashing (Compressão) Mais uma vez o Caminho Crítico será o alvo de uma análise que verificará se a adição, troca ou realocação de recursos poderá gerar ganhos de tempo no cronograma. Também, neste método as trade-off são necessárias. Na adição de recursos é necessário considerar a influência nos resultados de alguns fatores. 1- Se a atividade é sensível à duração, ou seja, se a adição de recurso de fato diminuirá sua duração. Por exemplo, em um projeto de uma casa, a atividade de concretagem da laje requer um número necessário e suficiente de recursos humanos e de equipamentos para a realização do trabalho de lançamento e assentamento do concreto que determinam sua duração. Não haverá redução de duração se houver um acréscimo de recursos nesta atividade. 2- A lei dos retornos decrescentes (Law of Dimininushing Returns), citada anteriormente, deve-se considerar fatores tais como: a maior necessidade de supervisão, perdas por processos de setup redundantes, etc. 3- É necessário avaliar (trade-off), se o custo do recurso adicional irá ultrapassar os ganhos de desempenho. Se isto acontecer, e o fator crítico de sucesso do projeto for custo, a adição não será uma alternativa viável. CUSTOS DO PROJETO Uma vez definidos o escopo, o que fazer, e o tempo necessário para fazer o que precisa ser feito no projeto, pode-se estimar o quanto irá custar o projeto. Como em todo o processo de planejamento a modo como o custo será tratado no projeto precisa ser planejado. Será necessário elaborar o plano de gerenciamento de custos do projeto que indicará a estrutura de custos do projeto determinando a classificação dos centros de custos, critérios de rateios, reservas previstas, etc., ou seja, definirá a estratégia a ser adotada na orçamentação do projeto. Classificação dos Custos A forma geral, contábil, de classificar custos leva em consideração o ponto de vista da empresa, isto é, o referencial é a empresa. Para uma classificação que sirva ao gerenciamento do projeto, deve-se classificar custos sob a perspectiva do projeto, ou seja, tendo como referencial o projeto e não a empresa. Custos Fixos e Variáveis Custos que não variam com o tempo, nem com a intensidade de utilização, nem com o volume de serviços gerados pelo projeto, são classificados como fixos. São custos que, independentemente da duração, ou de quaisquer variáveis do projeto, terão o mesmo valor. Se, ao contrário da situação anterior, os custos variarem de valor conforme o uso eles serão classificados como custos variáveis. Copyright Compass International Knowledge Center 61

62 O custo do transporte de um equipamento, que será usado no projeto, é um exemplo de custo fixo. Já o custo de mão-de-obra para a execução de uma atividade do projeto é um exemplo de custo variável, pois seu valor dependerá da duração da atividade. Custos Indiretos e Diretos Um custo será indireto se não conseguirmos atribuílo direta e especificamente a uma única atividade do projeto. Isto é, se deste custo beneficiarem-se mais de uma atividade do projeto. Neste caso haverá a necessidade de um rateio entre as atividades beneficiadas para que elas absorvam a proporção devida a cada uma do custo. Se, ao contrário, conseguirmos atribuir diretamente a uma única atividade um custo este será classificado como um custo direto. O salário do coordenador de uma área do projeto, por exemplo, cujo trabalho será dedicado a todas as atividades da áreas coordenada, é um custo indireto que deverá ser rateado entre todas as atividades da área segundo critérios que sejam capazes de representar a verdadeira proporção de dedicação do coordenador. Já o custo de um equipamento que será utilizado exclusivamente para a execução de uma única atividade deverá ser classificado como um custo direto. Uma classificação de custos realizada de forma indevida pode levar a distorções que mascarem a real distribuição dos custos no projeto, podendo gerar decisões desfavoráveis aos objetivos do projeto. Alocação dos custos no projeto A fim de representar o real impacto dos custos nas partes específicas do projeto é necessário que seja feita a apropriação de custos. A cada atividade do projeto deverá ser apropriado os valores correspondente aos seus custos diretos e à carga dos custos indiretos que lhes são devidas seguindo critérios de rateio. Atribuição (vinculação) dos custos a cada atividade do projeto Copyright Compass International Knowledge Center 62

63 A correta alocação dos custos do projeto gerará uma curva de custos incorporados que será o balizador de monitoramento e controle dos custos do projeto. Esta curva em razão da natureza geral de projetos, que possuem um comportamento típico de menor intensidade de consumo de recursos no seu início, maior consumo nas fases intermediárias e declínio de consumo ao seu final, assume o formato de S, sendo, portanto denominada de curva S do projeto. Curva S do Projeto Curva de distribuição dos custos acumulados do projeto Custo PROJETO 1 Atividade 1 Atividade 2 Atividade 3 Atividade 4 Atividade 5 Atividade 6 Atividade 7 Atividade 8 Atividade 9 Atividade 10 Custo Orçamento total do Projeto Reserva de Gerenciamento (Trat. Desconhecidos) Base de Referência de Custos (Cost Baseline) Curva S do Projeto Representa a correlação direta entre as atividades e os custos do projeto Reservas de Contingência (Trat. conhecidos) Estrutura hierárquica dos custos do projeto Projeto Após a correta alocação será obtido o montante geral orçamentário para o projeto ao qual 3-deverão Contas Controle ser somados os valores 100 relativos às reservas de contingência 100 do 50 Copyright 2- Pacotes Compass de Trabalho International Knowledge Center Atividades

64 projeto, ou seja, os valores dos orçamentos das ações de respostas aos riscos identificados e classificados como merecedores, dada à sua importância para os objetivos do projeto, de uma resposta ativa. Este somatório representará a base de referência de custos do projeto. Significa dizer que se o valor reservado ao plano de contingência for gasto nas ações do plano não haverá estouro de orçamento, ou seja este valor faz parte do plano de gerenciamento do projeto. Vide modelo abaixo: 8- Orçamento total do Projeto Reserva de Gerenciamento (Trat. Desconhecidos) Base de Referência de Custos (Cost Baseline) Reservas de Contingência (Trat. conhecidos) 4- Projeto Contas de Controle Pacotes de Trabalho Atividades O item 3 diz respeito a Contas de Controle que devem corresponder às macro entregas do ciclo de vida do projeto e serão as correspondências que o plano de contas da contabilidade da organização e o projeto poderão fazer sua conciliação. PLANEJAMENTO DA QUALIDADE DO PROJETO A elaboração do Plano de Gerenciamento do Projeto prossegue e, neste ponto do processo, já devem ter sido definidos o escopo, o tempo e o custo do projeto. Ou seja, as três principais variáveis determinantes do projeto. Outros elementos do plano, porém, ainda não terão sido tratados o que significa que as definições anteriores poderão e deverão ser reformuladas, uma vez que o processo de elaboração do plano é de fato interativo. A seqüência segue uma ordem lógica, mas que deve comportar idas e vindas. Antes de tudo, é importante lembrar que qualidade só pode ser entendida se referenciada a um padrão. Isto é, não existe qualidade absoluta, mas sim qualidade requerida por alguém (sujeito) que espera atendimento dos seus requisitos dentro de certas margens de tolerância. Estas margens de tolerância são os limites, fronteiras do padrão da qualidade requerida. Plano de Gerenciamento da Qualidade Assim sendo, o plano de gerenciamento da qualidade do projeto deve levar em consideração este cenário. A fim de encontrar a melhor estratégia para atender às expectativas do cliente deve empreender todos os esforços possíveis para descobrir quais são estas expectativas, explicitá-las, para, em seguida, encontrar os meios de Copyright Compass International Knowledge Center 64

65 atendê-las. O gerenciamento da qualidade do projeto, segundo o Guia PMBOK, é definido como sendo: os processos que cuidam das atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade para que o projeto satisfaça as necessidades para as quais foi criado. O plano de gerenciamento da qualidade definirá padrões e processos que garantam a qualidade do projeto. Determinará como serão tratados a garantia dos processos e o controle da qualidade do produto do projeto. Deve definir, também, as responsabilidades específicas dos membros da equipe para conduzir as ações do gerenciamento da qualidade. Quem liderará cada processo, quem fará inspeções, quem aprovará, autorizará etc. Análise de Custo x Benefício O conceito de qualidade enunciado pela ISO 9000:2000 é de que qualidade é: o grau no qual um conjunto de características inerentes satisfaz aos requisitos. Portanto, não há qualidade absoluta ou total. Em meados dos anos 80, o termo Qualidade Total foi interpretado equivocadamente como sendo qualidade absoluta, quando deveria significar que a totalidade da organização deve buscar a qualidade como objetivo e não apenas aqueles que tinham como função zelar pela qualidade. Assim sendo, é necessário, para o planejamento da qualidade do projeto, identificar qual a melhor relação entre as necessidades do cliente e os custos envolvidos para atender a estas necessidades. Haverá um ponto de equilíbrio indicando que a partir de um determinado ponto, não haverá valor percebido pelo cliente. Nível de Atendimento aos requerimentos Gold P lating Não Requsitado Não Esperado Não Contratado Requisitos do Projeto (CLIENTE) Valor Esperado (contratado) Orçamento do P rojeto Custo da Qualidade As entregas que excederem ao limite do contratado serão consideradas formalmente, além do requisitado, do esperado pelo cliente. Não foi pedido pelo cliente. O jargão da comunidade de gerenciamento de projetos denomina esta prática de gold plating. Em uma tradução livre, seria a gíria: dourar a pílula. Copyright Compass International Knowledge Center 65

66 Significa que não faz parte do escopo muito menos dos requisitos acordados formalmente. Não é uma boa prática de gerenciamento de projetos entregar além do requisitado, pois a premissa é de que seja elaborado um plano que atenda aos requisitos e que este plano seja executado. Qualquer diferença a mais ou a menos que não seja fruto da incerteza inerente a qualquer projeto, ou seja, movimentos intencionais de modificações do plano será uma quebra do acordo feito com o cliente. Determinação dos Padrões da Qualidade do Projeto A qualidade precisa de uma referência de avaliação. Esta referência é o padrão da qualidade que deve ser estabelecido pelo cliente do projeto. É função do gestor do projeto identificar este padrão e persegui-lo. Cada padrão, porém, possui uma probabilidade de ser atingido que dependerá das características de processamento e geração do produto. Esta probabilidade, ou possibilidade, de cumprimento do padrão que deve ser reconhecida e aceita pelo cliente será tratada como TOLERÂNCIA. Portanto, é necessário para estabelecer os acordos relacionados à qualidade que sejam determinantes do padrão, ou seja a tolerância do cliente à variabilidade dos resultados das entregas. Na figura abaixo temos a descrição de um padrão, ou tolerância, para a fabricação de uma peça mecânica. Esta é, certamente, uma situação de grau de facilidade alto para a determinação destas variáveis, pois quanto mais abstrato for o objeto da entrega mais difícil é a determinação dos padrões e tolerâncias envolvidos. É o caso por exemplo de projetos que geram soluções para um problema, ou melhorias. O que não exime o gestor do projeto de fazê-lo. Tolerância = PADRÃO DA QUALIDADE D- D+ D D Procedimentos, métricas e indicadores da qualidade Uma vez que tenham definidos os padrões de referência do projeto será preciso determinar os procedimentos necessários para que eles sejam atingidos, assim como Copyright Compass International Knowledge Center 66

67 as unidades de medida, métricas, para cada parâmetro da qualidade e os indicadores que permitirão monitorar o quanto eles estarão sendo cumpridos e tomar as medidas preventivas e corretivas necessárias. A medida da qualidade do projeto será a medida do cumprimento dos parâmetros estabelecidos nas variáveis de escopo, tempo de custo do projeto. Cada especificação do projeto passa a ser uma referência a ser seguida e medida da qualidade do projeto. A determinação de que uma parede em um projeto de construção de uma casa será pintada com uma tinta específica e com uma determinada densidade são itens de escopo, mas a medida do cumprimento destas especificações, isto é, a garantia de que a tinta e a densidade especificadas sejam cumpridas é assunto do gerenciamento da qualidade. PAPÉIS E RESPONSABILIDADES DAS PESSOAS NO PROJETO Atividades e ramos da economia, conforme sua natureza, são intensivos em capital, caso das instituições financeiras, intensivos em tecnologia, caso das empresas de telecomunicações, intensivas em equipamentos caso de empresas que dependam fortemente de máquinas, etc. Projetos são intensivos em pessoas. Significa que o sucesso de um projeto depende diretamente do desempenho das pessoas que o realizam. O planejamento dos recursos humanos do projeto tem como objetivo criar o Plano de Gerenciamento de Pessoal que estabelece a forma como as pessoas do projeto serão incorporadas, organizadas, distribuídas pelas partes do projeto, como serão capacitadas e coordenadas para alcançarem os objetivos do projeto. Contratação ou Mobilização da Equipe do Projeto De acordo com os requisitos de desempenho do projeto o plano indicará critérios e processos necessários para a busca e a escolha dos profissionais que integrarão a equipe do projeto. O tipo de vínculo que o profissional terá com o projeto, será determinado pela sua origem. Se for pessoal da própria organização será uma mobilização, mas se for externo à organização executora do projeto será uma contratação. Para tal é necessário que o gestor do projeto identifique as competências que a equipe deve ter a fim de realizar as atividades do projeto necessárias ao seu sucesso. A primeira dificuldade na identificação de competências reside no fato de que competência é diferente de qualificação, isto é, competência segundo Felipe Perrenoud (1999), é Capacidade de agir eficazmente em um determinado tipo de situação, apoiando-se em conhecimentos, mas sem limitar-se a eles. O currículo do profissional apresenta conhecimentos adquiridos em formação acadêmica e experiências anteriores, mas não consegue garantir que ele seja competente para a atividade requerida. Copyright Compass International Knowledge Center 67

68 O conhecimento é um dos componentes da competência, assim como as habilidades que são desenvolvidas na prática de atividades que requeiram a aplicação de técnicas conhecidas. De forma simplificada competências podem ser definidas como o conjunto de conhecimentos, habilidades e atitudes de um profissional. Esquematicamente podese dizer que conhecimentos são o saber, as habilidades o saber fazer, e as atitudes o querer fazer. Este último elemento refere-se ao posicionamento que o profissional frente aos desafios das atividades. Nele estão contidos o comprometimento, o envolvimento e a motivação para agir no momento adequado mobilizando conhecimentos e habilidades. A identificação de competências necessárias à execução do projeto assim como dos potenciais membros da equipe de um projeto não é da tarefa trivial. Exige, portanto, que o gestor do projeto invista esforço considerável já que uma equipe competente é fator crítico de sucesso para o projeto. As competências necessárias ao projeto precisam ser traduzidas de forma mais explicita e prática possível através da análise da natureza de cada tarefa. Por exemplo, será necessário elaborar um cronograma composto de: um gráfico de Gantt e de um Diagrama de Rede inseridos em um calendário, utilizando o software X. O profissional candidato à posição precisa ser capaz de executar esta atividade utilizando a referida ferramenta. Após a identificação das competências exigidas para execução de cada tarefa o gestor deve especificar o conjunto de competências que serão necessárias para cada profissional do projeto, determinando, assim um perfil desejado. Este perfil profissional desejado será o instrumento que servirá de guia para a busca na própria organização, para uma mobilização, ou no mercado, para uma contratação. Uma vez recrutados os candidatos, será necessária a seleção. Para esta etapa, Seguindo uma orientação focada em competências, o gestor do projeto pode solicitar que o candidato se submeta a um teste ou que obtenha informações de fontes abalizadas que atestem seu desempenho em tarefas equivalentes às que serão necessárias, ou seja, que obtenha uma comprovação das competências e não haja apenas uma demonstração de currículos. Organograma e Matriz de Responsabilidades do Projeto Como resultado estruturado do processo de especificação das pessoas em suas respectivas posições, atribuições e relações hierárquicas é um organograma e uma matriz de atividades por pessoas alocadas no projeto, conhecida como Matriz de Responsabilidades. Copyright Compass International Knowledge Center 68

69 Sponsor do Projeto Gerente do Projeto Apoio Adm Resp. Fase A Resp. Fase B Resp. Contratos Consultor Membro 1 Membro 2 Organograma do Projeto Membro 3 Resp. Ent. n - Resp. Atividade A - Resp. Atividade B - Resp. Atividade n No organograma devem estar demonstradas as relações de subordinação funcional no projeto. Devem estabelecer o papel de todas as pessoas que participarão ativamente no projeto, inclusive pessoas externas à organização executora. Para deixar claro que este organograma é do projeto e não reflete necessariamente a hierarquia da empresa, costuma-se denominá-lo de organograma virtual do projeto. A matriz de responsabilidades tem uma abordagem mais operacional, pois as referências são as atividades do projeto e o papel que cada membro da equipe do projeto desempenho em relação a elas. Alguns princípios devem nortear a elaboração da matriz, entre eles o da unicidade de comando. Isto é, cada atividade deve ter apenas um responsável. Mesmo que haja dois membros da equipe que dividam a responsabilidade pela execução da atividade, é recomendável que o gerente do projeto nomeie um deles como o responsável. Matriz de Responsabilidades do Projeto Copyright Compass International Knowledge Center 69

70 PLANEJAMENTO DAS COMUNICAÇÕES DO PROJETO O recente estudo de benchmarking realizado pelo PMI aponta a comunicação é um problema importante em projetos. Um dos principais fatores de fracassos em projetos. Tratar as comunicações de forma planejada, portanto, é um caminho para diminuir a probabilidade de dificuldades no gerenciamento do projeto. Projeto é algo que precisa ser criado para resolver um problema ou aproveitar uma oportunidade. Estas necessidades ou requisitos precisam ser transmitidos, comunicados, a quem será encarregado de realizá-lo. Sendo assim, a comunicação é elemento chave neste relacionamento que deverá identificar os objetivos e definir o escopo do projeto. Portanto, se analisadas em mais profundidade as causas de objetivos, escopo e outras varáveis de projeto mal definidos, pode-se chegar com freqüência ao componente comunicação como fator preponderante. Muitos dos problemas ligados à comunicação são identificados pela compreensão dos elementos presentes no processo, conforme demonstra a figura a seguir. Modelo Básico de Comunicação (fonte: Guia PMBOK, 2008) A partir deste modelo é fundamental deixar claro que a responsabilidade pela qualidade, eficácia, da comunicação é do emissor. Ou seja, de quem transmite a mensagem. Sendo assim, ele deve cuidar para que eventuais desvios, diferenças, ruídos, barreiras ou lacunas na comunicação não ocorram. E se ocorrerem dar o melhor tratamento. Jogar a responsabilidade pela não compreensão da mensagem para o receptor, não é prática recomendável. Ponto sensível em ambientes de projeto, a escolha do código utilizado pelo emissor para encapsular a mensagem é fator decisivo na eficácia da comunicação. O código escolhido pelo emissor deve ser de domínio do receptor. Como guardião da eficácia da comunicação, o emissor, antes de mais nada, deve certificar-se de que o receptor domina o código que será usado na transmissão da mensagem. Jargões técnicos de domínio de ambientes tecnológicos restritos, com siglas e abreviaturas específicas, muito comuns em projetos de áreas intensivas em tecnologia, são pontos de atenção para códigos desconhecidos pelo receptor. A presunção de que o jargão deve ser dominado, por quem é do meio, é perigosa. Projetos são atividades de relacionamentos internos e externos à organização executora. Hoje, dado o grau de especialização tecnológico e a velocidade das Copyright Compass International Knowledge Center 70

71 mudanças, profissionais de uma mesma área podem ter sérias dificuldades de compreender os termos usados na comunicação de um projeto. O problema se agrava se levarmos em consideração a interação que os executores de projetos precisam ter com membros da alta direção empresarial. Um diretor recém contratado pela organização pode se sentir constrangido em demonstrar desconhecimento de um jargão e por isso não externar que não compreendeu adequadamente uma informação valiosa para sua tomada de decisão. O mesmo pode ocorrer com um fornecedor ou outro stakeholder do projeto. Assumindo o papel de responsável pela eficácia da comunicação no projeto o emissor deve, inclusive procurar garantir que o retorno (feedback) dado pelo receptor seja ativo. Feedback ativo, não é o mesmo que o receptor responder entendi, porque pode ter sido entendido algo diferente do conteúdo que o emissor desejava comunicar. Feedback ativo, portanto, requer a confirmação do significado da mensagem nas palavras do receptor, afim de que seja possível ao emissor verificar se houve divergência entre o que foi entendido e o que precisava ser comunicado. A título de exemplo de uma estratégia para provocar feedback ativo de stakeholders importantes tais como o cliente ou o sponsor, o gestor do projeto, durante uma entrevista de levantamento de requisitos ou de definição de escopo, pode testar o entendimento, induzir ao feedback ativo, lendo em voz alta o que foi acertado e anotado e solicitando ao interlocutor que identifique alguma divergência. Portanto, o planejamento das comunicações do projeto deverá determinar: O que deve ser comunicado. Que documentos e informações do projeto devem ser transmitidas. O Termo de Abertura, a declaração do escopo, o plano de gerenciamento do projeto, variações de prazo, de custo, novos riscos identificados, mudanças, etc. Quem deve enviar e receber a comunicação. Os stakeholders (partes interessadas) do projeto devem ser o alvo de um plano de comunicação de um projeto. A boa técnica da comunicação recomenda, para maior eficácia, a seletividade. Isto é, a comunicação deve ser direcionada ao receptor específico. Se a comunicação não for seletiva pode causar o efeito que os s spam (comunicação em massa). A distribuição indiscriminada, não seletiva, desvaloriza tanto a mensagem quanto o emissor. Outras mensagens do emissor não seletivo tendem a ser desconsideradas. Este processo, portanto, depende de um bom mapeamento, identificação precisa das necessidades e interesses, de cada stakeholder do projeto. Quando deve ser feita a comunicação. A periodicidade ou momentos específicos do projeto que deve ser realizada. Uma vez que o princípio do planejamento prevaleça e o plano de gerenciamento do projeto determine um ciclo de controle, o calendário de reuniões de progresso programadas já deve ser divulgado a quem delas irá participar. Copyright Compass International Knowledge Center 71

72 Como será feita a comunicação. Que meios ou canais serão utilizados a fim de que haja maior eficácia. Aqui também, o princípio da seletividade se faz necessário. Cada informação a ser comunicada a um stakeholder específico deve ser entregue pelos meios, canais, ou veículos específicos. Determinada informação para alguns stakeholders pode ser suficiente a publicação em um jornal de grande circulação ou em um diário oficial regional. Para outro stakeholder pode ser mais indicado uma apresentação presencial em sua própria sala. Cabe ao gestor do projeto, apoiado pelo sponsor, identificar estas especificidades que são fatores críticos de sucesso para a comunicação do projeto. Documento Stakeholder Quando? Como? Termo de Abertura Sponsor, Cliente, Equipe, Gerentes Funcionais,... Na abertura do projeto Cópia em papel entregue em mãos Plano do Projeto Sponsor e Equipe Na conlusão do planejamento Cópia em papel entregue em mãos Contrato Sponsor e Cliente Na assinatura do contrato Cópia em papel entregue em mãos WBS Sponsor, Cliente, Equipe Na geração do documento Cópia em papel entregue em mãos Cronograma de Utilização de recursos Gerentes Funcionais No término do planejamento Memorando interno Riscos Identificados Sponsor, cliente e equipe Na abertura do projeto e na conclusão do plano Cópia em papel entregue em mãos Equipe Na identificação de novos riscos Problemas identificados Equipe Na identificação de problemas (...) (...) (...) Matriz de Comunicações GERENCIAMENTO DOS RISCOS DO PROJETO Risco de projeto, segundo o Guia PMBOK, é um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade. Projetos são atividades probabilísticas e não determinísticas, isto é, seus resultados possuem considerável grau de incerteza. Projetos são realizados para a criação de algo que não existe ou para a aplicação de uma solução a um problema presente. Em ambos os casos não é possível garantir com absoluta certeza que acontecerão. São eventos futuros sobre os quais é possível, no máximo, fazer estimativas e previsões com taxas de probabilidades associadas. Neste cenário o gerenciamento dos riscos constitui-se no conjunto de processos que aumentem a possibilidade de sucesso do projeto, aumentando a probabilidade e o impacto dos riscos positivos, e diminuir a probabilidade e o impacto dos riscos negativos do projeto. Aumentar a dimensão das oportunidades, ou fatores favoráveis Copyright Compass International Knowledge Center 72

73 ao projeto alcançar seus objetivos e diminuir as ameaças, ou fatores desfavoráveis ao alcance dos objetivos do projeto. Um risco origina-se de uma fonte, o evento materializa-se por uma causa que gera conseqüências, impactos nos objetivos do projeto. Configuração do Risco em projetos O evento será potencial, portanto, risco, se possuir uma probabilidade de ocorrência. Se a probabilidade for nula não será considerado como hipótese, ou se for de 100% será um fato que pode configurar-se como uma certeza, restrição ou irrelevante para o projeto. Havendo probabilidade de ocorrência e a presunção de que o evento venha a causar impactos, efeitos nos objetivos do projeto, será considerado risco. Portanto, um risco deve ser avaliado sempre considerando-se as duas variáveis: a probabilidade e o impacto. Plano de Gerenciamento dos Riscos O planejamento do gerenciamento dos riscos produzirá um plano que determinará como serão realizados os demais processos do gerenciamento dos riscos, que são: Identificar os riscos Realizar a análise qualitativa de riscos Realizar a análise quantitativa de riscos Planejar respostas aos riscos Monitorar e controlar os riscos Determinará, também, a abordagem, estratégia, que será dada aos riscos de acordo com suas características: se pró-ativa, agindo antecipadamente, ou reativa, agindo se e quando, o evento incerto ocorrer. Imediatamente após a elaboração do plano de gerenciamento dos riscos, ainda no processo de planejamento, será necessário realizar os processos do gerenciamento dos riscos, exceto o de monitoramento e controle dos riscos que será realizado ao longo do processo de execução do plano de gerenciamento do projeto. Identificar os riscos Determinação, através de uma abordagem organizada, dos riscos positivos e negativos que podem afetar os objetivos do projeto. Este processo envolve, também, o levantamento e documentação de informações que caracterizem os eventos ao ponto de permitir ações específicas sobre eles. Copyright Compass International Knowledge Center 73

74 Para um melhor resultado neste processo, visto que envolve a identificação de hipóteses de eventos potenciais, é recomendável utilizar métodos de trabalho em grupo que estimulem a criatividade, tais como brainstorming, delphi, modelagens mentais e de associação de idéias, diagramas de causa e efeito (Ishikawa), análise de Forças, Oportunidades, Fraquezas e Ameaças (SWOT Strengths, Weaknesses, Opportunities, and Threats) etc. Modelos de categorização elaborados no planejamento dos riscos, tais como estruturas hierárquicas em forma de organogramas, neste caso, denominadas de estrutura analítica de riscos (EAR), podem ajudar na indução de identificação de riscos. O principal resultado do processo de identificação de riscos é um documento denominado Registro de Riscos (Risk Register) que contém a lista de riscos, com suas respectivas causas, efeitos e potenciais respostas. Dicas para documentar bem os riscos do projeto: 1. Descrever o risco de maneira estruturada, utilizando uma descrição em 3 partes: Devido a <uma ou mais causas>, <risco> poderá ocorrer, o que levaria a <um ou mais efeitos>. 2. Quanto mais específica for a descrição do evento de risco, mais facilmente conseguiremos planejar uma resposta e monitorá-lo posteriormente. Descrição genérica de um risco: Devido à situação atual do cliente, poderão ocorrer mudanças de escopo, o que levaria a um atraso do projeto. Descrição específica de um risco: Devido à quantidade de dúvidas do cliente em relação às possibilidades de utilização do ambiente a ser construído, poderá ocorrer um aumento na área de construção prevista originalmente para o auditório, o que levaria a um atraso na fase de desenho do projeto. 3. Quando possível, identifique alertas (triggers) que indiquem que o risco está prestes a ocorrer. Eles o ajudarão futuramente no monitoramento e controle daquele risco. Descrição do Risco: Devido à falta de experiência do pessoal com o equipamento XYZ, um desempenho ruim na execução dos testes deste equipamento poderá ocorrer, o que levaria a um aumento da duração prevista dos testes, que é de 20 dias. Alerta: Progresso dos testes inferior a 20% após 4 dias de teste. Copyright Compass International Knowledge Center 74

75 Exemplo de EAR (Estrutura Analítica de Riscos) Realizar a análise qualitativa de riscos Priorização dos riscos identificados para análise ou ação adicional subseqüente através de avaliação e combinação de sua probabilidade de ocorrência e impacto. Classificação para priorização dos riscos em função da probabilidade e do impacto Copyright Compass International Knowledge Center 75

76 Para o processo de análise qualitativa de riscos podem ser utilizadas escalas relacionadas às duas principais variáveis do risco: a probabilidade de ocorrência e o impacto sobre os objetivos. A ferramenta denominada Matriz de Probabilidade x Impacto permite uma melhor visualização da classificação dos riscos do projeto. Os graus ou as faixas das escalas de probabilidade e de impacto devem ser determinados de acordo com o perfil de tolerância ou aversão a riscos da organização executora do projeto. Exemplo de Escala de PROBABILIDADES Exemplo de Escala de IMPACTOS Copyright Compass International Knowledge Center 76

77 Exemplo de MATRIZ DE PROBABILIDADE X IMPACTOS (P x I) Na matriz os eventos são posicionados de acordo com as estimativas de probabilidade e impacto a fim de que sejam classificados segundo o produto das duas variáveis. Esta classificação servirá de orientação à estratégia de resposta que será elaborada no processo de Planejamento de Resposta aos Riscos. Os riscos com classificação ALTA, por exemplo, alta probabilidade e alto impacto podem ser considerados de prioridade máxima e exijam tratamento agressivo. Já para os de classificação BAIXA, a estratégia pode ser passiva, ou seja, apenas monitorá-los a partir de uma lista de observação (Watchlist). Realizar a análise quantitativa de riscos Análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto. Tem por objetivo analisar numericamente os riscos mais significantes estabelecidos durante a análise qualitativa, e a interação entre eles, para estimar a faixa de possíveis resultados para o projeto como um todo. Este processo utiliza técnicas como a simulação de Monte Carlo e a análise da Árvore de Decisão para: Quantificar os possíveis resultados do projeto e suas probabilidades Avaliar a probabilidade de atingir objetivos específicos do projeto Identificar os riscos que exigem mais atenção quantificando sua contribuição relativa para o risco total do projeto. Identificar metas realistas e alcançáveis de custo, cronograma ou escopo, quando fornecidos os riscos do projeto Determinar a melhor decisão de gerenciamento de projetos Planejar respostas aos riscos Desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. Formas de responder a riscos NEGATIVOS de um projeto: Eliminar o risco, planejando uma forma de excluí-lo completamente. Copyright Compass International Knowledge Center 77

78 Mitigar o risco, buscando uma forma de reduzir a probabilidade de sua ocorrência ou do seu impacto, caso o mesmo venha a ocorrer. Transferir o risco, normalmente repassando-o para um terceiro. Formas de responder a riscos POSITIVOS de um projeto: Explorar o risco, eliminando a incerteza associada a um risco positivo fazendo com que a oportunidade efetivamente aconteça. Melhorar o risco, modificando o tamanho da oportunidade aumentando a probabilidade e/ou impacto (valor esperado) do risco positivo. Compartilhar o risco, atribuindo a sua propriedade a terceiros que possam capturar melhor a oportunidade do risco acontecer em benefício do projeto. Formas de responder a riscos POSITIVOS e NEGATIVOS de um projeto: Aceitar Ativamente, buscando se preparar com reservas de tempo ou de dinheiro caso o risco venha a ocorrer. Aceitar Passivamente, simplesmente não fazendo nada e torcendo para que o risco não venha a ocorrer. Respostas de Contingência, elaborando planos de contingência que só serão executados se algum alerta, sintoma ou trigger (gatilho) ocorrer, ou se o próprio risco ocorrer. Estratégias de Resposta aos Riscos Copyright Compass International Knowledge Center 78

79 Dicas para documentar bem um plano de respostas a riscos: 1. Planos de resposta a riscos devem ser mais do que simples desejos de que as coisas dêem certo. Plano de ação ou apenas um desejo?: - Garantir que o equipamento seja entregue no prazo. Plano de ação objetivo: - Negociar com o fornecedor visitas quinzenais à fábrica para verificação do progresso da fabricação do equipamento. - Disponibilizar linha de comunicação direta ( hot-line ) com a fábrica para agilizar comunicação de eventuais problemas durante a fabricação. 2. Evite que os planos de resposta descrevam apenas o que já é parte das atividades cotidianas do trabalho. Descrição do Risco: - Quebra da alavanca código BHYZPT durante instalação do quadro elétrico nº 21A. - Plano de ação ou trabalho do dia-a-dia?: - Seguir as especificações de instalação do quadro elétrico. O que poderia ser feito de diferente, em relação ao que já é costume, para mitigar ou prevenir a ocorrência do risco? 3. Cuidado com ações de resposta que exijam acompanhamento durante toda a extensão do projeto: Em lugar de: Prefira: - Acompanhar as atividades do fornecedor através de gestão integrada. - Elaborar procedimento para acompanhamento das atividades do fornecedor através de gestão integrada. Monitorar e controlar os riscos Acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação dos novos riscos, execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o ciclo de vida do projeto. Copyright Compass International Knowledge Center 79

80 Copyright Compass International Knowledge Center 80

81 PROCESSOS DE AQUISIÇÕES O projeto precisa de recursos para conseguir realizar seus objetivos. Dessa forma, os processos de aquisição determinarão como será a aquisição de bens e serviços de fora da organização executora do projeto. Planejar Aquisições Realizar Aquisições Administrar Aquisições Encerrar Aquisições Decisão de Comprar ou Fazer (Make or Buy) Como parte do processo de planejamento das aquisições, é necessário analisar as alternativas para cada recurso necessário ao projeto entre adquirir de fora da organização ou produzir internamente. Considerar prós e contras, preferencialmente utilizando métodos de tomada de decisão. Indicações de FAZER Facilidade de integração com operações de rotina Utilização de capacidade ociosa Falta de fornecedores confiáveis Necessidade de controle direto Indicações de COMPRAR Fornecimento especializado Pequenos volumes Capacidade limitada Ampliar leque de fornecedores Transferência de risco ao fornecedor Seleção do Tipo de Contrato 1- Contratos com Preço Fixo e com Pagamento Integral 2- Contratos com Reembolso de Despesas 3- Contratos de Mão-de-Obra e Material Especificação do Serviço (SOW Statement of Work) A fim de que as necessidades específicas do projeto sejam atendidas é importante identificar todas as características de cada item a ser adquirido. Neste momento do projeto o gestor do projeto estará atuando como um cliente. Quanto mais especificações forem passadas aos fornecedores maiores serão as chances de que as aquisições sejam adequadas. O nível de definição do escopo de cada parte do projeto determinará a possibilidade de especificação da aquisição e conseqüentemente do modelo de contrato que poderá ser firmado. Se o escopo não estiver bem definido o contrato dificilmente poderá ser por preço fixo, o que acarreta mais risco para o comprador, neste caso o gestor do projeto. Copyright Compass International Knowledge Center 81

82 Critérios e Métodos de Avaliação de Fornecedores A melhor prática de aquisições recomenda que se utilizem métodos de tomada de decisão que diminuam a subjetividade da escolha de fornecedores. Esta prática pode diminuir, também, a influência do fator preço sobre a escolha do fornecedor, o que em muitos casos não é sinônimo de qualidade nem de melhor solução técnica. APROVAÇÃO DO PLANO DE GERENCIAMENTO DO PROJETO Todo este trabalho que até agora analisamos de desenvolvimento do plano de gerenciamento do projeto precisou ser AUTORIZADO. Autorização esta necessária para que o gestor do projeto e, dependendo da situação, uma equipe de gerenciamento do projeto, pudessem trabalhar na configuração do plano de gerenciamento do projeto. O trabalho de desenvolvimento foi AUTORIZADO, entretanto o plano desenvolvido precisa ser APROVADO. A instância aprovadora do plano de gerenciamento do projeto dependerá de cada projeto. Tipicamente, o Patrocinador (Sponsor) do projeto teria esta prerrogativa, mas pode ser aprovado por uma diretoria ou constituído um comitê especialmente para esse fim. Cabe lembrar que a aprovação do plano pressupõe a concordância com todos os parâmetros do projeto incluindo, prazo e orçamento. Conceitualmente, a partir de sua aprovação, o plano de gerenciamento do projeto passa a representar a referência para a execução do projeto, a linha de base do projeto (Project baseline). A integridade desta referência, linha de base, passa a ser responsabilidade do gestor do projeto, isto é, uma vez aprovado o plano, criada a linha de base, toda mudança em qualquer dos parâmetros do projeto deve ser tratada como modificação do plano. Significa que deverá ser conduzido um processo de aprovação das mudanças pelas instâncias autorizadas para tal. REUNIÃO DE PARTIDA DA EXECUÇÃO DO PROJETO KICKOFF MEETING A boa prática recomenda que o início da execução do plano de gerenciamento do projeto seja marcado, isto é, COMUNICADO aos principais stakeholders do projeto e à organização executora como um todo. Este pontapé inicial tem a finalidade de esclarecer dúvidas relacionadas ao plano de gerenciamento do projeto, a estratégias utilizadas, sistemas de controle adotados, pontos críticos, objetivos específicos, metas, enfim, é o momento e a oportunidade de confirmar a participação e o comprometimento dos principais envolvidos com os objetivos do projeto e angariar apoio de áreas fornecedoras de recursos. Copyright Compass International Knowledge Center 82

83 Execução, Monitoramento e Controle do Projeto Uma vez elaborado o plano de gerenciamento do projeto, é necessário realizá-lo, cumpri-lo. Esta afirmativa está longe de ser uma obviedade, porque é comum que no calor dos acontecimentos o plano seja esquecido e o processo de execução passe a ser uma sucessão de improvisos. O processo de execução consiste na integração das pessoas e recursos materiais para realizar o plano de gerenciamento do projeto. A concentração dos esforços necessários para atingir os objetivos estabelecidos para o projeto. Os processos de monitoramento e controle ocorrem desde o primeiro momento do projeto, porém, quando o plano estiver sendo executado, as exigências de monitorar, isto é, verificar como está sendo executado o plano, e quando necessário, tomar medidas corretivas, ou seja, controlar, tornam-se mais prementes. A execução do projeto envolve essencialmente: Executar, seguir o PLANO DE GERENCIAMENTO DO PROJETO Realizar o ESCOPO do projeto Entregar os PRODUTOS INTERMEDIÁRIOS Gerenciar os RECURSOS Gerenciar MUDANÇAS Corrigir DESVIOS Atualizar o PLANO DE GERENCIAMENTO DO PROJETO Equipe de execução do projeto É o momento de incorporar os membros da equipe que o plano de gerenciamento de pessoal determinou como necessária à realização do projeto. Mobilizar, se for pessoal interno à organização ou contratar, se forem externos. Em ambos os casos o gestor deverá apóia áreas de suporte no recrutamento, conduzir entrevistas e avaliar as competências dos candidatos. Copyright Compass International Knowledge Center 83

84 Faz parte das atribuições do gestor neste momento do projeto, o desenvolvimento de competências que ainda não estejam plenamente incorporadas pelos membros da equipe, seguindo estratégias e métodos de desenvolvimento profissional. Ciclo de Controle do Projeto A freqüência com que o projeto será, de forma programada, monitorado e controlado pode ser decisivo para o sucesso do projeto, pois determinará o nível de esforço empreendido nestes processos. Ciclo muito frequente Mais uma vez coloca-se uma situação em que faz-se necessário encontrar o ponto de equilíbrio, pois uma frequência muito alta irá requerer um esforço que talvez inviabilize o trabalho de monitoramento e controle. Pode inviabilizar, por exemplo, a atualização dos documentos do projeto. Levando à situação na qual o controle excede o objeto controlado, princípio de Henry Fayol, que em outras palavras, significa consumir mais esforço para monitorar e controlar do que para fazer. Ciclo pouco frequente Por outro lado, demorar para monitorar o projeto pode levar a desvios de tal ordem que não possam mais ser corrigidos, isto é, não seja mais possível às ações corretivas fazerem o projeto voltar à sua linha de base. Desvios impossíveis de serem corrigidos levam à necessidade de mudança para que o projeto continue com uma linha de base factível. Uma linha de base que sirva, efetivamente de referência para a execução do projeto. Copyright Compass International Knowledge Center 84

85 O monitoramento e controle do projeto A cada ponto do ciclo de controle de acordo com o previsto no plano de gerenciamento do projeto devem ser realizadas medições para a coleta de dados para a determinação do status do projeto. A data em que as medições são realizadas é denominada DATA DATE (Data dos Dados). A sequência de gráficos, a seguir, As atividades em vermelho pertencem ao caminho crítico. No primeiro ponto do Ciclo de Controle (C1), na DATA DATE, os dados de execução do projeto deverão ser Copyright Compass International Knowledge Center 85

86 Dados coletados: Atividade A concluída e sem variação de custo Os dados indicam, portanto que no primeiro Ciclo (C1) o projeto está de acordo com o planejado. Cronograma e Orçamentos cumpridos. No segundo ponto do Ciclo (C2) Impactos no PRAZO 1- Atraso na Atividade B (Caminho Crítico) gera atraso no projeto 2- Atraso na Atividade C não gera atraso por ter FOLGA de 5 dias CRONOGRAMA ATRASADO Impactos no CUSTO 1- Atividade B gastou mais 20% do orçado para fazer apenas 80% de 100% planejados 2- Atividade C gastou mais 30% do orçado para fazer apenas 30% de 50% planejados ORÇAMENTO ESTOURADO Se nenhuma ação corretiva for tomada o projeto sofrerá os impactos totais identificados, mas é papel do gerente do projeto identificar ações que neutralizem ou Copyright Compass International Knowledge Center 86