Download Guia para o PMD Pro...
Um guia para o PMD Pro Gerenciamento de projetos para profissionais de desenvolvimento
Guia para o PMD Pro i
EDITORA
Este documento é publicado pela PM4NGOs.
© Copyright 2011 PM4NGOs PMD Pro e o símbolo PMD Pro são marcas registradas da PM4NGOs.
Informações de versão: Este é o guia revisado do PMD Pro. Versão 1.3 datada de 26 de março de 2012 (Pós-piloto) Versões anteriores e histórico: Versão 1.2 datada de 5 de março de 2012 - substituída Versão 1.1 datada de 8 fevereiro de 2012 - substituída Versão 1 datada de 9 de dezembro de 2011 - substituída
Guia para o PMD Pro ii
AGRADECIMENTOS
Este documento foi criado com o suporte de vários especialistas que contribuíram com sua criação, análise e edição. Entre esses colaboradores, estendemos um agradecimento especial a Chris Cattaway, Roger Steele, Bernie Leadbeater, John Fisher, John Davidson, Alan Harpham, Liz Berryman, Katalin Hanniker, John Cropper, Anna Kondakchyan, Eric Berg, Richard Kondowe, Godfrey Kalibbala, Juan Manuel Palacios, Dario Mozzi, Adonis Sucalit, Jeroen Bollujit, Tracy Steuve, Bernie Leadbeater, Bob Youker, Felipe Chaparro, Lynne Curran, Gretchen Regehr, Rodolfo Siles, Naomi Jones, Geoff Reiss, Guy Sharrock, Amos Doornbos, Robert Sweatman, Marie-Laure Curie, David Palasits, Simon Early, Vadim Usvitsky, Caren Conner, Marian Abernathy e Terri Ise. Além disso, reconhecemos o suporte da equipe e dos voluntários associados à Fundação Educacional Instituto de Gerenciamento de Projetos cujo suporte foi crucial para a criação dos materiais de aprendizagem relacionados com o guia. Também somos gratos a várias organizações cujos documentos e materiais foram usados como referência e adaptados para o uso no Guia do PMD Pro1. Gostaríamos de agradecer especialmente as contribuições da Catholic Relief Services pela sua inestimável série ProPack, à World Vision International pelos documentos sobre Aprendizagem para planejamento e avaliação (LEAP) e à Comissão Europeia pelas suas Diretrizes para prestação de auxílio, cujos materiais de estudo foram usados extensamente neste documento. Além disso, agradecemos ao Project Management Institute, o International Institute for Learning, a True Solutions Inc. e à Versatile Company por seu generoso fornecimento de suporte e materiais de aprendizagem. Pode-se encontrar uma lista completa de referências no final deste documento. Por último, esta atividade não teria sido possível sem a inspiração e o suporte de Richard Pharro e sua equipe do APM Group. Esse esforço só foi possível através de seu suporte financeiro, organizacional e técnico. Michael Culligan, Stephen Marks, Trevor Nelson, Leah Radstone e Eric Verzuh
Guia para o PMD Pro iii
CONTEÚDO
Editora ......................................................................................................................................................... ii Agradecimentos ...........................................................................................................................................iii Conteúdo .................................................................................................................................................... iv INTRODUÇÃO............................................................................................................................................. 1 Seção 1
: Projetos do setor de desenvolvimento ................................................................................... 7
1.1 O gerenciamento de projetos é desafiador! ...................................................................................... 7 1.2 Você não está só! .............................................................................................................................. 8 1.3 Definição de termos ......................................................................................................................... 10 1.4 Projetos, programas e portfólios ...................................................................................................... 11 1.5 A arte e a ciência do gerenciamento de projetos ............................................................................ 14 1.6 O modelo de competência de gerenciamento de projeto PMD Pro ................................................ 14 Seção 2
: As fases na vida de um projeto de desenvolvimento ................................................... 18
2.1 Gerenciamento de projeto equilibrado através da vida do projeto .................................................. 18 2.2 O modelo de projeto por fases do PMD Pro.................................................................................... 19 2.2.1 Fase 1: Identificação e design do projeto ................................................................................ 22 2.2.1.1
Coleta de dados ............................................................................................................ 24
2.2.1.1.1
Identificação das necessidades do projeto ................................................................ 24
2.2.1.1.2
Tipos de dados ........................................................................................................... 26
2.2.1.2
Análise de dados .......................................................................................................... 29
2.2.1.2.1
Análise do estado atual .............................................................................................. 29
2.2.1.2.2 2.2.1.3
Análise do estado futuro .......................................................................................... 30
Identificação da lógica de intervenção do projeto ........................................................ 33
2.2.1.3.1
Variações da estrutura lógica do projeto .................................................................... 33
2.2.1.3.2
Interpretação da matriz de estrutura lógica ................................................................ 34
2.2.1.4
Gerenciamento das portas de decisão do projeto ........................................................ 40
2.2.2 Fase 2: Definição do projeto .................................................................................................... 43 2.2.2.1
Objetivo ......................................................................................................................... 43
2.2.2.2
Estabelecimento da estrutura de governança do projeto ............................................. 43
2.2.2.3
Autorização oficial para o início do projeto ................................................................... 46
2.2.2.4
Comunicação para o lançamento do projeto ................................................................ 47
Guia para o PMD Pro iv
2.2.3 Fase 3: Planejamento do projeto ............................................................................................. 49 2.2.3.1
Objetivo ......................................................................................................................... 49
2.2.3.2
O planejamento de implementação é equilibrado ........................................................ 51
2.2.3.3
O planejamento de implementação é abrangente ....................................................... 52
2.2.3.4
O planejamento de implementação é integrado ........................................................... 53
2.2.3.5
O planejamento de implementação é participativo ...................................................... 54
2.2.3.6
O planejamento da implementação é reiterativo .......................................................... 55
2.2.4 Fase 4: Implementação do projeto ........................................................................................... 57 2.2.4.1
O gerenciamento de problemas ................................................................................... 57
2.2.4.2
O gerenciamento de pessoas ....................................................................................... 59
2.2.4.3
O gerenciamento de controles internos ........................................................................ 60
2.2.5 Fase 5: Monitoramento, avaliação e controle do projeto ......................................................... 63 2.2.5.1
Diferenciação entre monitoramento, avaliação e controle ........................................... 64
2.2.5.2
O plano de monitoramento e avaliação do projeto ....................................................... 66
2.2.5.3
Abordagens de avaliação de projeto ............................................................................ 69
2.2.5.4
Controle do projeto ....................................................................................................... 70
2.2.5.5
Mudanças do projeto: Tolerâncias e transferência para o nível hierárquico superior ...... 70
2.2.6 Fase 6: Transição para o final do projeto ................................................................................ 75 2.2.6.1
Gerenciamento da estratégia da transição para o final do projeto .............................. 76
2.2.6.2
Verificação do escopo do projeto e da aceitação dos Resultados/Produtos ............... 78
2.2.6.3
Encerramento administrativo, financeiro e contratual completo ................................... 78
2.2.6.4
Cumprimentar os aprendizagems no final do projeto .................................................. 79
2.2.6.5
Celebração dos sucessos............................................................................................. 79
Seção 3
: Gerenciamento de Projeto. ................................................................................................... 81
3.1 Disciplina 1: Gerenciamento do escopo ......................................................................................... 81 3.1.1 Definição de produtos e escopo do projeto .............................................................................. 83 3.1.2 Ferramentas para a definição do escopo do projeto ................................................................ 83 3.2 Disciplina 2: Gerenciamento do tempo........................................................................................... 86 3.2.1 Definição e sequenciamento de atividades .............................................................................. 87 3.2.2 Estimativa de recursos de atividade ......................................................................................... 88 3.2.3 Estimativa de duração da atividade .......................................................................................... 89 Guia para o PMD Pro v
3.2.4 Desenvolvimento do cronograma ............................................................................................. 90 3.2.5 Gerenciamento do cronograma do projeto ............................................................................... 92 3.3 Disciplina 3: Gerenciamento de recursos do projeto ...................................................................... 95 3.3.1 Por que o gerenciamento eficaz de recursos é importante? .................................................... 95 3.3.2 Gerenciamento das finanças do projeto ................................................................................... 96 3.3.3 Criação de orçamentos ............................................................................................................. 97 3.3.4 Orçamentos baseados em atividades ....................................................................................... 98 3.3.5 Identificação de estimativas de custo ....................................................................................... 99 3.3.6 Monitoramento do desempenho financeiro do projeto ........................................................... 101 3.3.6.1
Monitoramento de custos de projeto através da análise do valor agregado.............. 102
3.3.7 Gerenciamento da cadeia de suprimento ............................................................................... 105 3.3.7.1
Gerenciamento dos serviços de abastecimento ........................................................ 106
3.3.7.1.1
Planejamento dos serviços de abastecimento ......................................................... 107
3.3.7.1.2
Identificação de fornecedores .................................................................................. 107
3.3.7.1.3
Seleção, negociação e concessão: .......................................................................... 108
3.3.7.2
Gerenciamento de logística ........................................................................................ 108
3.3.7.2.1
Gerenciamento de inventário e armazéns ............................................................... 108
3.3.7.2.2
Transporte de materiais ............................................................................................ 109
3.3.7.3
Gerenciamento de ativos ............................................................................................ 109
3.3.8 Gerenciamento de recursos humanos .................................................................................... 110 3.4 Disciplina 4: Gerenciamento de riscos ......................................................................................... 111 3.4.1 Identificação de riscos ............................................................................................................. 113 3.4.1.1
Definir as categorias de risco ................................................................................ 113
3.4.1.2
Identificar riscos específicos das categorias ...................................................... 114
3.4.2 Avaliação de Risco .................................................................................................................. 115 3.4.3 Resposta ao risco ................................................................................................................... 116 3.4.4 Controle e monitoramento de riscos ....................................................................................... 119 3.5 Disciplina 5: Gerenciamento da justificativa do projeto ................................................................ 119 3.5.1 Identificação das necessidades baseadas em ativos ou baseadas em problemas ............... 120 3.5.2 Mudando de problemas para uma estratégia de intervenção ................................................ 120 3.6 Disciplina 6: Gerenciamento das partes interessadas ................................................................. 124 Guia para o PMD Pro vi
3.6.1 Identificação dos interessados ................................................................................................ 124 3.6.2 Análise dos interessados ........................................................................................................ 126 3.6.3 Envolvimento dos interessados .............................................................................................. 129 3.6.4 Comunicação com os interessados ........................................................................................ 131 Seção 4
: Adaptação ao PMD Pro ..................................................................................................... 132
4.1 Princípios fundamentais da adaptação ......................................................................................... 132 4.2 Fatores a serem considerados na adaptação do PMD Pro .......................................................... 133 Seção 5
: ANEXOS ............................................................................................................................. 138
5.1 Anexo 1: Glossário de termos ...................................................................................................... 138 5.2 Anexo 2: Resultados da aprendizagem do PMD Pro ................................................................... 142 5.3 Anexo 3: Lista de referências ....................................................................................................... 160
Guia para o PMD Pro vii
INTRODUÇÃO MUDANDO O MUNDO ATRAVÉS DE PROJETOS "Como você sonha em mudar o mundo?" Você cavaria poços para fornecer água potável a pequenos vilarejos? Criaria micro bancos para tirar mulheres da pobreza? Protegeria um ecossistema em risco de extinção? Reabilitaria uma escola? Instalaria clínicas de saúde rurais para comunidades carentes? Distribuiria alimentos a quem tem fome? Não é de surpreender que poucas pessoas responderiam "Eu gerenciaria projetos!" Mesmo assim, enquanto milhões de trabalhadores de desenvolvimento mudam o mundo todos os dias através de atividades na agricultura, assistência de saúde, micro financiamentos, conservação, casas acessíveis, educação, infraestrutura e direitos humanos, todos eles compartilham algo em comum: Eles mudam o mundo através de projetos!! As organizações de desenvolvimento gerenciam o seu trabalho através de projetos. Os seus escritórios possuem equipes de responsáveis de projetos que gerenciam as equipes de projeto. Por sua vez, a equipe de projetos elabora propostas de projetos, desenvolve planos de projetos, implementa atividades de projetos, monitora o seu andamento e avalia o seu impacto. E o mais importante, as comunidades beneficiadas investem o seu tempo, energia e recursos nos projetos. Eles confiam que os projetos somarão as suas forças coletivas para reforçar as áreas de fraqueza relativa e para enfrentar os desafios que, de outro modo, seriam considerados fora de controle. No entanto, embora o sustento de centenas de milhões de pessoas dependa da capacidade das organizações de desenvolvimento de fornecer resultados de projeto de modo eficiente e eficaz,. O gerenciamento de projeto raramente é identificado como uma prioridade estratégica para essas organizações. Em geral as organizações de desenvolvimento tendem a se concentrar nas áreas programáticas técnicas de seus projetos. As organizações tendem a contratar especialistas programáticos (agrônomos, profissionais de saúde pública, economistas, etc.), que então recebem o pedido de gerenciar projetos e liderar as equipes de projetos. Esses especialistas programáticos tendem a ser muito adeptos da identificação dos protocolos de tratamento de doenças, da criação de currículos para escolas, projetar sistemas agrícolas aprimorados e analisar as causas raízes da pobreza. Não é tão comum entretanto, descobrir que eles têm uma extensa experiência e habilidades na área do gerenciamento de projetos. As estimativas dos projetos são precisas? Os riscos do projeto foram previstos e são totalmente controlados? Os planos de projetos são abrangentes e detalhados? O andamento do projeto é monitorado em todos os níveis? Os desafios do projeto foram identificados, monitorados e solucionados? E, todos os aspectos do projeto foram gerenciados proativamente por toda a vida útil do projeto? As mudanças sociais que o projeto deseja solucionar estão sendo alcançadas? O objetivo do Guia do PMD Pro é aprimorar a capacidade de gerenciamento de projetos dos profissionais de desenvolvimento. O Guia fornece um recurso contextualizado, equilibrado, abrangente e adaptável para ajudar a melhorar a eficiência e a eficácia dos projetos do setor de desenvolvimento. Guia para o PMD Pro 1
O Guia para o PMD Pro fornece uma introdução independente da exploração do gerente de projetos dentro do contexto do setor de desenvolvimento. Ele visa a um público que inclui:
Gerentes de projetos e integrantes da equipe novos no gerenciamento de projetos;
Os gerentes de projetos e integrantes da equipe novos no setor de desenvolvimento;
Os profissionais do setor de desenvolvimento que pretendem obter credenciais profissionais no gerenciamento de projetos;
Consultores/equipes contratadas trabalhando no setor de desenvolvimento.
COMO O PMD PRO É ORGANIZADO O Guia do PMD Pro é organizado em quatro seções: Seção um: Projetos do setor de desenvolvimento Os projetos permeiam a cultura das organizações de desenvolvimento. Assim, o gerenciamento de projetos é uma competência crítica para os profissionais de desenvolvimento. A seção um fornece uma visão geral introdutória e de alto nível dos projetos do setor, respondendo a perguntas como estas:
Por que os projetos são importantes?
Como definir projetos e gerenciamento de projetos?
Como os projetos se encaixam na cultura estratégica principal das organizações de desenvolvimento?
Quais são as funções/responsabilidades do gerente de projeto e da equipe de projeto?
Quais são as competências necessárias para ser um gerente de projetos bem-sucedido?
Seção dois: As fases da vida de um projeto de desenvolvimento No gerenciamento de projetos, como acontece muito na vida, o segredo do sucesso é o equilíbrio. A seção dois do Guia explora a importância do gerenciamento equilibrado de projetos por toda a vida do projeto. Após uma breve apresentação que introduz o conceito de fases da vida do projeto, a seção dois do Guia explora cada uma das seis fases na vida útil do projeto, incluindo:
Identificação e design do projeto
1
Planejamento do projeto
Implementação do projeto
Monitoramento, avaliação e controle do projeto
Transição para o final do projeto
Definição do projeto
1
Para o Guia do PMDPro, definição do projeto é equivalente ao Inicio do projeto, formalização do projeto, dar a “luz verde” ao projeto para começar.
Guia para o PMD Pro 2
Seção três: Instruções de gerenciamento de projetos Para ser bem-sucedidos, os gerentes de projeto do setor de desenvolvimento precisam criar um conjunto de instruções de gerenciamento de projetos que devem ser aplicadas durante toda a vida do projeto. A seção três explora as seis áreas de disciplina dos gerentes de projetos no setor de desenvolvimento, incluindo:
Gerenciamento do escopo
Gerenciamento do tempo
Gerenciamento de recursos do projeto
Gerenciamento de riscos
Gerenciamento da justificativa do projeto
Gerenciamento das partes interessadas
Seção 4: Adaptação ao PMD Pro O guia do PMD Pro NÃO é um modelo a ser aplicado indiscriminadamente a todos os projetos e por todas as organizações. É importante lembrar que cada organização de desenvolvimento é única. Além disso, dentro de uma única organização, os projetos variam consideravelmente em termos de valor, complexidade e risco. Mesmo em situações em que dois projetos parecem similares, os ambientes em que eles são implementados são imprevisíveis e as realidades de campo podem variar significativamente da situação prevista nos planos feitos apenas alguns meses antes. Reconhecendo que as organizações de desenvolvimento e seus projetos são únicos, a Seção 4 examina as abordagens que os gerentes de 2 projetos podem empregar para adaptar o PMD Pro para o contexto em que seus projetos funcionam.
OS CINCO PRINCÍPIOS DO GERENCIAMENTO DE PROJETOS DO SETOR DE DESENVOLVIMENTO Conforme os leitores se aprofundam no Guia do PMD Pro, encontrarão caixas de texto que se referem aos principais conceitos que o PMD Pro identifica como os "Cinco princípios do gerenciamento de projetos do setor de desenvolvimento". Cada caixa de texto fornece um episódio rápido, um estudo de caso ou uma observação que destaca a importância da incorporação dos princípios no design, planejamento e implementação de projetos de desenvolvimento. A Figura 1 fornece um resumo de cada um dos cinco princípios de gerenciamento de projeto do PMD Pro.
2
O guia vai utilizar Gestão e Gerenciamento, para se dirigir ao mesmo processo.
Guia para o PMD Pro 3
Figura 1: os cinco princípios de gerenciamento de projetos do PMD Pro Os cinco princípios do gerenciamento de projetos do setor de desenvolvimento
O gerenciamento do projeto é equilibrado! – Os projetos devem ser gerenciados de modo equilibrado, aplicando um rigor igual em todas as fases da vida do projeto. O gerenciamento do projeto é abrangente! - As instruções de gerenciamento de projeto devem ser aplicadas para gerenciar de modo consistente e sistêmico, todo o trabalho do projeto, em toda a sua vida. O gerenciamento do projeto é integrado! - Todos os aspectos do gerenciamento do projeto devem estar alinhados e ser coordenados como meio de garantir que todos os elementos de design, planejamento, monitoramento e implementação do projeto ocorram uniformemente. O gerenciamento do projeto é participativo! – Incluir uma grande variedade de interessados na identificação, design, planejamento, implementação e monitoramento do projeto ajuda a garantir transparência, aprimorar a qualidade, aumentar a capacidade humana e fortalecer a adesão em todos os níveis. O gerenciamento do projeto é reiterativo! – Revisitar e repetir os processos de gerenciamento de projeto em toda a vida do projeto para confirmar que seus designs, planos e resultados pretendidos ainda estejam relevantes. Essa prática também fornece a oportunidade de aprimorar a precisão das estimativas dos projetos existentes e planejar os próximos passos do projeto.
O PROGRAMA DE CERTIFICAÇÃO PMD PRO Em um setor que depende de projetos para concluir seu trabalho, uma certificação ajuda a garantir que os gerentes de projeto estejam prontos para gerenciar os seus projetos de maneira eficaz em todo o mundo. A PM4NGOs, a editora do Guia do PMD Pro, oferece um programa de certificação de três níveis para os profissionais de projeto que trabalham no setor de desenvolvimento. A figura 2 3 ilustra a estrutura e o conteúdo do Programa de Certificação do PMD Pro . Os três níveis de certificação do Programa de Certificação PM4NGOs incluem:
Guia para o PMD Pro 4
Certificação nível 1 – A certificação de nível 1 exige que o profissional de projetos conclua com sucesso o exame de certificação PMD Pro1. Esse exame de múltipla escolha e 75 questões é realizado pela Internet e exige que os candidatos demonstrem que conhecem e entendem o conteúdo do Guia do PMD Pro. Os objetivos de aprendizagem do exame do PMD Pro1 são encontrados no Anexo 2 do Guia do PMD Pro.
Figura 2:O programa de certificação PMD Pro
Certificação nível 2 – Existem dois objetivos da Certificação de nível 2 da PM4NGOs: 1. Fornecer uma credencial de gerenciamento de projeto contextualizada de segundo nível para o setor de desenvolvimento; e 2. Fornecer uma plataforma a partir da qual os profissionais de desenvolvimento possam começar a buscar uma qualificação profissional credenciada internacionalmente em gerenciamento de projetos. Com isso em mente, os candidatos da Certificação de nível 2 devem concluir duas qualificações: A Certificação PMD Pro2 – O exame do PMD Pro2 é realizado pela Internet e exige que o candidato demonstre sua habilidade em aplicar e analisar o conteúdo do Guia do PMD Pro. Cada pergunta do exame do PMD Pro2 baseia-se em situações de projeto de desenvolvimento e é planejada para testar os objetivos de aprendizagem do PMD Pro2 encontrados no Anexo 2 do Guia do PMD Pro. Uma qualificação de nível básico de uma entidade certificadora independente e reconhecida internacionalmente – Existem várias certificações profissionais de nível básico que dão aos profissionais do projeto uma credencial para verificar a sua proficiência no gerenciamento de projetos. Elas incluem a credencial CAPM do Project Management Institute, a credencial Prince2 Foundation da APMG, a certificação IPMD Nível D e mais. Os candidatos do nível 2 devem concluir (no mínimo) uma dessas certificações de nível básico. Não importa a certificação independente específica selecionada, o objetivo de obter uma qualificação independente e reconhecida internacionalmente é criar uma ponte entre o aprendizado contextualizado encontrado no PMD Pro e o extenso corpo de conhecimentos que existe entre os gerentes de projetos que trabalham em outros setores. Observação: não há nenhuma ordem necessária através da qual os certificados de Nível 2 devem ser recebidos. Entretanto, os candidatos do Nível 2 precisam já ter concluído a certificação PMD Pro Nível 1 antes de concluir a certificação PMD Pro2.
Guia para o PMD Pro 5
Certificação nível 3 A certificação nível 3 está em desenvolvimento e avaliará até que ponto o candidato do PMD Pro3 aplica o conteúdo do Guia do PMD Pro em seus projetos de desenvolvimento. Além disso, para concluir a certificação PMD Pro3 contextualizada, os candidatos de Nível 3 também devem continuar a desenvolver a sua carreira profissional através da busca de uma qualificação avançada de uma entidade certificadora independente e reconhecida internacionalmente. Elas são, entre outras, o PMP do Project Management Institute, a certificação Nível C do IPMA ou Prince2 Practitioner.
Guia para o PMD Pro 6
SEÇÃO 1 1.1
: PROJETOS DO SETOR DE DESENVOLVIMENTO
O GERENCIAMENTO DE PROJETOS É DESAFIADOR !
O gerenciamento de projetos no setor de
Figura 3: Riscos do projeto do setor de desenvolvimento www.projectcartoon.com
desenvolvimento é tudo, menos simples. Os ambientes operacionais são complexos. Os desafios são numerosos. Os relacionamentos de projeto são complicados. E o custo do erro é alto. Resumindo, existem vários fatores que podem dar errado! Este gráfico serve como uma ilustração de apenas alguns dos vários desafios que poderiam ameaçar o sucesso dos projetos de desenvolvimento. Cada imagem identifica apenas uma das várias situações que poderiam aparecer se o design, o planejamento ou a implementação do projeto for concebido ou implementado de maneira inadequada. Infelizmente, a lista de desafios apresentada na Figura 2 não está completa. Existem vários outros fatores que podem "dar errado" em projetos de desenvolvimento. Por exemplo, "As taxas de câmbio estão estáveis?" "A dinâmica da equipe está funcional?" "Os sistemas de monitoramento fornecem informações úteis, precisas e oportunas?" "Os fornecedores do projeto são confiáveis?" "Existe instabilidade política?" “Existe algum interessado que esteja enfraquecendo o projeto?” Para ter sucesso, o gerente de projetos deve gerenciar proativa e decisivamente esses desafios. Muito frequentemente os projetos fracassados são indicados como vítimas das circunstâncias que estavam "fora de controle". Embora essa explicação possa ser válida algumas
Guia para o PMD Pro 7
vezes, muito frequentemente ela é usada como uma desculpa e deixa de reconhecer que os riscos poderiam ter sido melhor previstos, analisados e gerenciados ativamente. Para manter o controle de seus projetos - e portanto promover o seu sucesso - os gerentes de projeto precisam desenvolver as habilidades necessárias para identificar proativamente os desafios que podem impactar seu projeto e gerenciá-los efetivamente mesmo quando surgirem esses desafios. Essas também são as habilidades que exploraremos no Guia do PMD Pro.
1.2
V OCÊ NÃO ESTÁ SÓ !
Embora os desafios que confrontam os projetos de desenvolvimento sejam extensos e complexos, não são de nenhum modo exclusivos dos projetos gerenciados no setor de desenvolvimento. Considere, por exemplo, as informações fornecidas no gráfico e a tabela correspondente (Figura 4). Todos os anos o Standish Group realiza uma pesquisa intitulada Chaos Report, que coleta respostas de mais de 10.000 projetos de tecnologia da informação (TI). O relatório identifica a porcentagem dos projetos de TI avaliados como "bem-sucedidos", 4 "deficientes" ou "fracassados". Ano após ano, os resultados do Chaos report indicam que a maioria dos projetos de TI pesquisados pelo Standish Group são avaliados Figura 4: Resultados do projeto de Chaos Report como "deficientes" ou "fracassados" e apenas uma porcentagem relativamente pequena é considerada como "bem-sucedida". Em 2008, por exemplo, a porcentagem de projetos não qualificados como bem-sucedidos foi de 32%; deficientes (definidos como projetos abandonados no meio) foi de 24% e os 44% dos projetos restantes foram concluídos mas "deficientes" devido a custos ultrapassados, atrasos do calendário e/ou falha ao entregar todos os produtos ou serviços do projeto.”
4
"Bem-sucedidos" - Os projetos terminam dentro do escopo, do orçamento e do prazo. “Deficientes” – Os projetos são concluídos mas deixam de atender o escopo, o orçamento ou o calendário originais. “Fracassados” – Os projetos são encerrados precocemente.
Guia para o PMD Pro 8
É importante reconhecer que o Chaos Report não trata de projetos de desenvolvimento. A pesquisa foi desenhada e implementada por uma empresa de serviços de gerenciamento de projeto para estudar os resultados dos projetos de TI. Entretanto, os resultados do relatório são úteis visto que ressaltam os desafios de entregar projetos bem-sucedidos e fornecem dados que nos ajudam a responder a principal pergunta: "Quais são os principais problemas que resultam em projetos deficientes e fracassados?" De acordo com a análise do Chaos Report de 2009, existem três problemas que resultam frequentemente em projetos deficientes. 1. Requisitos e especificações incompletas; 2. Falta de planejamento de contingência para o gerenciamento de riscos; e 3. Falha em aprender com os erros. Isso soa familiar? O que chama a atenção na análise de projetos deficientes do setor de TI é a similaridade que os problemas têm com os problemas do setor de desenvolvimento. No final, apesar das várias diferenças entre os setores que gerenciam seu trabalho principalmente através de projetos (por exemplo, construção, telecomunicações, tecnologia da informação, desenvolvimento de software e mais), eles também compartilham desafios similares, incluindo: 1. Alcançar os resultados do projeto dentro dos limites de prazo, orçamento, qualidade, escopo, risco e benefício; 2. Desenvolver planos de projetos completos e detalhados e gerenciá-los por toda a vida útil do projeto; 3. Gerenciar os projetos que são frequentemente implementados através de empreiteiros, empresas subcontratadas e fornecedores; e 4. Identificar os riscos potenciais e criar processos para evitar e enfrentar esses riscos e garantir que os benefícios pretendidos do projeto sejam alcançados. Entretanto, embora haja similaridades entre esses setores, existem algumas características que tornam o gerenciamento de projetos único no setor de desenvolvimento e, às vezes, especialmente desafiador. Algumas dessas características exclusivas incluem:
Os projetos de desenvolvimento são responsáveis não apenas por fornecer produtos tangíveis, mas também fornecer resultados menos tangíveis para promover a mudança social e/ou a mudança de comportamento. Os projetos de desenvolvimento têm menos probabilidade de se concentrar no fornecimento de produtos concretos como objetivo máximo. Em vez disso, eles consideram esses produtos como um meio que leva a melhorias no bem-estar das populações alvo do projeto.
Os projetos de desenvolvimento visam a solucionar problemas complexos de pobreza, desigualdade e injustiça.
Os projetos de desenvolvimento tendem a operar em contextos excepcionalmente desafiadores (recursos limitados, altos riscos, redes complexas de obtenção de produtos, ambientes instáveis política e financeiramente, condições inseguras).
Guia para o PMD Pro 9
1.3
A implementação do projeto frequentemente é gerenciada através de um conjunto complexo de relacionamentos de interessados (agências parceiras, ministérios do governo, organizações comunitárias, empreiteiros, consórcios globais).
A abordagem do projeto frequentemente é tão importante quanto o objetivo propriamente dito (inclusive uma alta prioridade colocada nas abordagens de participação e baseadas em direitos).
A transferência de conhecimentos e aprendizagem para a população alvo é prioridade durante cada uma das fases do projeto.
D EFINIÇÃO DE TERMOS
Porém estamos nos adiantando demais. Antes de qualquer outra discussão sobre os desafios relacionados com o gerenciamento de projetos do setor de desenvolvimento, é importante definir primeiro alguns termos-chave. Um projeto é um empreendimento temporário assumido para criar um produto, serviço ou resultado 5 exclusivo. Com base nessa definição, o propósito do gerenciamento de projetos é planejar, organizar e gerenciar recursos para viabilizar a execução bem-sucedida dos objetivos, resultados e produtos do projeto. As práticas de gerenciamento de alta qualidade e abrangentes são indispensáveis para ajudar as organizações a gerenciar projetos com foco, eficiência e eficácia. Dentro do contexto de gerenciamento de projetos, o gerente de projetos é responsável por assegurar o sucesso total do projeto. E mesmo assim, embora o gerente de projetos seja responsável pelo seu sucesso, isso não significa, entretanto, que o gerente de projetos é responsável pessoalmente pela execução do trabalho do projeto. De fato, este raramente é o caso do setor de desenvolvimento. Em vez disso, a responsabilidade do gerente de projetos é trabalhar lado a lado com um conjunto de interessados para concluir o trabalho. 6 Esses interessados - inclusive os integrantes da equipe de projeto, de organizações de implementação, , grupos da comunidade e outros - devem trabalhar juntos para desenhar, implementar e controlar todos os aspectos do projeto. Como muitos setores, os gerentes de projetos do setor de desenvolvimento frequentemente precisam gerenciar os interessados com quem não têm nenhum relacionamento hierárquico formal. É comum que os interessados em um só projeto tenham diferentes etnias, idiomas, culturas e até mesmo nacionalidades. O desafio de gerenciar grupos nesse contexto pode ser especialmente difícil.
5
Um guia do corpo de conhecimentos de gerenciamento de projeto (Guia PMBOK), Terceira Edição, Project Management Institute. 6
O PMDPro1 utiliza o termo “Organizações de implementação” do mesmo jeito que os Parceiros Locais, Contrapartes, Organizações locais, Organizações associadas, etc.
Guia para o PMD Pro 10
Na prática, o desafio do gerente de projetos em alcançar o objetivo com sucesso sempre ocorrerá no contexto dos limites do projeto. Historicamente, há três elementos principais que limitam um projeto, que são chamados coletivamente de Triângulo de Gestão. Para entender o Triângulo de Gestão, imagine um triângulo em que cada lado está rotulado da seguinte forma: Escopo/Qualidade – Quais são os produtos/serviços que o projeto produzirá e qual é o trabalho necessário para produzir eles? Custo/Recursos – Qual é o dinheiro, materiais e esforço disponíveis para entregar os produtos/serviços do projeto e concluir o trabalho completo do projeto? Tempo/Cronograma – Qual é o tempo necessário para concluir os componentes do projeto?
Figura 5: O Triângulo de Gestão de projeto 7
O trabalho do gerente de projetos é garantir que o Triângulo de Gestão permaneça equilibrado. Cada um dos limites está conectado aos outros. Sempre que um desses limites for restringido ou estendido, os outros limites também precisarão ser estendidos/aumentados ou restringidos/reduzidos. O gerente de projetos precisa entender o relacionamento e as trocas que existem entre cada um dos limites. As três classificações básicas dos limites são: Inflexível – indicando que o limite é crítico e deve ser respeitado Adaptável – indicando que o limite é negociável, mas deve ser otimizado ao máximo possível Flexível – indica limites que podem ser flexíveis para gerenciar outro limite inflexível ou otimizar outro limite adaptável Ao esclarecer a classificação de cada um dos limites, o gerente de projetos pode entrar em discussões com os interessados no projeto para estabelecer prioridades. É importante que as prioridades sejam estabelecidas e acordadas por todos os interessados no início do projeto. Tentar negociar essas trocas após o lançamento do projeto é uma tarefa difícil ou impossível. Quando as pessoas solidificam o seu ponto de vista sobre as trocas com tarefas agendadas e recursos nomeados, o esforço para alterar essas trocas se torna muito mais difícil.
1.4
7
P ROJETOS , PROGRAMAS E PORTFÓLI OS
Vai se conhecer também como o Triângulo de limite triplo ou tríplice restrição
Guia para o PMD Pro 11
No dicionário do desenvolvimento, os termos 'projetos, programas e portfólio' são usados frequentemente, porém nem sempre com rigor ou precisão. Algumas vezes os termos são usados até mesmo um no lugar do outro. Na ausência de uma definição consistente e precisa desses termos, as funções e responsabilidades do gerente de projetos relacionados a cada um desses níveis de gerenciamento podem ficar obscuros ou sujeitos a interpretações errôneas. Gerenciamento de projeto é a disciplina de planejamento, organização, e gerenciar recursos para gerar a entrega bem-sucedida do objetivo , dos resultados e dos produtos do projeto. O principal desafio do gerenciamento de projetos é alcançar todos os objetivos, resultados e produtos do projeto, honrando os limites preconcebidos do projeto e relacionados ao escopo, orçamento, cronograma e qualidade. Gerenciamento de programa é o processo do gerenciamento de um grupo de projetos relacionados de modo coordenado para se obter os benefícios e o controle não disponíveis através do gerenciamento individual dos projetos. Os programas, ao contrário dos projetos, frequentemente são gerenciados através de um gerenciamento centralizado com vistas a coordenar um grupo de projetos para alcançar os objetivos e benefícios estratégicos do programa. O gerenciamento de programa é especialmente importante no setor de desenvolvimento porque os projetos gerenciados através de um programa coordenado têm o potencial de realizar mudanças (ou benefícios) que seriam impossíveis se fossem gerados separadamente. Algumas áreas de alinhamento potencial de programa incluem:
Área geográfica – Os projetos frequentemente funcionam lado a lado na mesma região em todo o país e uma das principais preocupações de um gerente de programa será como os recursos de vários projetos em andamento na mesma área geográfica podem ser aproveitados para causar um impacto maior do que cada um deles teria isoladamente. Muito frequentemente, os programas funcionam em um único país, apesar de ser cada vez mais comum encontrar programas com vários países ou globais no escopo.
Áreas de intervenção do setor – Embora os projetos tendam geralmente a funcionar em um setor único dentro de um prazo mais curto, os programas frequentemente englobam vários setores e trabalham dentro de um prazo maior.
Objetivos – Ao coordenar as metas e objetivos de vários projetos através de um programa coordenado, uma organização tem um potencial maior de atingir os seus objetivos de níveis mais altos.
Financiamento – Frequentemente uma única organização pode gerenciar vários projetos com fundos do mesmo doador institucional. Nessa situação, existe a oportunidade de coordenar esses projetos com um contexto de um único programa, o que pode gerar economia de escala.
Populações alvo – As organizações frequentemente se sobrepõem entre as populações-alvo para projetos em diferentes setores (saúde, água, educação, etc.). A coordenação desses projetos através de uma abordagem baseada em programas permite que a organização os vincule através de indicadores comuns, recursos e processos compartilhados que auxiliam as comunidades a avaliar continuamente se as organizações estão realizando as intervenções “corretas”.
Gerenciamento – Embora as equipes de projetos individuais se concentrem na implementação das atividades que contribuem diretamente com o rendimento e com os resultados dentro do
Guia para o PMD Pro 12
escopo, no nível do programa os gerentes se concentram no desafio da integração de vários projetos, melhor aproveitamento dos recursos e aumento do impacto do programa. O gerenciamento do portfólio supervisiona o desempenho da coleção de projetos e programas da organização. Os portfólios geralmente são gerenciados por uma equipe sênior no mais alto nível de uma organização ou por uma unidade específica de uma organização (escritório regional ou matriz). O gerenciamento de portfólio não se preocupa com as tarefas de áreas do projeto, mas se concentra, em vez disso, na seleção, iniciação e gerenciamento de todos os projetos, coletivamente, de modo a tratar 8 dos objetivos estratégicos da organização. O gerenciamento de portfólio inclui frequentemente a escolha de quais projetos não fazer, quais começar mais cedo ou quais parar de fazer para otimizar a adaptação estratégica dos projetos que estão sendo assumidos para cumprir a missão da organização. Mais frequentemente, o portfólio não é responsabilidade do gerente de projeto. Entretanto, isso não significa que as equipes de projeto não precisem se preocupar, elas mesmas, com problemas relacionados ao gerenciamento do portfólio. Os recursos disponíveis para investir em projetos frequentemente são limitados ou escassos e várias partes da organização podem competir para obter esses recursos. O processo de gerenciamento de portfólio tenta, portanto, priorizar e equilibrar as oportunidades e os riscos de acordo com a demanda e fornecer os recursos de modo que os objetivos da organização sejam alcançados. Dada essa competição por recursos limitados, os gerentes de projetos e suas equipes devem ser capazes de articular onde seus projetos:
Apoiam a estratégia da organização
Agregam valor para os programas e/ou portfólios da organização.
Figura 6: Relacionamento entre projetos, programas e portfólios
8
Um portfólio, por sua vez, tem a opção de incluir subportfólios de iniciativas e atividades agrupadas e gerenciadas juntas. Esses sub portfólios podem ser agrupados por área programática (saúde, educação, agricultura, etc.) ou de acordo com a região geográfica em que operam.
Guia para o PMD Pro 13
1.5
A ARTE E A CIÊNCIA DO GERENCIAMENTO DE PROJETOS
Quantos de nós conhecemos um gerente de projetos que não é muito experiente? Esse frequentemente é o gerente com excelentes habilidades no gerenciamento de projetos, mas tem medo ou é incapaz de colaborar com a equipe ou com os interessados no projeto. Por exemplo, esse gerente de projeto pode ser um mago com planilhas eletrônicas, organizando com destreza o trabalho e planejando situações futuras, porém não se sente à vontade para se comunicar. Como resultado a equipe do projeto fica perdida e os interessados, desejosos de liderança e comunicação. Essa situação naturalmente levanta uma questão: “O que é um gerenciamento de projeto forte?” É uma arte ou uma ciência? Ele requer habilidades “artísticas” mais sensíveis em relação às interações e ao comportamento humano ou é uma coleção de habilidades “científicas” que se concentram no gerenciamento técnico de entradas e saídas?” A resposta, não surpreendentemente, é “ambos”. No gerenciamento de projetos, como muito acontece na vida, o segredo do sucesso é o equilíbrio. A arte do gerenciamento de projetos se concentra no elemento humano. A arte do gerenciamento de projetos requer habilidades que permitam que os gerentes de projetos liderem, habilitem, motivem e se comuniquem. O gerente de projetos com arte pode dirigir a equipe quando os desafios do trabalho mudam, realinhar as prioridades quando a realidade do campo muda, resolver conflitos quando surgirem e determinar que informações deve comunicar quando e para quem. A ciência do gerenciamento de projetos se concentra no planejamento, na estimativa, na medição e no controle do trabalho. A ciência engloba as perguntas quem-faz-o-quê-quando?
Onde estamos nesse projeto?
Qual é o custo previsto do projeto?
Que recursos precisam ser gerenciados ativamente?
Existe algum risco que ameaça o projeto?
Quando o projeto será concluído?
Um elemento chave para um projeto bem-sucedido é identificar um gerente de projeto equilibrado que se sinta à vontade tanto com a arte quanto com a ciência do gerenciamento de projetos.
1.6
O MODELO DE COMPETÊNCIA DE GERENCIAMENTO DE PROJETO PMD P RO
Embora a classificação das habilidades de gerenciamento de projeto em categorias como “arte” e “ciência” seja útil, é apenas a primeira etapa na identificação das características de um gerente de projetos bem-sucedido. Um modelo de competência de gerenciamento de projeto mais abrangente ajudará a identificar as habilidades necessárias dos gerentes de projeto e poderá servir como uma ferramenta para avaliar os níveis de habilidade, identificar áreas que podem ser aprimoradas e mapear áreas para o
Guia para o PMD Pro 14
desenvolvimento de carreiras. Embora existam modelos de competências múltiplas para gerentes de projetos, o modelo PMD Pro organiza as competências de gerenciamento de projetos em quatro áreas:
Técnica – essa é frequentemente chamada como ‘ciência’ por trás do gerenciamento de projeto. O gerente de projetos pode identificar, selecionar e empregar as ferramentas e processos corretos para garantir o sucesso do gerenciamento de projetos?
Liderança/Interpessoal – frequentemente chamada de ‘arte’ do gerenciamento de projeto. Por exemplo, como o gerente de projeto se comunica, inspira e soluciona conflitos?
Pessoal/Autogerenciamento – a habilidade do gerente de projetos de se autogerenciar. Por exemplo, o gerente de projeto pode definir prioridades com eficiência, gerenciar o tempo e organizar o trabalho?
Desenvolvimento específico do setor – a capacidade de usar as competências técnicas, liderança/interpessoal e pessoal/autogerenciamento no contexto dos projetos de desenvolvimento. Por exemplo, o gerente de projetos pode identificar, selecionar e empregar as ferramentas e processos corretos que são exclusivos e específicos do setor de desenvolvimento?
Além dessas quatro áreas gerais de competência, os gerentes de processo também devem possuir a competência de trabalhar com eficiência dentro da cultura de sua própria organização. O gerente de projetos consegue navegar pela estrutura de gerenciamento, cultura organizacional, sistemas/processos e redes de recursos humanos específicos de sua organização? A cultura da organização define sua identidade (marca) e a distingue de outras organizações que gerenciam projetos similares.
Guia para o PMD Pro 15
Figura 7: elementos ilustrativos das quatro áreas de competência Competência Pessoal técnico
Elementos ilustrativos
Liderança/ Interpessoal
Pessoal/Autogerenciamento
Específicos do desenvolvimento
Gerenciar o escopo proativamente Identificar todas as atividades necessárias para o sucesso do projeto Gerenciar o cronograma geral para garantir que o trabalho seja feito dentro do prazo Definir e coletar indicadores para medir o andamento do projeto Identificar, acompanhar, gerenciar e resolver problemas do projeto Disseminar proativamente as informações do projeto para todos os interessados Identificar, gerenciar e minimizar os riscos do projeto Definir sistemas logísticos Garantir que os resultados/produtos do projeto sejam de qualidade aceitável Visão panorâmica de um projeto dentro do portfólio de uma organização Promover o projeto (estimulando a adesão) Comunicar a visão – definindo expectativas aceitáveis e desafiadoras Fornecer retorno de desempenho oportuno e útil para os integrantes da equipe Facilitar um ambiente produtivo da equipe Comunicar proativamente (verbal e por escrito), incluindo escuta ativa Motivar os integrantes da equipe a seguir a direção e alcançar os objetivos com boa vontade Habilidades organizacionais Atenção a detalhes Habilidade à multitarefa Raciocínio lógico Raciocínio analítico Autodisciplina Gerenciamento do tempo Entender os valores e paradigmas do setor de desenvolvimento Entender os diferentes interessados envolvidos em projetos de desenvolvimento Entender e navegar em ambientes de desenvolvimento complexos Trabalhar efetivamente com um conjunto de parceiros de implementação Lidar com as pressões exclusivas e os ambientes de desenvolvimento Manifestar sensibilidade cultural
Como era de se esperar, o nível de habilidade que um gerente de projetos precisa em cada uma dessas áreas de competência varia de modo correspondente ao tamanho, complexidade e risco do projeto. Entretanto, apesar de suas diferenças, todos os projetos se beneficiariam de uma abordagem baseada no projeto para garantir que:
as atividades sejam totalmente identificadas, priorizadas e sequenciadas; o cronograma seja detalhado e identifique os elementos inter-relacionados do plano do projeto; os processos de obtenção (de materiais e empreiteiros) sejam identificados e implementados; as normas de comunicação para os interessados adequados estejam em vigor e sejam executadas; existam sistemas de pessoal para a equipe, voluntários e parceiros de implementação;
Guia para o PMD Pro 16
os riscos sejam antecipados e monitorados; um sistema esteja em vigor para garantir que os projetos atendam normas aceitáveis de qualidade; um processo de gerenciamento de mudança esteja em vigor e que seja gerenciado.
Como as responsabilidades dos gerentes de projetos aumentam de projetos relativamente simples para projetos mais complexos, os requisitos de conhecimentos, habilidades e comportamentos em cada uma dessas áreas de competência precisará aumentar proporcionalmente. Além disso, uma das habilidades mais variadas que os gerentes de projetos desenvolvem com o tempo é a arte de saber quais alternativas existem para enfrentar um desafio (estouro de orçamento, conflitos de equipes, papéis ambíguos, mudanças de cronograma, riscos não previstos) e identificar qual competência (ferramenta/habilidade/processo) seria mais adequada para atender as necessidades exclusivas de cada situação. Apesar das quatro áreas de competência do gerenciamento de projetos serem críticas para garantir o sucesso do projeto, o escopo do Guia do PMD Pro se concentra especificamente na área de competência técnica dos gerentes de projetos. As seções 2 a 4 do Guia se concentram nos processos, ferramentas e mecanismos que podem ser usados para fortalecer o design, planejamento, implementação, monitoramento, controle e encerramento dos projetos. É indiscutível que os gerentes de projetos também devem trabalhar para fortalecer suas competências pessoais, interpessoais e desenvolvimento de competências específicas do setor; entretanto, não é o objetivo deste documento abordar extensamente sobre essas áreas de desenvolvimento profissional.
Guia para o PMD Pro 17
SEÇÃO 2 2.1
: AS FASES NA VIDA DE UM PROJETO DE DESENVOLVIMENTO
G ERENCIAMENTO DE PROJ ETO EQUILIBRADO ATRAVÉS DA VIDA DO PROJE TO
Para que os projetos de desenvolvimento tenham sucesso, é essencial que o conjunto inteiro de competência de gerenciamento de projetos seja aplicado de modo equilibrado durante toda a vida do projeto. Para isso, muitas organizações de desenvolvimento criaram diagramas de ciclo de vida do projeto que elas utilizam para identificar as fases através das quais os projetos passam desde o início até o fim. Juntas, essas fases do ciclo de vida do projeto identificam a sequência lógica das atividades que alcançam as metas e objetivos do projeto. Figura 8: Ciclo de vida do projeto FAO A Figura 8, por exemplo, representa o design do ciclo de vida da Organização das Nações Unidas para Alimentação e Agricultura (FAO). Nesse caso, o ciclo de vida do projeto é representado por uma série de circuitos interconectados. No entanto, essa é apenas uma abordagem que as organizações de desenvolvimento empregam para comunicar seus desenhos de ciclo de vida de projetos. Outras organizações de desenvolvimento adotaram os ciclos de vida de projetos representados por outros desenhos, incluindo modelos circulares, modelos lineares ou modelos espirais modificados. A sequência exata e o modo de expressar os diagramas de ciclo de vida de projetos podem variar consideravelmente entre setores e organizações diferentes; entretanto, seus objetivos são os mesmos. Ao agrupar atividades em uma sequência de ciclo de vida de projetos, o gerente de projetos e a equipe principal podem:
Definir as fases que conectam o início de um projeto ao seu fim
Identificar o processo que as equipes de projeto devem implementar ao percorrerem as fases do ciclo de vida do projeto
Ilustrar como o ciclo de vida do gerenciamento de projeto pode ser usado como modelo do gerenciamento de projetos
Fazer um modelo de como os projetos funcionam dentro de um ambiente de ‘limites’ onde as alterações de qualquer limite resultará em alterações aos outros parâmetros do projeto.
Guia para o PMD Pro 18
2.2
O MODELO DE PROJETO POR FASES DO PMD P RO
Ao reconhecer que existem vários diagramas de ciclo de vida de projeto entre as organizações do setor de desenvolvimento, o PMD Pro apoia seu próprio modelo de projeto por fases de seis etapas (Figura 9). O modelo de projeto por fases do PMD Pro não visa a substituir nenhum modelo de ciclo de vida específico nem servir como um padrão para o setor. Em vez disso, seu objetivo é fornecer um modelo de projeto por fases equilibrado e abrangente que cubra a vida inteira do projeto.
Figura 9: O modelo de Projeto por Fases do PMD Pro O modelo de projeto por fases PMD Pro foi desenhado com a intenção de assegurar que o modelo seja equilibrado e completo. O equilíbrio e a abrangência do modelo do projeto são especialmente importantes dentro do contexto do setor de desenvolvimento. Frequentemente, as organizações de desenvolvimento põem ênfase especialmente forte no design, monitoramento e avaliação (DM&E) do projeto; mas essa ênfase algumas vezes obscurece a importância de outras fases na vida do projeto. Obviamente é necessário um DM&E forte. Entretanto, isso não é suficiente para garantir o sucesso do projeto. Um projeto deve não apenas investir em um DM&E forte e coerente, mas também se comprometer em investigar níveis similares de recursos e esforços em todas as fases da vida do projeto. No modelo de projeto por fases PMD Pro, por exemplo, as atividades de monitoramento, avaliação e controle do projeto estão presentes continuamente na vida do projeto. Entretanto, eles são apenas um componente das seis fases do modelo do projeto que inclui: Design e identificação do projeto: é durante essa fase que as equipes de projeto definem necessidades, exploram oportunidades, analisam o ambiente do projeto e criam alternativas para o design do projeto. As decisões tomadas durante a fase de Design e identificação do projeto definem a estratégia e a estrutura operacional dentro da qual o projeto funcionará subsequentemente.
Guia para o PMD Pro 19
9
Implementação do projeto – O trabalho diário de implementação do projeto é liderar e gerenciar a aplicação do plano de implementação do projeto: Liderar a equipe, resolver problemas, gerenciar a equipe do projeto e integrar os elementos diferentes do plano do projeto de modo criativo. Monitoramento, avaliação e controle do projeto – Essa fase se estende por toda a vida do projeto e mede continuamente seu andamento e identifica as ações corretivas adequadas em situações em que o desempenho do projeto se desvia significativamente do plano.
O gerenciamento do projeto é reiterativo
Definição do projeto – é durante essa fase que o projeto é oficialmente autorizado e os seus parâmetros gerais são definidos e comunicados aos principais interessados do Portas de decisão projeto. Também é durante essa fase que a equipe do projeto estabelece a estrutura de Conforme o projeto progride pelas seis fases, é governança de projetos de alto nível. recomendado que a equipe do projeto revisite a justificativa e o planejamento dele através de uma Planejamento do projeto – começando série de portas de decisão formais (representada com os documentos desenvolvidos nas fases pelos triângulos do modelo de fase de projeto anteriores do projeto, durante a fase de PMD Pro). planejamento a equipe desenvolve um plano 10 Em cada porta de decisão, a equipe do projeto de implementação abrangente e detalhado tem a oportunidade de decidir se a justificativa que fornece um modelo para todo o trabalho inicial do projeto é válida, se qualquer outra do projeto. Esse plano é revisitado por toda mudança maior é necessária ou se os a vida do projeto e atualizado (se necessário) investimentos do projeto precisam ser totalmente para refletir os contextos de mudança do interrompidos. projeto. Todo projeto e organização terá uma abordagem diferente para as portas de decisão. As portas de decisão usadas mais frequentemente tendem a ser aquelas encontradas nas primeiras fases do projeto. Isso inclui propostas preliminares do projeto que englobam os documentos de entrada para decidir se se deve seguir em frente com projetos em potencial. Entretanto é aconselhável incluir portas de decisão também nas últimas fases do projeto. Durante a fase de implementação, por exemplo, é útil verificar que a necessidade que o projeto visa a atender ainda existe, que a lógica da intervenção ainda é válida e que os planos de implementação ainda estão precisos.
Transição para o final do projeto - Essa fase inclui a implementação de todas as atividades de transição que precisam ocorrer no final do projeto,
9
O Guía PMDPro1 utiliza o termo “Definição do Projeto” para identificar a etapa de Começo Formal, Início do Projeto, Iniciação do projeto, Formalização. Então podem se utilizar esses termos para chamar à mesma etapa. 10
Pode se conhecer também com o termo “Execução”
Guia para o PMD Pro 20
inclusive (mas sem se limitar a) a confirmação de resultados/produtos com beneficiários, a coleta das lições aprendidas e a complementação das atividades de encerramento administrativo, financeiro e contratual. Embora o modelo de Projeto por Fases do PMD Pro dê a impressão de que as fases são distintas e sequenciais, na prática elas interagem e se sobrepõem. Por exemplo:
Já na fase de Identificação e Design do projeto, está sendo executado um trabalho extenso para preparar os elementos do planejamento para a implementação do projeto;
Durante a fase de Definição do projeto, serão estabelecidos sistemas que guiarão as atividades da fase de monitoramento, avaliação e controle.
Em toda a fase de implementação, ocorrerão atividades que posicionarão o projeto para o encerramento eficiente quando chegar a fase de transição para o final do projeto.
Embora seja geralmente verdade que certas fases do projeto ocorrem apenas depois de outras serem concluídas – obviamente, a transição para o final do projeto ocorrerá após o design do projeto – algumas fases ocorrem concomitantemente. Por exemplo, como o gráfico da Figura 10 ilustra, uma quantidade considerável de trabalho é investida no planejamento do projeto mesmo antes que ele seja definido formalmente. De modo similar, as atividades de transição para o final do projeto começam algum tempo antes da conclusão da implementação do projeto. Figura 10: Interações de Projeto por Fases
Guia para o PMD Pro 21
2.2.1 FASE 1: IDENTIFICAÇÃO E DESIGN DO PROJETO
Figura 11: A fase de identificação e 11 design do projeto
O gerenciamento do projeto é participativo!
Todos os projetos começam com uma ideia – uma necessidade ou oportunidade que é avaliada, analisada e, por último, desenvolvida em um projeto gerenciado pelos ciclos de vida do projeto. É durante esse processo que começamos a responder a pergunta crítica ‘Estamos fazendo o projeto correto?’ Se você entender algo errado aqui, o projeto permanecerá errado por um bom tempo – mesmo que todo o trabalho do projeto seja planejado e bem implementado . Entenda bem e você terá trilhado a metade do caminho.
Consulte os interessados cedo (e frequentemente) A fase de identificação e design do projeto fornece uma oportunidade precoce no ciclo de vida do projeto para que se comece a criar a norma de participação. Embora as abordagens participativas do design e do desenvolvimento do projeto possam requerer mais tempos e recursos, os resultados máximos se beneficiarão das seguintes vantagens:
Os interessados têm a oportunidade de assumir o controle de seu próprio processo de desenvolvimento; O design do projeto será mais forte; e Aumenta o domínio do projeto entre os interessados.
Em vários setores que contam com uma cultura de gerenciamento de projeto, o projeto começa oficialmente com a aprovação oficial. Este geralmente não é o caso dos setores de desenvolvimento em que a vida do projeto começa mais comumente com a fase de Identificação e design do projeto.
11
Utiliza-se também o termo “Desenho”
Guia para o PMD Pro 22
Durante a fase de Identificação e design do projeto, são investidos tempo/recursos/esforços para definir as necessidades, explorar oportunidades, analisar o ambiente do projeto, cultivar relacionamento, gerar confiança, criar parcerias e alternativas de design para o projeto. As decisões tomadas durante a fase de Identificação e design do projeto se conectam às estratégias existentes e determinam a estrutura geral dentro da qual o projeto se desenvolverá subsequentemente. Uma das razões da fase de Identificação e design do projeto ser tão importante é porque ela fornece a oportunidade mais econômica para responder a perguntas fundamentais sobre os parâmetros do projeto. Conforme ilustrado na Figura 12, o momento mais fácil de fazer alterações em um projeto é no início de sua vida. Se uma equipe de projeto quiser alterar os objetivos, o calendário ou o orçamento, é mais fácil fazer isso ANTES que o projeto esteja em andamento (gastando dinheiro, esgotando o calendário e investindo recursos para concluir o trabalho). Conforme o projeto avança no seu ciclo de vida haverá outras oportunidades para revisitar questões do escopo/qualidade, orçamento/recursos e tempo/calendário. Entretanto, quando a implementação do projeto começa (a equipe é contratada, as atividades se iniciam, os orçamentos são alocados e as resultados/produtos começam a se tornar tangíveis) o custo da mudança desses parâmetros de projeto aumenta e essas alterações, por sua vez, tornam-se muito mais difíceis de gerenciar. Portanto, é importante que o gerente de projetos reúna e processe os dados para informar essas decisões durante a fase de Identificação e design do projeto e que a abordagem geral para essa fase seja a que é aberta à exploração criativa, tempestade de ideias, visão e debate de estratégia.
Figura 12: Oportunidade para gerenciar as mudanças de modo eficaz Embora existam várias atividades que possam ser concluídas durante essa fase, em termos gerais o trabalho concluído durante essa fase pode ser executado em três categorias principais:
Guia para o PMD Pro 23
1. Coleta de dados; 2. Análise de dados; 3. Identificação da lógica de intervenção do projeto.
2.2.1.1 Coleta de dados A primeira etapa para determinar se você está “fazendo o projeto certo” é coletar os dados. O objetivo dessa coleta de dados é pesquisar amplamente um grande número e variedade de questões, fornecendo informações que, quando analisadas, informarão as prioridades e identificarão intervenções que enfrentarão os desafios na área alvo. 2.2.1.1.1 Identificação das necessidades do projeto Como parte de um processo amplo de pesquisa, a equipe de projeto precisará coletar dados que identifiquem as necessidades da comunidade na área de intervenção potencial. Entretanto, os dados não devem ser limitados unicamente aos exames das questões relacionadas com as necessidades da comunidade. Outros tópicos a serem explorados devem incluir o presente estado de prestação de serviços, os pontos positivos existentes na comunidade, um exame dos interessados presentes na área da intervenção e mais. Um dos desafios na coleta de dados é que o processo pode ser extremamente subjetivo. As pessoas (como indivíduos e como integrantes dos grupos sociais e de interesse) podem ter ideias radicalmente diferentes sobre o que deve ser definido como uma ‘necessidade’ e o que não deve. Como resultado, o processo de definição das necessidades em um único local pode gerar resultados significativamente diferentes dependendo de quem é consultado e que abordagem é empregada. Uma abordagem para limitar a subjetividade da definição do problema e trabalhar com as diferentes perspectivas das necessidades “reais” é através da triangulação dos dados de avaliação. A triangulação é uma técnica poderosa que facilita a validação dos dados através do cruzamento de mais de duas fontes. Por exemplo, se um estudo usa apenas um método/perspectiva de coleta de dados, a tentação de acreditar nas descobertas é forte. Se um investigador usar dois métodos/perspectivas, os resultados podem ser conflitantes. Entretanto ao usar três métodos/perspectivas para responder uma pergunta, a esperança é que os resultados de pelo menos duas das três se reforçarão entre si. Por outro lado, se forem produzidas três respostas conflitantes, o investigador sabe que a questão precisa ser reformulada, os métodos, reconsiderados, ou ambos. Em seu núcleo, a abordagem da triangulação aumenta a confiança e a validade dos resultados do estudo. Ao combinar várias perspectivas e métodos, os pesquisadores podem superar a fraqueza ou as tendências intrínsecas e os problemas que surgem do método único ou de uma perspectiva do observador único – aumentando assim a credibilidade e a validade dos resultados. Uma maneira de triangular o processo da identificação das necessidades é usar uma abordagem apresentada pelo sociólogo americano Jonathan Bradshaw, que acreditava que as avaliações das necessidades deveriam explorar quatro tipos de necessidades em uma comunidade e que a presença de todos os tipos de necessidades indicaria uma necessidade “real”.
Guia para o PMD Pro 24
Figura 13: Triangulação de necessidades usando a classificação de Bradshaw Como ilustrado na Figura 13, as quatro categorias de necessidade social de Bradshaw são:
Necessidades normativas – compara a situação atual com um conjunto de normas profissionais ou de especialistas. Frequentemente, essas necessidades são identificadas por um profissional ou especialista – médico, engenheiro, profissional de saúde pública, etc. Por exemplo, um especialista em saneamento básico pode indicar que as taxas de material fecal em águas domésticas estão acima da norma estabelecida pelo ministério da saúde.
Necessidades comparativas – compara a situação atual com a situação de outros. Um dos usos mais comuns dessa abordagem tem sido a comparação do acesso da população aos recursos. Essa abordagem reconhece que a necessidade é um conceito relativo e, portanto, qualquer debate sobre ela deve ocorrer no contexto de uma comparação entre pessoas. Por exemplo, membros de uma cooperativa de pesca podem observar que as reservas pesqueiras estão maiores em uma cidade próxima com instalações sanitárias.
Necessidades sentidas – focadas nos pensamentos e sonhos da comunidade propriamente dita. O que as pessoas acreditam que deve ser prioridade. Uma necessidade sentida provavelmente é subjetiva e pode ser mais bem descrita como um ‘desejo’. A necessidade sentida é necessariamente afetada pelo conhecimento e pelas expectativas do indivíduo, o que pode ser irreal e/ou insustentável. Por exemplo, as mães podem expressar desagrado com a bagunça e as condições insalubres que resultam da falta de saneamento básico – mas podem não estar cientes das alternativas que existem para mudar o estado atual.
Guia para o PMD Pro 25
Necessidades expressas – são inferidas pela observação das ações da comunidade. Por exemplo, se houver listas de espera longas por um serviço, há um indicativo de que a comunidade prioriza essa necessidade. Às vezes as necessidades expressas são consistentes com o que a comunidade expressou (eles sentiram a necessidade). Entretanto, algumas vezes, essas necessidades podem não ser identificadas concretamente em público (como necessidades sentidas) como resultado das pressões políticas e culturais ou porque ninguém nunca perguntou. Por exemplo, as famílias podem não ter expressado seu descontentamento com a falta de saneamento básico verbalmente, mas agora estão começando a identificar os locais onde descartam o lixo doméstico (fossas de lixo).
Conforme as organizações exploram as necessidades da comunidade, o desafio será garantir que o processo de identificação das necessidades é preciso e honesto. Frequentemente indivíduos e grupos já têm uma ideia com base em suas observações e experiências sobre que tipo de projeto ou serviço é preferido por uma organização de desenvolvimento específica. As organizações de desenvolvimento precisam se prevenir contra a dinâmica que leva os indivíduos e grupos a apresentar suas necessidades de modo que provavelmente se encaixem nas prioridades da organização de desenvolvimento para garantir que sejam selecionados para participar e se beneficiar. Por exemplo, em uma organização de desenvolvimento reconhecida por apoiar principalmente projetos aquáticos, os participantes do projeto provavelmente expressarão os seus problemas e soluções de um modo que eles se encaixem nas intervenções potenciais preferidas daquela organização de desenvolvimento – um projeto aquático. 2.2.1.1.2 Tipos de dados O processo de coleta de dados, entretanto, não é limitado exclusivamente à definição de necessidades. Para entender totalmente o contexto do projeto, sua equipe precisará coletar dados relativos a um número de áreas relacionadas ao ambiente do projeto, incluindo, mas sem se limitar, aos dados relativos a:
Interessados no projeto
Pontos positivos, oportunidades e visão da comunidade
Sucessos e capacidade
Ambiente biológico/físico
Redes organizacionais
Infraestrutura
Instituições jurídicas, policiais e políticas
Condições sociais e culturais
Em cada uma dessas áreas, existem três tipos de dados que podem ser coletados:
Dados secundários – informações disponíveis através de fontes publicadas e não publicadas, incluindo análises de literatura, pesquisas, avaliações, relatórios de ONGs, agências das Nações Unidas, organizações internacionais e órgãos governamentais. Os dados secundários podem ser muito econômicos e devem ser a primeira fonte acessada para se obter dados de avaliação. Infelizmente, o acesso a documentos secundários frequentemente é limitado e é necessário ter
Guia para o PMD Pro 26
cuidado ao interpretar dados secundários. Algumas vezes a coleta de dados primários será necessária para se verificar a confiabilidade e a relevância dos dados secundários para o contexto específico ou para se obter informações mais profundas e mais específicas.
Dados quantitativos primários – nas situações em que as fontes secundárias não fornecem informações de avaliação suficientes, as organizações podem coletar dados através de abordagens de avaliações quantitativas (pesquisas, questionários, testes, instrumentos de observação padronizada) que se concentram nas informações que podem ser contadas e submetidas a análises estatísticas. Os pontos positivos dos métodos de coleta de dados quantitativos incluem: o
Capacidade de expansão – processar os resultados a partir de um número grande de tópicos e permitir uma generalização dos resultados;
o
Objetividade e precisão dos resultados – menos tendenciosidade pessoal na coleta e na interpretação dos dados;
o
Padronização – os coletores de dados usam abordagens padrão cujos resultados podem ser comparados a outros dados.
As deficiências dos dados quantitativos são que essa abordagem, algumas vezes, perde a profundidade da situação e pode ser difícil coletar informações contextuais essenciais.
Dados qualitativos primários – em contraste com as abordagens quantitativas de dados, as abordagens qualitativas procuram capturar as experiências de participantes usando palavras, imagens e objetos (e até mesmo pistas não verbais emitidas pelos fornecedores dos dados). Os pontos positivos da coleta de dados qualitativos incluem: o
Profundidade e detalhes: os dados qualitativos frequentemente fornecem descrições detalhadas das situações, fornecendo a riqueza do contexto ausente nos dados quantitativos. Se as técnicas qualitativas forem usadas juntamente com a coleta de dados quantitativos, elas podem explicar por que foi dada uma resposta específica;
o
Cria abertura: estimular as pessoas a expandir suas respostas pode abrir novas áreas de tópicos não consideradas inicialmente;
o
Simula a experiência individual das pessoas: pode-se criar uma imagem detalhada sobre o motivo pelo qual as pessoas agem de certos modos e seus sentimentos em relação a essas ações.
Os dados qualitativos são coletados mais frequentemente como uma narrativa aberta, diferentemente do formato típico de pergunta e resposta das pesquisas, questionários ou testes.
Guia para o PMD Pro 27
Figura 14: Ferramentas para coleta de dados Dados secundários Análise de literatura Análise de registros Estatísticas existentes Índices Documentos do governo Documentos de outras ONGs
Dados quantitativos primários Pesquisa de conhecimento, prática e cobertura Pesquisas em residências Testes e pesquisas padronizados Instrumentos de observação padronizados Medições antropométricas
Dados qualitativos primários Tempestade de ideias Diagramas de afinidade Grupos focais Narrativas históricas Cronogramas Círculos de capacitação Visão Inquérito por amostragem Mapeamento da localidade Entrevistas semiestruturadas Entrevistas com informantes chave Exercícios de classificação
Deve-se ter cuidado na seleção das ferramentas e abordagens mais adequadas (e mais econômicas) para a coleta de informações. A sabedoria convencional algumas vezes indica que algumas abordagens de coleta de dados são melhores do que outras. Por exemplo, os dados primários frequentemente são percebidos como preferidos aos dados secundários. Entretanto, na prática está claro que há um lugar para várias fontes de dados e métodos mistos em quase todos os processos de avaliação. Embora a coleta de dados primários possa ser focada especificamente nas necessidades pontuais de um projeto proposto, a coleta dos dados primários também pode levar muito tempo, consumir muito dinheiro e envolver muitas pessoas. Por essa razão, muitas organizações recomendam que o primeiro turno de avaliação se baseie nos dados secundários e que os turnos subsequentes usem abordagens de coleta de dados primários para preencher os espaços não cobertos por dados secundários. Além disso, embora as percepções sugiram frequentemente que os dados qualitativos têm menos rigor do que os quantitativos, as abordagens quantitativas frequentemente correm o risco de gerar expectativas entre parceiros e comunidades locais e podem ser especialmente caras. As avaliações de dados qualitativos, por sua vez, podem planejadas e implementadas com experiência de forma a descobrir ideias reveladoras sobre as razões por trás das tendências identificadas através das abordagens secundária e quantitativa. Uma combinação dos métodos secundário e primário (incluindo as ferramentas qualitativa e quantitativa) no mesmo processo de coleta de dados pode fornecer uma imagem mais abrangente e integrada a partir da qual se tomam decisões. E, no final, o mais importante de tudo é tomar decisões. Antes de iniciar a coleta de dados, é necessário perguntar ‘Como esses dados serão usados?’ Se não houver nenhuma resposta aceitável para essa pergunta, não prossiga. O tempo e os recursos são muito valiosos para serem desperdiçados em exercícios inúteis. Lamentavelmente, muitos exercícios de avaliação coletaram dados extensos que produziram grandes documentos e que frequentemente permaneciam nas estantes “acumulando poeira”. Esses documentos representam um uso inadequado dos recursos, podem ser uma invasão nas vidas dos interessados e podem criar falsas expectativas que podem danificar importantes relacionamentos de parceiros e/ou beneficiários.
Guia para o PMD Pro 28
2.2.1.2 Análise de dados Embora o objetivo da coleta de dados seja explorar amplamente um grande número e uma grande variedade de questões, o objetivo da análise de dados é ordenar e organizar os dados brutos de modo que seja possível extrair informações úteis deles. Mais especificamente, os projetos de desenvolvimento tendem a se concentrar em duas categorias amplas de análise:
1. Análise do estado atual. 2. Análise do estado futuro. 2.2.1.2.1 Análise do estado atual A análise do estado atual é o ponto inicial do design dos bons projetos. É o processo de compreensão do status, condições, tendências e principais problemas que afetam as pessoas e seus sustentos, ecossistemas ou instituições em um dado contexto geográfico. Existe uma grande variedade de ferramentas para se conduzir análises de dados. Cada uma é projetada para um objetivo específico e a equipe de projeto deve selecionar as suas técnicas e ferramentas com base nos objetivos pretendidos do exercício da análise. Figura 15: Ferramentas de análise Objetivo Organizar informações Priorizar dados de avaliação
Identificar o estado atual da prestação de serviços Promover o raciocínio crítico por parte dos interessados no projeto Investigar relações de causa e efeito
Ferramenta Matrizes de vulnerabilidade Mapas mentais Diagramas de afinidade Matrizes e exercícios de classificação Análise da avaliação de deficiências Mapeamento Discussões em grupo Grupos focais Oficinas Análise de campo de força Árvores de problemas
Cada uma das ferramentas de análise da Figura 15 é importante e todas elas podem ser usadas para processar as informações reunidas através do processo de coleta de dados. Por exemplo, se a tarefa visa organizar ou classificar as informações de avaliação, será necessária uma ferramenta diferente de análise do que se o objetivo fosse promover mais raciocínio crítico por parte dos interessados no projeto. Na prática, entretanto, é improvável que uma equipe de projeto use todas as ferramentas de análise em todo e qualquer projeto que implementa. Embora não esteja dentro do escopo do PMD Pro examinar todas as técnicas e ferramentas de análise em profundidade, os gerentes de projetos devem se sentir à vontade para:
Guia para o PMD Pro 29
Identificar as diferentes ferramentas existentes que podem ser usadas para alcançar os diferentes objetivos que são uma parte da análise dos problemas;
Selecionar a melhor ferramenta para cada objetivo de análise de problema;
Desenvolver (com o tempo) as habilidades e os comportamentos necessários para usar diferentes ferramentas de análises de problemas com vários grupos.
2.2.1.2.2 Análise do estado futuro Quando a análise de estado atual estiver concluída, a etapa seguinte será analisar o estado futuro do projeto. Isso envolve fazer perguntas sobre como o projeto aprimorará o sustento, o ecossistema ou as instituições dos participantes do projeto. A análise do estado futuro ajuda a criar uma imagem ou descrição de onde o projeto levará:
O que será diferente no futuro se o projeto for bem-sucedido ao atender as expectativas?
O que os beneficiários do projeto poderão fazer que não conseguem fazer agora?
Que mudança social será possibilitada?
Na prática, a análise do estado futuro raramente é simples. Embora uma análise do estado futuro possa identificar uma ampla gama de intervenções potenciais para um projeto, raramente é o caso que uma organização possa implementar todas as atividades indicadas na análise do estado futuro. Nesse ponto, a organização de desenvolvimento deve considerar três perguntas estratégicas críticas:
Quais elementos serão incluídos na intervenção do projeto?
Quais elementos não serão incluídos no escopo do projeto?
Quais critérios serão usados para se tomar essas decisões?
Essas questões inevitavelmente vão se mostrar difíceis e as organizações serão confrontadas com várias alternativas. Elas precisarão tomar decisões concretas relativas ao escopo do projeto. Onde o projeto intervirá? Que serviços serão prestados? Quem será atendido? O consenso sobre essas questões pode ser complicado e o processo de tomada de decisões tem o potencial de se tornar muito complexo e controverso. Consequentemente, é importante que a equipe do projeto identifique e priorize claramente as várias considerações que entram em jogo ao se decidir o que será incluído no projeto eventual e o que será omitido.
Guia para o PMD Pro 30
Figura 16: Critérios para a determinação do que será incluído nas intervenções do projeto Categoria Priorização de necessidades
Critérios ilustrativos Que necessidades receberam o mais alto nível de ênfase durante a avaliação e a análise? O tratamento de quais necessidades pareceria ter o potencial mais alto de impacto?
Considerações do programa externo
Quem mais está trabalhando na área de intervenção proposta? Quais são os pontos positivos do programa? Que atividades existentes complementam a análise da árvore de objetivos?
Adequação
A abordagem proposta é aceitável para a população alvo e para os principais grupos interessados? Por exemplo, um programa de saúde reprodutiva seria adequado às normas religiosas e culturais?
Capacidade institucional
Quais são os pontos positivos de sua organização? Quais são os níveis de capacidade do seu parceiro de implementação?
Disponibilidade de recursos
Existe financiamento disponível? Existe potencial de crescimento? Que oportunidades existem para aproveitar recursos?
Viabilidade financeira/econômica
A taxa de retorno do investimento é aceitável?
Sustentabilidade e viabilidade técnica
O trabalho proposto pode ser realizado de modo realista? O trabalho do projeto pode ser sustentado e mantido com o tempo?
Considerações internas do programa
Quais são as prioridades estratégicas de sua organização na região? País? Outros? Quais são os pontos positivos de sua organização? Que prioridades a sua organização tem com relação à geografia? Beneficiários? Outros?
Considerações sobre o portfólio
O projeto se ‘encaixa’ no portfólio maior de projetos da organização?
Observe que as categorias acima podem ser organizadas em dois grupos. O primeiro grupo de categorias (priorização das necessidades, considerações do programa externo, adequação, capacidade institucional) usa as informações coletadas através das avaliações de necessidades e atividades de análise para decidir se e como uma organização intervirá. Essas categorias examinam se existem necessidades prioritárias que devem ser atendidas; se há outros programas que fornecem serviços complementares, se existem parceiros de implementação que têm a capacidade de executar o projeto e se as atividades propostas são adequadas. O segundo grupo de categorias (disponibilidade de recursos, viabilidade financeira/econômica, viabilidade técnica, considerações internas do programa) se concentra menos nos resultados das análises de necessidades e mais nos critérios relacionados com as considerações organizacionais. Por exemplo, existem doadores interessados em financiar o projeto? Existem recursos disponíveis? A organização tem capacidade na área do programa proposto? O projeto se encaixa no portfólio de projetos da organização? Guia para o PMD Pro 31
Coleta e análise de dados durante a vida do projeto
O gerenciamento do projeto é reiterativo!
Quando estiver claro quais objetivos potenciais do projeto atendem os critérios da tabela anterior, o design do projeto de alto nível pode ser postos em prática. Como indicado anteriormente, nem todos os objetivos potenciais do projeto podem ser atendidos em um único projeto. Essas áreas que não atendem os critérios ficarão de fora da intervenção.
Embora a coleta e a análise de dados sejam associadas normalmente com a fase de identificação e design, essas atividades podem e devem ser conduzidas em várias fases do projeto. Por exemplo, as ferramentas de coleta e análise são especialmente úteis na:
Tome-se como exemplo um estudo de caso baseado em uma comunidade fictícia, a cidade do Rio Delta. Uma avaliação recente na cidade descobriu que a deterioração da Expansão ou alteração do escopo de um projeto existente; qualidade da água ocasionou a diminuição Condução de atividades de das reservas pesqueiras; reduziu-se a renda monitoramento e avaliação; de pesca entre famílias de pescadores; e há Conclusão das atividades de uma incidência cada vez mais alta de aprendizagem durante a fase de transição para o final do projeto. doenças transmitidas pela água especialmente entre famílias carentes e crianças abaixo dos cinco anos. Existem níveis altos de resíduos fecais e lixo doméstico/industrial no rio ao longo de toda a comunidade; e alguns dos vários fatores que contribuem com o problema são:
Baixa conscientização pública dos perigos de descarte de lixo doméstico;
Baixo acesso e uso de instalações sanitárias para o descarte de resíduos fecais;
Supervisão fraca (ineficiente e corrupta) da Agência de proteção ambiental sobre a indústria têxtil local;
Orçamentos governamentais inadequados resultam no tratamento ineficaz do lixo industrial (onde há serviços) e a água residual não atende as normas ambientais.
É óbvio, nessa situação, que existem muitas áreas potenciais em que um projeto pode intervir (aumento da conscientização, descarte de resíduos, tratamento de resíduos industriais, defesa de orçamentos maiores, sistemas de descarte de resíduos fecais, etc.). Realisticamente, entretanto, um projeto deve identificar concretamente onde ele INTERVIRÁ e onde NÃO INTERVIRÁ. Em última instância, essas são decisões sobre a estratégia e a alocação de recursos que devem ser tomadas através da identificação de critérios de intervenção da mais alta prioridade. Nesse estudo de caso, esses critérios são:
Priorização de necessidades – as casas indicam que uma necessidade requer intervenção urgente.
Considerações externas do programa – o trabalho em instalações sanitárias é adequado à política do governo local e do órgão de implementação.
Guia para o PMD Pro 32
Considerações existentes de capacidade - a organização de implementação não tem a capacidade na área de engenharia de tratamento de águas residuais, mas tem uma experiência extensa na mudança do comportamento que é relacionada ao descarte de lixo doméstico.
Disponibilidade de recursos – um plano de cinco anos de um grande doador internacional para uma região incluiu recursos para melhorar a saúde dessa área.
Com base nessas considerações, a decisão foi tomada para que o design do projeto se concentrasse nas instalações sanitárias e que aumentasse a conscientização sobre os perigos do descarte de resíduos.
2.2.1.3 Identificação da lógica de intervenção do projeto Agora que os processos de coleta e análise de dados estão completos, a próxima etapa é começar a identificar a lógica do projeto. Uma das ferramentas principais usadas para estabelecer a lógica dos projetos de desenvolvimento é a matriz de estrutura lógica (quadro lógico). A estrutura lógica é uma ferramenta analítica usada para planejar, monitorar e avaliar projetos. O seu nome vem das relações lógicas definidas pelos planejadores para conectar um meio do projeto com seu final. 2.2.1.3.1 Variações da estrutura lógica
12
do projeto
Existem várias variações dos modelos de estrutura lógica usados no setor de desenvolvimento. Muitos desses modelos usam termos diferentes para identificar os resultados/produtos do projeto. Alguns identificam metas e objetivos e outros identificam resultados e efeitos. De modo similar, não há consenso sobre o número de níveis em uma matriz de estrutura lógica. Algumas organizações apoiam uma matriz de quatro níveis e outras, cinco. A tabela da Figura 17 pode servir como recurso para comparar os modelos de estrutura lógica de vários doadores internacionais e organizações de desenvolvimento. O que se torna imediatamente aparente durante a análise da tabela são as diferenças no número de níveis de cada modelo e das variações no uso da terminologia. Não obstante, haja variações entre os modelos de estrutura lógica em relação aos termos que usam e sua estrutura, todos eles visam atender os mesmos objetivos básicos, servindo como:
12
Uma ferramenta sistemática para organizar os relacionamentos de identificação e pensamento do projeto entre recursos, atividades e resultados do projeto;
Um modo visual de apresentação e compartilhamento da lógica de intervenção do projeto;
Uma ferramenta para identificar e avaliar os riscos inerentes ao design do projeto proposto;
Uma ferramenta para medir o andamento através de indicadores e meios de verificação.
Estrutura lógica e quadro lógico, são entendidas da mesma maneira para o PMDPro.
Guia para o PMD Pro 33
Figura 17: Terminologia da estrutura lógica de algumas organizações de desenvolvimento
UE
Mudança máxima Objetivo/ Impacto Objetivo do programa Objetivo geral
FAO
Objetivo geral
NORAD USAID
Objetivos Objetivo Objetivo Resultado intermediário estratégico Impacto/Meta/Objetivo de Resultado/ desenvolvimento Propósito Objetivo do Meta do Resultado programa projeto
UsAid CARE
Banco mundial World Vision
Mudança intermediária Propósito/ Resultado Objetivo final do projeto Propósito do projeto Objetivo intermediário
Objetivo do componente Objetivo intermediário Objetivo específico Objetivo
Produto tangível Saída Saída
Intervenções específicas Programa/tarefa do trabalho Atividade Entrada
Resultado esperado Saída
Atividade
Entrada
Atividade
Entrada
Saída Saída
Atividade Atividade
Entrada Entrada
Saída
Processo/ Atividade Atividade
Entrada
Saída
Entrada
2.2.1.3.2 Interpretação da matriz de estrutura lógica A matriz de estrutura lógica identifica e comunica os relacionamentos lógicos em um projeto acompanhando uma logica vertical e horizontal que conecta os níveis da matriz. O relacionamento entre os elementos de cada nível da estrutura lógica ilustra a lógica vertical que resultará no alcance do objetivo máximo do projeto. Embora haja muitas versões da estrutura lógica do projeto, o PMD Pro apoia um modelo de estrutura lógica de quatro níveis que inclui os seguintes componentes: 1. Atividades são ações realizadas através de insumos (recursos financeiros, humanos, técnicos, materiais e de tempo) que são mobilizadas para produzir resultados/produtos (treinamento, construção, etc.) de um projeto d o qual a equipe é responsável.
2. Os Resultados/produtos, são tangíveis ou serviços que resultam das atividades do projeto. Eles incluem produtos, bens, serviços e mudanças (ex.: pessoas treinadas com conhecimento e habilidades maiores; estradas de boa qualidade construídas) que agregam e contribuem a atingir objetivos. 3. Objetivos são o que o projeto espera conseguir no nível de beneficiário (ex.: uso do conhecimento e habilidades na prática atual com o tempo; o transporte de bens em estradas construídas com o tempo) e contribuem com as mudanças do nível populacional (redução da má nutrição, melhoria da renda, aumento dos rendimentos, etc.) que agregam e promovem o alcance dos impactos com o tempo. 4. Impactos são o nível mais alto desejado de objetivos finais (transformações, sustentabilidade, sustento, bem-estar, etc.) para o qual o projeto contribui (o objetivo máximo de muitas estruturas lógicas).
Guia para o PMD Pro 34
Figura 18: Lógica vertical do quadro lógico
Tendo definido o impacto, objetivo, resultados/produtos e atividades do projeto a próxima questão que surge é: Que riscos externos (fora do controle do projeto) poderiam interferir potencialmente na lógica vertical do projeto? Em cada nível de estrutura lógica existem fatores externos que podem afetar o sucesso do projeto. Por exemplo, se houver um outro ano de seca, as sem*ntes poderão não germinar e, portanto, o produto (uma colheita) poderá não acontecer. Ou se as crianças estiverem com diarreia devido à má qualidade da água, elas podem comer mais, mas permanecerão mal nutridas. Esses fatores externos importantes devem ser anotados na coluna Pressupostos . Você pode não conseguir fazer nada sobre alguns dos riscos (é improvável que uma ONG local possa impedir a deflagração de uma guerra), mas é importante prever os possíveis problemas. A lista de riscos e pressupostos também pode ajudar a explicar por que um projeto não alcançou todos os seus objetivos. Os pressupostos definem a lógica horizontal da matriz, criando um relacionamento 'se-então' que afirma que se os pressupostos de cada nível da estrutura permanecerem verdadeiros, o caminho do desenvolvimento vertical do projeto provavelmente será bem-sucedido como ilustrado no gráfico a seguir.
Guia para o PMD Pro 35
Figura 19: Lógica horizontal do quadro lógico
É especialmente importante se concentrar nos pressupostos encontradas na célula direita do nível de produtos da estrutura lógica. Os pressupostos encontrados nessa célula formam o ponto crucial da lógica da intervenção do projeto. É aqui que a conexão é feita entre os resultados tangíveis produzidos no nível do produto e a mudança social desejada no nível do objetivo. Por exemplo, se os produtos do projeto forem: 1. Construir latrinas. 2. Conduzir uma campanha de conscientização para aumentar o uso de latrinas. Então a consideração no nível dos produtos é que o aumento da disponibilidade de latrinas e a maior conscientização sobre elas aumentará significativamente o seu uso – melhorando assim a qualidade da água e a saúde da comunidade. Após o estabelecimento do objetivo e a identificação dos riscos e pressupostos, os elementos finais da estrutura lógica são os indicadores e os meios de verificação de cada nível da estrutura lógica. Um indicador é uma medida quantitativa ou observação qualitativa usada para descrever mudanças. Para que o indicador meça a mudança, ele deve ter um parâmetro (uma medida ou descrição do desempenho atual e um comparador) como um ponto de referência inicial. Os parâmetros devem ser definidos no início de um projeto ou próximo dele. O desempenho durante a implementação do projeto é medido em relação a um alvo (os aprimoramentos, mudanças ou alcances esperados durante a implementação do projeto), levando em consideração os parâmetros.
Guia para o PMD Pro 36
Os indicadores representam o até que ponto um projeto está alcançando seus resultados, objetivo e impactos. Eles comunicam em termos específicos e mensuráveis o desempenho a ser alcançado a cada nível de mudança. Os indicadores também ajudam a remover declarações vagas e imprecisas sobre o que se pode esperar das intervenções do projeto. A Figura 20 fornece diretrizes para o desenvolvimento do indicador em cada nível da estrutura lógica.
Figura 20: Diretrizes de indicadores por nível de estrutura lógica Elementos Impacto – o objetivo máximo ou o resultado final mais alto possível com o qual o projeto contribui Objetivo– o que o projeto espera conseguir no nível de beneficiário, que agregam e promovem o alcance dos impactos com o tempo Resultados/Produtos – tangíveis ou serviços que resultam das atividades do projeto. Eles incluem produtos, bens, serviços e mudanças que contribuem a atingir objetivos Atividades – ações realizadas através de insumos que são mobilizados para produzir resultados/produtos.
Diretrizes de indicadores Os indicadores vão ser de impactos de longo prazo que não são específicos de um projeto único. Ao contrário, eles são objetivos de programas, subsetores ou setores com os quais vários outros projetos e variáveis contribuirão. Exemplos: transformação, sustentabilidade, sustento e bem-estar. Os indicadores nesse nível são cruciais, mas podem ser mais difíceis de determinar. A mudança é procurada entre beneficiários estendidos, populações alvo, instituições colaborativas e parceiros locais. Exemplos: uso de conhecimento e habilidades na prática real com o tempo; transporte de bens em estradas construídas com o tempo, má nutrição reduzida, aumento de renda e melhores rendimentos. Os indicadores nesse nível são mais fáceis de especificar do que um nível de objetivo, porque representam bens e serviços tangíveis a serem fornecidos pelo projeto. Todos os produtos precisam ser produzidos até o final do período de implementação do projeto e, de acordo com o cronograma, incluídos no plano do projeto. Exemplos: pessoas treinadas com maior conhecimento e habilidade; estradas de boa qualidade construídas, bens entregues e serviços prestados. Nem todas as organizações de desenvolvimento geram indicadores no nível da atividade. Os indicadores desse nível são quase diretamente relacionados com a descrição da atividade propriamente dita. Os exemplos incluem: atividades da equipe, gastos reais comparados com o orçamento, uso de equipamentos, componentes de treinamento e componentes de construção.
Ao desenvolver indicadores, a norma é usar o critério SMART para guiar a construção de um indicador de desempenho. SMART é um acrônimo com o seguinte significado:
Specific (Específico) – Os indicadores devem ser quantificáveis e mensuráveis? O que o projeto pretende mudar? Os indicadores fornecem parâmetros detalhados em relação a: o
Quantidade – as representações numéricas esperadas do que deve ser alcançado;
o
Qualidade – a narrativa ou descrição ilustrativa dos resultados esperados;
o
Local – o limite geográfico das realizações esperadas.
Guia para o PMD Pro 37
Measureable (Mensurável) – Os indicadores devem ser quantificáveis e mensuráveis. O indicador pode ser avaliado objetiva e independentemente?
Achievable (Alcançável) – Os indicadores devem ser alcançáveis dentro dos limites do triângulo do projeto (orçamento/recursos, tempo/orçamento e escopo/qualidade).
Relevant (Relevante) – Os indicadores devem medir precisamente a mudança que o projeto aspira gerar. O indicador mede de forma prática e econômica o que a equipe do projeto precisa saber?
Time-bound (Limitado pelo tempo) – O indicador devem identificar uma hora e data específicas. Quando o indicador será alcançado? O indicador pode ser alcançado dentro do prazo estabelecido?
A tabela da Figura 21 ilustra uma criação parcial da estrutura lógica do projeto relacionado ao estudo de caso do projeto Rio Delta apresentado anteriormente. O conteúdo dessa estrutura lógica fornece exemplos da lógica vertical e horizontal do projeto e também fornece exemplos dos pressupostos e dos indicadores encontrados em cada nível da estrutura lógica.
Guia para o PMD Pro 38
Descrição
Indicadores
Meios de verificação
Melhoria da saúde de crianças abaixo de cinco anos especificamente entre as famílias de baixa renda que vivem às margens do rio.
Incidência de doenças transmitidas pela água entre crianças com menos de cinco anos reduzida em 30% até 2012.
Registros de clínicas e hospitais municipais coletados por equipes de saúde móveis
Volume reduzido de resíduos fecais despejados no rio
Concentração de E. coli reduzida em 20% (em comparação com os níveis em + 2003) e atende as normas nacionais de saúde e saneamento até 2012
Pesquisas mensais de qualidade da água realizadas pela EPA e pela autoridade fluvial
60% dos resíduos fecais domésticos são descartados através de latrinas ou conexões de esgoto
Atividades
Resultados/Produtos
Objetivo
Impacto
Figura 21: Estrutura lógica do projeto Rio Delta
Latrinas de qualidade construídas e usadas por integrantes da comunidade Etc.
Número de latrinas concluídas Número de latrinas que passam no teste de qualidade Número de homens, mulheres, meninos e meninas que usam latrinas regularmente
Pesquisa de amostra anual realizada pelo município entre 2009 e 2012
Dados de inventário do formulário usado pelos voluntários do saneamento comunitário Entrevistas com informantes-chave Etc.
Etc. Iniciar campanhas públicas de conscientização sobre saneamento Mobilizar comunidades para a construção de latrinas Preparar especificações de engenharia Localizar pontos ideais para a construção de latrinas Etc.
Número de reuniões públicas Número de pessoas que receberam informações Número de pessoas nas reuniões de conscientização Planos de engenharia concluídos Planos aprovados pelo Ministério de obras de utilidade pública Número de locais identificados Satisfação do cliente com os locais propostos para as latrinas Etc.
Guia para o PMD Pro 39
Diário de atividades da equipe e dos voluntários Registros de participação nos eventos Cópia do plano verificada Formulário de aprovação do Ministério de obras de utilidade pública Mapa dos locais com fundamentos documentando as entradas dos clientes Etc.
Pressupostos
A qualidade da água rio acima permanece inalterada A água do rio limpa é um determinantechave do estado de saúde de crianças com menos de 5 anos de idade. A maior conscientização garante a adoção da latrina e seu uso contínuo O uso de latrinas reduzirá adequadamente o volume de despejo de resíduos no rio Etc.
2.2.1.4 Gerenciamento das portas de decisão do projeto
Consulta aos interessados
“Nesse momento nós já investimos uma quantidade considerável de tempo/dinheiro/esforço na identificação e design do projeto sem ter nenhuma garantia de que ele será financiado. Esse não é um risco significativo?” Essa questão é adequada e suas preocupações são 100% válidas. Sempre há um risco de que a organização invista recursos extensos na fase de identificação e design do projeto e depois descubra que o projeto não foi aprovado oficialmente. Em um mundo ideal, a equipe do projeto definiria um sistema através do qual eles pudessem receber uma indicação clara de se o projeto receberá (ou não) apoio ANTES que sejam investidos recursos consideráveis na identificação e no design do projeto.
O gerenciamento do projeto é participativo!
Espere! Nesse momento, o leitor astuto levantará a seguinte questão:
Conforme a equipe cria os documentos associados com cada porta de decisão (isto é, 13 um documento conceitual ou proposta preliminar, carta de interesse, proposta do projeto, etc.), ela precisará envolver os interessados para explorar as questões centrais relacionadas ao projeto potencial. Essas questões incluem (mas não se limitam a) ao seguinte:
O escopo do projeto foi analisado e aceito pelos seus principais beneficiários? O cronograma de alto nível do projeto é consistente com as expectativas e restrições dos interessados? Os interessados concordaram com um requisito de qualidade de nível mínimo? O escopo do projeto de alto nível, o cronograma e o orçamento foram analisados com as organizações de implementação que conduzirão as atividades do projeto? Essas questões e outras fornecem pontos de verificação precocemente no processo de design do projeto, o que ajuda a garantir que a proposta oficial do projeto seja adequada.
As equipes de projeto querem evitar a situação “projeto perfeito, mas rejeitado”, em que as organizações já tenham gasto milhares (ou até dezenas de milhares) de dólares nas atividades de identificação e design do projeto, mas ele, em última análise, não tem o apoio dos interessados chave (dentro da organização, na comunidade, entre a equipe governamental ou dos doadores pretendidos). Uma das “melhores práticas” usadas para gerenciar o risco de uma situação “projeto perfeito, mas rejeitado”, é apoiar um processo de porta de decisão que consista em uma série de pontos de autorização em vários estágios do projeto. Usando as portas de decisão, as organizações identificam uma série de pontos no projeto que exigem uma decisão para prosseguir com a fase seguinte do projeto, modificar o escopo, cronograma ou orçamento do projeto ou encerrar o projeto imediatamente. Cada porta de decisão sucessiva se soma ao trabalho que foi desenvolvido no estágio anterior.
13
Concept paper, perfil de projeto.
Guia para o PMD Pro 40
O gerenciamento de um grupo grande de interessados através de várias portas de decisão leva um tempo considerável frequentemente e corre o risco dos desafios da comunicação. Apesar dessa complexidade e do risco, entretanto, as vantagens de utilizar as portas de decisão são as seguintes:
Elas garantem que a organização não invista uma quantidade extensa de tempo, dinheiro, capacidade da equipe e capital organizacional no desenvolvimento de propostas de projetos que não têm o compromisso e o suporte dos principais tomadores de decisão (doadores, parceiros de implementação, tomadores de decisão internos da organização). Elas apoiam uma análise robusta do conceito do projeto fornecendo várias perspectivas e estimulando a propriedade coletiva do projeto quando se inicia sua implementação. Elas mapeiam o processo através do qual um projeto precisa ser examinado para garantir que ele tenha o apoio (interno e externo) necessário para que o projeto seja, em última instância, aprovado.
Dentro do contexto do modelo de projeto por fases do PMD Pro, as portas de decisão são representadas pelos triângulos localizados entre as fases do projeto.
Figura 22: um exemplo ilustrativo das portas de decisão na vida de um projeto Conforme reconhecido anteriormente, o número de portas de decisão de um projeto varia de acordo com o projeto, sua complexidade e com os principais interessados. Por essa razão, o modelo PMDProvisa a servir como um modelo ilustrativo de onde as portas de decisão podem ser colocadas. Alguns projetos podem ter mais portas de decisão e outros podem ter menos. O que deve ficar claro, entretanto, é que um sistema de portas de decisão ajudará a garantir que os investimentos do projeto não sejam feitos sem o consenso dos principais interessados. A colocação de portas de decisão com intervalos regulares (por exemplo, no início de cada ano da implementação do projeto) ajuda a:
Manter o projeto concentrado na necessidade que o projeto foi iniciado originalmente para atender;
Guia para o PMD Pro 41
Garantir que o contexto e os pressupostos que levaram à aprovação do projeto inicialmente ainda existam;
Fornecer uma oportunidade para que a equipe do projeto e os principais interessados decidam se devem: o
Continuar o projeto como ele está concebido atualmente;
o
Modificar o plano do projeto;
o
Encerrar o projeto (o que não é necessariamente uma falha se a intervenção não for mais adequada, viável ou necessária).
O exemplo abaixo identifica três portas de decisão que foram definidas para o projeto Rio Delta durante a fase de identificação e design do projeto. NOTA: é importante reconhecer que a sequência do portal de decisão do estudo de caso do Rio Delta representa apenas UMA das MUITAS sequências que podem existir para um projeto de desenvolvimento e esse exemplo identifica apenas as portas de decisão estabelecidas durante a fase de identificação e design do projeto.
Caso: Portas de decisão do projeto Rio Delta
Os produtos durante a fase de identificação e design do projeto nesse caso são as seguintes: Porta de decisão 1: Proposta do projeto. Este documento é apresentado aos interessados internos para autorizar internamente as atividades de análise e avaliação exploratória e receber retorno sobre o desenvolvimento da proposta potencial. Porta de decisão 2: Expressão de interesse. Esse documento é enviado a doadores em potencial para obter um sinal verde dos principais interessados externos. Esse documento visa a ser desenvolvido em um prazo relativamente curto usando-se recursos limitados, e visa a gerar uma conversa sobre o design de alto nível do projeto e receber retorno para o projeto ANTES que sejam gastos recursos consideráveis no desenvolvimento de uma proposta mais expansiva do projeto. Porta de decisão 3: Proposta do projeto. Nessa etapa é criado um documento formal para receber a aprovação por uma solicitação de financiamento para um 14 projeto. Esse documento deve ser claro e mais preciso na descrição do CSSQ (custo, escopo, cronograma e qualidade) do projeto. O formato da proposta do projeto de desenvolvimento pode variar consideravelmente dependendo do tamanho dos requisitos do projeto e do doador.
14
Cost, Scope, Schedule and Quality
Guia para o PMD Pro 42
2.2.2 FASE 2: DEFINIÇÃO DO PROJETO
Figura 23: A fase de definição do projeto
2.2.2.1 Objetivo Todo projeto bem-sucedido começa com uma fase de definição planejada e implementada cuidadosamente. Os objetivos da fase de definição do projeto incluem: 1. O estabelecimento da estrutura de governança do projeto. 2. Autorização oficial para o início do projeto. 3. Comunicação para o lançamento do projeto.
2.2.2.2 Estabelecimento da estrutura de governança15 do projeto Infelizmente, o termo “governança” frequentemente invoca imagens de processos e protocolos burocráticos. Essa não é a intenção ou o propósito no caso da governança do projeto. No contexto do gerenciamento de projeto, a governança define a estrutura de gerenciamento dentro da qual as decisões do projeto são tomadas. Uma estrutura de governança forte esclarece: Autoridade: quem tem o poder de tomar decisões e dentro de quais níveis de tolerância; Responsabilidade: quem é o responsável pelo sucesso do projeto? Sem responsabilidade clara pelo sucesso do projeto, ninguém agirá para solucionar os problemas do projeto.
15
Para o PMDPro, a governança pode se entender também como o Comitê de Projeto.
Guia para o PMD Pro 43
As estruturas de governança podem assumir várias formas. Em sua forma mais simples, uma estrutura de governança composta de um único indivíduo – o patrocinador do projeto – pode ser o suficiente. Nessa situação, a responsabilidade do patrocinador do projeto seria:
Garantir a responsabilidade e o compromisso organizacional para o projeto;
Decidir sobre as alterações propostas do projeto (escopo, orçamento, calendário e outros) que se estendem além das tolerâncias acordadas do gerente de projetos;
Supervisionar o projeto, fornecendo recursos, direção e ideias conforme necessário;
Monitorar a viabilidade constante do projeto, tomando decisões para encerrá-lo, se necessário;
Apoiar e aconselhar o gerente de projetos sobre o gerenciamento do projeto, especialmente sobre questões que se estendem além da esfera de controle de um gerente de projetos.
Lutar pelos recursos e apoio organizacional necessários para o projeto;
Garantir que a organização “detenha” o processo e os resultados do projeto.
E mesmo assim, enquanto uma estrutura de governança composta de um único patrocinador possa ser simples, ela frequentemente deixa de representar as várias perspectivas de projetos de desenvolvimento. Todos nós sabemos, entretanto, que os projetos de desenvolvimento raramente são simples. A equipe do projeto deve gerenciar agendas com vários interessados, incluindo (mas sem se limitar ) o doador do projeto, as organizações de implementação, as comunidades beneficiárias e os fornecedores do projeto. Nesses contextos complexos, um único patrocinador do projeto não fornecerá o suporte que a equipe de projeto precisa para obter o sucesso. Ao contrário, uma estrutura de governança mais eficaz seria um comitê de projeto que incluísse representantes dos vários interessados envolvidos no projeto. Não há uma norma única e definitiva para a criação de comissões de projeto. Entretanto, a seguinte orientação fornece ideias sobre como elas podem ser estruturadas e gerenciadas.
Tamanho
Não há tamanho padrão para as comissões de projeto. No mínimo, deve haver duas pessoas e é comum encontrar comissões compostas de três, quatro ou cinco representantes. Como mencionado anteriormente, grupos menores facilitam a colaboração e a tomada de decisão eficientes. Entretanto, é útil expandir o tamanho do comitê quando o gerenciamento dos interessados é complexo. Por exemplo, se houver vários doadores, vários grupos beneficiários ou várias organizações trabalhando no mesmo projeto
Composição
Os integrantes do comitê devem representar as seguintes perspectivas de conhecimento/gerenciamento/experiência
Uma perspectiva executiva – avaliar se o projeto está fornecendo valor como um todo e fornecer o financiamento e os recursos necessários para se obter esse valor. Existe apenas um representante com perspectiva executiva no comitê.
Uma perspectiva de um usuário sênior – estabelecer que o projeto está
Guia para o PMD Pro 44
atendendo as necessidades das pessoas que trabalharão diretamente com os produtos do projeto. Pode haver mais do que um representante com a perspectiva do usuário sênior no comitê. Outra alternativa seria estabelecer um “grupo de usuários senior” para o projeto, o que, por sua vez, identifica um representante único do comitê para representar as opiniões de todos os integrantes do grupo.
Uma perspectiva de um fornecedor sênior – proporcionar confiança de que os produtos do projeto (dos quais o valor será derivado) podem ser agregados com recursos disponíveis e com o nível de qualidade exigido. Pode haver mais do que um representante com a perspectiva do usuário sênior no comitê. Outra alternativa seria estabelecer um “grupo de fornecedores seniores” para o projeto, o que, por sua vez, identifica um representante único do comitê para representar as opiniões de todos os integrantes do grupo. Cada perspectiva do integrante do comitê reflete uma dimensão diferente do projeto em termos dos recursos fornecidos ao projeto; entendimento das necessidades organizacionais, do usuário e do desenvolvedor (para a tomada de decisões sobre a viabilidade constante do projeto); e a pesagem dos resultados do projeto. Cada um desses itens tem sua própria avaliação sobre o que significa “sucesso” e todas as perspectivas quando consideradas juntas definem o sucesso do projeto.
Responsabilidades
Coletivamente, o comitê do projeto é o dono do projeto e suas responsabilidades incluem:
Decidir sobre as alterações propostas do projeto (escopo, orçamento, calendário e outros) que se estendem além das tolerâncias acordadas do gerente de projetos;
Supervisionar o projeto, fornecendo recursos, direção e ideias conforme necessário;
Monitorar a viabilidade constante do projeto, tomando decisões para encerrá-lo, se necessário;
Representar o interesse da perspectiva que representam;
Apoiar e aconselhar o gerente de projetos sobre o gerenciamento do projeto, especialmente sobre questões que se estendem além da sua esfera de controle.
Lutar pelos recursos e apoio necessários para o projeto.
Guia para o PMD Pro 45
Reuniões
Recomenda-se que as comissões do projeto realizem reuniões programadas regularmente em que a pauta é definida pelo gerente de projetos em cooperação com o representante da perspectiva executiva. Os itens importantes da pauta incluem a análise do registro de riscos e registro de problemas a serem discutidos posteriormente. Além disso, uma reunião do comitê do projeto também é necessária em todas as portas de decisão.
Uma área de confusão que algumas vezes surge é se o comitê do projeto age como uma democracia simples em que cada integrante do comitê tem voz igual na votação de decisões importantes. É importante reconhecer que nem todas as vozes do comitê do projeto terão autoridade igual em todas as decisões. Se, por exemplo, houver necessidade de solicitar um aumento de orçamento ou uma extensão do prazo para o projeto, talvez todos os integrantes do comitê do projeto sejam consultados, mas a autoridade máxima da decisão está exclusivamente com um único integrante do comitê (provavelmente, nesse exemplo, a perspectiva executiva) ou um pequeno grupo de integrantes do comitê. Lembre-se de que a eficácia da tomada de decisões de um grupo pode ser imaginada como inversamente proporcional ao seu tamanho. Os grupos grandes não apenas podem falhar ao tomar decisões oportunas, como a qualidade das decisões pode ser afetada pelos desafios do gerenciamento do grupo.
2.2.2.3 Autorização oficial para o início do projeto Se um projeto tem seguido o modelo das portas de decisão, várias decisões do tipo sim/não já terão sido tomadas antes que se entre na fase de definição do projeto – por exemplo, quando a proposta preliminar foi criada, quando uma declaração de interesse foi apresentada ou quando uma proposta de projeto foi analisada e aprovada. Durante a fase de definição do projeto, é importante garantir que ele seja autorizado formalmente pela equipe de administração do projeto (quer ela seja composta de um patrocinador ou umo comitê de projeto). 16
Essa aprovação deve ser documentada através do desenvolvimento de uma Ata de Constituição do projeto, um documento que fornece uma descrição de alto nível do projeto e que é assinado pela equipe de administração do projeto. O conteúdo do documento básico pode variar, mas ele geralmente inclui declarações relativas a:
Propósito do projeto – incluindo a declaração sobre a necessidade que o projeto atenderá.
Resultados/produtos do projeto – articular o escopo do projeto , incluindo seu impacto, 18 objetivo e resultados/produtos (escopo do produto ).
17
16
A Ata de Constituição do Projeto, normalmente, é um contrato formal ou um convênio entre as partes financiadoras e executoras do projeto. 17
O Escopo do Projeto é o conjunto de atividades (esforço) necessário para atingir o objetivo do projeto.
18
O Escopo do Produto são as características e detalhes dos produtos/resultados que o projeto se propõe a entregar. Guia para o PMD Pro 46
Estimativas de projeto de alto nível – incluindo uma declaração de alto nível sobre: o Atividades do projeto; o Programação do projeto; o O orçamento do projeto; e o Uma lista preliminar das funções e das habilidades necessárias à execução do trabalho necessário. Riscos do projeto – identificar riscos e problemas potenciais que o projeto pode encontrar.
Tolerâncias do projeto – articulação das tolerâncias do projeto relativas a os resultados/produtos, programação, custo e risco do projeto.
Controle sobre mudanças do projeto – definir um processo de tratamento de exceções para quando o projeto ultrapassar uma tolerância em qualquer uma dessas áreas.
Depois de criado e assinado, é importante que não seja colocado na prateleira e esquecido. O documento básico do projeto é um documento extremamente útil que pode ser usado para alcançar os seguintes objetivos:
Autorizar oficialmente o início das atividades do projeto e o uso de recursos para a sua implementação;
Garantir que existe um entendimento compartilhado dos parâmetros do projeto entre os principais interessados e os financiadores do projeto (interna e externamente);
Documentar um compromisso compartilhado com os objetivos do projeto e os recursos/atividades necessários para o sucesso do projeto.
Além disso, a Ata de Constituição deve ser considerada um documento vivo. Se a equipe de administração do projeto aprovar mudanças importantes no projeto (escopo, orçamento, calendário ou outros), a Ata de Constituição deve ser atualizada e assinada para refletir os novos parâmetros do projeto. Em resumo, a Ata de Constitução do projeto serve como aliado do gerente de projetos e, na ausência de uma Ata de Constituição do projeto, a equipe de projeto corre o risco de:
começar a empregar tempo, dinheiro, materiais, equipe e capital organizacional na execução de um projeto que não tenha o compromisso e o apoio dos principais tomadores de decisão, (doadores, parceiros de implementação, tomadores de decisão internos da organização);
os principais interessados não compartilharem um entendimento comum do projeto (escopo, orçamento, cronograma, benefícios e riscos).
2.2.2.4 Comunicação para o lançamento do projeto
Guia para o PMD Pro 47
Um dos principais objetivos da fase de definição do projeto é comunicar as atividades aos vários interessados na intervenção. Esses interessados podem incluir as comunidades beneficiárias, ONGs que trabalham na intervenção, representantes dos ministérios do governo, o público em geral e vários outros. Existem várias ferramentas de comunicação que podem ser usadas para anunciar o lançamento do projeto para a comunidade de interessados. Entretanto, independentemente do mecanismo empregado, o objetivo das atividades de comunicação do lançamento do projeto permanecem inalteradas.
Reconhecer formalmente o início do projeto;
Garantir que os principais interessados tenham entendimento consistente do projeto;
Apresentar aos interessados o projeto.
De vários modos, a Ata de Constituição do projeto é um documento ideal, em que se comunica oficialmente o lançamento do projeto para o grande público. Devido ao seu formato (curto e conciso), a Ata de Constituição do projeto é especialmente boa para comunicar os seus parâmetros de alto nível. Como resultado, esse documento será frequentemente útil ao se lidar com algumas pessoas que têm memória curta, intencionalmente ou não. O compartilhamento da Ata de Constituição do projeto com a comunidade de interessados em geral não é apenas uma prática eficaz de comunicação,também é um meio de promover a transparência e a responsabilidade no projeto. Se, no entanto, houver razões para que a equipe do projeto prefira não compartilhar todos os elementos da Ata de Constituição com a comunidade de interessados em geral, existem outros mecanismos de comunicação. Se houver informações confidenciais, elas podem ser incluídas em uma versão com emendas da Ata de Constituição do projeto que pode ser compartilhado com o público em geral. Além disso, artigos em jornais, entrevistas coletivas, visitas em campo, reuniões e festas de lançamento também podem ser usadas para se comunicar com a comunidade em geral. As mensagens dessas comunicações pode variar dependendo do público e de sua conexão com o projeto. É importante, entretanto, que pelo menos os parâmetros de alto nível do projeto sejam compartilhados com os interessados antes do início da implementação do projeto.
Guia para o PMD Pro 48
2.2.3 FASE 3: PLANEJAMENTO DO PROJETO
Figura 24: Fase de planejamento do projeto
2.2.3.1 Objetivo Geralmente no momento em que o projeto entra oficialmente na fase de planejamento, a equipe do projeto já criou vários documentos (isto é, a estrutura lógica do projeto, a proposta do projeto, a Ata de Constituição do projeto, etc.) que contêm um extenso nível de detalhes relacionados ao projeto:
Objetivo, resultados e produtos Escopo e atividades Indicadores e meios de verificação Orçamento Programação
É importante, entretanto, não confundir a proposta do projeto, a estrutura lógica do projeto ou outros documentos criados durante a identificação do projeto e as fases de início com um plano de projeto. O plano de projeto difere significativamente desses outros documentos em termos de formato, propósito, público, nível de detalhes, participação, cronologia e restrições de cronograma. Embora algumas pessoas argumentem que a estrutura lógica do projeto e/ou as propostas do projeto forneçam uma quantidade aceitável de informações para servir como um plano de projeto, esses documentos raramente fornecem um nível suficiente de detalhes necessários para sua implementação. Isso ocorre porque esses documentos são escritos para servir diferentes propósitos de uma única vez. Considere, por exemplo, a proposta do projeto em comparação com o plano de implantação do projeto. A Figura 25 faz a diferenciação entre os dois documentos de acordo com seus propósitos, formato e nível de detalhe (observe que uma comparação similar poderia ser feita entre a estrutura lógica do projeto e seu plano de implementação).
Guia para o PMD Pro 49
Figura 25: Propostas do projeto x planos de implementação do projeto Proposta do projeto Obter aprovação e financiamento para o projeto, enfatizando a comunicação clara e concisa das ideias que o vendem para os financiadores interessados.
Plano de implementação do projeto Garantir que o projeto ocorra dentro do prazo, do escopo e do orçamento e de acordo com os parâmetros de qualidade estabelecidos; enfatizar o planejamento completo e lógico e modelar o projeto para análise pela equipe do projeto e outros interessados
Formato
O formato é determinado pelos requisitos do doador ou pelos interessados da agência responsável pelas decisões de investimento
O formato é determinado pela equipe de projeto e pelos principais interessados
Nível de detalhes
Limitado em nível de detalhes – devido ao propósito, formato, previsão, cronograma e cronologia da proposta
O nível de detalhes é criado pela equipe do projeto e pelos principais interessados
Participação
Escrito por uma pequena equipe como resultado das restrições de tempo que limitam a participação
Existe a oportunidade de expandir a participação e incluir um conjunto de interessados, incluindo especialistas e conselheiros técnicos
Público-alvo
Concentrado nos doadores e interessados que distribuem recursos
Concentrado nas necessidades da equipe que está implementando as atividades do projeto
Cronologia e cronograma
Elaborado sob rígidas restrições de tempo, alguns meses (ou mesmo anos) antes da implementação
Existe a oportunidade de revisitar as propostas para desenvolver/revisar/atualizar ainda mais os planos no início da implementação do projeto ou principal ponto de referência do ciclo de vida
Objetivo
Não obstante haja diferenças consideráveis entre propósito, processo e conteúdo de uma proposta de projeto e um plano de implementação de projeto, muitas organizações de desenvolvimento usam a proposta de projeto como um plano de implementação. Esse é especialmente o caso em que o formato da proposta baseia-se nas exigências feitas pelos doadores que resultam em propostas que se aproximam dos planos do projeto em termos de duração e nível de detalhes. Cuidado – mesmo as propostas de projeto mais extensas (e muitas podem ultrapassar 100 páginas) ainda têm pontos fracos que limitam sua eficácia no planejamento para a implementação do projeto. O formato e os elementos dos planos de implementação do projeto variam de acordo com a organização, doador e/ou projeto. Independentemente do formato do documento, todos os planos de implementação do projeto (em comparação com as resultados/produtos do início criadas durante as primeiras fases) devem tratar com certeza dos princípios do gerenciamento de projetos do PMD Pro: O planejamento de implementação é equilibrado! O planejamento de implementação é abrangente! O planejamento de implementação é integrado! O gerenciamento do projeto é participativo! - O gerenciamento do projeto é reiterativo!
Guia para o PMD Pro 50
2.2.3.2 O planejamento de implementação é equilibrado Lembre-se! Existem seis fases no ciclo de vida do projeto do PMD Pro! O gerenciamento dos projetos deve ser equilibrado para garantir que todas as atividades, orçamento e o calendário necessários para conduzir o trabalho relacionado com cada uma das fases sejam executados. Obviamente, o plano de implementação incluirá as informações necessárias para concluir o trabalho na fase de implementação. Também é importante que o plano inclua o diagrama exigido para realizar o trabalho necessário para gerenciar também as outras fases do projeto, incluindo:
Planejamento do inicio do projeto - no momento em que um plano detalhado de implementação é criado, a maioria das atividades do inicio já está concluída. Entretanto, não se esqueça de que as atividades de governança do projeto começadas na fase de inicio precisam ser mantidas por toda a vida do projeto. Isso pode significar, por exemplo, o planejamento do calendário e o orçamento para as reuniões do comitê do projeto.
Planejamento do projeto – Os planos do projeto não são estáticos. Como parte das melhores práticas, os planos devem ser revisitados regularmente e atualizados para refletir nos dados de monitoramento mais recentes . Se isso acontecer, entretanto, a prática da revisitação do plano do projeto precisa incluir oportunidades e recursos para a equipe de projeto e para os principais interessados revisitarem o plano para garantir que ele esteja adequado, preciso e realista.
Planejamento para a implementação do projeto – claramente, o planejamento da implementação consumirá a maior parte do documento de planejamento. O plano precisará fornecer uma implementação detalhada dentro de um cronograma para cada componente do projeto, incluindo ações específicas necessárias para se alcançar os objetivos de impacto do desenvolvimento do projeto.
Planejamento para monitoramento e avaliação do projeto - as atividades relacionadas com o monitoramento e a avaliação são críticas para o sucesso do projeto. Entretanto, essas atividades precisam ser mapeadas no plano do projeto para garantir que elas ocorram. As questões críticas de que o plano deve tratar são “Quem é responsável por coletar dados, processar os dados de monitoramento, analisar os dados, documentar os resultados e comunicar as mensagens?” “Quando essas atividades ocorrerão?” “Como os dados serão usados?” “Haverá uma avaliação? Se sim, quando e de que tipo?” “Que recursos serão necessários para se concluir a avaliação?"
Planejamento da transição do projeto - que etapas precisam ser seguidas no final do projeto? Que atividades precisam ocorrer para o encerramento administrativo e do contrato? O projeto será transferido para outros interessados? Se sim, quais investimentos precisam ser feitos para garantir que a transmissão seja bem-sucedida?
Guia para o PMD Pro 51
2.2.3.3 O planejamento de implementação é abrangente Além de ser equilibrado, o plano do projeto deve tratar de forma abrangente de todo o trabalho necessário para garantir seu sucesso. Um plano de projeto abrangente incluirá todos os elementos de planejamento exigidos para se entregar os resultados diretos do projeto (latrinas construídas, profissionais de saúde treinados, técnicas agrícolas adotadas, etc.), bem como os elementos de planejamento exigidos para se concluir o trabalho indireto relativo ao projeto. Mais especificamente, o plano de projeto abrangente incluirá detalhes relativos a cada um dos seguintes elementos do gerenciamento de projetos:
Figura 26: Elementos de um projeto abrangente
Planejamento do gerenciamento do escopo do projeto - Como o escopo do projeto (seus produtos, serviços e o trabalho necessário para fornecer esses resultados) será gerenciado e controlado por toda a vida do projeto?
Planejamento do gerenciamento de tempo do projeto - Que processos e ferramentas devem ser usados para se estimar os requisitos de tempo do projeto e como os seus calendários serão gerenciados em toda a sua vida?
Planejamento do gerenciamento das justificativas do projeto - Qual necessidade vai atender o projeto e quais recursos serão consumidos pelo mesmo (dinheiro, tempo, reputação organizacional, esforço) contribuindo eficaz e eficientemente com a realização desse benefício?
Planejamento do gerenciamento dos interessados no projeto - Quem são os indivíduos, grupos e instituições cujos interesses podem ser afetados positiva ou negativamente pela execução ou conclusão do projeto? Como esses interessados se envolverão durante toda a vida do projeto?
Guia para o PMD Pro 52
Planejamento do gerenciamento de riscos do projeto - Como o projeto identificará, analisará, monitorará e gerenciará os riscos do projeto?
Planejamento do gerenciamento de recursos do projeto - Que processos e sistemas existem para a aquisição e gerenciamento de equipamentos e materiais, para gerenciamento de finanças e para o gerenciamento de recursos humanos? Quais pontos de referência logísticos precisam ser alcançados para que o cronograma seja bem-sucedido?
No centro desses seis elementos de um projeto completo está o Planejamento da coordenação do projeto. O plano do projeto também deve fornecer um plano de como os diferentes interessados trabalharão juntos. Quais são as normas para a colaboração? As funções e as responsabilidades são claras? Como a equipe do projeto atualizará aos interessados? Que mecanismos de comunicação serão usados? Quem é responsável pela comunicação? O formato dos planos de implementação varia consideravelmente. Em alguns casos, os elementos de um plano completo estão incluídos em um único documento do plano de implementação do projeto. Em outros casos, o plano de implementação do projeto é composto de vários documentos. Em algumas situações o plano do projeto principal é feito com planos separados que fornecem um nível mais profundo de detalhes sobre uma área específica de planejamento de projetos. Por exemplo, um projeto pode ter um plano de implementação principal e um plano específico para o monitoramento e avaliação do projeto. De modo similar, dependendo do tamanho, da complexidade e do risco do projeto, a equipe pode escolher ter documentos separados que tratam especificamente da definição do projeto, da comunicação do projeto, gerenciamento de recursos humanos do projeto, etc. Cada um desses planos deve ser consistente (e ligado) aos outros documentos que compõem o plano de implementação do projeto completo. A intenção do plano de implementação do projeto é fornecer um modelo do projeto. Ele fornece aos integrantes da equipe de projeto um ambiente de baixo custo e baixo risco onde se pode explorar e testar alternativas do projeto; identificar situações ‘e se’; e considerar abordagens alternativas – ANTES que os recursos do projeto tenham sido gastos e antes que o tempo tenha passado.
2.2.3.4 O planejamento de implementação é integrado Lembra-se do triângulo de gestão do projeto? Uma das principais mensagens da imagem do triângulo é a de que os limites do projeto estão conectados, o que impossibilita a alteração de um sem afetar outros. Essa dinâmica continua no contexto do plano de implementação do projeto. Cada um dos elementos do plano de implementação do projeto está conectado aos outros. Isso fica aparente nas extensas conexões que existem entre os diferentes elementos de um plano de implementação completo, alguns dos quais incluem o seguinte: -
As decisões relacionadas ao orçamento dependem da escolha que deve ser feita em relação ao escopo.
-
As decisões relacionadas ao calendário dependem da escolha que deve ser feita em relação à logística.
Guia para o PMD Pro 53
-
As decisões relacionadas com as comunicações dependem da escolha que deve ser feita em relação aos recursos humanos.
-
As decisões relacionadas ao monitoramento dependem da escolha feita em relação ao risco.
Essa lista fornece apenas alguns exemplos dos vários relacionamentos que existem em um plano de projeto completo. O que esses exemplos ressaltam, no entanto, é a importância de garantir que todas essas áreas estejam integradas no plano de implementação.
2.2.3.5 O planejamento de implementação é participativo Os processos participativos são estimulados e priorizados durante cada fase do ciclo de vida do projeto no setor de desenvolvimento. Entretanto, durante as fases de identificação e design do projeto, é comum encontrar situações onde o processo de desenvolvimento da proposta do projeto inclua apenas uma participação limitada dos interessados. Embora essa não seja uma situação desejável, frequentemente é atribuível a várias razões:
Os cronogramas de desenvolvimento da proposta do projeto frequentemente são acelerados devido a limitações de tempo. Frequentemente, os doadores dão às organizações apenas um mês ou dois entre a liberação de uma oportunidade de financiamento e a data de entrega da proposta (em contextos emergenciais esse prazo pode ser de até 24 horas). Em tais situações, as organizações são pressionadas a concluir todas as etapas envolvidas na avaliação, análise e design lógico do projeto e a navegar pelas portas de decisão de início necessárias para desenvolver e enviar uma proposta de projeto. Um dos vários impactos dessas restrições de tempo é que elas impedem as organizações de consultar e colaborar extensamente com os principais interessados do projeto durante a fase de identificação e design do projeto.
As propostas dos projetos frequentemente são desenvolvidas por equipes pequenas. Como esse público das propostas dos projetos geralmente é composto de interessados que têm autoridade sobre as decisões de financiamento (doadores internos ou grupos externos da organização), a equipe de desenvolvimento da proposta do projeto frequentemente é mais concentrada sobre a melhor maneira de ‘vender’ o projeto - e é composta por pessoas que mais sabem escrever e navegar no processo de apresentação de propostas. Isso pode gerar uma diminuição da concentração da comunicação e da colaboração com os principais interessados no processo de desenvolvimento da proposta.
As propostas dos projetos não visam a servir como documentos completos de planejamento. Embora um certo nível de médio a alto dos detalhes esteja incluído na proposta do projeto, frequentemente os detalhes do projeto não são tratados até que o plano de implementação esteja desenvolvido. Nesse ponto, as pessoas mais próximas da implementação do projeto podem ser valiosas em relação à elaboração de estimativas precisas dos esforços (tempo, dinheiro, recursos e equipe) necessários para concluir o trabalho do projeto.
Por todas essas razões, é importante que as equipes de projeto aproveitem a vantagem da oportunidade que o processo de planejamento de implementação do projeto oferece para envolver os interessados mais extensa e completamente possível durante a fase de identificação e design do projeto.
Guia para o PMD Pro 54
O processo de planejamento do projeto deve envolver todos os integrantes da equipe e os interessados adequados, dependendo de sua influência sobre o projeto e seus resultados. A participação no processo de planejamento tem várias vantagens, incluindo: 1. Os interessados têm habilidades e conhecimento que podem ser aproveitados ao se desenvolver estimativas precisas relativas ao orçamento, requisitos de tempo, níveis de esforço e outros recursos necessários para se concluir o trabalho do projeto. 2. Os interessados do projeto frequentemente estão na melhor posição para identificar os seus riscos potenciais e fazer planos para minimizar seu impacto. 3. A nova equipe e/ou a nova equipe parceira pode se beneficiar da orientação aprimorada do projeto quando participam de atividades de planejamento. Essas atividades ajudam a garantir um entendimento comum dos resultados, dos produtos e do projeto. 4. Os interessados envolvidos no processo de planejamento do projeto têm mais probabilidade de assumir a liderança, propriedade e adesão das atividades de implementação do projeto. Ao mesmo tempo, os interessados que se opõem ao projeto possam ser convencidos pela equipe do projeto ouvindo suas preocupações e reformulando o escopo (ou outros elementos do projeto) para superar suas preocupações.
2.2.3.6
O planejamento da implementação é reiterativo
Durante todo o projeto é importante tratar o plano de implementação como um documento ‘vivo’ e não como se fosse estático e imutável. O modelo de fases de projeto do PMD Pro representa expressamente a fase de planejamento do projeto como parte de um circuito com a fase de implementação e a fase de monitoramento, avaliação e controle. Juntas, essas três fases fornecem continuamente ideias e aprendizagem que informam e atualizam o plano de implementação do projeto. Com o tempo, as mudanças no plano de implementação do projeto ajudam a fornecer maiores detalhes sobre o cronograma, os custos e os recursos necessários para se atender o escopo definido do projeto. Esse processo reiterativo de fornecer cada vez mais níveis de detalhes ao plano de implementação do projeto com o tempo geralmente é chamado de ‘planejamento em ondas sucessivas’. A reiteração, por definição, é o ato de repetir uma tarefa uma segunda, terceira ou mais vezes para alcançar o resultado desejado. O planejamento em ondas sucessivas pode ser especialmente útil em situações em que as informações do projeto são difíceis de coletar ou mudam muito rapidamente (por exemplo, em contextos de alto risco ou emergenciais). Nessas situações, conforme as novas informações do projeto são coletadas, dependências adicionais, requisitos, riscos, oportunidades, considerações e limites serão identificados. Mudanças significativas em qualquer uma dessas áreas que ocorra durante toda a vida do projeto podem disparar a necessidade de alterar um ou mais elementos do plano de implantação. O planejamento em ondas sucessivas, entretanto, não é limitado exclusivamente a contextos emergenciais. Uma organização que emprega uma política de planejamentos sucessivos em seus projetos de desenvolvimento é o Banco de Interamericano de Desenvolvimento. Cada um de seus
Guia para o PMD Pro 55
projetos é aprovado através de uma proposta multianual. Os destinatários do projeto, entretanto, devem apresentar planos de operação anuais das atividades do projeto. Esses planos anuais servem não apenas para garantir que as estimativas do trabalho do projeto sejam precisas e relevantes, mas também servem como pontos de decisão para decidir se deve continuar ou não com o projeto conforme ele foi concebido no plano multianual ou se deve revisitar o plano, se necessário. O processo de análise e aprovação dos planos anuais serve como oportunidade para verificar os pressupostos que serviram como a base do design do projeto, bem como para confirmar a disponibilidade dos recursos necessários, avaliar o contexto/riscos do projeto externo e monitorar a lógica vertical do projeto.
Guia para o PMD Pro 56
2.2.4 FASE 4: IMPLEMENTAÇÃO 19 DO PROJETO
Figura 27: Fase de implementação do projeto O trabalho diário de implementação do projeto é liderar e gerenciar a aplicação do plano de implementação do projeto. Essa tarefa pode ser relativamente simples ou pode se tornar extremamente complexa, dependendo da natureza do projeto. Como em todo o gerenciamento de projeto, o sucesso durante a implementação é, em certa medida, uma arte (gerenciar pessoas, liderar equipes, comunicar-se com clareza), mas também é uma ciência. Em sua forma mais simples, a responsabilidade do gerente do projeto é implementar o plano do projeto. Entretanto, após uma inspeção mais atenta, fica claro que o gerente de projetos deve aplicar várias habilidades técnicas para ter sucesso durante a implementação. Essas habilidades incluem:
O gerenciamento de problemas
O gerenciamento de pessoas
O gerenciamento de controles internos
2.2.4.1 O gerenciamento de problemas No mundo do boxe, diz o ditado que “todo mundo tem um plano...até ser atingido.” Existe a mesma dinâmica ao se gerenciar um projeto. Exatamente como um boxeador no ringue, a vida de um gerente de projetos é arriscada, complexa e, algumas vezes, simplesmente bagunçada. Mesmo com um plano completo e detalhado, haverá “socos” (problemas) que desafiarão o projeto durante sua implementação.
19
Pode se utilizar a palavra implementação como sinônimo de execução do projeto.
Guia para o PMD Pro 57
Como todo bom boxeador, o gerente de projetos deve aprender como gerenciar os problemas, navegar pela complexidade e adaptar o plano para refletir a realidade mais recente. Um problema é uma decisão não tomada, uma situação ou um problema que afetará significativamente o projeto e que a equipe de projeto não poderá resolver imediatamente. O gerenciamento de problemas consiste em ter um processo de identificação desses problemas e gerenciá-los até que estejam resolvidos. A solução de problemas frequentemente está além da autoridade da equipe. Entretanto, mesmo que um problema precise ser submetido ao nível superior ou delegado para uma outra pessoa resolvê-lo, ele ainda precisará ser acompanhado pelo gerente de projetos. O gerente de projetos precisa estar pronto durante toda a fase de implementação do projeto para aplicar recursos para tratar e resolver esses problemas. O gerenciamento de problemas é um empenho colaborativo. Consequentemente, todos os membros da equipe do projeto são responsáveis pelo seguinte:
Identificação dos problemas do projeto;
Contribuição para a resolução dos problemas do projeto (Observação: a experiência demonstra que as pessoas mais próximas do trabalho geralmente sabem como melhor resolver os problemas. Portanto, é trabalho do gerente de projetos definir um ambiente em que o integrante da equipe do projeto esteja em posição de resolver o maior número possível de problemas em seu nível);
Levar os problemas importantes para o gerente de projetos o mais rápido possível.
Não obstante, embora o gerenciamento de problemas seja um empenho colaborativo, o gerente de projetos é, em última instância, responsável pelo gerenciamento de problemas (lembre-se de que em uma tabela RECI existe apenas um indivíduo responsável por uma tarefa/atividade). Ter um processo de gerenciamento de problemas bem documentado é fundamental para comunicar e por em prática esse processo na equipe. Se os problemas não forem resolvidos, as consequências negativas podem incluir o seguinte:
Incapacidade de cumprir os prazos, os custos e o cronograma do projeto; Qualidade ruim ou inaceitável do projeto; Reputação ruim entre as comunidades, doadores e outros; e Disputas pós-implementação.
Como um gerente de problemas, o gerente de projetos precisa gerenciar todos os processos de gerenciamento de problemas: 1. Identificação e acompanhamento de problemas – identificação de questões, decisões e outros problemas pendentes antes que afetem negativamente o projeto. Como tal, o processo de identificação e acompanhamento está intimamente relacionado com o tópico do gerenciamento de risco (que é explorado no capítulo monitoramento, avaliação e controle deste documento). Assim, a fase de Implementação e a fase de Monitoramento, avaliação e controle estão intimamente ligadas e normalmente funcionam em paralelo. Guia para o PMD Pro 58
2. Análise do problema – entender o problema suficientemente para considerar as consequências dos planos de ação desenhados para resolvê-lo. 3. Comunicação do problema – comunicar os problemas ao nível certo da organização para que sejam resolvidos. Além disso, é importante comunicar quando e como os problemas são resolvidos. 4. Controle do problema – o gerente de projetos é responsável por criar um ambiente em que a equipe do projeto e os parceiros de implementação possam executar ações para garantir que os problemas sejam resolvidos de maneira oportuna e efetiva. O processo de controle de problemas está intimamente relacionado às atividades de monitoramento, avaliação e controle e deve incluir a criação e o acompanhamento de um plano para resolver os problemas. A ferramenta de controle mais importante é o registro de problemas, que os resume, descreve seu status atual e identifica quem é o responsável do acompanhamento dele. O registro de problemas pode empregar uma série de formas técnicas, desde papel até um banco de dados totalmente integrado. Um formato de exemplo pode ser encontrado na tabela de registro de problema abaixo. Figura 28: Registro de problemas Referência do problema
Informado por
Descrição
Data do relatório
Delegado a
Data da delegação
Situaçã o atual
Data de atualiza ção
Resolução
Tenha em mente que um sistema de gerenciamento de problemas perfeito será caro, se não impossível de se alcançar. É normal aceitar um nível razoável de imperfeição com base nos cálculos das relações entre valor x custo, benefício, risco e tempo.
2.2.4.2 O gerenciamento de pessoas Nunca é demais enfatizar a importância do gerenciamento competente de pessoas. Os gerentes de projetos trabalham em equipes e, frequentemente, só conseguem atingir seus objetivos como resultado do compromisso, da cooperação e das contribuições das pessoas da equipe do projeto. Como resultado, o gerenciamento de pessoas pode se tornar o trabalho mais importante e mais difícil do gerente de projetos. Frequentemente, quando pensamos nos gerentes de projetos, especialmente talentosos no gerenciamento de pessoas, tendemos a nos concentrar em seu domínio de habilidades interpessoais no gerenciamento de pessoas. Esses são os gerentes de projeto especialmente eficazes na motivação dos Guia para o PMD Pro 59
integrantes da equipe, na comunicação da visão, na capacitação da equipe, no reconhecimento das realizações, em ouvir, liderar pelo exemplo, resolver conflitos e gerar confiança. Todas essas habilidades interpessoais estão relacionadas com as competências interpessoais do gerente de projetos e são extremamente importantes para o sucesso do projeto. Portanto, os gerentes de projetos devem se esforçar para aprimorar a sua capacidade de liderar, motivar, inspirar, mediar, comunicar e encorajar. Isso não significa, entretanto, que não haja habilidades técnicas envolvidas no gerenciamento de pessoas. Um plano de projeto completo não depende exclusivamente das habilidades interpessoais do gerente de projetos para garantir o sucesso do gerenciamento de pessoas. Ao contrário, um plano de projeto completo identificará as atividades concretas necessárias para se gerenciar todos os elementos da equipe de projeto proativamente. Essas atividades concretas serão implementadas durante a fase de implementação do projeto e incluirão:
Formação de uma equipe de projeto – Como parte da função de gerenciamento da equipe, o líder da equipe de projeto deve ser claro em seus sistemas para identificar candidatos para a equipe, entrevistar candidatos, identificar os critérios de seleção e fazer as seleções finais da equipe de projeto.
Criação das descrições de cargo da equipe – As descrições de cargo da equipe incluem a lista de deveres, das funções e responsabilidades dos integrantes da equipe. As descrições de cargo não são usadas apenas para recrutar, orientar e gerenciar a equipe, mas também são usadas para avaliar o desempenho individual dos integrantes da equipe.
Documentação do organograma do projeto – Os organogramas representam os relacionamentos hierárquicos entre os integrantes da equipe.
Desenvolvimento da equipe do projeto – Que habilidades são necessárias? Quais são os treinamentos necessários? Existem exigências de certificação. Realização da avaliação de desempenho – As avaliações de desempenho são avaliações formais ou informais documentadas do desempenho dos integrantes da equipe. Após analisar as informações, os gerentes de projeto podem identificar e resolver problemas, reduzir conflitos e aprimorar o trabalho geral da equipe.
Criação de normas de comunicação da equipe – Como líder da equipe de projeto, o gerente de projetos deve planejar concretamente as comunicações (através de reuniões, oficinas, relatórios, memorandos, boletins, blogs, etc.) que permitam que a equipe do projeto compartilhe informações, trabalhe ativamente para identificar problemas e conflitos e interaja criativamente para resolver esses problemas.
2.2.4.3 O gerenciamento de controles internos Um dos desafios do gerente de projetos é supervisionar os valiosos ativos que foram alocados para conduzir o trabalho do projeto. Para auxiliar nesse desafio, devem-se por na prática sistemas de controle interno para fornecer uma garantia aceitável em relação ao uso responsável dos ativos do projeto. Os processos de controle interno devem ser planejados com os seguintes objetivos:
Guia para o PMD Pro 60
Promover a eficácia e a eficiência das operações;
Aumentar a confiabilidade dos resultados do projeto;
Promover a conformidade com as leis e regulamentos aplicáveis;
Proteger os recursos da organização, tanto físicos (ex.: maquinário e propriedades) como intangíveis (ex.: reputação, propriedade intelectual);
Reduzir o risco de fraude e corrupção.
Controles internos incluem os processos através dos quais os recursos da organização são direcionados, monitorados e medidos. Eles desempenham um papel importante na prevenção e na detecção de fraudes e na proteção dos recursos da organização, tanto físicos (maquinário, propriedades) como intangíveis (reputação ou propriedade intelectual como marcas registradas). No nível organizacional, os objetivos de controle interno estão relacionados com a confiabilidade dos relatórios financeiros, do retorno oportuno sobre o alcance dos objetivos operacionais ou estratégicos e a conformidade com leis e regulamentos. Um componente chave da capacidade organizacional do projeto inclui a definição de controles internos que tratam de maneira abrangente a totalidade dos sistemas de suporte, administrativo e logístico necessários para uma implementação bem-sucedida. As áreas que se beneficiam dos controles internos incluem
Capacidade e sistemas de recursos humanos As políticas de recursos humanos documentadas estão em conformidade com as leis locais e com os regulamentos da organização? Existem sistemas para controle de horário, análises de desempenho e desligamento de funcionários?
Serviços de abastecimento Existem sistemas para selecionar fornecedores? Existem critérios de seleção de fornecedores? Existem sistemas para gerenciar fornecedores? Existem sistemas similares para consultores?
Financeiro Existem sistemas para o gerenciamento do dinheiro? Gerenciamento de despesas? Relatórios financeiros? Há uma segregação dos deveres para os cargos financeiros?
Inventário Existem sistemas para a identificação e o acompanhamento do inventário? Existem sistemas para o uso/transferência/descarte de equipamentos após o encerramento do projeto?
Contratos e acordos Existem sistemas para o gerenciamento de concessões e contratos? Existem sistemas para gerenciar relacionamentos com organizações parceiras?
Infraestrutura Que sistemas de comunicação existem? Telefones, internet, rádio? Que sistemas para gerenciar veículos e transportes existem?
Guia para o PMD Pro 61
Protocolos de segurança Existe a necessidade de controles especiais de segurança? Orientação para viagens? Programas de acompanhamento? Outros?
Gerenciamento de frota Existem registros de quilometragem que controlam o uso de veículos de serviço?
Gerenciamento de informações Há um sistema de manutenção de registros (papel/eletrônico) em vigor? Existem normas e políticas para o gerenciamento das informações? Os documentos, contratos e recibos estão acessíveis para atender as exigências da auditoria do projeto?
Em resumo, é importante reconhecer que os controles internos podem fornecer apenas uma garantia aceitável – não uma garantia absoluta – em relação à conquista dos objetivos da organização. Além disso, os controles internos inadequados ou inacessíveis reduzem a produtividade, aumentam a complexidade dos sistemas, aumentam o tempo necessário para concluir os processos e não agregam valor às atividades. Entretanto, bons controles internos são essenciais para garantir a conquista das metas e objetivos. Eles garantem operações eficientes e eficazes que conquistam os objetivos do projeto e ainda protegem os funcionários e os ativos.
Guia para o PMD Pro 62
2.2.5 FASE 5: MONITORAMENTO, AVALIAÇÃO E CONTROLE DO PROJETO
Figura 29: Monitoramento, avaliação e controle do projeto Mesmo os projetos bem desenhados, planejados de modo abrangente, que contam com todos os recursos e que são executados meticulosamente enfrentam desafios. Esses desafios podem ocorrer a qualquer momento durante a vida do projeto e a equipe do projeto deve trabalhar para revisitar continuamente o design, o planejamento e a implementação do projeto para confirmar que são válidos e determinar se são necessárias ações corretivas quando o desempenho do projeto se desviar significativamente de seu design e do seu plano. Esse é o propósito da fase de monitoramento, avaliação e controle do projeto. As três principais categorias de atividades que ocorrem durante a fase de monitoramento, avaliação e controle sejam:
Monitoramento do projeto Avaliação do projeto Controle do projeto
Essas atividades devem ocorrer continuamente, durante toda a vida do projeto (por isso, o modelo de projeto por fases do PMD Pro inclui a fase de monitoramento, avaliação e controle como uma base que se estende das primeiras tarefas de identificação e design do projeto até as últimas tarefas da fase de transição para o final do projeto. Por exemplo, as primeiras medições e cálculos dos indicadores do projeto já estão sendo desenvolvidas durante a fase de identificação e design do projeto; o plano de monitoramento é desenvolvido durante a fase de planejamento; as visitas de monitoramento são conduzidas durante a fase de implementação e muitas atividades de avaliação são realizadas durante a fase de transição para o final do projeto.
Guia para o PMD Pro 63
2.2.5.1 Diferenciação entre monitoramento, avaliação e controle Antes de examinar cada uma das três categorias de atividades da fase de monitoramento, avaliação e controle do projeto em detalhe, primeiro é importante diferenciá-las. O monitoramento acompanha o trabalho operacional do projeto. Ele responde perguntas como “As atividades foram concluídas conforme o planejado?” “Os produtos foram produzidos como previsto?” “O trabalho do projeto está progredindo conforme projetado?” Em um nível fundamental, é um processo passivo, pois não muda nada. Ao contrário, ele informa ao gerente de projetos onde o desempenho do projeto está em termos de dinheiro, tempo, risco, qualidade e outras áreas de progresso do projeto. Em seu núcleo, os objetivos, a cronologia e as atividades do monitoramento do progresso do projeto são, talvez, melhor identificados através da tabela a seguir: Figura 30: O quê, porquê, quando e como do monitoramento O quê Por quê?
Quando Como
Uma análise contínua do progresso do projeto nos níveis de atividade e resultados/produtos Identificar a ação corretiva necessária Analisar a situação atual Identificar problemas e encontrar soluções Descobrir tendências e padrões Manter as atividades do projeto no cronograma Medir o progresso em relação aos produtos Tomar decisões sobre recursos humanos, financeiros e materiais Contínuo Visitas de campo Registros Relatórios
Se você precisasse examinar os indicadores encontrados na estrutura lógica do projeto, as atividades de monitoramento do progresso correspondem aos dois níveis inferiores do quadro lógico (atividades e resultados/produtos). A tabela a seguir fornece alguns indicadores potenciais de monitoramento de três áreas programáticas diferentes de intervenção (agricultura, microfinanciamento e água). Figura 31: Exemplos de indicadores de monitoramento Exemplo de agricultura Produtos – 'Os produtos tangíveis ou serviços’
Número de grupos de fazendeiros criados - competência das pessoas treinadas
Atividades – ‘Tarefas ou ações realizadas para implementar as intervenções do projeto’
Número de visitas da equipe às comunidades agrícolas Número de sessões de treinamento organizadas
Exemplo de microfinanciamento Número de clientes que recebem e usam o crédito corretamente Número de clientes que participam dos programas de poupança Número de visitas da equipe às vilas Número de sessões de treinamento bancário - competência das pessoas treinadas
Guia para o PMD Pro 64
Exemplo de água Número de novos sistemas de água instalados e funcionando corretamente Número de comunidades organizadas para a instalação de sistemas de água
A avaliação do projeto tende a se concentrar no acompanhamento do progresso nos níveis mais altos da estrutura lógica – isto é, o objetivo e impactos do projeto. As avaliações tendem a explorar questões como, “o projeto é bem-sucedido em conseguir seu objetivo?” “O projeto está contribuindo com seu impacto?” Os dados de avaliação são coletados e analisados menos frequentemente e na maioria dos casos exigem uma intervenção mais formal (frequentemente de conselheiros técnicos ou avaliadores externos) para mostrar os resultados do projeto. Figura 32: Exemplos de indicadores de avaliação Exemplo de agricultura Impacto – ‘Os objetivos do projeto estão contribuindo com um impacto maior dentro das comunidades alvo?’ Objetivo – ‘Os resultados/produtos do projeto estão gerando o objetivo desejados?’
% de famílias que produzem alimento suficiente para cobrir períodos de escassez Diminuição % de crianças mal nutridas % de famílias que adotam técnicas aprimoradas % de hectares cobertos com as técnicas aprimoradas
Exemplo de microfinanciamento Aumento da renda doméstica líquida Mudança positiva nos padrões de consumo domésticos % de casas com aumento de capital de giro
Exemplo de água Morbidade e mortalidade reduzidas devido às doenças transmitidas pela água % de casas que usam suprimento de água seguro Aumento no consumo per capita de água
*Observação – Embora se espere que os projetos contribuam para se alcançar os indicadores de nível do impacto, NÃO é responsabilidade do projeto alcançar (ou monitorar) os impactos. O controle do projeto envolve a definição de sistemas e de processos de tomada de decisão para gerenciar as discrepâncias entre os planos do projeto (em termos de escopo, custo, cronograma, etc.) e a realidade da implementação do projeto. Também envolve a definição de como as discrepâncias e mudanças do projeto são gerenciadas, documentadas e comunicadas aos interessados.
Guia para o PMD Pro 65
2.2.5.2 O plano de monitoramento e avaliação do projeto
Conexão da estrutura lógica e do plano de monitoramento e avaliação
O gerenciamento do projeto é reiterativo!
Um elemento crucial do plano de implementação abrangente é o plano de monitoramento e avaliação que identifica o sistema para rastrear e medir o progresso, o desempenho e o impacto do projeto. O tempo adequado para desenvolver o plano de monitoramento e avaliação formal é depois do projeto ser aprovado para financiamento, mas antes do início das atividades do projeto. Entretanto, o trabalho preparatório que contribui com o plano começará muito antes desse ponto.
Conforme indicado no modelo de projeto por fases do PMD Pro, a fase de monitoramento, avaliação e controle se estende por toda a vida do projeto. A estrutura lógica do projeto é a primeira etapa no desenvolvimento do plano integral de monitoramento e avaliação do projeto. Os indicadores e os meios de verificação incluídos na estrutura lógica acabarão se tornando os fundamentos do plano integral de monitoramento e avaliação do projeto.
Um design competente do projeto facilita a criação do alinhamento de sistemas de monitoramento e avaliação completos. O plano de monitoramento e avaliação se expande nos indicadores de progresso iniciais fornecidos na estrutura lógica e na proposta do projeto e fornece detalhes adicionais para cada um dos níveis da estrutura lógica do projeto. Embora o formato dos planos de monitoramento e avaliação do projeto variem, o plano geralmente inclui as seguintes informações:
Que indicadores estão sendo monitorados e avaliados? Que informações são necessárias para acompanhar o indicador? Quais são as fontes de informação? Que métodos de coleta de dados são adequados? Quem coletará as informações? Com que frequência elas serão coletadas? Quem receberá e usará os resultados?
Embora haja muitas considerações (orçamentos, recursos, exigências dos doadores, etc.), para se ter em mente ao se identificar quais dados coletar no plano de monitoramento e avaliação do projeto, a consideração mais importante deve ser a utilidade dos dados. Ao identificar os indicadores, a equipe do projeto deve sempre perguntar “o que essas informações nos dirão?” e “quais são as melhorias esperadas nas tomadas de decisão resultantes desses dados?”
Guia para o PMD Pro 66
Figura 33: Exemplo de um formato de plano de monitoramento e avaliação de projeto Hierarquia Indicadores Definição Informações Fontes de Métodos de Quem Frequência Usuários dos termos necessárias dados coleta de coleta da coleta chave dados Impactos Objetivo Resultados /Produtos Atividades Insumos*
* Observe que alguns planos de monitoramento e avaliação não apenas rastreiam o progresso em relação às atividades, produtos, objetivo e impacto consistentes com a estrutura lógica do projeto, mas também monitoram os insumos ou recursos necessários para implementar as atividades do projeto. O método de coletar dados para os indicadores depende de vários critérios, dois dos quais incluem o seguinte: Que tipo de dados o projeto está tentando coletar?
Métodos quantitativos concentram-se na intensidade da intervenção, fornecendo informações objetivas e confiáveis que permitem uma generalização de resultados para uma população mais ampla. O método quantitativo usado mais comumente é um questionário padronizado administrado para uma amostra aleatória de indivíduos ou residências dentro de uma população alvo.
Métodos qualitativos concentram-se em uma interação direta e profunda com participantes, fornecendo dados ricos e detalhados. Os métodos qualitativos usados comumente incluem técnicas de estimativa rural participativa, grupos focais, entrevistas com informantes chave ou com a comunidade e observação.
Qual é o nível aceitável de custo e complexidade da coleta de dados?
O custo e a complexidade da coleta de dados pode variar consideravelmente com base no método da coleta usado. O gráfico abaixo fornece uma comparação de vários métodos de coleta de dados (quantitativo e qualitativo) em termos de custo e complexidade.
Guia para o PMD Pro 67
Figura 34: A relação custo/complexidade do monitoramento de dados Independentemente do formato que um projeto emprega para definir seu plano de monitoramento e avaliação, como um padrão mínimo, todo o sistema de monitoramento deve incluir pelo menos seis elementos essenciais: Figura 35: Seis elementos de um sistema de monitoramento Indicadores
Claramente definidos Com parâmetros e critêrios Sistematicamente medidos
Cronograma e orçamento
Tempo e dinheiro são alocados para tarefas de monitoramento Processos de detalhes de cronograma para coleta de dados, análise, resumo, avaliação e retorno
Equipe/parceiros
Responsabilidades de monitoramento identificadas claramente Competências Planejar atividades de monitoramento com a comunidade Capacitar os integrantes da comunidade em sistemas de monitoramento baseados na comunidade Usar técnicas de monitoramento participativo Reunir e verificar dados de monitoramento Processar dados de monitoramento
Um ciclo de dados inteiro
Incluindo um ciclo inteiro para gerenciar os dados de monitoramento: 20 1. Coleta; 2. Revisão; 3. Resumo; 4. Análise; 5. Realimentação
Gerenciamento de dados
Existem procedimentos usados para garantir a integridade dos dados e seu armazenamento adequado
Vínculo com o próximo nível
O sistema de monitoramento de projeto está vinculado ao próximo nível do programa ou portfólio da organização.
20
Feedback
Guia para o PMD Pro 68
O gerenciamento do projeto é abrangente!
Monitoramento do progresso do projeto e risco do projeto
Embora a atenção do plano de monitoramento e avaliação esteja concentrada no acompanhamento do progresso do projeto em relação aos indicadores em cada um dos níveis do quadro lógico do projeto, a equipe também deve acompanhar o risco em toda a vida do projeto. O monitoramento do risco, em comparação com o monitoramento do progresso, envolve pesquisar continuamente o horizonte do projeto e prever a possibilidade de que algo pode sair errado ou não sair como planejado. O gerente de projetos precisa pesquisar de modo contínuo e abrangente os riscos que têm o potencial de ameaçar o sucesso do projeto e gerenciar essas ameaças ativamente por toda a vida do projeto. A prática do gerenciamento de risco é uma das seis disciplinas de gerenciamento de projeto discutida mais detalhadamente na Seção 3 do Guia do PMD Pro.
2.2.5.3 Abordagens de avaliação de projeto Ao planejar as atividades de avaliação de projeto a serem incluídas no plano de monitoramento e avaliação do projeto, as organizações devem escolher sua abordagem de avaliação com base nos objetivos de aprendizagem. Três abordagens de avaliação extensamente usadas no setor de desenvolvimento são as avaliações finais, as avaliações intermediárias e as avaliações ex-post. As avaliações finais, ordenadas frequentemente por uma agência financiadora ou exigidas pela própria política da organização de desenvolvimento, são realizadas no final do projeto. As perguntas comuns podem incluir:
O projeto teve sucesso ao alcançar os resultados, metas e o impacto desejado? O projeto foi relevante, efetivo e eficiente? O projeto tem o potencial de ser sustentável em suas operações e impacto? A teoria expressa na estrutura lógica foi confirmada?
As avaliações intermediárias oferecem a vantagem de responder a muitas das mesmas perguntas levantadas através das avaliações finais, mas também fornecem a oportunidade de fornecer sugestões para melhorar a eficiência e o impacto do projeto enquanto as atividades ainda estão em andamento. As avaliações ex-post examinam o impacto do projeto em um período definido após sua conclusão e, algumas vezes, após seu encerramento final. Algumas vezes é chamada avaliação de impacto, a avaliação ex-post mede a extensão até a qual o objetivo e impactos do projeto são atingidos através da apropriação dos participantes. As descobertas da avaliação ex-post podem ser um meio especialmente útil de usar evidências para defender uma abordagem melhorada de desenvolvimento. Por exemplo, um Guia para o PMD Pro 69
relatório ex-post foi usado por uma organização de desenvolvimento para convencer um doador a apoiar um treinamento em habilidade aritmética e alfabetização dentro de um programa de microfinanciamento.
2.2.5.4 Controle do projeto Ao refletir sobre a evolução, Charles Darwin observou que ‘não é o mais forte a espécie que sobrevive, nem a mais inteligente, mas aqueles mais adaptáveis às mudanças.’ De modo similar, os gerentes de projetos também devem reconhecer que as mudanças serão frequentemente ou quase sempre necessárias para o sucesso de seus projetos. Essas mudanças são normais, aceitáveis e (às vezes) até desejáveis. Os planos de projeto não visam ser documentos estáticos e deve-se ter cuidado para se garantir que não sejam considerados estáticos ou excessivamente difíceis de mudar. As equipes de projeto precisam se lembrar que um plano de implementação é um “meio para um fim" e não um fim em si mesmo! Mais especificamente, a equipe precisa reconhecer as armadilhas que existem quando os planos de projeto são tratados como documentos estáticos, incluindo:
Não reconhecer que os planos originais são imperfeitos; Medo de reconhecer para doadores externos (e internos) que o plano original não é mais viável; Relutância em revisitar os documentos originais para criar um plano novo e mais adequado; Falta de clareza com relação a qual processo precisa ser seguido para atualizar os documentos do projeto.
Entretanto, quando trata-se de gerenciar solicitações de mudança, o gerente de projetos deve equilibrar duas considerações habilmente: Por um lado os documentos do projeto não devem ser considerados como imutáveis independentemente da realidade de mudança do projeto. Por outro lado, deve-se ter cuidado para não fazer as mudanças de modo imprudente ou sem rigor. Para gerenciar esse equilíbrio, os gerentes de projeto precisam estabelecer normas que os permitam incorporar flexivelmente as mudanças de projeto quando necessário, mas também precisam garantir que as alterações propostas do projeto sejam gerenciadas através de um processo de controle de mudanças rigoroso e integrado que assegure que qualquer mudança do projeto seja: a. Gerenciada através de um processo formal de gerenciamento de mudança; b. Analisada para garantir que as implicações dessas mudanças sejam muito bem pensadas; c. Documentada para ilustrar o impacto completo em todos os elementos integrados do projeto d. Comunicada aos principais interessados do projeto.
2.2.5.5 Mudanças do projeto: Tolerâncias e transferência para o nível hierárquico superior Uma questão que precisa ser respondida durante o gerenciamento de problemas é se a mudança proposta do projeto está dentro dos limites da autoridade do gerente de projetos. Se o problema e a mudança proposta estiverem baixo a autoridade do gerente de projetos, o passo seguinte será o gerente de projetos tomar as providências para solucioná-lo. Se o gerente de projetos não tiver autoridade para implementar a mudança proposta, ela precisará ser transferida para o nível hierárquico superior. Guia para o PMD Pro 70
O desafio será diferenciar quais problemas e respostas propostos estão dentro da autoridade do gerente de projetos e quais não estão. Para responder essa questão, é importante primeiro explorar o tópico da tolerância e identificar o qual nível de tolerância foi definido para o projeto. As tolerâncias do projeto definem os limites de desempenho dentro dos quais o gerente de projetos pode manter a autonomia. As tolerâncias positivas (o valor até o qual você pode ir) são as mais comuns. Entretanto, as tolerâncias negativas também são muito importantes. Por exemplo, ficar abaixo do orçamento significa que o dinheiro da empresa está desnecessariamente amarrado por um certo tempo. As tolerâncias são uma parte principal de ser capaz de trabalhar autonomamente como gerente de projetos. Ter uma tolerância significa que o gerente de projetos tem uma certa flexibilidade em relação aos limites do projeto. Na prática, isso significa que o projeto pode estar um pouco abaixo ou um pouco acima e não precisa voltar continuamente para a governança de projeto (ou para o doador) e solicitar aprovação para as mudanças do projeto. As duas tolerâncias usadas mais frequentemente são orçamento e tempo, apesar de poderem ser qualquer uma das seguintes áreas: Tolerância de tempo – o tempo em que a execução do projeto pode atrasar ou adiantar em relação à data planejada. Tolerância de custo - a porcentagem ou o valor em dinheiro com que o projeto pode ultrapassar ou ficar abaixo do orçamento planejado. Tolerância de escopo – é medida como uma variação acordada da descrição do produto e qualquer variação potencial deve ser documentada na estrutura de divisão de produto. Tolerância de risco – fornece um ponto de referência para quais riscos você deve levar à comissão de projeto. Tolerância de qualidade – limites que definem o desenvolvimento aceitável para um produto, documentado nas descrições de produto. Tolerância de benefícios – limites de desempenho aceitável do projeto no nível dos resultados. Durante a fase de definição do projeto, as tolerâncias devem ser definidas de modo a identificar os parâmetros dentro dos quais a entrega do projeto pode ser aceitável – os níveis gerais de tolerância do 21 projeto. As tolerâncias precisam ser definidas e aprovadas pela estrutura de controle do projeto. Pode ser a governança de projeto, entretanto, se ela não existir, as tolerâncias precisarão ser definidas pelo patrocinador ou doador do projeto. Se, em qualquer momento durante o monitoramento, o gerente de projetos perceber que o nível de tolerância pode ser ultrapassado, o corpo de governança do projeto deve ser consultado.
21
Estrutura de governo ou governança do projeto, corpo de governança.
Guia para o PMD Pro 71
Mapeamento do processo de aprovação de solicitação de mudanças Quando estiver claro qual nível de autoridade é necessário para tomar decisões em uma solicitação de mudança de projeto, a próxima etapa é responder às seguintes questões adicionais:
A solicitação de mudança é permissível conforme os acordos existentes? Os impactos da solicitação da mudança sobre o cronograma, os recursos, os custos e a qualidade foram explorados e aprovados? Os interessados do projeto foram consultados em relação à mudança proposta? O plano do projeto completo e integrado foi atualizado para documentar as implicações da alteração proposta? Os recursos (tempo, materiais, dinheiro, recursos humanos) estão prontos para implementar a mudança proposta?
Um mapa de solicitação de mudança como o apresentado na Figura 36 pode fornecer recursos úteis para identificar e controlar o processo de gerenciamento de mudanças do plano do projeto.
Guia para o PMD Pro 72
Figura 36: Mapa ilustrativo do projeto para uma solicitação de mudança
Entretanto, embora um mapa de processo como da Figura 36 seja útil, é extremamente importante reconhecer que ele varia substancialmente conforme a estrutura de governança do projeto, as relações dos doadores, as exigências contratuais, os parceiros de implementação, etc. Portanto, é importante personalizar o diagrama de processo com a realidade do contexto operacional do projeto. Independentemente do mapa de processo específico para solicitação de mudanças, é especialmente importante que qualquer mudança seja gerenciada de modo integrado. Isso quer dizer, garantir que
Guia para o PMD Pro 73
qualquer revisão do plano do projeto identifique claramente as implicações que a mudança possa ter em outras seções do plano de gerenciamento do projeto. Pessoas familiarizadas com cada uma das áreas do plano do projeto (escopo, custo, cronograma, risco, serviços de suprimento, qualidade, etc.) precisarão avaliar o impacto das mudanças propostas sobre o plano inteiro do projeto. Quando houver consenso de que a mudança proposta será benéfica e que as implicações serão aceitáveis, a solicitação de mudança poderá ser aprovada. Quando aprovado, o plano do projeto revisado deve ser comunicado a toda a equipe de projeto para que todos trabalhem com o plano atualizado.
Uso de modelos de planejamento reiterativo para gerenciar mudanças Essa situação soa familiar? Um projeto de três anos entrou no segundo ano de sua fase de implementação. Em geral, o projeto está indo bem. A lógica da intervenção do projeto ainda é válida e os resultados/produtos ainda são viáveis. Existe, no entanto, um problema significativo com o plano do projeto. A realidade de campo da implementação de dois anos tem diferenças com o que foi previsto quando os planos do projeto foram desenvolvidos 20 meses antes. Está cada vez mais claro que algumas estimativas orçamentárias foram significativamente subestimadas, enquanto outros componentes não são necessários devidos às mudanças nas funções dos parceiros de implementação. Embora esses desafios possam ser tratados através de uma combinação de gerenciamento de problemas e solicitações de mudanças, alguns projetos foram tratados através de uma estratégia de planejamento reiterativo de projeto. Em um modelo de planejamento reiterativo, um plano de projeto inicial é estabelecido quando o projeto é aprovado. Entretanto, reconhecendo-se que a realidade de campo da implementação do projeto pode/irá variar com o tempo, os detalhes do plano do projeto não são definidos até posteriormente. Em vez de estabelecer um único plano de implementação detalhado, os projetos apoiam um modelo de planejamento que inclui atualizações periódicas dos planos de implementação. Nos projetos de desenvolvimento, esses planos periódicos geralmente são feitos anualmente e chamados de planos operacionais anuais. Em um projeto de resposta emergencial, esse prazo, para os planos atualizados, deve ser significativamente mais curto. O ECHO, o grupo de proteção civil e auxílio humanitário da comissão europeia, por exemplo, permite um ajuste das propostas de projeto uma vez a cada três meses com base em um entendimento sobre quem precisa autorizar as alterações para cada um dos níveis da estrutura lógica. Ao adotar uma abordagem reiterativa de planejamento de projeto, as organizações tem mais flexibilidade para acomodar mudanças. A equipe do projeto consegue revisitar o plano de implementação do projeto no início de cada período para: 1. Confirmar a lógica, os riscos, as oportunidades, os pressupostos e os limites. 2. Atualizar e revisar as atividades, cronogramas e recursos do projeto. 3. Garantir que as atividades de intervenção do projeto sejam concentradas no tratamento dos riscos e problemas que apresentam as ameaças mais imediatas ao sucesso do projeto.
Guia para o PMD Pro 74
2.2.6 FASE 6: TRANSIÇÃO PARA O FINAL DO PROJETO
Figura 37: Transição para o final do projeto Um projeto, por definição, é um esforço temporário, que tem um início e um fim definidos (geralmente limitados por data, mas possivelmente pelo financiamento ou resultados/produtos). A natureza temporária dos projetos os diferencia das operações comerciais normais de uma organização (ou ‘operações em andamento’, que são produtos ou serviços que produzem trabalho funcional repetitivo permanente ou semipermanente). No campo de desenvolvimento, frequentemente encontram-se projetos que estão em operação há anos – com uma fase do projeto continuando o trabalho das fases anteriores. Essa observação salienta a realidade que o fim de um projeto do setor de desenvolvimento é frequentemente caracterizado mais precisamente como uma fase de transição em vez de um encerramento definido rigidamente. Na prática, existem quatro situações de transição para projetos de desenvolvimento. Essas quatro situações estão apresentadas na tabela abaixo.
Guia para o PMD Pro 75
*O *Encerramento também pode incluir a ’transferência’ ou a cessão das atividades do projeto para um parceiro, instituição ou comunidade local. ** A extensão, embora possa ocorrer “sem” custo, cabe o entendimento que esta ausência de custo se refere a não haver desembolso direto do projeto, ou acréscimo de financiamento por parte do doador. Sempre uma extensão terá custos, mesmo que “invisíveis”, como, por exemplo, horas de trabalho da equipe ou de colaboradores. Infelizmente, embora a transição do projeto seja extremamente importante, ela frequentemente é negligenciada e/ou conta com poucos recursos. Com pressões para ir para novos projetos e realocar os integrantes da equipe para outras atividades, o modo mais prático de garantir o encerramento completo de um projeto é inclui-lo no plano do projeto.
2.2.6.1 Gerenciamento da estratégia da transição para o final do projeto Como mencionado na discussão da fase de planejamento do projeto, os planos completos do projeto precisam incluir um plano de transição do projeto que descreve como o projeto pretende evoluir após a conclusão do calendário do projeto e garantir que o progresso na direção dos impactos continuará. Um plano de transição pode incluir várias situações ou contingências que tratem dos riscos e também podem alocar recursos adicionais quando não for possível sair inteiramente. O setor de desenvolvimento considera a transição especialmente importante devido á sua preocupação de que os impactos sejam mantidos após a finalização do projeto. Uma ferramenta usada para planejar a sustentabilidade do projeto é a Matriz de planejamento de transição conforme a tabela abaixo:
Guia para o PMD Pro 76
Figura 38: Matriz de planejamento de transição Componente 1. Plano de transição do projeto
Principais questões Que tipo de transição está prevista? Qual é o cronograma e quais são os pontos de referência?
Princípios de orientação Análise e revisão do projeto em andamento Transparência; financiamento especial
2. Desenvolver parcerias e vínculos locais
Seleção dos parceiros corretos? O que os parceiros oferecem?
3. Gerar capacidade organizacional local e humana
Que capacidades são necessárias? Que capacidades existem?
4. Mobilizar recursos locais e externos
5. Descontinuação escalonada de várias atividades
6. Permitir que os relacionamentos evoluam após a transição
Que insumos são necessárias para manter os serviços? Os benefícios podem ser mantidos sem contribuições contínuas?
Quais são os principais elementos do projeto? Quais elementos dependem de outros?
Que tipos de suporte constante (recomendações, aconselhamento, assistência técnica, etc.)? Como o suporte constante será financiado?
Guia para o PMD Pro 77
Diversidade: podem ser necessários outros insumos/recursos do projeto Metas claras e comuns Aproveitar a capacidade existente, se possível Criar ambientes que apoiem as capacidades Buscar serviços de suprimento localmente quando possível Trazer cada vez mais recursos externos sob o controle local Flexibilidade; a sequência escalonada podese alterar na implementação Evita o desvio dos objetivos pretendidos do projeto, incluindo um projeto estendido, expandido ou replanejado
Desafios Equilíbrio dos compromissos da organização com flexibilidade Deixar o tempo adequado para desenvolver capacidades Alinhamento das necessidades e objetivos de diversos interessados Apoiar parceiros locais Monitoramento de design para acompanhar a criação de capacidade Fornecer incentivos e manter a equipe experiente Dificuldade de encontrar recursos locais adequados e disponíveis Outros financiadores não aderem aos objetivos originais Tempo suficiente para que o ciclo do projeto comece a ver o impacto e os objetivos pretendidos Disponibilidade de financiamento para o suporte constante Disponibilidade da equipe que pode concentrar tempo e energia suficientes no suporte constante
2.2.6.2 Verificação do escopo do projeto e aceitação dos resultados/produtos Conforme o projeto entre na fase de transição para o final, o gerente de projetos deve entrar em contato com os interessados externos (incluindo o comitê do projeto ou o patrocinador do projeto) para verificar se o escopo foi alcançado e se as resultados/produtos foram aceitas. Frequentemente, a verificação do escopo é medida em qualquer avaliação final conduzida para o projeto. Entretanto, em situações em que não é realizada uma avaliação final, a verificação das resultados/produtos ainda deve ser realizada. Isso geralmente ocorre em um processo de duas etapas.
A equipe de implementação do projeto se reúne para verificar cuidadosamente o trabalho concluído em relação ao plano de implementação do projeto. Pode haver, por exemplo, atividades postergadas desde o início do projeto e nunca foram executadas posteriormente.
Reunião com os principais interessados (doadores, grupos comunitários) para: Analisar os resultados em relação ao plano do projeto e depois obter sua aceitação documentada por algum tipo de reconhecimento ou aceitação formal. Certificar-se de que estejam satisfeitos, mas não apenas com os aspectos técnicos do projeto como também com os resultados gerais (isso geralmente é uma questão de percepção tanto quando é questão da existência de produtos e da conquista de resultados).
2.2.6.3 Encerramento administrativo, financeiro e contratual completo Se o projeto precisar ser auditado dois anos após o encerramento, o que aconteceria? Existem sistemas para garantir que os elementos administrativos, financeiro e contratual do encerramento do projeto estejam completos? Esses sistemas são críticos não apenas porque evitam problemas com as auditorias de projeto como também reduzem o risco de que haverá conflitos com fornecedores, funcionários e doadores sobre o status da conta. Os sistemas devem ser identificados para auxiliar cada uma das seguintes três áreas de atividade: Encerramento do contrato
Todos os contratos estão fechados? Fornecedores? Subcontratados? Doadores? Outros? Organizações de implementação?
O doador analisou e aceitou as resultados/produtos do projeto? Encerramento financeiro
Todo o financiamento permitido foi recebido do doador?
Todas as contas a receber (adiantamentos do projeto, adiantamentos de viagem e adiantamento para fornecedores) foram liquidadas ou transferidas para outro número de projeto ou código contábil?
Todas as contas a pagar foram pagas? Encerramento administrativo
A equipe do projeto foi liberada ou reatribuída?
Os equipamentos, veículos, escritórios do projeto foram realocados? Vendidos? Transferidos?
Os relatórios do projeto e os documentos de encerramento estão completos?
Os arquivos e/ou arquivo morto do projeto estão atualizados?
Guia para o PMD Pro 78
2.2.6.4 Aprendizagem no final do projeto As lições aprendidas são o banco de memória da organização. De modo ideal, a equipe do projeto criará um registro das lições aprendidas na fase do inicio ou definição do projeto que rastreará as lições aprendidas conforme elas ocorrerem ou, pelo menos, os pontos de avaliação ou marcos importantes durante todo o projeto. Conforme o projeto entra na fase de transição, é importante garantir que as lições aprendidas relacionadas ao projeto sejam detalhadas adequadamente, arquivadas e que fiquem facilmente acessíveis. Além disso, é crucial que o gerente de projetos distribua as lições aprendidas para aqueles que podem se beneficiar delas. Sem um sistema para capturar a aprendizagem do final do projeto, a organização reinventará a roda perenemente toda vez que uma decisão for tomada ao executar um projeto similar. Os doadores frequentemente estão interessados em assegurar que a aprendizagem seja disseminada em todo o setor para garantir que os novos projetos se beneficiem da aprendizagem gerada por outros projetos que financiaram. Hoje em dia as ONGs publicam frequentemente relatórios de avaliação e existem bancos de dados que incluem milhares de relatórios de avaliação de várias organizações diferentes. Uma análise da aprendizagem também chamada de ‘Análise após a ação’ é uma atividade de aprendizagem simples, rápida e versátil que pode ser usada para identificar e registrar as lições de conhecimento que surgem de um projeto. As análises de aprendizagem são relativamente simples de organizar e implementar. Durante a análise, são feitas perguntas que ajudam os participantes a entender o que foi planejado em comparação com o que realmente aconteceu:
O que planejamos fazer? O que alcançamos? Concentrar-se mais em fatos do que em opiniões; O que deu realmente certo? Novamente, analisar os fatos. Por que deu certo? Comparar o plano com a realidade. O que poderia ter sido melhor? Comparar o plano com a realidade. O que nos impediu de fazer mais? O que podemos aprender com isso?
A vantagem de uma análise de aprendizagem é que ela pode coletar informações úteis com relativa rapidez e sem gastar muitos recursos. A facilitação da análise visa a ser rápida, aberta e não concentrada no pensamento profundo e na discussão. A principal intenção é informar as decisões nas operações, política ou estratégia relacionada com intervenções de programas em andamento ou programas futuros.
2.2.6.5 Celebração de resultados obtidos Assim como é importante reconhecer o início de um projeto através de atividades de lançamento, um gerente de projetos também deve comemorar adequadamente e reconhecer formalmente a transição para o final do projeto:
Reconhecendo os esforços dos integrantes da equipe; Reconhecendo as contribuições dos principais interessados no projeto; e Expressando o apreço a indivíduos e grupos que foram cruciais para o sucesso do projeto.
Guia para o PMD Pro 79
O reconhecimento das resultados obtidos do projeto dentro da organização e para o mundo externo também facilita a geração de relações públicas positivas e prepara o caminho para futuras oportunidades de negócio.
Guia para o PMD Pro 80
SEÇÃO 3
: GERENCIAMENTO DE PROJETO.
Não há um caminho único para o gerenciamento de projetos. Cada projeto é único e tem seus próprios objetivos, contexto, recursos, relacionamentos e desafios. E, mesmo assim, embora dois projetos não sejam exatamente iguais, o gerenciamento de projetos bemsucedido exige que todas as equipes de projeto apliquem um conjunto de disciplinas de gerenciamento de projetos de modo abrangente e ativo por toda a vida do projeto. O PMD Pro identifica seis disciplinas de gerenciamento de projetos especialmente importantes ao se gerenciar projetos no setor de desenvolvimento. Elas são:
Gerenciamento do escopo
Gerenciamento do tempo
Gerenciamento de recursos do projeto
Gerenciamento de riscos
Gerenciamento da justificativa do projeto
Gerenciamento das partes interessadas
A seção Três do Guia explora cada uma dessas disciplinas de gerenciamento de projeto, fornecendo detalhes sobre as ferramentas e mecanismos especialmente úteis ao se gerenciar cada uma das disciplinas. Além disso, reconhecendo que cada disciplina interage com as outras, o Guia também explora abordagens para gerenciar disciplinas de um modo integrado, com cada disciplina alinhada adequadamente e conectada com as outras.
3.1
D ISCIPLINA 1: G ERENCIAMENTO DO ESCOPO
A lenda do beisebol Americano, Yogi Berra, disse uma frase que ficou famosa – “se você não sabe para onde está indo, vai acabar em outro lugar.” É por isso que o gerenciamento de escopo é tão importante para os projetos bem-sucedidos. Um escopo de projeto bem definido não apenas dirá à equipe de projeto onde ele está indo, como também explicará como o projeto pretende chegar lá. Em seu núcleo, o gerenciamento de escopo tem dois componentes: Escopo do produto – inclui todos os resultados/produtos necessários ao projeto, atendendo a especificação acordada. (O que será fornecido?) Escopo do projeto – inclui todo o trabalho necessário para fornecer o objetivo do projeto. (Como as resultados/produtos serão criadas e entregues?)
Guia para o PMD Pro 81
Expectativas não claras: A ambiguidade do escopo leva à confusão entre os interessados do projeto com relação ao que se esperar – e não se esperar - do projeto. Um escopo identificado claramente ajuda os interessados a compartilhar um entendimento comum dos benefícios do projeto e do trabalho necessário para entregar os resultados e produtos do projeto com sucesso. Os interessados precisam ter uma clareza de 100% sobre o escopo para garantir que não tenham expectativas incorretas ou irreais sobre que produtos/serviços serão fornecidos.
Uma observação de advertência sobre a definição de escopo
O gerenciamento do projeto é abrangente (e detalhado)!
Os dois componentes são críticos para o sucesso do projeto e precisam ser gerenciados diligentemente. Na ausência de uma definição clara do escopo, podem surgir os seguintes problemas:
Embora o gerente de projetos possa ficar tentado a pensar que os documentos gerados durante a fase de identificação e design (estrutura lógica, proposta do projeto, etc.) são suficientes para definir o escopo do projeto, isso raramente é verdade! Lembre-se, a estrutura lógica e a proposta do projeto foram criados com fins bastante distintos. Embora sejam especialmente fortes em delinear a lógica de alto nível do projeto e em vender o projeto para doadores, não são desenhados para guiar uma equipe na implementação do projeto. Antes do início do trabalho real do projeto, o gerente de projetos precisa confirmar que o escopo do projeto está abrangente e detalhado. Deve-se ter um cuidado especial para garantir que as informações sobre o trabalho indireto do projeto sejam incluídas no escopo, por exemplo, detalhes relacionados aos serviços de suprimento, coordenação, comunicações, recursos humanos e gerenciamento de risco.
Estimativas imprecisas: Os erros da definição do escopo resultam frequentemente em projetos que falharam ao identificar todo o trabalho necessário para concluir o projeto (de modo oposto, um escopo criado de maneira inadequada pode gerar trabalho desnecessário incluído no projeto). Esses erros de escopo podem gerar um efeito cascata que gerará erros no orçamento e nas estimativas de prazo. Esses erros de estimativa podem gerar erros no cronograma afetando assim a ultrapassagem dos custos.
Avanço lento do cronograma – O propósito da definição do escopo é descrever claramente e chegar a um acordo sobre os limites das resultados/produtos do projeto e do trabalho do projeto. Deixar de controlar esses limites leva a um avanço lento do escopo – uma das principais causas de atrasos do projeto e de projetos que possivelmente “não terão fim". Para evitar o avanço lento, o escopo precisa ser documentado e gerenciado por toda a duração do projeto através de um processo formal de mudança.
Guia para o PMD Pro 82
3.1.1 DEFINIÇÃO DE PRODUTO E ESCOPO DO PROJETO Reconhecendo a diferença sútil, porém significativa entre dois elementos do escopo do projeto, vamos examinar essas duas definições mais atentamente: -
O ESCOPO DO PRODUTO descreve as resultados/produtos do projeto. Uma definição completa do escopo do produto será uma descrição inequívoca e abrangente e uma especificação dos produtos/serviços a serem entregues. O nível de detalhe fornecido no escopo do projeto deve ser suficiente para compensar qualquer discordância potencial futura sobre o que se pretendia. O escopo do produto é orientado para o cliente, o que significa que sua definição deve ser acordada com o cliente (os financiadores e usuários) das resultados/produtos do projeto.
-
O ESCOPO DO PROJETO descreve o trabalho do projeto. Uma definição completa do escopo do projeto fornece uma descrição abrangente e detalhada do trabalho que deve ser realizado para o fornecimento das resultados/produtos do projeto. O escopo do projeto é orientado para o provedor, o que significa que ele depende do que a equipe do projeto decidir como o modo mais adequado de se alcançar o escopo do produto.
Quando a equipe do projeto tiver definido o escopo do produto e do projeto, o gerente de projetos deve analisar a definição do escopo quanto aos seguintes itens:
Totalidade – a equipe sabe exatamente o que se está pedindo para ser entregue?
Ambiguidade – i Os diferentes interessados terão a mesma compreensão do que está sendo solicitado?
Recursos – os requisitos de recurso foram entendidos e definidos?
Acordo – a equipe concordou com as resultados/produtos?
Viabilidade – a equipe é capaz de produzir a mercadora acordada?
Aceitação – todos (equipe e interessados) concordaram sobre o que constitui um produto aceitável?
3.1.2 FERRAMENTAS PARA A DEFINIÇÃO DO ESCOPO DO PROJETO A Estrutura Analítica do Projeto (EAP)(Work Breakdown Structure – WBS) é a principal ferramenta que os gerentes de projetos usam para definir o escopo do projeto. A EAP é uma divisão hierárquica do trabalho de um projeto. Simplificando, a EAP organiza o escopo do projeto em um resumo ou hierarquia de ‘pacotes de trabalho’. O formato da EAP geralmente assume um dos dois estilos a seguir: O formato gráfico fornece uma visão gráfica fácil de ler nos níveis relativos do trabalho de um projeto. Essa imagem permite que os parceiros e a equipe enxerguem os relacionamentos entre os elementos da EAP e como os componentes menores do projeto se transformam em componentes maiores. Além disso, o formato gráfico pode ser gerado facilmente em um ambiente de grupo usando-se post-it ou cartões que Guia para o PMD Pro 83
são fáceis de mudar de um lugar para outro. Para fins de apresentação, esse formato também facilita o ajuste da profundidade dos detalhes adequados para vários públicos. Figura 39: EAP do projeto Delta (criado parcialmente em formato gráfico)
O formato indentado tem a vantagem de ser mais fácil de criar e editar em um computador. Também é um formato mais fácil de carregar em ferramentas de software de gerenciamento como o Microsoft Project, assim como para imprimir relatórios e para o monitoramento computadorizado. Começando com o formato gráfico da Figura 39, a EAP da Figura 40 fornece um exemplo de como seria uma criação parcial da EAP para o projeto Rio Delta em um formato EAP indentado. Figura 40: EAP do projeto Delta (criado parcialmente em formato indentado) 1. Sistema de gerenciamento de resíduos fecais 1.1. Sistema de monitoramento de nível fecal 1.2. Campanhas de conscientização pública 1.3. Construção de latrinas 1.3.1.Preparativos de pré-construção 1.3.1.1. Plano aprovado pelo ministério 1.3.1.2. Especificações de engenharia aprovadas 1.3.1.3. Estudo de lençóis freáticos 1.3.2.Preparativos dos proprietários 1.3.3.Serviços de suprimento Guia para o PMD Pro 84
2.
Sistema de gerenciamento de lixo doméstico
Embora a EAP seja uma ferramenta central para os gerentes de projetos na maioria dos setores, ela é relativamente desconhecida no setor de desenvolvimento. Conforme os gerentes de projetos começam a adotar a EAP como uma ferramenta para identificar os produtos e serviços e o trabalho do projeto, surgirão inevitavelmente várias dúvidas.
O gerenciamento do projeto é integrado
2.1. etc.
Conexão do quadro lógico com a EAP Observe que as grandes categorias de trabalho da EAP são consistentes com o conteúdo da estrutura lógica do projeto. Entretanto, a EAP incluirá um nível de abrangência e detalhes que está frequentemente ausente da estrutura lógica. Pode haver categorias adicionais de trabalho incluídas na EAP que não foram incluídas na estrutura lógica. A EAP também visa a fornecer o nível de detalhe específico que frequentemente fica faltando na estrutura lógica.
Que formato? No final das contas, as preferências que a equipe do projeto e interessados tenham para interpretar as informações provavelmente influenciarão o formato da EAP. Algumas pessoas conseguem processar dados mais facilmente quando os visualizam graficamente, outras preferem listas. Às vezes é uma boa ideia criar os dois. Frequentemente o formato gráfico é gerado primeiro como um exercício em grupo facilitado. Um formato indentado é então criado para gerenciar a implementação do plano do projeto.
Quem deve estar envolvido? A participação da equipe de projeto inteira e dos principais interessados é importante durante o processo da EAP. Nenhuma pessoa isoladamente ou grupo pequeno consegue saber o suficiente para fornecer o nível de abrangência e de detalhes necessários na EAP. Por exemplo, recomenda-se que os integrantes da equipe responsáveis pelo gerenciamento financeiro e pelas atividades de serviços de suprimento do projeto se envolvam não apenas para informar a qualidade da EAP, mas também para garantir que eles entendam as atividades pelas quais são responsáveis. Quantos níveis? A EAP também pode diferir significativamente no número de níveis que apresenta. Embora não haja regras para estipular o número exato de níveis, a EAP deve ser detalhada o suficiente para que as sub resultados/produtos possam ser controladas e monitoradas com sucesso. O que deve ser incluído na EAP? É crucial que a EAP seja abrangente e inclua todas as atividades necessárias para o sucesso do projeto. Isso inclui atividades de gerenciamento que são frequentemente omitidas nas propostas de projeto e nas estruturas lógicas (planejamento e controle do projeto, treinamento dos interessados, comunicações, relatórios, serviços de suprimento e atividades de transição para o final do projeto). Verbos ou substantivos? Mais comumente, a EAP é definida como um diagrama orientado para o produto, o que significa que as declarações da EAP são escritas como substantivos. Entretanto, algumas definições da EAP permitem que suas declarações sejam orientadas para processos ou declaradas na forma de verbos. Da perspectiva do PMD Pro, as declarações da EAP podem ser escritas
Guia para o PMD Pro 85
como substantivos ou verbos. O importante é garantir que o conteúdo da EAP seja abrangente e detalhado. Uma EAP bem elaborada pode ser usada para: Guiar o processo de identificação e sequenciamento das atividades;
Fornecer uma base para: o Estimativas precisas da duração do projeto; o Estimativas precisas do custo do projeto; o Estimativas precisas dos recursos (veículos, pessoas, suprimentos, materiais de construção);
Identificar os serviços departamentais, subcontratados e fornecedores necessários;
Comunicar e concordar com o escopo do produto e do projeto com o interessado no projeto;
Mostrar a hierarquia do trabalho necessária para se concluir um projeto e indicar as interfaces entre elas;
Delegar os pacotes de trabalho aos integrantes da equipe de projeto, parceiros de implementação ou fornecedores;
D ISCIPLINA 2: G ERENCIAMENTO DO TEMP O
Imagine um projeto com desafios de cronograma. Qual foi o problema? O projeto alocou tempo insuficiente para concluir as resultados/produtos? As principais tarefas do projeto foram executadas com atraso? O cronograma do projeto baseou-se em estimativas de recursos (mão de obra, maquinário, outros?) não realistas? Entregar projetos dentro do prazo é um dos maiores desafios enfrentados no gerenciamento de projetos. Para gerenciar o tempo com sucesso, os gerentes de projeto exigem a capacidade de desenvolver cronogramas precisos e implementá-los por toda a vida do projeto. A primeira etapa do gerenciamento de tempo bem-sucedido é o planejamento do cronograma. As etapas do processo de planejamento do cronograma incluem:
O gerenciamento do tempo não ocorre no vácuo!
O gerenciamento do projeto é integrado!
3.2
Definição da atividade – identificar de modo Guia para o PMD Pro 86
Lembra-se do triângulo de gestão do projeto? Os lados daquele triângulo são todos conectados e é impossível mexer um dos limites-chave do projeto (prazo/calendário, custo/recursos, escopo/qualidade) sem levar os outros em consideração Por exemplo, se o seu projeto tem uma limitação de tempo inflexível – “ele DEVE ser feito em um ano!” - certifique-se de que as exigências de escopo e os recursos (dinheiro, pessoas e materiais) sejam planejados para garantir que o cronograma seja realista. De modo oposto, se um dos outros limites-chave do projeto for fixo (Orçamento? Escopo? Ambos?) então reconheça que é provável que essas limitações afetem o calendário do projeto.
abrangente as atividades que precisam ser executadas para produzir as resultados/produtos do projeto. Sequenciamento de atividades – identificar o relacionamento que existe entre as várias atividades do cronograma. Estimativa de recursos de atividade – alocar o tipo e a quantidade de recursos disponíveis/necessários para se executar cada atividade programa. Estimativa da duração da atividade – estimar o tempo necessário para concluir as atividades do projeto. Desenvolvimento do cronograma – criar um cronograma de projeto baseada em atividades, sequências, durações, recursos e limites do cronograma.
3.2.1 DEFINIÇÃO E SEQUENCIAMENTO DE ATIVIDADES Começando com a EAP, a equipe de projeto cria uma lista de atividades que registra de modo abrangente todas as atividades dentro do escopo do projeto ou dentro do escopo de um pacote de trabalho específico do projeto. Em seguida, a equipe do projeto cria um diagrama de rede que representa graficamente as sequências, o relacionamento e as dependências entre as atividades da EAP. Retornando ao estudo de caso do projeto Rio Delta, a Figura 41 fornece uma representação parcial de um diagrama de rede para o componente construção de latrinas do projeto. Observe que o diagrama da Figura 41 está incompleto porque as unidades de tempo ainda precisam ser inseridas abaixo de cada atividade do projeto. Cada uma das caixas do diagrama de rede identifica uma atividade do escopo do projeto. Essas caixas são conectadas por setas que indicam suas dependências. Essas dependências identificam como as atividades de projeto estão relacionadas entre si dentro no contexto do calendário e da sequência através da qual as atividades precisam ser concluídas. Em alguns casos, a sequência de caixas de atividades é linear, o que implica em um relacionamento precedente que requer que uma atividade seja concluída para que outra possa ser iniciada. As outras caixas estão em caminhos paralelos e não podem ser sequenciadas independentemente entre si.
Guia para o PMD Pro 87
Figura 41: Uso de um diagrama de rede para sequenciar as atividades de construção de latrinas
Algumas das mensagens que podem ser interpretadas a partir do design do diagrama de rede do projeto de latrinas incluem: -
A equipe do projeto deve aguardar a fabricação da tampa da latrina antes que ela possa ser instalada.
-
A equipe do projeto não precisa aguardar a conclusão da tampa da latrina antes de cavar o buraco correspondente.
-
As atividades de treinamento podem ser concluídas independentemente das atividades de construção das latrinas. OBSERVAÇÃO: Se o treinamento foi exigido como um pré-requisito para a participação em atividades de construção, a CAIXA DE TREINAMENTO DA COMUNIDADE precisaria ser colocada em um caminho diferente daquele em que se localiza atualmente.
3.2.2 ESTIMATIVA DE RECURSOS DE ATIVIDADE Quando a sequência de atividades é identificada, é tentador ir diretamente para a estimativa de duração da atividade. Em primeiro lugar, entretanto, a etapa importante da estimativa de recursos deve ser concluída. Em seu núcleo, o relacionamento entre as estimativas de recursos e as estimativas de duração é intuitivo. Todos sabem que levará mais tempo para uma outra pessoa cavar um buraco do que para uma equipe de cinco pessoas. Além disso, as estimativas de duração variam consideravelmente dependendo de se a equipe de escavação planeja usar uma única pá, uma furadeira pneumática ou dinamite para fazer o furo. Resumindo, os recursos são importantes. Eles são um dos fatores centrais que influenciam as estimativas de duração do projeto. Portanto, as decisões de recursos precisam ser tomadas antes da realização das estimativas de duração. As decisões relativas ao número e à qualidade dos recursos
Guia para o PMD Pro 88
comprometidos com uma atividade, por sua vez, dependem de vários fatores incluindo (sem se limitar) ao seguinte: Tempo – Se houver um prazo muito apertado, o projeto pode escolher se dedicar a altos níveis da equipe, materiais e equipamento de capital para atender os limites de tempo. De modo inverso, se o prazo for livre, o projeto pode escolher se dedicar a níveis mais baixos de recursos alocados para uma atividade. Orçamento - Se o dinheiro estiver escasso, o projeto pode preferir investir em uma combinação de recursos de ‘baixo custo’. Por exemplo, mais trabalhadores manuais e menos máquinas são uma alternativa de baixo custo preferível. Essa decisão de recurso, entretanto, estenderá a duração das atividades de escavação de latrinas. Políticas de regulamentos e organizacionais – frequentemente os projetos são limitados por leis trabalhistas ou políticas organizacionais internas que limitam os cronogramas de trabalho (horas por dia, dias por semana, feriados por ano, políticas de licença familiar). Esses limites influenciam a disponibilidade de recursos e, consequentemente, as estimativas de duração. Outros fatores que influenciam a disponibilidade de recursos – vários outros fatores influenciam a disponibilidade de recursos e assim, influenciam as estimativas de duração das atividades. Alguns exemplos desses fatores são: Limites devido ao clima atrasam um projeto agrícola em que a participação da comunidade e impossível durante a colheita. Limites materiais atrasam um projeto de moradias que requer materiais de construção escassos, o que torna a necessária a adoção de uma estratégia alternativa que demanda mais tempo. Limites logísticos impedem um projeto de alívio de emergência de acessar transportes, estender o tempo necessário para abastecer armazéns de alimentos. Limites de recursos humanos impede um projeto de saúde de acessar mão de obra qualificada, estender estimativas de duração por atividades tecnicamente complexas.
3.2.3 ESTIMATIVA DE DURAÇÃO DA ATIVIDADE Quando as estimativas de recursos estiverem concluídas, o diagrama de rede deve ser revisitado e as estimativas de duração serão acrescentadas a todas as atividades. Retornando ao estudo de caso do projeto Rio Delta, a Figura 42 fornece um diagrama de rede finalizado para o componente construção de latrinas do projeto.
Guia para o PMD Pro 89
Figura 42: Diagrama de rede para o componente de latrinas do projeto Rio Delta
Agora o diagrama de rede está completo e pode ser usado para ajudar a equipe do projeto a identificar: O caminho crítico do projeto – o caminho crítico é uma série de tarefas que determinam o tempo mínimo necessário para concluir as atividades do projeto. Na Figura 42, o caminho crítico é a série de tarefas sombreadas. Por que essa sequência de atividades? Porque essa sequência de tarefas representa o caminho mais longo entre o início e o fim do projeto – nesse caso, 23 dias. Nesse exemplo, o caminho crítico está nos dizendo que é impossível concluir o projeto em menos de 23 dias, a MENOS que outros limites do triângulo de gestão do projeto sejam alterados (dinheiro/recursos ou escopo/qualidade). A flutuação (ou folga) do projeto – no gerenciamento de projetos, a folga é o tempo em que uma tarefa de um diagrama de rede de projeto pode ser atrasada sem causar atraso na data de conclusão do projeto. No exemplo da latrina, existe uma folga zero no caminho crítico. No entanto, a atividade ‘construir tampa de latrinas’ pode ser atrasada em até oito dias sem afetar o cronograma do projeto. De modo similar, as atividades de treinamento podem ser atrasadas em até 20 dias sem afetar o cronograma do projeto. Se uma atividade que não está no caminho crítico do projeto for atrasada além da data tarde de início, isso pode significar que o caminho crítico determinado no plano do projeto não é mais o caminho crítico.
3.2.4 DESENVOLVIMENTO DO CRONOGRAMA Com base nas estimativas geradas através das etapas anteriores, a equipe do projeto agora pode criar um cronograma do projeto. Dentro do setor de desenvolvimento, a ferramenta preferida para a criação de organogramas de projetos é o gráfico Gantt. O planejamento e a implementação de projetos ficam mais fáceis se forem vistos como pequenos itens gerenciáveis em que as dependências são ilustradas visualmente, os processos paralelos são aparentes e o cronograma geral é representado graficamente. Guia para o PMD Pro 90
Um gráfico de Gantt usa barras para representar graficamente o cronograma das atividades de projeto, incluindo a data inicial, a data final e as durações esperadas. A complexidade e a abrangência do gráfico de Gantt variam. Em seu núcleo, a ferramenta gráfico de Gantt tem a vantagem de ser relativamente fácil de preparar, ler e usar. Entretanto, é importante reconhecer que as tarefas de um projeto podem ser muito complexas e pode haver muitas dependências entre elas. Um modo de manter a simplicidade no gráfico de Gantt mesmo quando as tarefas e dependências são complexas, envolvem a implementação de atividades mais amplas e mais abrangentes de um projeto em um gráfico de Gantt resumido com os detalhes mais elaborados em um cronograma detalhado. O gráfico de Gantt resumido não difere apenas do gráfico de Gantt detalhado em relação ao nível de detalhes, mas também em relação ao seu propósito. O gráfico de Gantt resumido será especialmente útil ao se discutir o progresso de alto nível do projeto com interessados (integrantes do comitê de projeto, principais interessados, doadores, etc.). O gráfico de Gantt detalhado, entretanto, será menos concentrado na comunicação de alto nível e muito mais concentrado no planejamento operacional, na implementação e monitoramento das atividades. Aqui, o público se concentrará na equipe do projeto e nos fornecedores e parceiros de implementação responsáveis pela execução dos pacotes e tarefas de trabalho do projeto. Figura 43: Gráfico de Gantt para o projeto de latrinas (criação limitada)
Nesse exemplo, os pacotes de trabalho, tarefas e subtarefas estão no eixo Y e a linha do tempo está no eixo X. As barras mostram quando uma tarefa deve começar e quando deve acabar. As caixas delineadas fornecem um cronograma de implementação resumido para o pacote de trabalho. As barras mais escuras mostram as tarefas que foram concluídas. As barras claras mostram o trabalho que ainda precisa ser feito. Observe que esse gráfico de Gantt foi desenhado para ser atualizador fornecendo à equipe de projeto uma ferramenta não apenas para indicar quais atividades foram planejadas para quais
Guia para o PMD Pro 91
meses, mas também para fornecer uma ferramenta visual para acompanhar quais atividades do projeto foram concluídas e quais não foram. No gráfico de Gantt do projeto de latrinas, a tabela foi criada usando-se um programa de computador. Embora esse seja frequentemente o caso nos projetos de desenvolvimento, poderiam também ter sido usadas outras ferramentas. Por exemplo, frequentemente os gráficos de Gantt são desenhados à mão, no papel ou em quadros brancos que são mantidos no escritório do projeto. Outra opção para a criação e o gerenciamento de gráficos de Gantt é o emprego de programas de gerenciamento de projetos como o Microsoft Project ou qualquer um das dezenas de outros programas do mercado. Existem vários fatores que devem ser considerados ao decidir quais ferramentas usar para criar o gráfico de Gantt. Alguns desses critérios são:
Acesso a programas de computador; Habilidades com computadores e programas; O valor e a complexidade do projeto; Riqueza de recursos; Robustez/flexibilidade para o gerenciamento de mudanças do projeto e para atualização dos planos do projeto.
Frequentemente, os critérios de cancelamento que as organizações de desenvolvimento consideram ao tomar decisões são os tópicos um e dois da lista acima. A realidade é que as equipes de projeto do setor de desenvolvimento tendem a não ter acesso ao programa de gerenciamento de projetos ou não ter a habilidade para usar esses programas. Por essa razão, as equipes de projeto tendem a gerenciar seus projetos à mão ou usando processadores de texto e planilhas eletrônicas de cálculo. Essa decisão é aceitável, entretanto, é importante reconhecer que, conforme os projetos aumentam o nível de complexidade e risco, os programas comerciais de gerenciamento de projetos incluem recursos avançados especialmente úteis. Por exemplo, os gráficos de Gantt feitos em programas de gerenciamento de projetos incluem recursos que permitem às equipes de projeto:
Identificar vínculos entre as dependências do projeto – identificando automaticamente quais tarefas devem ser concluídas antes do início das outras. Além disso, identificar quando as mudanças na execução de uma tarefa gerarão atrasos no início de outras atividades.
Acompanhar atividades ao longo do caminho crítico – indicando automaticamente quando os atrasos das atividades ao longo do caminho crítico ameaçam atrasar o cronograma geral do projeto.
Vincular o gráfico de Gantt do projeto a outros documentos críticos de gerenciamento do projeto - identificando automaticamente quando as alterações do gráfico de Gantt do projeto exigem a realização de alterações integradas em outros documentos do projeto como o orçamento do projeto e a estrutura da divisão de trabalho do projeto.
3.2.5 GERENCIAMENTO DO CRONOGRAMA DO PROJETO Os gerentes de projetos devem monitorar seus cronogramas regularmente para garantir que o calendário do projeto permaneça no caminho certo. Se o cronograma do projeto começar a variar, a equipe do Guia para o PMD Pro 92
projeto terá várias opções através das quais o projeto poderá voltar ao rumo certo. Por exemplo, os prazos podem ser atrasados ou o escopo do projeto pode ser reduzido. Entretanto, se os prazos do projeto forem fixos e o escopo do projeto não puder ser alterado, pode não ser possível que o projeto volte ao rumo certo através das técnicas comuns de gerenciamento de cronograma. Como alternativa, em situações em que o escopo e o calendário são inflexíveis, duas técnicas a serem consideradas são o procedimento acelerado e compressão de duração. Usar o “procedimento acelerado” no cronograma de um projeto envolve pegar atividades que normalmente seriam concluídas em sequência e concluí-las em paralelo. Para obter o máximo do procedimento acelerado, as equipes de projeto devem visar as tarefas do caminho crítico primeiro, pois elas têm maior potencial de acelerar o cronograma em geral do projeto. Por exemplo, em um diagrama de rede do projeto de construção de latrinas, o plano original era construir a estrutura de latrinas DEPOIS da escavação das fossas. Na situação do procedimento acelerado (Figura 44), o diagrama de rede (e, portanto, o gráfico de Gantt) foi alterado de modo que a estrutura da latrina agora é construída ao mesmo tempo em que as fossas são escavadas. Ao concluir as atividades em paralelo, o caminho crítico do projeto é reduzido dos 23 dias originais para 17 dias, permitindo assim que o projeto compense o tempo perdido. Figura 44: Uso do procedimento acelerado no cronograma do projeto de latrinas
“Comprimir a duração” do cronograma significa acrescentar outros recursos ao caminho crítico para acelerar o progresso, entretanto, sem necessariamente obter o mais alto nível de eficiência. Por exemplo, digamos que o plano original do projeto de latrinas tinha uma pessoa trabalhando 14 dias para Guia para o PMD Pro 93
cavar um buraco. Para reduzir esse prazo, uma opção será acrescentar uma segunda pessoa à atividade de CAVAR BURACO. Isso muito provavelmente aumentará a velocidade em que a atividade CAVAR BURACO será concluída. Entretanto, não considere que dobrar recursos dobrará a produtividade. Frequentemente a produtividade adicional do segundo recurso é inferior. A produtividade inferior dos recursos marginais pode resultar de várias razões. Por exemplo, pode não haver espaço suficiente no buraco para que duas pessoas trabalhem eficientemente ou o projeto pode não ter materiais de escavação (pás, caçambas, picaretas, cordas, etc.) para apoiar o trabalho dos dois cavadores. No caso do projeto da latrina, acrescentar um segundo cavador à equipe de escavação reduz o tempo gasto na atividade CAVAR BURACO de 14 para 10 dias. Portanto, como resultado da compressão de duração do projeto, o caminho crítico foi reduzido de 23 para 19 dias. Figura 45: Compressão de duração do cronograma do projeto de latrinas
Guia para o PMD Pro 94
3.3
D ISCIPLINA 3: G ERENCIAMENTO DE RECU RSOS DO PROJETO
Como o nome sugere, o gerenciamento de recursos do projeto é a organização e a distribuição dos recursos disponíveis de um projeto. Os recursos do projeto normalmente incluem finanças, suprimento e inventário, tempo humano, habilidades e insumos, equipamentos e tecnologia da informação.
3.3.1 POR QUE O GERENCIAMENTO EFICAZ DE RECURSOS É IMPORTANTE? Um dos trabalhos mais importantes e mais desafiadores de um gerente de projetos é organizar efetiva e eficientemente todos os recursos envolvidos em um projeto. Não é preciso dizer que a complexidade dessa tarefa depende enormemente do escopo e da natureza do projeto em questão. Mas, em todos os casos, é UM FATOR CRÍTICO POR TRÁS DO SUCESSO OU DO FRACASSO.
O gerenciamento do projeto é integrado!
A qualquer momento, o gerente de projetos deve saber como equilibrar efetivamente vários recursos do projeto. O gerente deve saber como criar e se manter dentro de um orçamento de modo que os fundos sejam alocados onde são necessários e como organizar com eficácia os trabalhadores e a equipe do projeto de modo que as pessoas certas sejam designadas para as tarefas corretas. Além disso, é necessário ter uma implementação e um fluxo eficazes de serviços, suprimentos e inventário de modo que o projeto tenha acesso ao que precisa, quando e onde precisar e com o preço mais adequado.
Colaboração com a equipe de suporte
A comunicação efetiva e fluida com os serviços de suporte é vital para o sucesso do projeto. Diz-se frequentemente que o “gerenciamento de projetos é muito importante para ser deixado unicamente com a equipe do projeto”. Os integrantes da equipe de suporte têm habilidades e
Guia para o PMD Pro 95
Um dos desafios mais importantes do gerenciamento de recursos do projeto é garantir que o gerente de projetos, juntamente com a equipe de suporte do projeto (isto é, finanças, recursos humanos, tecnologia da informação e cadeia de suprimentos) e seus gerentes estejam intimamente alinhados e integrados. A criação desse relacionamento deve começar durante a fase de identificação e design. Conforme o design inicial do projeto é formulado, a equipe de suporte adequada deve ser envolvida na definição de parâmetros orçamentários de alto nível na identificação de habilidades e na especificação de necessidades de suprimentos. Conforme o projeto entra na fase de planejamento, a equipe de suporte pode ser especialmente útil ao assegurar que os formatos dos orçamentos estejam corretos, que as estimativas sejam precisas, que a lista de itens do orçamento seja abrangente e que o orçamento seja detalhado. Eles garantirão que os planos da cadeia de suprimentos sejam precisos e que o recrutamento e o planejamento do desenvolvimento de habilidades seja incorporado nos planos do projeto. Posteriormente, conforme o projeto entra na fase de monitoramento, avaliação e controle, a equipe de suporte será crítica para garantir que os relatórios financeiros do projeto sejam precisos, oportunos e úteis. Apenas com essas informações a equipe de projeto será capaz de obter uma compreensão total de onde o projeto se encontra em relação ao seu progresso.
experiências críticas. Eles precisam estar envolvidos no projeto o mais cedo possível. Deixar de envolvê-los geralmente resultará no planejamento impreciso e/ou incompleto e, como resultado, em uma implementação e entrega inadequadas. O PMD Pro se concentra em três das áreas de gerenciamento de recursos do projeto: gerenciamento financeiro, gerenciamento da cadeia de suprimentos e gerenciamento de recursos humanos. Esses três formam o núcleo dos serviços de suporte do projeto. É importante ficar claro que a responsabilidade máxima pelas finanças do projeto, pela cadeia de suprimentos e pelo gerenciamento dos recursos humanos fica com o gerente de projetos. Isso é verdadeiro mesmo apesar de o gerente de projetos não ter responsabilidade gerencial direta pelas finanças, cadeia de suprimentos e equipe. É trabalho do gerente de projetos garantir que as finanças do projeto sejam bem gerenciadas; que os bens, serviços e materiais sejam gerenciados eficaz e eficientemente e que a equipe do projeto tenha todas as habilidades necessárias para alcançar o sucesso.
3.3.2 GERENCIAMENTO DAS FINANÇAS DO PROJETO As organizações do setor de desenvolvimento geralmente contam com doadores individuais ou organizacionais para financiar programas – e eles esperam que as doações sejam bem gerenciadas. As organizações de desenvolvimento também têm obrigação com as comunidades e parceiros que atende, sendo responsáveis por garantir que os recursos obtidos em seu nome sejam usados da maneira ideal para maximizar o impacto. Para exercer o gerenciamento financeiro prudente do projeto, o gerente de projetos precisará desenvolver habilidades nestas três áreas:
Criação de orçamentos Identificação de estimativas de custo Monitoramento de orçamentos e gastos
É a realidade prática da maioria dos projetos que o gerente não tenha controle total sobre todos os processos financeiros. Para ser bem-sucedido, um gerente de projetos precisará colaborar e coordenar intimamente com um gerente financeiro mais um conjunto de outras pessoas em todas as etapas do processo do gerenciamento financeiro. Contudo, apesar de haver elementos de gerenciamento financeiro onde o gerente não tem autoridade e controle sobre os processos, o gerente de projetos ainda é responsável. Estas seis áreas de coordenação e colaboração de finanças são especialmente críticas:
Acesso de dados históricos para relatórios financeiros Explicação de variações do orçamento Emissão de cheques Autorização de gastos Gerenciamento de saldos de caixa Implementação de políticas de compras
Como discutido anteriormente, o mandato do gerente de projetos é assumir a responsabilidade para garantir o sucesso geral do projeto. No caso dos elementos financeiros, o gerente de projetos deve
Guia para o PMD Pro 96
garantir que as funções e responsabilidades de todos os indivíduos envolvidos nos processos financeiros estejam claras E que os indivíduos estejam cumprindo seus compromissos.
3.3.3 CRIAÇÃO DE ORÇAMENTOS Um orçamento é a descrição do plano financeiro do projeto que inclui uma lista das estimativas de custo do projeto. Como é o caso de todos os componentes do plano do projeto, a chave para um orçamento preciso é garantir que ele seja abrangente e detalhado. Orçamentos abrangentes – todos os itens do orçamento necessários para entregar os produtos e serviços devem ser incluídos. Como primeira etapa, a equipe do projeto precisa identificar os gastos necessários para entregar os produtos e serviços do projeto. Eles são as despesas relacionadas ao trabalho direto do projeto; incluindo salários, veículos, materiais, suprimentos, equipamentos, etc. Entretanto, é importante não parar aí, mas lembrar-se de que um orçamento abrangente deve prever as despesas relacionadas com o trabalho indireto do projeto. Um gerente de projetos deve fazer uma pergunta importante: “que recursos serão necessários para apoiar os processos vitais para o sucesso do projeto?” Eles incluem os recursos necessários para comunicações, gerenciamento de risco, monitoramento, avaliação, serviços de gerenciamento do projeto, gerenciamento de recursos humanos, processos de serviços de suprimento, integração do projeto e despesas indiretas gerais do projeto. Orçamentos detalhados – exatamente como o escopo do projeto deve se aprofundar para identificar atividades específicas necessárias à implementação bem-sucedida de um projeto, assim deve ser o orçamento do projeto. Embora orçamentos de alto nível sejam úteis para comunicar os parâmetros gerais do projeto a vários interessados, a equipe do projeto requer uma identificação mais precisa e específica dos custos do projeto para implementar as atividades com sucesso. Alguns exemplos do nível de detalhe que precisam ser incluídos no projeto são: Custos de operação: por exemplo, ao identificar o custo dos serviços de suprimento, o orçamento da equipe deve não apenas identificar o custo direto do serviço ou produto como também o custo do gerenciamento do processo dos serviços de abastecimento. O nível de detalhe do orçamento deve incluir as despesas necessárias para iniciar um projeto (estabelecimento de controles internos, sistemas de contabilidade, processos de contratação, etc.) e o custo do transição dos projetos (encerramento de contratos, encerramento da equipe, etc.). Serviços compartilhados: outro nível de detalhes frequentemente ausente nos orçamentos de projetos é o custo dos serviços alocados para o projeto pela organização de desenvolvimento propriamente dita. Por exemplo, o orçamento precisa incluir as despesas da porcentagem do tempo alocado ao projeto pelo gerente financeiro, um motorista, uma equipe de tecnologia da informação ou outros? Se o projeto deixar de incluir o nível suficiente de detalhes no orçamento, correrá o risco de não conseguir acessar a gama completa de serviços e supervisão necessárias para a implementação bem-sucedida do projeto.
Guia para o PMD Pro 97
O design e a estrutura de um documento orçamentário dependem frequentemente da fonte do financiamento do projeto. Por exemplo, nas situações em que os projetos de desenvolvimento recebem dinheiro de doadores externos, os parâmetros orçamentários seguem mais frequentemente as diretrizes do doador. Como resultado, os orçamentos dos projetos variam consideravelmente em relação à tabela de contas e cronologia. Tabelas de contas – os itens do orçamento do projeto são agrupados em categorias de custos que ajudam as equipes de projeto a capturar e analisar as transações por área de programa, fonte de financiamento, localização, departamento, etc. Por sua vez, essas categorias de custos são agrupadas em subelementos fornecidos com códigos de itens de linha. Embora seja uma prática comum para os orçamentos empregar uma abordagem de tabela de contas que identifique todas as contas do projeto, as categorias de custo e os itens de linha não são padronizados e variam conforme os doadores, organizações de implementação e/ou parceiros de projeto. Cronologia: todos os orçamentos devem definir o período ao qual se aplicam. Existem várias abordagens para o gerenciamento do cronograma do orçamento: Orçamento vida do projeto (ou orçamento multianual) – aqui o orçamento global para toda a vida do projeto é criado e serve como o documento financeiro oficial que acompanha o plano do projeto. Orçamentos de projetos anuais – alguns projetos adotam a norma de revisitar o orçamento vida do projeto regularmente e requerem que uma equipe do projeto submeta um orçamento de um ano após a conclusão de cada ano do projeto. Embora os orçamentos multianuais tendam a ser o padrão do setor de desenvolvimento, requerer um orçamento de projeto anual diminui o risco de que as estimativas de orçamentos baseadas em horizontes multianuais sejam imprecisas, sofram com a variabilidade de preços ou não sejam flexíveis o suficiente para ajustar-se a mudanças no ambiente operacional de campo.
3.3.4 ORÇAMENTOS BASEADOS EM ATIVIDADES
Os orçamentos baseados em atividades se concentram na identificação dos custos das atividades que ocorrem em todas as áreas de um projeto e na determinação de como essas atividades se relacionam entre si, incluindo o trabalho direto e indireto. Os proponentes veem os orçamentos baseados em atividades como mais realistas do que outras abordagens de orçamentos, pois eles envolvem a compreensão de quanto as atividades realmente custarão. Se um gerente de projetos conseguir desenvolver uma lista completa (abrangente e separada) das atividades junto com as estimativas de custo das atividades, então o orçamento se mostrará preciso. Os orçamentos baseados em atividades também oferecem mais oportunidades para a equipe da linha de frente se envolver, aumentando a probabilidade do orçamento ser preciso. Guia para o PMD Pro 98
Embora haja vários formatos possíveis de orçamentos baseados em atividades que acrescentam detalhes como códigos de conta, códigos de doadores e custos unitários – todos têm dois requisitos similares: 1) Criar uma lista completa de atividades durante o planejamento do escopo. 2) Trabalhar o que for necessário para alcançar cada atividade e estimar quando ela custará. Atendendo esses dois requisitos, o orçamento fornecerá detalhes para cada atividade e mostrará os custos associados que podem, por sua vez, ser monitorados. Se o monitoramento mostrar que os gastos reais ultrapassaram as estimativas de custo, o gerente de projetos saberá que o projeto provavelmente não entregará o escopo completo. Deve-se replanejar o trabalho para encontrar maneiras mais eficientes de se implementar as atividades restantes. Como alternativa, o gerente pode solicitar um comitê de projeto ou outra estrutura de governança de projeto para ajustar o escopo. Figura 46: Exemplo de orçamento baseado em atividade simples
3.3.5 IDENTIFICAÇÃO DE ESTIMATIVAS DE CUSTO Independentemente do projeto ou do formato de seu orçamento, um plano financeiro é tão bom quanto as estimativas sobre as quais ele se baseia. Até certo ponto, sempre haverá um risco associado com as estimativas do projeto. A estimativa nunca será uma ciência precisa que produz resultados 100% precisos. Os gerentes de projetos não conseguem prever o futuro. Sempre haverá variáveis de projeto que ficarão de fora do controle da equipe do projeto. E, mesmo assim, embora haja muitas razões pelas quais fazer estimativas precisas é um desafio, elas podem ser precisas o suficiente para apoiar boas decisões do projeto. Além disso, existem as melhores práticas que ajudam os gerentes de projetos a aprimorar a precisão de suas estimativas orçamentárias: Guia para o PMD Pro 99
1. Selecionar a abordagem correta para fazer a estimativa – as estimativas geralmente são desenvolvidas através da combinação das três técnicas a seguir: Estimativas de cima para baixo começam com uma estimativa global do custo de um projeto e depois atribuem uma porcentagem do total para diferentes fases ou pacotes de trabalho do projeto. As porcentagens atribuídas aos componentes são geralmente identificadas por indivíduos que têm experiência anterior em projetos similares. Essa abordagem para estimar tende a ser mais exclusiva e envolve um grupo relativamente pequeno de pessoas consideradas especialistas com base em sua experiência passada. Estimativas de baixo para cima não começam com uma estimativa global do custo do projeto. Em vez disso, as tarefas são estimadas e “implementadas”. Nesse modelo, as estimativas são solicitadas das pessoas que têm conhecimento da realidade de campo do projeto e frequentemente são as mesmas pessoas responsáveis pela implementação das atividades do projeto (incluindo parceiros, fornecedores, integrantes da comunidade, etc.). A estimativa de baixo para cima tende a envolver um número maior de participantes e exige maior esforço para ser gerenciada. As estimativas de baixo para cima têm maior probabilidade de serem precisas pois a equipe de campo provavelmente terá uma consciência melhor dos limites dos recursos que afetam as estimativas de custo. Como exemplo, elas podem saber exatamente quanto recurso as diferentes comunidades podem fornecer para ajudar com a escavação de latrinas – dando uma estimativa muito melhor do que considerar que todas as comunidades podem fornecer o mesmo recurso. Estimativas paramétricas contam menos com as pessoas e, em vez disso, usam um relacionamento estatístico entre os dados históricos e outras variáveis (por exemplo, a área de construção, metros de estrada, etc.). As estimativas paramétricas tendem a ser usadas para projetos e componentes do projeto que geram produtos concretos (por exemplo, construção de infraestrutura, construção de estradas, serviços de tradução, etc.). Aqui a estimativa é feita pela identificação dos dados históricos de projetos que forneceram produtos similares (por exemplo, quilômetros de estada, área de construção, linhas de texto) e usando-os para calcular estimativas de escopo/qualidade, custo/recursos e/ou tempo/calendário. Essa técnica pode produzir níveis mais altos de precisão, mas depende da qualidade dos dados básicos integrados no modelo. 2. Estimativas da fase de desenvolvimento (quando possível) – no início da implementação do projeto, os doadores frequentemente exigem um compromisso firme com o orçamento da vida do projeto. Embora essa prática seja considerada frequentemente uma boa estratégia para gerenciar orçamentos descontrolados, ela funciona somente até o ponto em que os orçamentos dos projetos são realistas. Frequentemente é difícil elaborar orçamentos precisos durante os primeiros estágios da vida do projeto. A realidade de campo muitas vezes se altera durante a implementação. Custos não previstos surgirão. A realidade de campo evoluirá. Os preços e a inflação mudarão. Por essa razão, as equipes de projeto preferem frequentemente trabalhar através de um processo de estimativa em fases que permite a possibilidade da criação de uma série de orçamentos em diferentes pontos ao longo do calendário do projeto (isso pode, por exemplo, ser uma cadeia de Guia para o PMD Pro 100
orçamentos anuais). Essa estratégia ajuda a garantir que os orçamentos do projeto sejam precisos e que entrem na fase seguinte do projeto. Ela também fornece um ponto lógico para o corpo de governança do projeto verificar a justificativa do projeto e garantir que ele ainda "faça sentido" antes de empregar fundos adicionais.
3.3.6 MONITORAMENTO DO DESEMPENHO FINANCEIRO DO PROJETO Ao monitorar o desempenho financeiro do projeto, a primeira pergunta geralmente é “o projeto está acima ou abaixo do orçamento?” Para responder essa questão, a maioria das equipes de projeto considera os dados do orçamento mais recente e compara os custos planejados cumulativos com os custos reais cumulativos do projeto até uma certa data. Infelizmente, esse cálculo frequentemente é limitado em sua utilidade. Embora possa fornecer uma foto indicando se o projeto gastou mais ou menos dinheiro do que o estimado em um certo período, ele não fornece dados para explicar por que pode existir alguma variação. Considere, por exemplo, os dados fornecidos na Figura 47. A análise inicial dos dados do mês três desse projeto indicaria que ele está acima do orçamento. Isso ocorre porque o custo cumulativo planejado no final do mês três (1100) é inferior ao custo cumulativo real (1300). Figura 47: Orçamento ilustrativo de um projeto de seis meses (incluindo os custos reais até o mês 3) Tarefa
Custo Mês um planejado
Mês dois Mês três Mês quatro
A
100
B
200
200
C
100
100
D
400
400
E
100
100
F
200
200
G
200
200
H
100
100
I
300
J
100
Mês cinco
Mês seis
100
300 100
Custo total planejado por mês
100
300
700
300
300
100
Custo cumulativo planejado
100
400
1100
1400
1700
1800
Custo total real por mês
150
350
800
Custo cumulativo real
150
500
1300
Guia para o PMD Pro 101
Infelizmente esse cálculo rápido não dá o panorama inteiro do status financeiro do projeto. Sim, o projeto gastou 200 (11%) a mais do que o que foi orçado para os primeiros três meses do projeto. Entretanto, embora seja tentador considerar que a variação do custo no final do mês três significa que o projeto está “acima do orçamento”, tenha cuidado para não tirar conclusões precipitadas! Os custos maiores do que o esperado podem ser atribuídos a uma das duas razões:
Situação A: Por um lado, o projeto pode ser mais caro do que foi estimado originalmente. Nesse caso, as atividades do projeto estão dentro do cronograma, mas custam mais do que o previsto no orçamento. Análise: a situação A é definitivamente problemática. Ela aponta para uma tendência que, caso continue, resultará em um projeto acima do orçamento. Nessa situação, serão necessárias ações corretivas para garantir que o projeto evite déficits de orçamento.
Situação B: Por outro lado, o projeto pode estar gastando mais do que o esperado porque ele está adiantado no cronograma. Como resultado, o projeto está gastando mais do que o previsto nos primeiros três meses do projeto. Análise: a situação B não é necessariamente problemática. Sim, o projeto da situação B está gastando mais dinheiro por mês do que o que foi planejado originalmente, entretanto, também está realizando mais trabalho do que foi planejado. Nessa situação, o projeto precisa coletar mais informações para decidir se está gastando mais dinheiro do que tinha previsto para a quantidade de trabalho que está realizando. Observação - nas duas situações o projeto precisará garantir que tem dinheiro suficiente em mãos (fluxo de caixa) para continuar as operações porque ele está gastando mais dinheiro por mês do que o previsto originalmente.
A situação B fornece um desafio interessante para a equipe de projeto. Essa situação salienta a mensagem importante de que não é suficiente analisar apenas se o orçamento gastou mais ou menos dinheiro do que o estimado em um certo período. Em vez disso, o monitoramento do desempenho financeiro também deve observar dois indicadores separados, porém relacionados: o monitoramento do fluxo de caixa e o monitoramento dos custos através da análise do valor agregado.
3.3.6.1 Monitoramento de custos de projeto através da análise do valor agregado Para melhor monitorar os custos do projeto, é preferível monitorar o custo do trabalho concluído durante um período. A análise do valor agregadoé uma ferramenta que compara os custos planejados e reais de cada tarefa realizada e TAMBÉM compara a taxa de progresso de cada tarefa com o que foi planejado no plano do projeto. Isso significa que para realizar a análise de valor agregado o gerente de projetos precisará de um conjunto mais completo de dados que combinam elementos do orçamento do projeto E do calendário do projeto. A Figura 48 fornece uma visão atualizada do projeto de seis meses apresentado anteriormente, mas agora ela inclui duas novas colunas que fornecem o custo real de cada tarefa e a porcentagem do trabalho concluído de cada tarefa.
Guia para o PMD Pro 102
Figura 48: Exemplo de um orçamento de projeto de seis meses (incluindo dados da análise de valor agregado) Tarefa
Custo planejad o
Custo real
% concluí da
Mês um
Mês dois
Mês três
Mês quatro
A
100
150
100%
100
B
200
200
100%
200
C
100
100
100%
100
D
400
400
100%
400
E
100
0%
100
F
200
100
50%
200
G
200
200
100%
200
H
100
50
50%
100
I
300
100
50%
J
100
Mês cinco
Mês seis
300
0%
100
Custo total planejado por mês
100
300
700
300
300
100
Custo cumulativo planejado
100
400
1100
1400
1700
1800
Custo total real por mês
150
350
800
Custo cumulativo real
150
500
1300
Ao analisar as informações da Figura 48, existem duas conclusões importantes que devem ser retiradas dos dados:
Após três meses o projeto concluiu integral ou parcialmente oito tarefas. Ao comparar os custos planejados de cada uma dessas tarefas com o custo real de desempenho dessas tarefas, podese mostrar que o projeto está EXATAMENTE dentro do orçamento quando comparado com o trabalho realizado (o projeto gastou 1300 para obter o valor do trabalho correspondente a 1300).
O plano do projeto pede o valor de 1100 do trabalho a ser realizado em três meses. Em vez disso, foram obtidos 1300. Isso significa que o projeto está 18% adiantado no cronograma.
Assim, que conclusões podem ser derivadas dessa análise?
Guia para o PMD Pro 103
Se o projeto continuar no índice de trabalho atual, ele será concluído cedo;
Se as tendências do projeto continuarem imutáveis, o projeto será concluído dentro do orçamento.
Observe que as conclusões da análise do valor agregadodiferem das conclusões da análise de variação de custo cumulativo da seção anterior. Isso ocorre porque a análise do valor agregadofornece dados mais ricos que integram o escopo, orçamento e os dados do calendário no nível da atividade do projeto. Como resultado, a análise do valor agregadoajuda a salientar que nem todas as situações onde os custos cumulativos ultrapassam o orçamento do projeto são “ruins”. De modo inverso, nem todas as situações em que os custos cumulativos estejam aquém do orçamento são “boas”. O gerente de projetos deve explorar ainda mais para obter uma compreensão mais clara da situação em comparação com a conclusão programada das resultados/produtos do projeto. A Figura 49 fornece uma visão geral das contribuições dos resultados que podem ocorrer durante a realização da análise de valor agregado e identifica a implicação das diferentes situações. Observe que as células da tabela fornecem algumas combinações de orçamento/cronograma que são “boas”, outras que são "ruins" e algumas que requerem mais dados para se entender o status do projeto. Figura 49: Combinações dos resultados para a análise do valor agregado Atraso no cronograma
Dentro do prazo
Adiantado no cronograma
Abaixo do orçamento
São necessários mais dados
Bom
Bom
Dentro do orçamento
Ruim
Bom
Bom
Ruim
Ruim
São necessários mais dados
Acima do orçamento
Embora as classificações de status na Figura 49 sejam úteis, independentemente da classificação, os gerentes de projeto devem usá-la para iniciar uma exploração mais profunda “sobre a razão pela qual nosso status de análise de valor agregado atual”. O que é isso? É nosso status atual, um resultado das decisões que o projeto tomou em relação ao gerenciamento de qualidade, ao gerenciamento de risco, o gerenciamento de interessados ou qualquer um dos muitos outros tópicos que influenciam o orçamento e o calendário”. Ao concluirmos essa exploração do monitoramento financeiro, há uma observação final importante a se destacar. Embora a análise do valor agregadopossa fornecer dados ricos que ajudem a melhor monitorar o status financeiro do projeto, ela também requer um sistema de contabilidade preciso do projeto que Guia para o PMD Pro 104
integre o custo baseado nas atividades e os dados do cronograma. Juntos, esses dados podem ser usados para calcular as medidas do valor agregado para o custo total do projeto e desempenho do cronograma. O sistema de contabilidade precisará ser baseado em uma estrutura prática e dividida em trabalhos orientados para atividades e precisará incluir as informações oportunas dos custos. Qualquer atraso nos relatórios de custos é um atraso na capacidade de avaliar o custo atual e o status do cronograma do projeto. Esses pré-requisitos frequentemente estão ausentes dos sistemas de organizações de desenvolvimento, o que torna difícil a adoção dessa ferramenta de gerenciamento dentro do contexto dos projetos de desenvolvimento.
3.3.7 GERENCIAMENTO DA CADEIA DE SUPRIMENTO Imagine que você está construindo uma casa. Como você enfrentaria os complexos desafios relacionados com o gerenciamento do fluxo de bens e serviços entre seus pontos de origem e seu uso eventual na construção da casa? Como você planeja comprar os materiais, definir os cronogramas de entrega, comprar equipamentos, identificar instalações de armazenagem para os materiais, obter licenças, acompanhar o status dos materiais... e a lista segue em frente! Agora imagine construir a mesma casa em uma comunidade remota e com poucos recursos. Como gerente de projetos, agora você precisará gerenciar todos os desafios do complexo gerenciamento de suprimentos listados acima, mas também precisará gerenciar um conjunto de riscos exclusivos ao contexto de desenvolvimento. Os fornecedores são confiáveis? Existe corrupção no sistema de serviços de suprimento? Existe algum mecanismo para o transporte de materiais? Existem problemas de segurança? A segurança da equipe é uma preocupação? Quais são os limites dos recursos? Mesmo essa lista curta de riscos fornece uma ideia do desafio de gerenciar suprimentos nos projetos de desenvolvimento. Os atrasos causados por um gerenciamento de linha de suprimentos inadequado levam não apenas à perda do controle do projeto como também à perda da reputação e da satisfação dos beneficiados. Esses ativos são inestimáveis e são praticamente impossíveis de se recuperar depois de perdidos. Além disso, devido à natureza crítica dos serviços que as organizações de desenvolvimento prestam, as falhas e os descuidos podem resultar em sérias consequências para os beneficiários, o que poderia significar literalmente a diferença entre a vida e a morte. Além disso, o gerenciamento da cadeia de suprimentos pode ser responsável por uma porcentagem significativa do orçamento de um projeto. Por isso é importante que os suprimentos do projeto sejam gerenciados o mais eficiente e eficazmente possível. Provavelmente o gerente de projetos não se responsabilizará pelo gerenciamento da cadeia de suprimentos. Pode haver uma equipe de especialistas em logística que forneça suporte aos serviços de suprimento e logística para vários projetos. Apesar disso, o gerente de projetos é responsável por garantir que o projeto tenha acesso aos bens e serviços corretos no momento adequado e, como resultado, precisa exercer a colaboração e coordenação rigorosamente com a função de suporte da cadeia de suprimentos para garantir o sucesso. O PMD Pro define três componentes do gerenciamento da cadeia de suprimentos: Guia para o PMD Pro 105
Gerenciamento dos serviços de suprimento - incluindo a identificação de que materiais e serviços são necessários, quando são necessários e a identificação de como eles serão adquiridos e por quem. O plano dos serviços de suprimentos também precisa ser integrado com todos os outros elementos do plano do projeto para garantir que todas as decisões dos serviços de suprimentos estejam alinhadas com o orçamento, calendário, e parâmetros de risco e qualidade do projeto. Gerenciamento de logística – incluindo o planejamento, a implementação e o controle do fluxo e do armazenamento eficiente e econômico das matérias-primas do inventário em processo, dos bens acabados e das informações relacionadas do ponto de origem até o ponto de consumo com o propósito de estar em conformidade com os requisitos do cliente. Gerenciamento de ativos – incluindo os sistemas em que os itens de valor de um projeto são monitorados, mantidos e descartados. O gerente de projetos é responsável por garantir que esses componentes estão sendo bem gerenciados.
3.3.7.1 Gerenciamento dos serviços de suprimento Os serviços de suprimento incluem o processo completo de obtenção de bens e serviços, desde a preparação e o processamento de uma requisição até o recebimento e a aprovação da fatura para o pagamento. O gerente de projetos pode ser responsável pelos serviços de suprimento atuais dos serviços ou produtos necessários para desenvolver e implementar o projeto ou pode direcionar essas atividades através de um líder de equipe de contratos ou serviços de suprimento. Independentemente do papel e da responsabilidade precisos do gerente de projetos, essas atividades de serviços de suprimento podem ter um impacto significativo no orçamento e no cronograma do projeto para que possam ser integrados no plano, orçamento e cronograma do projeto geral. Os exemplos de serviços de suprimento típicos associados a um projeto incluem:
Materiais: Podem variar de produtos típicos como móveis e computadores pessoais, até produtos altamente especializados para o projeto como equipamentos médicos, máquinas perfuratrizes ou materiais para construção de estradas. O gerente de projetos pode ser responsável pelos serviços de suprimento atuais dos serviços ou produtos necessários para desenvolver e implementar o projeto ou pode direcionar essas atividades através de um especialista em serviços de suprimento.
Consultores: Frequentemente, embora haja recursos internos disponíveis para se realizar uma parte significativa do trabalho do projeto, são necessários recursos adicionais para concluí-lo em tempo ou para fornecer alguma habilidade necessária. Uma estratégia é obter recursos externos, geralmente de consultores, para aumentar a equipe do projeto.
Fornecedores: Nesse caso, o fornecedor assume a responsabilidade de executar todos os aspectos de um serviço selecionado, geralmente conforme normas específicas ou por um custo fixo. Nesse tipo de situação, o projeto compra o serviço específico. Os exemplos podem incluir serviços de demolição, serviços de transporte, serviços de segurança e serviços de construção.
Guia para o PMD Pro 106
Existem três etapas no gerenciamento dos serviços de suprimento:
Planejamento dos serviços de suprimento
Identificação de fornecedores
Seleção, negociação e concessão.
3.3.7.1.1 Planejamento dos serviços de suprimento É aconselhável criar um plano de serviços de suprimento sempre que o projeto exigir que os itens sejam comprados de fornecedores. Um plano logístico define os produtos e serviços que o projeto receberá de fornecedores externos. Um bom plano de serviços de suprimento vai um passo além descrevendo o processo pelo qual você passará para indicar esses fornecedores contratualmente. As etapas no planejamento de serviços de suprimento incluem:
Definição dos itens que você precisa; Definição do processo para aquisição desses itens; Programação dos prazos de entrega.
3.3.7.1.2 Identificação de fornecedores Vários documentos de serviços de suprimento podem ser usados para solicitar informações de fornecedores em potencial de serviços e materiais. Estimativas: Uma estimativa independente do tempo e do custo para fornecer o serviço ou os materiais geralmente é fornecida quando o critério de avaliação para a seleção do fornecedor é relativamente simples e será decidido principalmente/exclusivamente pelo preço. Embora o preço seja uma consideração especialmente importante durante a avaliação das estimativas, deve-se ter cuidado para avaliar se o custo proposto é uma estimativa realista e não excessivamente otimista de modo que leve em consideração as tecnologias e as habilidades envolvidas no projeto. Se houver variações significativas entre as estimativas de custo e cronograma em propostas enviadas, a oferta menor nem sempre tem o melhor valor. Se a oferta baixa é significativamente menor do que as outras estimativas, ela deve ser analisada com muito cuidado. Se o contrato não for lucrativo, ele pode gerar vários problemas para o contratante e para a agência. Propostas: Quando os critérios de seleção dos fornecedores em potencial forem mais complexos, os documentos da estimativa não coletarão necessariamente todas as informações necessárias para se tomar uma decisão bem informada. Esses tipos de serviços de suprimento podem coletar informações adicionais através de um Convite para oferta (IFB) ou um processo de Solicitação de proposta (RFP). A RFP deve conter uma declaração abrangente e concisa do trabalho (SOW) que defina claramente os produtos desejados, seus requisitos funcionais, características operacionais e de desempenho e as interfaces geradas com outros sistemas e processos da agência.
Guia para o PMD Pro 107
3.3.7.1.3 Seleção, negociação e concessão: O processo de serviços de suprimento deve ser planejado para permitir que uma organização obtenha e avalie estimativas/propostas de vários fornecedores diferentes, usando vários critérios que podem ser relevantes para a decisão. Os critérios de seleção podem ser limitados ao preço e calendário se o material ou serviço estiver prontamente disponível e for relativamente simples em sua configuração. Geralmente, entretanto, a seleção do fornecedor baseia-se em uma combinação de considerações financeiras e técnicas. Quaisquer que sejam os critérios de seleção empregados, o grupo tomador de decisão deve ser claro sobre os critérios a serem usados para tomar as decisões e os seus pesos relativos. Esse entendimento informará sua opção final de modo a facilitar a avaliação das respostas.
3.3.7.2
Gerenciamento de logística
Como muitos projetos dependem do fornecimento oportuno de materiais, o suporte adequado de logística é uma necessidade importante. Logística significa ter as coisas certas no lugar certo e na hora certa. Em seu senso mais limitado, a logística envolve o transporte de bem, porém é mais do que isso. Em um sentido muito mais amplo, a logística inclui todas as atividades necessárias para fornecer itens precisa e eficientemente, dentro do cronograma, em um local e para a pessoa a quem se destinam. A definição mais ampla da logística efetiva envolve:
Gerenciamento de inventário e armazéns
Transporte de materiais
3.3.7.2.1 Gerenciamento de inventário e armazéns Dependendo do projeto, o inventário pode representar um custo grande no valor total do projeto. Esse valor é composto do custo do inventário propriamente dito, mais o custo do transporte de bens, do custo do gerenciamento dos bens (mão de obra, embalagens, etc.) e manter os bens em armazéns. A equipe do projeto precisa definir um gerenciamento de inventário para garantir que o estoque esteja disponível para atender as necessidades do projeto como e quando necessário. Para isso, o gerente de projetos deve coordenar juntamente com os integrantes da equipe diretamente responsável pelo gerenciamento do inventário, conectando constantemente os requisitos de inventário com as necessidades de alterações e as prioridades do projeto. Como parte desse desafio, o projeto deve definir o equilíbrio entre o fornecimento e a demanda estabelecendo um estoque mínimo para cobrir os tempos de produção. Conforme a equipe do projeto estabelece esse equilíbrio, o gerente de projetos deve garantir que as políticas adequadas estejam em vigor para definir as normas e controles para o gerenciamento de todos os elementos do controle do inventário e armazém.
Guia para o PMD Pro 108
3.3.7.2.2 Transporte de materiais O objetivo do transporte é deslocar os suprimentos fisicamente de maneira confiável e segura, dentro do prazo, econômica e eficientemente até o seu destino. A estratégia de transporte depende não apenas das necessidades do projeto como também varia de situação para situação.
3.3.7.3
Gerenciamento de ativos
Todos os equipamentos, suprimentos e outras propriedades financiadas ou fornecidas ao projeto devem ser considerados como seu ativo. Como tal, o projeto deve identificar uma política de gerenciamento de ativo em que os materiais de valor do projeto sejam monitorados, mantidos e descartados de maneira consistente com as exigências da organização e/ou dos doadores. Essa política deve incluir a orientação sobre os seguintes tópicos: Definição de ativos: Cada organização precisará encontrar sua própria definição de valor e vida útil que defina o que é um ativo. Essa definição varia conforme a organização, o doador e/ou o projeto. O UNDP, por exemplo, identifica o limite dos ativos fixos como US$ 1.000 ou mais e uma vida útil de pelo menos três anos. A tabela abaixo fornece uma visão geral de várias das principais categorias de ativos que gerencia e a vida útil de cada categoria de ativos. Figura 50: Categorias de ativos do UNDP CATEGORIA
VIDA ÚTIL
Itens típicos que funcionam com eletricidade: (ex.: computadores, impressoras)
3 anos
Máquinas grandes: (ex.: geradores, condicionadores de ar)
20 anos
Móveis
10 anos
Veículos
5 anos
OUTROS FATORES
OU 100.000 quilômetros (62.000 milhas).
Registro de ativos: Os projetos devem manter registros completos e precisos de todas as aquisições de ativos fixos. Todos os ativos adquiridos para o projeto (através de compras, transferências ou doações) devem ser registrados.
Guia para o PMD Pro 109
Rotulação de ativos – Os ativos do projeto devem ser rotulados para facilitar a supervisão e controle. Qualquer convenção de rotulação adequada pode ser usada desde que seja aplicada consistentemente e sirva o propósito do monitoramento dos ativos. Monitoramento e registro de ativos – As informações dos ativos devem ser atualizadas regularmente para prestar contas sobre a aquisição, os ajustes, a transferência e informações de descarte. Isso incluirá uma contagem física e as discrepâncias precisarão ser investigadas, entendidas e documentadas no registro de problemas do projeto. Proteção dos ativos: Garantir que os controles adequados estejam em vigor de modo que os ativos fixos sejam mantidos e protegidos de maneira adequada. Esses controles variam conforme o ativo e o risco. Por exemplo, uma organização pode exigir que laptops sejam protegidos por um cabo de travamento adequado e colocados de modo seguro em uma gaveta trancada ou em um arquivo quando não estiverem sendo usados. Outro exemplo seria uma exigência de que os equipamentos de escritório emprestados aos integrantes da equipe sejam sempre registrados nos registros de equipamentos/empréstimos. Descarte de ativos – deve-se dever processos claros de descarte dos ativos que incluam qualquer requisito relacionado com aprovações, publicidade, requisitos dos doadores e relatórios. Se necessário, a política deve incluir qualquer requisito necessário relacionado com o valor do ativo ou o tipo de ativo que está sendo gerenciado (veículos, computadores, outros). O descarte inadequado de ativos pode ter um impacto importante nas finanças do projeto pois os doadores podem se recusar a permitir gastos em ativos que não foram descartados corretamente e podem exigir o pagamento e reduzir o valor dos pagamentos finais do contrato.
3.3.8
GERENCIAMENTO DE RECURSOS HUMANOS
O gerenciamento de recursos humanos é uma arte e uma ciência. A arte do gerenciamento de recursos humanos depende de habilidades interpessoais e da liderança do gerente de projetos. O gerente de projetos consegue motivar os interessados? Inspira confiança? Gerencia conflitos? Melhora o moral da equipe? A ciência do gerenciamento dos recursos humanos depende de um planejamento eficaz. O planejamento dos recursos humanos é um elemento integral de um plano de projeto abrangente de implementação. O plano de gerenciamento de recursos humanos do projeto identifica as atividades e os recursos necessários para gerenciar a equipe do projeto. Os componentes do gerenciamento dos recursos humanos são: Formação de uma equipe de projeto – Como parte da função de gerenciamento da equipe, o líder da equipe de projeto deve ser claro em seus sistemas para identificar candidatos para a equipe, entrevistar candidatos, identificar os critérios de seleção e fazer as seleções finais da equipe de projeto. Identificação das atribuições da equipe do projeto – As atribuições da equipe do projeto são a lista de deveres, das funções e responsabilidades dos integrantes da equipe. As atribuições da equipe Guia para o PMD Pro 110
frequentemente são usadas durante o processo de monitoração e controle para avaliar os integrantes da equipe individualmente. Documentação do organograma do projeto – Os organogramas representam os relacionamentos hierárquicos entre os integrantes da equipe. Desenvolvimento da equipe do projeto – Que habilidades são necessárias? Quais são os treinamentos necessários? Existem exigências de certificação? Quais são os problemas de conformidade? Realização da avaliação de desempenho – As avaliações de desempenho são avaliações formais ou informais documentadas do desempenho dos integrantes da equipe. Após analisar as informações, os gerentes de projeto podem identificar e resolver problemas, reduzir conflitos e aprimorar o trabalho geral da equipe. Promoção de um ambiente altamente produtivo para a equipe – como líder da equipe do projeto, o gerente de projetos deve trabalhar ativamente para identificar problemas e conflitos e trabalhar criativamente para solucioná-los. Muitas das atividades envolvidas no gerenciamento da equipe do projeto (implementação do plano da equipe do projeto, aquisição da equipe, identificação das atribuições da equipe, documentação dos organogramas) têm natureza técnica – frequentemente são descritos como a ciência do gerenciamento da equipe do projeto. As habilidades, atitudes e comportamentos necessários para se promover um ambiente altamente produtivo para a equipe, entretanto, depende da capacidade do gerente do projeto de ir além da ‘ciência’ do gerenciamento do projeto e se envolver na ‘arte’ da disciplina. Para promover um ambiente altamente produtivo para a equipe, o gerente de projetos deve ser habilidoso na comunicação da visão, no encorajamento da propriedade compartilhada, em transferir pautas dentro ou fora da organização e gerenciar situações em que não haja nenhuma autoridade hierárquica direta.
3.4
D ISCIPLINA 4: G ERENCIAMENTO DE RISC OS
Ao explorar os elementos “essenciais” do gerenciamento competente de projetos, a maioria das discussões converge rapidamente para o tópico de risco. Mas o que é risco? O termo é usado frequentemente solto, sem consistência e, algumas vezes, incorretamente. No contexto do PMD Pro, o risco é o efeito potencial da incerteza sobre os objetivos do projeto. Ao considerar a definição do risco, existem duas ideias principais que precisam ser mais exploradas: Probabilidade – o risco pode ser visto como relativo à probabilidade de eventos futuros incertos (se comparados com problemas que lidam com os eventos atuais que devem ser tratados imediatamente). Lembre-se, conforme discutido na fase de implementação de projeto da seção dois, esses problemas são riscos que podem se tornar realidade.
Guia para o PMD Pro 111
Impacto – o risco tem o potencial de afetar o projeto. A maioria das equipes de projeto se concentra no risco negativo que tem o potencial de prejudicar o projeto (prazo/calendário, custo/recursos, qualidade, escopo, etc.). Em geral, os riscos negativos devem ser evitados. Os riscos positivos, por outro lado, são conhecidos e entendidos menos amplamente. As equipes de projeto podem considerar riscos positivos se virem uma oportunidade potencial juntamente com um potencial de falha. Isso se chama assumir riscos com inteligência. O gerenciamento de riscos, entretanto, é uma disciplina central do gerenciamento de projetos e o objetivo deste capítulo é fornecer um guia conciso do gerenciamento de riscos no setor de desenvolvimento. Um evento de risco é algo que pode ocorrer e afetar o projeto. Observe que as palavras “podem ocorrer” indicam uma probabilidade inferior a 100%. Se um evento tem uma probabilidade de 100% - em outras palavras ele ocorrerá – o evento se tornou um problema (consulte a discussão sobre o gerenciamento de problemas na Seção dois). Durante os primeiros estágios da identificação e design do projeto, a equipe começará a ganhar um entendimento inicial dos riscos potenciais que podem confrontar o projeto. Por exemplo, em um projeto de agricultura as entrevistas iniciais com famílias de agricultores podem identificar problemas nos canais de distribuição e de marketing do produto. Conforme o projeto evolui, alguns riscos serão resolvidos ou diminuídos, enquanto outros podem aparecer e serem acrescentados. É importante, entretanto, revisitar continuamente a questão do risco dos primeiros estágios do projeto através de toda a fase de implementação. Os riscos são gerenciados através de um processo de quatro etapas:
Identificação de riscos - a identificação e documentação de todos os riscos que podem afetar o projeto.
Avaliação de riscos – a determinação da probabilidade de que os riscos ocorram e a estimativa de seu impacto potencial e priorização dos riscos.
Planejamento de resposta aos riscos – decidir quais ações são necessárias para reduzir ou remover as ameaças, especialmente aquelas com alta probabilidade e alto impacto.
Controle e monitoramento de riscos – responder aos riscos conforme eles ocorrem e garantir que os procedimentos adequados de gerenciamento de riscos estejam sendo seguidos.
Guia para o PMD Pro 112
3.4.1 IDENTIFICAÇÃO DE RISCOS Existem duas etapas dentro do processo de
Riscos negativos e positivos
identificação de riscos: 1. Definir as categorias de risco do projeto.
3.4.1.1 Definir as categorias de risco A categorização de riscos pode ser comparada com uma avaliação médica eficaz. Se o médico perguntar: “Como você se sente?", o paciente pode dizer "Ótimo." Mas o exame é muito mais revelador se o médico perguntar: “O que você sente no joelho?” E nos pulmões? Alguma dor nas costas?” Com essas perguntas, o paciente começará a pensar especialmente sobre áreas específicas do corpo.
O gerenciamento do projeto é abrangente!
2. Identificar riscos específicos em cada uma das categorias de risco.
O gerenciamento completo de riscos se concentrará tanto nos riscos negativos quanto nos positivos.
As categorias, entretanto, não devem ser muito amplas ou muito específicas. Se, no exemplo acima, o médico perguntasse
O risco negativo é representado por eventos potenciais que podem prejudicar o projeto. Em geral, esses riscos devem ser evitados. Os riscos positivos, por outro lado, referem-se a riscos que nós mesmos geramos porque vemos uma oportunidade potencial, juntamente com um potencial de falha. Considere, por exemplo, um projeto de agricultura com estimativa de ser concluído em seis meses. A equipe do projeto percebe que se forem acrescentados vários novos parceiros de implementação, o projeto pode ser concluído na metade do tempo. Obviamente, novos parceiros significam novos riscos. E se a capacidade deles for baixa? E se houver atrasos na adoção de novos sistemas? Etc. Aí está o dilema: você arrisca e introduz o risco para obter um ganho positivo? Ou continua com os parceiros tradicionais e se conforma com o prazo de entrega de seis meses?
apenas sobre a parte superior e inferior do corpo do paciente, isso não ajudaria muito. Por outro lado, se o médico perguntasse sobre cada osso, junta e órgão, o paciente rapidamente ficaria frustrado com a perda de tempo. Em vez disso, o médico deve identificar um número adequado de categorias significativas que ajudarão o paciente a identificar os problemas. Ao criar as categorias dos riscos do projeto de desenvolvimento, é importante reconhecer que cada projeto é único e que não é possível criar um conjunto único de categorias de risco adequadas a todas as organizações e projetos. As equipes do projeto devem pesquisar o contexto do desenvolvimento do projeto específico, criar um conjunto de categorias de risco adequadas às suas necessidades específicas. Algumas categorias potenciais de risco do projeto incluem: Estratégia/comercial Guia para o PMD Pro 113
Falha dos fornecedores em cumprir os compromissos contratuais Fraude/roubo Parceiros de implementação que deixam de fornecer o resultado desejado Econômico/financeiro/mercado Flutuação da taxa de câmbio Instabilidade da taxa de juros Inflação Desenvolvimentos de mercado que afetam os planos negativamente. Jurídico e regulamentar Legislações novas ou alteradas invalidam os pressupostos do projeto Deixar de obter a aprovação adequada (ex.: planejamento, consentimento) Composições contratuais não satisfatórias Fatores organizacionais/de gerenciamento/humanos Liderança inadequada Autoridade inadequada de pessoas-chave para desempenhar as funções Procedimentos inadequados de seleção da equipe Falta de clareza sobre as funções e responsabilidades Desavenças pessoais Falta de suporte operacional Político Mudança de governo ou de políticas governamentais Guerra e desordem Opinião pública adversa/intervenção na mídia Interferência de políticos nas decisões de desenvolvimento Meio ambiente Desastres naturais Mudanças bruscas nos padrões do clima Técnico/operacional/infraestrutura Design inadequado Mudança do escopo Expectativas não claras Risco de gerenciamento de projeto Falta de planejamento, análise de risco, contingências Acompanhamento e resposta de controle inadequados Cronogramas irreais Logística mal gerenciada Atrasos na aprovação dos documentos do projeto
3.4.1.2 Identificar riscos específicos das categorias Quando as categorias de risco em geral forem identificadas, a equipe do projeto deve colaborar com os principais interessados para identificar riscos específicos de cada categoria de risco. No mínimo, a equipe e os principais interessados devem começar examinando os documentos programáticos e específicos do projeto. Existem várias técnicas disponíveis para facilitar o risco. Elas incluem tempestade de ideias, grupos de foco, planejamento de situações e entrevistas com especialistas. Ao identificar os riscos, deve-se ter cuidado para anotar o risco de modo que três fatores fiquem aparentes para um futuro leitor. Eles são:
A causa ou origem do risco;
Guia para o PMD Pro 114
O evento do risco ou a situação propriamente dita; O impacto do risco sobre o projeto.
Por exemplo, “Como o transporte de materiais para essa área pode ser afetado por inundações, existe o risco de que as entregas de cimento não sejam feitas oportunamente, o que significa que as bases das latrinas não seriam concluídas dentro do cronograma”. Descrever os riscos dessa maneira permite a criação de respostas que tratem da causa, do risco propriamente dito ou do efeito. Muitos dos riscos iniciais serão identificados durante a fase de identificação e design do projeto. Conforme a equipe do projeto pesquisa o contexto do projeto através das atividades de avaliação e análise, os resultados desses exercícios começarão a mostrar o panorama dos riscos potenciais do projeto. O processo de identificação de riscos, entretanto, precisa continuar por toda a vida do projeto. Isso ocorre porque os riscos do projeto envolverão horas extras. Por exemplo, durante as primeiras fases de um projeto, os riscos podem ser mais centrados na aquisição de fundos ou no gerenciamento dos interessados. Conforme o design de identificação do projeto entra na implementação, os riscos podem se tornar mais operacionais na natureza e ser centralizados em questões de cronograma, estimativa de custos e orçamentos/controles. Tudo isso aponta para a importância de se garantir que a identificação dos riscos não seja uma atividade única que ocorra apenas uma vez no início do projeto. Os riscos devem ser monitorados por toda a vida do projeto para garantir que a equipe do projeto esteja ciente das ameaças potenciais ao sucesso do projeto, que surgirão inevitavelmente.
3.4.2 AVALIAÇÃO DE RISCO A avaliação de risco é o processo de quantificar os riscos documentados no estágio de identificação de risco. A avaliação de risco trata de dois desafios especialmente difíceis durante o gerenciamento dos riscos do projeto:
Priorização de riscos: Usando critérios acordados pela equipe do projeto e pelos principais interessados, os riscos são classificados de acordo com sua probabilidade e impacto.
Identificação da tolerância ao risco: Em seguida, a equipe do projeto precisa trabalhar com os principais interessados para identificar seus níveis de tolerância aos riscos, quais riscos são aceitáveis, quais extrapolam os níveis de tolerância aceitáveis e precisam ser gerenciados ativamente.
Uma ferramenta útil para avaliar riscos é a Matriz de avaliação de riscos. A tabela abaixo fornece um exemplo de como a matriz pode ser usada para avaliar os riscos em um projeto de desenvolvimento.
Guia para o PMD Pro 115
Figura 51: Matriz de avaliação de riscos Risco B
Alta Risco C
Média PROBABILIDADE do risco ocorrer
Risco A
Baixa Baixa
Média
Alta
IMPACTO potencial sobre o projeto No exemplo acima, o processo de criação da matriz de avaliação de riscos seguiu um processo de duas etapas: Classificação de prioridade dos riscos: A equipe do projeto e os interessados priorizaram três riscos classificando sua probabilidade e impacto potencial em uma escala Baixa, Média ou Alta Identificar a linha de tolerância ao risco: Os riscos estão classificados por cor (vermelho, laranja, amarelo, sem cor). Nesse exemplo, o Risco B é uma preocupação clara e será gerenciado ativamente. O Risco A está em uma célula sombreada (amarela), mas é uma preocupação de nível inferior e não será monitorado. O Risco C não está em uma célula sombreada, portanto, não extrapola as tolerâncias de risco do projeto. De algumas formas, a matriz de avaliação de riscos é uma ferramenta ilusoriamente simples. Embora a matriz possa ser relativamente simples, para usá-la produtivamente a equipe do projeto e os principais interessados precisam compartilhar um entendimento comum dos critérios usados para priorizar o risco e identificar os níveis de tolerância ao risco. Para chegar a esse entendimento comum, o gerente de projetos deve trabalhar com os principais interessados para concluir o processo, algumas vezes difícil, associado com a resposta às seguintes perguntas:
Que critérios serão usados para priorizar os riscos? Tempo? Escopo? Custo? Outros fatores como o valor para proteger beneficiários? Regulamentos de conformidade dos doadores? Segurança dos funcionários?
Que processo será usado para identificar as tolerâncias ao risco?
3.4.3 RESPOSTA AO RISCO A identificação e a avaliação do risco formam a base para opções sólidas de respostas ao risco. Quando um risco for identificado acima da linha de tolerância ao risco do projeto, a equipe do projeto deve identificar uma estratégia que responda melhor ao risco.
Guia para o PMD Pro 116
Lembre-se! O objetivo do gerenciamento do risco NÃO É ELIMINAR TODOS os riscos do projeto. Ao contrário, o objetivo é reconhecer quando responder se o risco ultrapassar os níveis de tolerância do projeto. Por exemplo, os projetos “intolerantes ao risco” tentarão ativamente gerenciar os riscos, independentemente de onde eles caiam na matriz. Por outro lado, projetos “tolerantes ao risco” podem estar dispostos a aceitar riscos grandes sem intervir para gerenciar ativamente a situação. Se o projeto decidir gerenciar um risco ativamente, as estratégias de resposta incluirão as seguintes opções (ou combinação de opções):
Evitar riscos – não faça (ou faça de um modo diferente) uma parte do escopo que tem alto impacto e/ou alta probabilidade de risco. Por exemplo, um projeto pode escolher não trabalhar em uma área geográfica porque há muita insegurança.
Transferência de risco – compartilhar o risco com outros atores para alguns aspectos do projeto. O exemplo mais comum de transferência de risco é o seguro. Por exemplo, as políticas de seguro transferem o risco de danos ao veículo e perda para a empresa seguradora.
Mitigação do risco – ato para reduzir a probabilidade e/ou o impacto de um risco potencial. Considere, por exemplo, um projeto preocupado com o risco de roubo de resultados/produtos. o A probabilidade do roubo em potencial pode ser reduzida aumentando-se o sistema de segurança do prédio (guardas, portas novas, janelas com grade). o O impacto do roubo potencial pode ser reduzido instituindo-se uma política em que apenas as resultados/produtos necessárias para os sete dias seguintes fiquem protegidas no armazém.
Aceitação do risco – se a probabilidade percebida e o impacto do risco forem avaliados como aceitáveis, uma organização pode escolher não tomar nenhuma providência. Por exemplo, um projeto pode reconhecer que enfrenta a possibilidade do início de uma estação chuvosa tardia interrompendo seu ciclo agrícola, mas a equipe escolhe conviver com o risco e não toma nenhuma precaução para evitar, transferir ou minimizá-la.
Observe que “ignorar” não é uma estratégia de resposta ao risco aceitável. O risco não deve deixar de ser reconhecido, gerenciado e não deve ser ignorado. Mesmo em situações em que o risco é aceito, ele não estará sendo ignorado. Nesses casos, a decisão de aceitar o risco baseia-se em um processo lógico de identificação, avaliação e resposta ao risco, com o resultado sendo a decisão de aceitar o risco. Nesse momento, a equipe do projeto precisará formular um plano de ação para as atividades de resposta ao risco selecionadas. O documento do gerenciamento do risco precisará realizar o seguinte:
Elaborar um plano de gerenciamento de risco organizado e completo;
Determinar os métodos a serem usados para implementar as respostas ao risco;
Planejar os recursos adequados de resposta ao risco.
Cada plano de risco deve ser documentado, mas o nível de detalhe variará dependendo do projeto. Projetos grandes ou projetos com altos níveis de incerteza se beneficiarão de planos de gerenciamento de risco detalhados e formais que registrem todos os aspectos da identificação do risco, da avaliação do
Guia para o PMD Pro 117
risco e da resposta ao risco. Projetos menores ou que contêm incertezas mínimas podem exigir uma lista de itens de sinais de perigo que pode ser atualizada em marcos críticos durante todo o desenvolvimento e a construção do projeto. Uma lista de itens de sinal de perigo é criada nos primeiros estágios do design do projeto e mantida como uma lista de verificação durante a vida do projeto. Ao listar os itens que podem possivelmente afetar o custo, o cronograma, o escopo e a qualidade do projeto (ou outros fatores que os interessados concordaram como sendo prioridade específica) e mantendo a lista atual, a equipe do projeto tem uma perspectiva melhor para definir as contingências adequadas e controlar os riscos. Para projetos mais complexos e projetos com mais incertezas, um documento de registro de risco fornece uma identificação mais formal e mais detalhada dos riscos e o plano para enfrentá-los. Similar à lista de sinais de perigo, o registro do projeto force aos gerentes de projetos uma lista dos riscos significativos. Entretanto, o registro dos riscos também contém informações sobre a magnitude da probabilidade e o impacto da ocorrência do risco. Ele também pode incluir as respostas de minimização propostas, os “proprietários” do risco e o status atual do risco. O registro do risco também pode incluir informações sobre os impactos dos riscos no custo e no cronograma. Embora o formato do registro de riscos possa variar conforme a organização ou conforme o projeto, um exemplo de formato seria incluir as informações abaixo.
Quando
Responsável
Resposta
Pontuação do risco
Impacto
Probabilidade
Status
Nome do risco
Categoria de risco
Figura 52: Registro de riscos
Estratégia Falta de capacidade do parceiro
Ativo – o risco 3/5 está sendo monitorado ativamente
4/5
7
Minimizar – dinheiro do orçamento para treinamento em contabilidade
Marian
T1
Natureza
A chuva atrasa as atividades
Isolado – risco 2/5 eliminado
3/5
5
Evitar – atrasar atividades até a estação seca
PM
T1
Político
A insegurança Isolado – ameaça as o risco foi entregas solucionado
5/5
7
Transferir – contratar transportadores para absorver o risco de perda
MV
T2
2/5
Etc.
Guia para o PMD Pro 118
3.4.4 CONTROLE E MONITORAMENTO DE RISCOS A etapa final do processo de gerenciamento de risco é monitorá-los continuamente para identificar qualquer alteração de seus status ou se eles se transformarem em um problema. É melhor manter as análises de risco regulares para identificar as ações pendentes, o impacto e a probabilidade do risco, remover riscos que passaram e identificar novos riscos. Recomenda-se que o registro de riscos seja criado o mais cedo possível na vida do projeto. Se ele ainda não tiver sido criado durante a fase de definição do projeto, ele deve ser definido no mesmo momento que outros elementos do sistema de controle interno forem definidos. Em seguida, o registro de riscos deve ser mantido durante todo o restante do projeto pois os riscos são dinâmicos. A lista dos riscos e estratégias associadas de gerenciamento de risco provavelmente mudarão conforme o projeto amadurece e novos riscos surgem ou os riscos previstos desaparecem. As análises de risco de projeto programadas regularmente podem ser usadas para garantir que o risco do projeto seja um item da pauta em todas as reuniões de gerenciamento do projeto. Se surgirem riscos não previstos ou o impacto de um risco for maior do que o esperado, a resposta planejada ou a alocação do risco pode não ser adequada. Nesse momento, a equipe do projeto deve realizar um planejamento de resposta adicional para controlar o risco.
3.5
D ISCIPLINA 5: G ERENCIAMENTO DA JUST IFICATIVA DO PROJETO
Os projetos são empreendidos por várias razões, mas no final, os investimentos são feitos por causa do valor potencial que o projeto fornecerá aos interessados envolvidos. Por exemplo:
A organização doadora precisa ser convencida de que um investimento nessa atividade valerá à pena;
A comunidade em que o projeto funcionará precisa perceber que sua participação resultará em benefícios concretos;
A liderança da organização de desenvolvimento precisa estar assegurada de que o sucesso do projeto contribuirá para os objetivos maiores do programa (ou portfólio).
O gerenciamento competente da justificativa do projeto ajuda a demonstrar por que um projeto faz muito sentido para a organização, para o doador e para as comunidades beneficiárias. Os gerentes de projetos bem-sucedidos precisam ter as habilidades e as competências para:
Identificar a justificativa de seus projetos;
Comunicar a justificativa para um público maior;
Acompanhar o progresso do projeto ao alcançar o valor que justificou sua existência.
Guia para o PMD Pro 119
3.5.1 IDENTIFICAÇÃO DAS NECESSIDADES BASEADAS EM ATIVOS OU BASEADAS EM PROBLEMAS Em outros setores que dependem enormemente de uma cultura de projetos (tecnologia da informação, telecomunicações, etc.), a justificativa do projeto é associada mais frequentemente com o Retorno sobre o investimento (ROI) e os benefícios comerciais. As perguntas feitas mais frequentemente pelos patrocinadores de projetos giram em torno da justificativa financeira do projeto: "Quanto tempo levará para que a organização recupere seu investimento no projeto?" E ainda, embora o ROI ofereça uma tremenda alavancagem e benefícios na definição de uma justificativa para um projeto, é apenas uma das várias ferramentas que podem ser usadas para apoiar uma decisão de investimento. No contexto do setor de desenvolvimento, os exercícios de justificativa do projeto começam geralmente com uma análise da necessidade. Além disso, conforme a equipe do projeto começa a coletar os dados referentes ao design preliminar do projeto, uma das decisões que devem ser tomadas é se o projeto definirá as necessidades com base na abordagem “baseada em problemas” ou a “baseada em ativos”. Em uma abordagem das necessidades baseadas em problemas, a primeira pergunta feita para a comunidade é “Quais são os problemas que vocês têm?” Essa pergunta visa a identificar as lacunas/falhas que podem ser solucionadas. O desafio dessa abordagem tradicional é que se procurar problemas, você invariavelmente os encontrará e, às vezes, eles podem ser problemas que de outro modo não seriam preocupantes se não tivessem sido identificados pela pergunta. Uma abordagem baseada em ativos é mais positiva no foco e enfatiza as oportunidades em vez dos problemas. Aqui a pergunta de abertura procura os pontos positivos e os recursos existentes. Por exemplo, “O que está indo bem?” “Que áreas de excelência você gostaria de compartilhar com outras pessoas?" Ao identificar os ativos/recursos que existem atualmente em uma comunidade, o foco da definição das necessidades fica menos concentrado em se consertar o que está quebrado e mais concentrado em se reproduzir e reforçar o que está funcionando. Figura 53: Abordagem baseada em problemas x abordagem baseada em ativos Abordagem baseada em problemas Definir o problema Consertar o que está quebrado Foco no negativo
Abordagem baseada em ativos Procurar soluções/ativos que já existem Reforçar o que está funcionando Foco no positivo
3.5.2 MUDANDO DE PROBLEMAS PARA UMA ESTRATÉGIA DE INTERVENÇÃO Muito do trabalho do gerenciamento de justificativa ocorre durante a primeira fase do projeto, identificação e design. Se nesse momento a equipe do projeto escolher seguir uma abordagem concentrada no problema para definir as necessidades, muito frequentemente o passo seguinte do processo de justificativa será a criação de uma árvore de problemas. A árvore de problemas fornece uma versão simplificada, porém robusta da realidade e identifica não apenas o problema central a ser solucionado, mas também afeta o problema principal e os problemas subjacentes e as causas raízes que contribuem para o estado atual.
Guia para o PMD Pro 120
Ao criar uma árvore de problema, é importante iniciar o processo com a identificação do ‘problema iniciador’ que pode ser identificado através de um processo aberto de tempestade de ideias com os interessados ou pré-identificado com base na análise preliminar de informações existentes. Quando o problema iniciador for identificado, o processo subsequente da elaboração da árvore de problemas será concluído (preferivelmente através de um processo de grupo participativo) usando estas instruções:
Problemas que são a causa direta do problema iniciador são colocados abaixo (causa):
Problemas que são efeitos diretos do problema iniciador são colocados em cima (efeitos).
A questão guia por trás da lógica da árvore do problema é ‘O que causa isso?’ Se houver duas ou mais causas combinadas produzindo um efeito, elas são colocadas no mesmo nível no diagrama. As setas de causa/efeito são usadas para conectar os níveis da árvore de problemas. O gráfico abaixo ilustra uma árvore de problemas elaborada na comunidade do Rio Delta e que examinou as causas e os efeitos da deterioração da qualidade da água do rio naquela área. Observe que esse diagrama é uma representação simplificada da situação – e não é incomum que as árvores de problemas tenham vários níveis de causa e efeito ao redor do problema principal. Como resultado, as árvores de problema frequentemente se tornam extremamente complexas.
Figura 54: Árvore de problemas do Rio Delta Quando uma árvore de problemas é concluída, a etapa seguinte mais comum é elaborar uma árvore de objetivos que comece a identificar as possíveis intervenções que podem ocorrer para consertar o que Guia para o PMD Pro 121
está quebrado na árvore de problemas. Em sua forma mais simples, a árvore de objetivos é uma imagem espelhada da árvore de problemas – em que cada declaração da árvore de problemas é transformada em uma declaração objetiva e positiva. Embora a árvore de problemas exiba os relacionamentos de causa e efeito, a árvore de objetivos mostra os relacionamentos ‘de meios com os fins’. Novamente, usando o exemplo da deterioração da qualidade da água, a árvore de problemas se tornaria uma árvore de objetivos parecida com o seguinte:
Figura 55: Árvore de objetivos do projeto do Rio Delta Quando a coleta ampla de necessidades é identificada (através da análise do problema como fizemos com o exemplo da árvore de problemas acima ou através de um processo baseado em ativos), o próximo desafio é analisar as necessidades que foram identificadas e determinar inicialmente se há uma justificativa adequada para a intervenção de um projeto. Nesse ponto, a organização de desenvolvimento deve considerar duas perguntas estratégicas críticas:
Quais elementos da árvore de objetivos serão incluídos na intervenção do projeto?
Quais elementos não serão incluídos no escopo do projeto?
Guia para o PMD Pro 122
O consenso sobre essas questões pode ser ardiloso e o processo de tomada de decisões tem o potencial de se tornar muito complexo e controverso. Mas não se esqueça das lições aprendidas na Seção 2 do Guia. Na discussão da fase de identificação e design do projeto, foi identificada uma série de critérios (Figura 16) que pode ser usada para guiar essas decisões em relação à seleção do escopo do projeto. Esses critérios ajudarão a equipe do projeto e os interessados a tomar decisões concretas sobre onde o projeto intervém, os serviços que são prestados, quem será atendido e como os serviços serão prestados. Voltando ao projeto do Rio Delta, os critérios de seleção do escopo incluíram a disponibilidade de recursos, a capacidade da organização de implementação, as prioridades do governo local e as necessidades das casas. Com base nesses critérios, a equipe do projeto criou uma árvore de alternativas que comunica os resultados, objetivos e metas (veja as caixas coloridas mais claras na imagem abaixo) que a organização pretende seguir. É importante observar que a árvore de alternativas também comunica quais elementos não entram no escopo do projeto (as caixas coloridas mais escuras da imagem). Figura 56: Árvore de alternativas do projeto do Rio Delta
Guia para o PMD Pro 123
3.6
D ISCIPLINA 6: G ERENCIAMENTO DAS PARTES INTERESSADAS
Os projetos de desenvolvimento são complexos e afetam um conjunto de interessados – indivíduos, grupos e organizações envolvidos ativamente em um projeto ou cujos interesses podem ser positiva ou negativamente afetados pela execução ou conclusão do projeto. A experiência mostra que quando os interessados são negligenciados ou mal entendidos no design do projeto ou seus interesses são envolvidos inadequadamente ou excluídos durante o planejamento e a implementação do projeto, os resultados são resultados inesperados e indesejados. Em contraste, os projetos que dedicam tempo para identificar e entender os interessados se beneficiam de:
Um entendimento mais claro dos indivíduos, grupos e instituições que serão afetados e que devem se beneficiar das atividades do projeto. Uma indicação melhor das capacidades desses interessados; Um entendimento mais bem informado de quem pode influenciar e contribuir com o planejamento e a implementação do projeto; Uma perspectiva aprimorada sobre alternativas para desenhar intervenções de projeto e tratar de conflitos do projeto.
Para ter sucesso, a equipe do projeto precisa criar a disciplina de gerenciar o relacionamento desses interessados. Os integrantes da equipe precisam entender a realidade e a complexidade dos interesses e das relações, avaliar e prever os impactos (positivos e negativos) do projeto sobre todos os grupos de interessados; desenhar e implementar planos de envolvimento que estimulem a participação e a comunicação eficiente no projeto. Os componentes de um sistema de gerenciamento competente dos interessados incluem:
Identificação dos interessados Análise dos interessados Envolvimento dos interessados Comunicação com os interessados
3.6.1 IDENTIFICAÇÃO DOS INTERESSADOS Durante as primeiras fases de um projeto, a identificação e o design, geralmente fica claro que o projeto terá vários interessados. Como resultado, uma das primeiras etapas da fase de identificação e design do projeto é identificar os interessados. Para auxiliar nesse processo, a PMD Pro reconhece seis categorias de interessados que fornecem um ponto inicial para a identificação dos interessados no projeto. Os usuários são pessoas que se beneficiarão diretamente dos produtos e/ou serviços do projeto. Por exemplo, em um projeto de gerenciamento de um manancial, os usuários incluirão, sem dúvida, integrantes da comunidade que serão beneficiados devido à melhor qualidade do solo e as famílias, com um acesso melhor à água (de qualidade). Guia para o PMD Pro 124
Interessados da governança são as pessoas ou grupos de pessoas que têm um interesse em como as coisas são gerenciadas no projeto. Por exemplo, essa categoria pode incluir os seguintes subgrupos:
Comissões de projeto, grupos de coordenação ou patrocinadores que gerenciam a estrutura de governança do projeto;
Auditores e reguladores que definiram os requisitos de conformidade e o contexto regulatório do projeto;
Financiadores (indivíduos ou organizações) que fornecem o financiamento do projeto. Esses financiadores podem ser externos (como quando uma organização doadora fornece financiamento) ou internos (como quando o projeto é financiado com fundos internos).
Fornecedores são indivíduos que participam ativamente no trabalho do projeto. Gerentes, integrantes da equipe, organizações de implementação, empreiteiros e fornecedores estão nessa categoria. Influenciadores são as pessoas que têm a capacidade de mudar a direção (positiva ou negativamente) do projeto. Um exemplo pode ser a mídia local, funcionários do governo, interessados comerciais e líderes de comunidade. Dependentes são aqueles que querem algo do projeto além do produto ou serviço final planejado. Normalmente, os dependentes são outros projetos ou unidades funcionais da organização que precisam de um dos resultados/produtos do projeto. Voltando ao projeto de desenvolvimento de um manancial, um projeto de moradias para famílias de baixa renda da mesma comunidade pode estar aguardando a conclusão do plano de zoneamento do manancial para começar suas atividades de construção. Sustentadores são grupos responsáveis por apoiar o produto após a conclusão do projeto. Novamente, usando o projeto de gerenciamento de um manancial como exemplo, pode-se esperar que o ministério de obras públicas e o ministério da agricultura assumam a propriedade de médio e longo prazo das atividades de gerenciamento do manancial após a conclusão das resultados/produtos do projeto. Algumas considerações a ter em mente ao se classificar os interessados em categorias incluem: -
Reconhecer quando as categorias de usuários se sobrepõem. Existem vários exemplos em que um indivíduo ou grupo entraria em mais do que uma categoria. Por exemplo, as comunidades poderiam ser usuários e sustentadores.
-
Considere dividir as categorias. As categorias podem ser divididas em subcategorias se isso for útil. A categoria de interessados da governança, por exemplo, já está dividida em três subcategorias. De modo similar, pode ser especialmente útil dividir a categoria de usuários em mais subgrupos.
Guia para o PMD Pro 125
-
Reconhecer que os interessados do projeto mudam com o tempo. Novos interessados podem entrar na área de intervenção enquanto outros perdem sua influência ou interesse. A identificação dos interessados é, portanto, um processo contínuo que deve ser revisitado em intervalos regulares durante toda a vida do projeto.
3.6.2 ANÁLISE DOS INTERESSADOS Quando os interessados do projeto estiverem identificados, a próxima etapa é concluir a análise dos interessados. O processo de análise dos interessados envolve:
Explorar os benefícios dos interessados. O que eles podem ganhar ou perder com o projeto? Quais são as expectativas dos interessados (positivas e/ou negativas)? Que recursos eles podem comprometer? Quais são as funções potenciais dos interessados? Quais são suas capacidades? Eles são apoiadores ou bloqueadores?
Mapeamento da influência dos interessados. A Influência refere-se ao poder que os interessados têm sobre um projeto com sua autoridade de tomada de decisão ou sua capacidade de influenciar as atividades do projeto ou interessados de maneira positiva ou negativa. Qual é a extensão da cooperação ou conflito em relacionamentos entre os interessados? Quem tem o poder de fazer as mudanças acontecerem para problemas imediatos, problemas subjacentes e causas raízes?
Embora haja muitas ferramentas que podem ser usadas para conduzir atividades de análises de interessados, esse documento se concentrará em duas delas em particular
Diagramas de Venn
Matriz de análise de interessados
Os diagramas de Venn são criados para analisar e ilustrar a natureza dos relacionamentos entre os principais grupos de interessados. Um diagrama de Venn é desenvolvido através da perspectiva de um único interessado no projeto (ou grupo de interessados no projeto). Cada círculo do diagrama identifica um interessado envolvido no projeto. O tamanho do círculo usado pode ajudar a indicar a influência/poder relativo de cada interessado, enquanto a separação espacial é usada para indicar a força ou fraqueza relativa do relacionamento/interação de trabalho entre diferentes grupos/organizações. Os diagramas de Venn normalmente são usados como uma ferramenta de planejamento participativo com grupos alvo para ajudá-los a classificar o conceito de tais relacionamentos. A imagem abaixo fornece um exemplo do uso de um diagrama de Venn para identificar o poder e a influência de vários interessados envolvidos no gerenciamento pesqueiro em uma comunidade que vive à margem do rio. Observe que o diagrama de Venn é retratado pela perspectiva de um dos grupos de interessados, nesse caso, famílias de pescadores. O tamanho e a localização do círculo da empresa X indica que ela é muito influente, porém remota. Usando a mesma lógica, a agência de proteção ambiental está remota e claramente alinhada com os interesses da indústria. As cooperativas pesqueiras representam os interesses dos pescadores e têm um relacionamento íntimo com os varejistas. O pequeno tamanho do círculo que representa o departamento de pesca indica que ele tem pouca influência. Guia para o PMD Pro 126
Figura 57: Diagrama de Venn dos interessados do projeto Rio Delta A matriz de análise dos interessados usa os resultados do diagrama de Venn (ou outra ferramenta de mapeamento da influência dos interessados) para identificar, elaborar e comunicar melhor os interesses, a capacidade e as ações potenciais dos interessados no projeto. Ao contrário do diagrama de Venn, a matriz permite uma narrativa mais profunda que fornece dados adicionais sobre os interessados, seus benefícios, sua influência e ações potenciais para tratar dos benefícios dos interessados. A tabela abaixo fornece uma matriz de análise dos interessados do projeto de gerenciamento de pesca apresentado no diagrama de Venn acima. A matriz ajuda a identificar maneiras para envolver os interessados adequadamente de modo que possam participar significativamente de todos os estágios do ciclo de vida do projeto. Por exemplo, a tabela identifica os riscos potenciais para o sucesso do projeto que vêm de setores têxteis mal regulamentados. Reconhecendo essa possível ameaça, a equipe do design do projeto pode tomar as medidas para garantir melhor o sucesso do projeto - talvez se reunindo com líderes do setor têxtil para negociar soluções ou para identificar maneiras de envolvê-los no projeto.
Guia para o PMD Pro 127
Figura 58: Matriz de análise de interessados Características básicas e partes interessadas
Interesse e como eles são afetados pelo problema
Capacidade e motivação para viabilizar mudanças
Ações possíveis para tratar os interesses dos interessados.
Famílias de pescadores 20,000 famílias, trabalhadores de baixa renda, empresas familiares de baixa produção, Organizados em cooperativas informais. Mulheres envolvidas ativamente no processamento de peixes.
• Manter e melhorar o meio de subsistência • A poluição está afetando o volume e a qualidade da pesca • A saúde da família está sofrendo, especialmente mães e crianças.
• Profundo interesse em medidas de controle da poluição • Influência política limitada, dada a fraqueza da estrutura organizacional
• Capacidade de apoio para organizar e fazer lobby • Reduzir a poluição • Identificar e desenvolver fontes alternativas de renda.
Indústria Têxtil Operação industrial de média escala, mal regulamentada e sem sindicatos. Bem relacionada com o partido de governo. Histórico ambiental ruim.
• Manter/ aumentar lucros • Uma certa preocupação com a imagem pública • Preocupação pelos custos dos regulamentos ambientais atuais.
• Ter recursos financeiros e técnicos para empregar tecnologias novas e mais limpas. • Motivação atual limitada para a mudança
• Aumentar a consciência do impacto social e ambiental • Fazer pressão política para influenciar no comportamento da indústria • Fortalecer e pôr na prática as leis ambientais
Casas 45,000 casas descartam lixo doméstico no rio que também é usado como fonte de água potável e para pesca
• Consciência da poluição da indústria têxtil e do impacto na qualidade da água • Gostaria de descartar o próprio lixo longe da casa • Gostaria de acesso á água limpa
• Compreensão limitada do impacto na saúde do descarte do lixo na água • Parecem dispostos a pagar por melhores serviços de controle de resíduos
• Acrescentar a consciência das implicações das práticas de descarte de resíduos • Trabalhar com as comunidades e o governo para tratar os problemas de saneamento e de água
Etc.
Etc.
Etc.
Agência de proteção ambiental: Etc.
Guia para o PMD Pro 128
3.6.3 ENVOLVIMENTO DOS INTERESSADOS Um gerente de projetos raramente trabalha sozinho. Mesmo os menores projetos dependem de redes de interessados. Como a complexidade dos projetos aumenta, a rede de relacionamentos se expande até poder potencialmente incluir grupos da comunidade, ministérios do governo, fornecedores, organizações não governamentais locais, universidades, organizações religiosas e outras. Um dos desafios no gerenciamento de uma rede de interessados é garantir que haja clareza em relação às funções, responsabilidades, autoridade e comunicações dos diferentes autores do projeto. Uma ferramenta que ajuda nesse desafio é o gráfico RECI – uma matriz normalmente criada com um eixo vertical (coluna esquerda) de tarefas ou resultados/produtos e um eixo horizontal (linha superior) de funções e cujo nome vem de um acrônimo das quatro principais funções geralmente identificadas na matriz: Responsável Um Responsável inclui aqueles que fazem o trabalho para conquistar a tarefa. Para cada tarefa existe um papel que é o principal na execução do trabalho, apesar de outros poderem ser delegados para auxiliar. Encarregado O Responsável pela prestação de contas deve aprovar (assinar) o trabalho que a pessoa Responsável prestou. Deve haver apenas uma Pessoa responsável pela prestação de contas especificada para cada tarefa ou mercadoria. Consultado Aqueles cujas opiniões são procuradas; e com quem há uma comunicação recíproca. Informado Aqueles que são mantidos atualizados sobre o progresso, frequentemente apenas na execução de uma tarefa ou mercadoria e com que há comunicação de apenas uma via. A tabela a seguir fornece um exemplo de uma matriz RECI simplificada para o projeto Rio Delta:
Guia para o PMD Pro 129
Figura 59: Matriz RACI do Rio Delta Tipo de participação
Quem é o responsável?
Tarefa do projeto
Quem está fazendo acontecer? Fazendo o trabalho associado com a tarefa? Líder Gerente de projetos Assistente Organização de implementação Líder Gerente de projetos Assistente ONG de implementação Líder Gerente de projetos Assistente ONG de implementação
Observação do conceito
Avaliação do design Análise Estrutura lógica e planejamento de M&E Elaboração e envio da proposta
Planejamento do programa detalhado
Líder Gerente de projetos ONG de implementação
Implementação
Líder Gerente de Projetos ONG de implementação
Monitoramento e avaliação
Líder Funcionário do Programa Doador
Quem é o Encarregado pela prestação de contas? Quem aprova a mercadoria associada à tarefa?
Quem precisa ser consultado?
Quem precisa ser informado?
Quem precisa ser solicitado ativamente para dar informações?
Quem precisa ser mantido em dia através de cópias de relatórios, emails, etc.
Gerente de projetos
Conselheiro técnico de saneamento
Funcionários do ministério da saúde (MOH)
ONG de implementação Conselheiro técnico Gerentes de projetos Funcionários locais ONG de implementação Pessoal técnico Conselheiro sobre AIDS Gerente de projetos Equipe comercial da sede ONG de implementação Gerente de projetos Funcionários locais
Participantes do projeto Funcionários do MOH local Doador
Funcionários do MOH (nível nacional)
Funcionários do MOH local Doador
Participantes do projeto
Participantes do projeto Funcionários do MOH local Conselheiro técnico de saneamento Doador Funcionário do Programa
Funcionários do MOH (nível nacional)
Conselheiro técnico regional
Funcionários do MOH (nível nacional)
ONG de implementação, Participantes do projeto, Gerente de projetos Participantes do projeto Funcionário do projeto
Doador
Quando criada, a matriz RECI pode ser compartilhada entre a equipe do projeto e os interessados do projeto para assegurar o entendimento e as expectativas dos cargos e responsabilidades do projeto.
Guia para o PMD Pro 130
3.6.4 COMUNICAÇÃO COM OS INTERESSADOS Quando as funções e responsabilidades dos interessados no projeto estiverem definidas, o desafio de implementação seguinte é o gerenciamento das comunicações do projeto com esses grupos. Uma boa comunicação é tanto uma arte como uma ciência. Por outro lado, a arte da comunicação bem-sucedida depende das habilidades interpessoais e de liderança do gerente de projetos. A ciência das comunicações, entretanto, é uma questão de planejamento e execução. Parte da ciência da boa comunicação é identificar cuidadosamente a estratégia de comunicação adequada em relação ao tamanho e complexidade do projeto. Por exemplo, no contexto de um projeto pequeno, práticas de comunicação excessivamente formais podem se tornar rapidamente um fardo administrativo que interferirá em outras atividades do projeto. No contexto de um projeto grande, as práticas de comunicação informais e eventuais podem transformar rapidamente o sucesso em desastre se os problemas e as oportunidades importantes se perderem através de planejamentos e implementações de comunicação negligentes. Como resultado, deve haver clareza em relação a “o que”, “porquê ”, “quem”, “como” e “quando” das comunicações. Essas informações podem ser identificadas em uma comunicação com um formato de plano como o seguinte: Figura 60: Plano de comunicações Comunicação
Objetivo
Público-alvo
Autor
Atribuído a
Veículo de comunicação
Frequência
Ao identificar o veículo para comunicações, o mecanismo precisa ser compatível com as mensagens e interessados do projeto. Como um guia, veja as várias perguntas a serem respondidas durante a determinação de quais mecanismos usar para a comunicação do projeto:
Qual mecanismo ou veículo aumentará a probabilidade de que a mensagem será realmente recebida, entendida e que providências serão tomadas?
Quanta informação será incluída e em que nível de detalhe?
Qual mecanismo é mais adequado para o tipo da mensagem?
Que mecanismo os interessados preferem?
Que nível de interação é necessário (uma via ou duas vias)?
Além disso, é importante diferenciar entre comunicações regulares ou contínuas com os integrantes da equipe do projeto, patrocinadores e outros principais interessados regularmente. Os métodos selecionados incluem relatórios de status, reuniões agendadas, atualizações mensais, comunicações orientadas para eventos, sessões de problemas críticos, reuniões com fornecedores, cronogramas de treinamento e cronogramas de implementação.
Guia para o PMD Pro 131
SEÇÃO 4
: ADAPTAÇÃO AO PMD PRO
“Como fazer o PDM Pro trabalhar para você?” Ferramentas, técnicas, metodologias e assim por diante não conseguirão nada se a equipe de projeto não puder fazê-las funcionar em seu ambiente real de projeto. Esta seção analisa como adaptar as várias ferramentas e técnicas que foram apresentadas para fazê-las trabalhar para o gerente de projetos e para a equipe de implementação do projeto.
4.1
P RINCÍPIOS FUNDAMENTA IS DA ADAPTAÇÃO
Como mencionado anteriormente neste guia do PMD Pro, “não há um único caminho para se gerenciar projetos. Cada projeto é único – com seus objetivos específicos.” Simplesmente aplicar ferramentas e técnicas sem pensar no contexto, nos recursos, nos relacionamentos e desafios, na melhor das hipóteses, contribuirá para um projeto robótico e “direcionado para modelos”. Além de criar muito trabalho desnecessário, apenas acrescentar ferramentas e técnicas sem pensar cuidadosamente na justificativa e na aplicação, provavelmente confundirá e desmoralizará o projeto e a equipe parceira de implementação. Dois gerentes de projetos concluíram o treinamento do PDM Pro e obtiveram um conhecimento e uma compreensão claros da metodologia. Nenhuma dessas organizações, infelizmente, tinha muita consideração ou entendimento sobre o gerenciamento do projeto. Ao voltar ao local de trabalho disseram a um gerente de projetos: “aquelas ferramentas PMD Pro são boas, mas nós não gostamos de fazer isso dessa maneira aqui.” Um superior disse ao outro gerente de projetos: “você deve decidir que ferramentas e técnicas deseja e implementá-las você mesmo”. Embora um gerente de projetos deve estar disposto a tomar a iniciativa individual apesar das restrições organizacionais, as duas situações descritas no exemplo acima devem ser evitadas sempre que possível. A implementação do PDM Pro deve envolver ferramentas e técnicas de avaliação disponíveis, decidindo quais serão mais úteis em uma situação em particular e pensando em como essas ferramentas podem ser integradas nos processos e sistemas organizacionais. Por exemplo, a fotografia abaixo exibe os resultados de um exercício simples de mapeamento que uma equipe de projetos concebeu em uma tempestade de ideias após a conclusão do curso PMD Pro tentando conectar as novas ferramentas do PM às ferramentas existentes.
Guia para o PMD Pro 132
Sempre que possível, os gerentes de projetos devem se envolver com suas organizações para discutir o seguinte:
Uma nova ferramenta complementará ou substituirá uma ferramenta existente? Como as informações de uma nova ferramenta se encaixarão nos processos existentes? Precisamos fazer mudanças nos processos existentes como resultado da integração de uma nova ferramenta ou técnica?
Além disso , um gerente de projetos deve analisar todas as ferramentas e técnicas e fazer essa pergunta: “Posso implementar essa ferramenta agora – ou quero mais suporte organizacional?” A Figura 59 ilustra um exemplo de um plano de adaptação de ferramentas. Ele é preenchido com dados de amostragem que mostram o status e indicam se as mudanças organizacionais ainda serão necessárias para viabilizar a implementação da ferramenta com sucesso. Figura 61: Exemplo de ferramentas de gerenciamento de projetos de adaptação Ferramenta EAP
Diagramas de rede Documento básico do projeto Diagrama RECI Controle de mudanças
4.2
Posso implementar agora? Sim
Desejo mais suporte?
Sim
Não
Não
Sim
Sim
Não
Sim
Sim
Não
Que mudanças organizacionais devem ser feitas antes que possamos adaptar adequadamente e usar essa ferramenta? Certificar-se de que minha equipe e nossos colaboradores contribuem com sua experiência específica e com detalhes Certificar-se de que minha equipe entenda o propósito e os processos. Encorajar nossa organização a concordar com um formato aprovado. Deve ser usado para solicitar e compartilhar informações com nossos interessados Deve se integrar e se vincular com nosso sistema de governança de projeto
F ATORES A SEREM CONSI DERADOS NA ADAPTAÇÃO DO PMD P RO
Nenhum projeto existe no vácuo. Os projetos “vivem” em programas e portfólios. Além disso, os projetos são gerenciados dentro do contexto dos sistemas organizacionais e estruturas dos doadores. Em um sentido, eles são um ambiente de operação mais amplo para os projetos. Portanto, como esses fatores afetam o desempenho dos projetos, devem ser levados em consideração na adaptação do PMD Pro aos projetos. C ONSIDERAÇÕES DO PROGRAM A – Conforme indicado anteriormente neste Guia, os programas consistem em um grupo de projetos relacionados, gerenciados de modo coordenado para se obter benefícios e o controle não disponível através do gerenciamento individual. As escalas de tempo dos programas são maiores e os resultados geralmente são mais complexos, com cada projeto individual Guia para o PMD Pro 133
desenhado para fazer uma contribuição para os objetivos. Claramente, em um programa bem gerenciado, haverá consistência de ferramentas, métodos e abordagens. Algumas ONGs têm uma unidade de gerenciamento de programa ou escritório (PMU ou PMO), cuja função é garantir a consistência das abordagens, padrões, geração de capacidade, kits de ferramentas e manuais de operação. Em tais situações, os gerentes de projetos e suas equipes precisam se alinhar às diretrizes, ferramentas e abordagens da unidade do programa. Além disso, em relação à conexão entre os programas e os projetos, as ONGs do setor de desenvolvimento internacional tendem a desenhar projetos grandes e complexos, quando seria mais adequado construir um programa que contivesse uma gama de projetos menores e mais simples. C ONSIDERAÇÕES DOS SISTEMAS – Um gerente de projetos raramente tem a oportunidade de influenciar a escolha dos sistemas organizacionais. Independentemente disso, o gerente de projetos deve certificarse de que o fluxo de informações de e para a organização atenda as necessidades da equipe do projeto. Os dois exemplos abaixo ilustram como um gerente de projetos deve examinar e entender os sistemas organizacionais para planejar maneiras de trabalhar para o benefício do projeto. Relatórios financeiros/orçamentários: Os orçamentos das propostas dos doadores geralmente são em forma de orçamentos de atividades. Várias ONGs, na verdade, não têm sistemas financeiros que conseguem reproduzir relatórios baseados em atividades – mas usam relatórios com itens de linha/códigos de conta. Em tal situação, um gerente de projetos deve garantir que o trabalho necessário para traduzir as informações financeiras de um formato para outro seja planejado e implementado de maneira oportuna. Moeda e taxas de câmbio do orçamento: Não é incomum que um gerente de projetos seja informado de que “um projeto tem uma perda de US$ 20.000 devido à taxa de câmbio, portanto é necessário realizar menos atividades para compensar”. Embora estratégias de hedging possam ser usadas pelas organizações para reduzir o impacto, a variação da taxa de câmbio não pode ser eliminada. Apesar disso, um gerente de projetos pode selecionar e usar as abordagens de gerenciamento mais adequadas para minimizar a defasagem. Como a tarefa de escolher a moeda do orçamento é feita frequentemente pela equipe do departamento de finanças ou angariamento de fundos, eles frequentemente selecionam a moeda do contrato. Se o gasto for feito em uma moeda diferente, isso complica imediatamente a vida da equipe do projeto – que fica com o orçamento em uma moeda e os gastos em outra. Embora não seja sempre possível, o gerente de projetos deve insistir para que o orçamento e os gastos sejam feitos na mesma moeda. Mesmo se a opção da moeda não for negociável, o gerente de projetos pode insistir na aplicação de uma taxa de câmbio atual em toda a vida do projeto – em vez de usar uma taxa contábil fácil de calcular. Embora tais estratégias de gerenciamento não minimizem as flutuações da moeda, elas ajudam a reduzir a variação da taxa de câmbio. C ONSIDERAÇÕES SOBRE TAM ANHO , COMPLEXIDADE E RISCO - O bom senso diz que um projeto pequeno e simples não requer a mesma consideração de um projeto de um milhão de dólares com vários locais e várias equipes em um ambiente difícil e inseguro e com vários interessados. Independentemente desse conhecimento, os fatores associados com as considerações de tamanho, Guia para o PMD Pro 134
complexidade e risco muito frequentemente recebem atenção insuficiente dos gerentes de projetos e suas organizações no setor de desenvolvimento internacional. Duas áreas importantes e relacionadas estão citadas abaixo como exemplos: Planejamento e gerenciamento de risco – um registro de riscos é sempre útil. Em um projeto de baixo valor e baixa complexidade, um registro de riscos simples e qualitativo pode ser suficiente. Em um projeto com um perfil de risco muito mais alto, o gerente provavelmente precisará de um registro quantitativo de risco. Além disso, as normas do projeto para usar e modificar o registro de risco diferem. Quem pode modificá-lo? Quem pode sugerir mudanças? Quando o registro de risco será analisado? Como com todas as ferramentas do PMD Pro, o gerente de projetos precisa pensar sobre a melhor maneira de usar as ferramentas e garantir que elas ajudem a equipe do projeto. Governança do projeto – uma área-chave que precisará de atenção em projetos mais complexos é a governança. Projetos menores e mais simples podem compartilhar uma estrutura de governança com vários projetos similares – talvez em um Comtê do programa ou um Comitê dos projetos do país ou uma estrutura similar. Um projeto de milhões de dólares, vários locais e várias equipes, precisará do seu próprio comitê do projeto com usuário sênior, um fornecedor sênior e um executivo de projetos representando seus interessados e suas perspectivas. O comitê do projeto precisará de termos claros de normas de referência e operação. Os integrantes do comitê devem entender suas funções e responsabilidades. Além disso, pode ser necessário alterar o perfil do comitê do projeto em um projeto mais longo para garantir que as perspectivas corretas sejam representadas. CONSIDERAÇÕES SOBRE APRENDIZAGEM E COMPETÊNCIA – Embora o gerente de projetos seja responsável por garantir que os integrantes da equipe e parceiros de implementação tenham as competências corretas, incluindo o conhecimento, as atitudes e habilidades, o gerente não deve esperar a geração de capacidades para tratar de todos os pontos fracos imediatamente. Uma parte essencial da adaptação do PMD Pro será a avaliação do nível atual da equipe e a implementação das competências dos parceiros e em seguida a promoção da aprendizagem para aumentar as capacidades onde forem identificadas lacunas. Uma ferramenta chamada diagrama aranha ilustra as lacunas entre as competências atuais (referências) e as desejadas (alvo) em um determinado período. A Figura 61 mostra uma maneira que o diagrama aranha pode ser usado – observando que existem várias outras aplicações desse diagrama. Figura 62: Diagrama aranha mostrando as referências e os alvos das competências selecionadas do PMD Pro
Guia para o PMD Pro 135
Se, por exemplo, um gerente de projetos tentar implementar uma Estrutura Analítica do Projeto (EAP)(WBS) sem certificar-se de que cada integrante individual da equipe e que cada parceiro de implementação entenda os fundamentos, aprecie o valor e possa realmente usar a EAP em uma situação real; a implementação provavelmente fracassará. Para organizações que implementam o PMD Pro, muitas das necessidades de aprendizagem e de competência provavelmente já terão sido consideradas. Entretanto, um gerente de projetos ainda precisa confirmar que todos parceiros e equipes do projeto possam usar corretamente cada uma das ferramentas escolhidas na prática real. As lacunas identificadas no desempenho precisam ser tratadas através de treinamento ou outras ações de gerenciamento. C ONSIDERAÇÕES DE DESEMPENHO – O gerente de projetos não é apenas responsável por garantir que a equipe do projeto se torne cada vez mais competente, mas, o mais importante, que o desempenho no trabalho contribua com os impactos visados pela organização. Deve-se lembrar que as alterações das organizações que trabalham no setor de desenvolvimento internacional geralmente têm como alvo a qualidade de vida, o bem-estar, a sustentabilidade, a redução da pobreza, a capacitação, a consciência social e/ou as áreas de melhoria ambiental. O curso do PMD Pro não deve ser visto como um evento "único" mas deve ser o início de um processo dinâmico que transforma a aprendizagem em desempenho aprimorado e, mais importante, contribui para o aprimoramento contínuo do projeto. Ao vincular o PMD Pro com os resultados do projeto e exigindo que a equipe seja responsável por colocar o que aprenderam em prática, os gerentes de projetos aumentam as chances de ver alterações que realmente importam e que estão muito próximas dos objetivos do projeto. O escritório de uma ONG, após conduzir alguns cursos do PMD Pro, decidiu que todos os participantes do evento de aprendizagem do PMD Pro deveriam desenvolver um plano individual de aprendizagem contínua e implementação do PMD Pro (envolvendo também uma equipe de projetos, quando possível). O modelo do plano pedia os detalhes da aplicação pretendida do conhecimento e ferramentas do PM no trabalho em um período de 12 meses. Um indivíduo designado da unidade de gerenciamento de projetos foi designado a se comunicar com cada aluno e seu supervisor direto com um intervalo de 3 meses para avaliar a conformidade, medir a Guia para o PMD Pro 136
contribuição para os resultados e coletar/compartilhar melhores práticas. O escritório dessa ONG também está oferecendo maneiras para que os alunos obtenham acesso virtual (por telefone, emails, mídias sociais, etc.), a especialistas em gerenciamento de projetos que possam aconselhá-los sobre o uso/adaptação da ferramenta e outros problemas de implementação do PMD Pro que possam surgir. Eles também decidiram começar fazendo uma transição para a introdução das ferramentas do PM de modo a permitir a experimentação, adaptação e aprendizagem contextualizada na prática. Eles decidiram que a ‘caixa de ferramentas’ inicial incluiria quatro ferramentas de PM que foram consideradas mais críticas para o aprimoramento inicial. Eles escolheram o RECI, o registro de riscos, a EAP e o registro de problemas. E M RESUMO – Adaptar o PMD Pro, conforme detalhado acima, é realmente essencial. Entretanto, devese observar uma advertência: O trabalho do gerente de projetos NÃO deve ser reduzido a um conjunto de regras rígidas aplicadas irrefletidamente em todo e cada projeto, programa ou portfólio. Lembre-se, conforme declarado anteriormente neste Guia, o gerenciamento de projetos é tanto uma ‘arte’ quanto uma ‘ciência’. Haverá circunstâncias em que uma ferramenta ou técnica de PM poderão ser usadas mas, por várias razões, ela pode NÃO ser a opção mais inteligente. Em outras palavras, estar muito entusiasmado em exigir a adoção obrigatória e uniforme das ferramentas e técnicas de PM em todos os projetos, programas e portfólios pode ser um erro enorme. Todo e qualquer gerente de projetos deve aprender a ser disciplinado e cuidadoso – tornando-se proficiente na análise de cada projeto individual antes de selecionar cuidadosa e colaborativamente e adotar o melhor do PMD Pro.
Guia para o PMD Pro 137
SEÇÃO 5 5.1
: ANEXOS
A NEXO 1: G LOSSÁRIO DE TERMOS
Atividades
Baseado em ativos Análise após a ação Considerações
Referência
Taxonomia de Bloom Estimativa de baixo para cima Capacidades
Certificado Competências
Observação do conceito Compressão de duração Credencial Caminho crítico Porta de decisão
As ações realizadas através de quais entradas (recursos financeiros, humanos, técnicos, materiais e de tempo) são mobilizadas para produzir resultados/produtos (treinamento, construção, etc.) de um projeto para o qual a equipe pode ser responsabilizada e que, quando agregada, produz produtos Metodologia que procura descobrir e destacar os pontos positivos da comunidade como um meio para o desenvolvimento sustentável Uma atividade de aprendizagem simples, rápida e versátil que pode ser usada para identificar e gravar lições e os conhecimentos que surgem de um projeto. Hipóteses sobre condições necessárias, internas e externas, identificadas em um design para garantir que os relacionamentos de causa e efeito presumidos funcionam conforme esperado e que as atividades planejadas produzem os resultados esperados Um ponto fatual de referência sobre as condições ou desempenho antes do início de uma intervenção – necessário para servir de base para o monitoramento, avaliação e controle do projeto Uma classificação de níveis de conhecimento/habilidades que fornecem uma estrutura para o planejamento da aprendizagem Essa técnica de estimativa começa consultando as mesmas pessoas responsáveis pelas tarefas do projeto e agregando suas estimativas em um orçamento global completo. Competências, habilidades, entendimentos, atitudes, valores, relacionamentos, comportamentos, motivações, recursos e condições que permitem que os indivíduos, organizações, redes/setores e sistemas sociais mais amplos executem as funções e alcancem os objetivos com o tempo. Um documento emitido para uma pessoa após a conclusão bem-sucedida de um curso de estudo Conjuntos integrados de habilidades, conhecimentos, atitudes e comportamentos necessários para se ter um desempenho eficiente em um determinado trabalho, cargo ou situação Uma visão geral de alto nível de um projeto elaborada para solicitar feedback antes de comprometer recursos para criar uma proposta extensa Acrescentar recursos adicionais ao projeto para acelerar o progresso do cronograma Prova de qualificação, competência ou autorização vinculada a uma pessoa A sequência de atividades que representam o caminho mais longo entre o início e o fim do projeto Os grandes pontos de controle usados para concluir e aceitar os produtos de uma fase particular do projeto e seguir para a fase seguinte
Guia para o PMD Pro 138
Separação DM&E Organização de desenvolvimento
Procedimento acelerado Flutuação (ou folga) Gráfico de Gantt Meta
Definição Impacto Insumos Problema Registro de controle de problemas Iteração Logística
Diagrama de rede Resultados
Uma técnica para separar ou dividir as resultados/produtos do projeto em elementos, componentes ou partes menores Design, monitoramento e avaliação Um espectro das organizações que entram em um contínuo amplo de alívio e desenvolvimento em seus projetos e práticas: uma extremidade do contínuo facilita os programas de longo prazo e de desenvolvimento participativo em áreas como meio ambiente, saúde, educação e agricultora e a outra extremidade do contínuo envolve mais diretamente a implementação rápida e temporária de projetos de alívio para pessoas que passam por inanição, falta de moradia ou desamparo devido a conflitos ou desastres naturais repentinos Acelerar o cronograma de um projeto realizando atividades que normalmente seriam concluídas em sequência e concluí-las em paralelo. O tempo em que uma tarefa do diagrama de rede de um projeto pode ser atrasada, sem causar atraso na data de conclusão do projeto Um gráfico de barras que representa graficamente o cronograma das atividades do projeto O nível mais alto desejado de resultados finais ou impactos (transformações, sustentabilidade, sustento, bem-estar, etc.) para o qual o projeto contribui - o objetivo máximo de muitas estruturas lógicas O processo de descrever e decidir começar um projeto e autorizar o gerente de projetos a empregar recursos, esforços e dinheiro O efeito significativo ou resultado de longo prazo (identificado com os resultados e níveis de meta em várias estruturas lógicas) Os recursos que o projeto deve mobilizar e aplicar em suas atividades (recursos humanos e financeiros, equipamentos, etc.) Um risco que ocorre no momento. Ele pode assumir a forma de uma decisão, situação ou problema não resolvido que impactará significativamente o projeto Um documento acessível ou banco de dados que resuma os problemas, seu status atual e quem é responsável atualmente pela solução O ato de repetir um processo por uma segunda, terceira ou mais vezes para atingir a meta, o objetivo ou resultado desejado O processo de planejamento, implementação e controle do fluxo e do armazenamento eficiente e econômico das matérias-primas do inventário em processo, dos bens acabados e das informações relacionadas do ponto de origem até o ponto de consumo com o propósito de estar em conformidade com os requisitos do cliente. Resumo ilustrado das decisões e fluxos que compõem um procedimento ou processo do início até o fim O que o projeto espera conseguir no nível de beneficiário (ex.: uso do conhecimento e habilidades na prática atual com o tempo; o transporte de bens em estradas construídas com o tempo) e contribuem com as alterações do nível populacional (redução da má nutrição, melhoria da renda, aumento dos rendimentos, etc.) que agregam e promovem o alcance dos objetivos e o impacto com o tempo
Guia para o PMD Pro 139
Produtos
Estimativa paramétrica
Portfólio Gerenciamento de portfólio Serviços de suprimento
Escopo do produto Programa
Projeto Documento básico do projeto Controle do projeto Plano de implementação do projeto Gerenciamento de Projetos Gerente de projetos
Proposta do projeto
Escopo do projeto Risco Planejamento em ondas sucessivas
As resultados/produtos tangíveis que resultam das atividades do projeto, incluindo produtos, bens, serviços e alterações (ex.: pessoas treinadas com conhecimento e habilidade maiores; estradas de boa qualidade construídas) que agregam e contribuem com os resultados desejados O uso de dados históricos de projetos similares para definir estimativas para as atividades do projeto. Essa técnica de estimativa baseia-se menos nas pessoas e mais em dados estatísticos. Um composto de programas/projetos de atividades, equipes e orçamentos alocados a cada um deles Início e gerenciamento o portfólio total de programas/projetos Planejamento e implementação de todos os aspectos da aquisição de recursos, incluindo desenvolvimento de especificações, pesquisa do mercado de fornecedores, negociações, atividades de compra, administração de contratos e controle de inventário Todas as resultados/produtos definidos para a entrega do projeto, atendendo a especificação acordada. (O que será fornecido) Um grupo de projetos relacionados gerenciados de modo coordenado para obter os benefícios e o controle não disponíveis através do gerenciamento individual deles Um conjunto de atividades que atende os objetivos acordados em um período específico com um conjunto acordado de recursos Um documento que descreve o projeto em um alto nível de detalhes e que é usado para autorizar o gerente de projetos a começar o trabalho O processo de medição e de relatos do andamento e a tomada de medidas corretivas para garantir que os objetivos do projeto sejam alcançados Uma apresentação abrangente e lógica do modelo de projeto detalhado para garantir que ele chegue a tempo, conforme o escopo e dentro do orçamento Planejamento, organização e gerenciamento de recursos para viabilizar a execução bem-sucedida dos objetivos, resultados e produtos específicos do projeto Um profissional do campo de gerenciamento de projeto que tem a responsabilidade de planejar, implementar e fechar projetos para viabilizar a execução bem-sucedida dos objetivos, resultados e produtos específicos do projeto Uma oferta clara e concisa que busca a aprovação de um financiador em potencial para fornecer produtos e/ou serviços em reposta às solicitações ou necessidades previstas do doador Todo o trabalho necessário para entregar o escopo do produto. (Como as resultados/produtos serão criadas e entregues) O efeito potencial da incerteza sobre os objetivos do projeto Processo reiterativo de fornecer maiores níveis e detalhe para o projeto. Preparação para a implementação no tempo
Guia para o PMD Pro 140
Estimativa de cima para baixo Estrutura Analítica do Projeto (EAP)(WBS)
Essa técnica de estimativa conta com um grupo relativamente pequeno de “especialistas” que trabalham para definir a estimativa global de um projeto que seja então decomposta em pacotes de trabalho menores. Uma lista hierárquica de tarefas criada pela decomposição do projeto em componentes e a divisão do processo do projeto em tarefas cada vez mais detalhadas
Guia para o PMD Pro 141
5.2
A NEXO 2: R ESULTADOS DA APRENDI ZAGEM DO PMD P RO
O objetivo do Anexo 2 é identificar os resultados de aprendizagem associados ao Guia do PMD Pro. Esses resultados de aprendizagem, por sua vez, fornecem aos candidatos ao exame do PMD Pro (e às organizações de treinamento) uma divisão detalhada do que os exames PMD Pro1 e PMD Pro2 avaliarão. O modelo de avaliação de resultado de aprendizagem PMD Pro identifica quatro níveis de resultados de aprendizagem. O exame PMD Pro1 mede os resultados dos níveis 1 e 2; enquanto o exame PMD Pro2 mede os resultados dos níveis 3 e 4. Figura 63: O modelo de avaliação dos resultados da aprendizagem do PMD Pro Modelo de avaliação dos resultados da aprendizagem do PMD Pro
Definição genérica do modelo de avaliação dos resultados de aprendizagem do APMG
1. Conhecimento
2. Compreensão
3. Aplicação
4. Análise
Conhecer fatos, termos e conceitos chave do manual/orientação
Entender os conceitos chave do manual/orientação
Ser capaz de aplicar os conceitos chave relativos à área do plano de estudos para uma determinada situação
Ser capaz de identificar, analisar e distinguir o uso adequado e inadequado do PMD Pro
Figura 64: Resultados de aprendizagem do Guia do PMD Pro Código da área do plano de estudos PR
Área do plano de estudos: Projetos do setor de desenvolvimento
PMD Pro1
PMD Pro2
Referência manual primária
Nível Tópico Conhecer fatos, termos e conceitos relacionados aos projetos no tópico do setor de desenvolvimento. 01
01
01
02
01
03
Definir os termos do gerenciamento de projeto no contexto do desenvolvimento internacional, incluindo projetos, programas, portfólios e gerenciamento de projetos. Identificar os três lados do triângulo de gestão conforme definido no PMD Pro Recordar as competências dos gerentes de projetos no setor de desenvolvimento
Guia para o PMD Pro 142
1.3, 1.4
1.3 1.6
01
04
Recordar as responsabilidades dos gerentes de projetos no setor de desenvolvimento Entender os projetos do tópico do setor de desenvolvimento
1.3
02
01
1.2
Explicar como a cultura de projetos do setor de desenvolvimento difere do de outros setores. 02 02 Mapear as habilidades e as responsabilidades dos gerentes de projetos no setor de desenvolvimento 02 03 Explicar o relacionamento entre os lados de um triângulo de gestão e as suas implicações no gerenciamento de projetos. Ser capaz de aplicar e personalizar os projetos do setor de desenvolvimento a uma situação específica 03
1.6 1.3
01
Gerenciar o desempenho da equipe que tem vários níveis de competência no gerenciamento de projetos 03 02 Identificar as vantagens do gerenciamento de um grupo de projetos dentro do contexto de um programa 03 03 Identificar o desenvolvimento das habilidades necessárias conforme um integrante da equipe de projeto progride da gerencia de projetos de nível básico para um gerente de projetos experiente. 03 04 Dada uma situação em que os limites do projeto são instáveis, identificar alternativas para gerenciar o triângulo de gestão . Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada dos projetos na área do plano de estudos do setor de desenvolvimento em uma situação específica 04
01
04
02
04
03
1.4 1.6
1.3
Identificar as diferenças das competências do gerenciamento de projetos necessárias conforme aumentam o tamanho, complexidade e o risco de uma situação do projeto Comparar e contrastar o conteúdo, propósito e o processo dos projetos, programas e portfólios internacionalmente Identificar as implicações das mudanças nos limites do projeto no gerenciamento do triângulo de gestão .
Código da área do plano de estudos PM Nível
1.6
Área do plano de estudos: O modelo De Projeto por Fases do PMD Pro
1.6
1.4 1.3
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados ao modelo de fase de projeto PMD. 01
01
Identificar as seis fases no modelo de fase de projeto do PMD Pro.
2.2
01
02
Recortar termos, fatos e conceitos relacionados às seis fases do ciclo de vida do projeto genérico do setor internacional de desenvolvimento
2.2
Entender o modelo De Projeto por Fases do PMD Pro
Guia para o PMD Pro 143
02
01
Explicar as maneiras que as fases do projeto do modelo de fase de projeto do PMD Pro interagem entre si.
2.2
02
02
Explicar a diferença entre o design, monitoramento e avaliação do projeto e o gerenciamento do projeto no contexto do setor de desenvolvimento internacional.
2.2
02
03
Entender o propósito e os benefícios das portas de decisão de gerenciamento através do ciclo de vida do projeto do PMD Pro.
2.2
02
04
Explicar a importância da incorporação dos princípios do gerenciamento de projetos durante toda a vida de um projeto.
2.2
Ser capaz de aplicar e personalizar o modelo de fase de projeto do PMD Pro a uma situação específica 03
01
Capacidade de aplicar as seis fases, personalizando as atividades e as ações recomendadas quando adequado a uma situação específica do projeto
2.2
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada da área do plano de estudos e o modelo de fase de projeto do PMD Pro a uma situação específica. 04
01
Capacidade de avaliar a aplicação das seis fases a uma situação específica do projeto, avaliando se as atividades relevantes do processo foram aplicadas corretamente
Código da área do plano de estudos ID Nível
Área do plano de estudos: Identificação e design do projeto
2.2
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à área de identificação e design do projeto. 01
01
Recordar as três categorias dominantes do trabalho na fase de identificação e design do projeto
2.2.1
01
02
Identificar os propósitos da coleta e análise de dados
2.2.1.1, 2.2.2.2
01
03
Identificar metodologias, abordagens e ferramentas para coleta de dados
2.2.1.2
01
04
Identificar metodologias, abordagens e ferramentas para a análise de dados
2.2.1.2
01
05
Identificar os propósitos da estrutura lógica
2.2.1.3
01
06
Definir as 5 características de um indicador SMART
2.2.1.3
Guia para o PMD Pro 144
01
07
Recordar os parâmetros chave do projeto descritos na estrutura lógica
2.2.1.3
01
08
Recordar os exemplos de portas de decisão na vida de um projeto
2.2.1.4
Entender a fase de identificação e design do projeto 02
01
Explicar o conceito da diminuição de oportunidades para gerenciar economicamente as mudanças durante a vida do projeto
2.2.1
02
02
Identificar as diferenças entre as quatro categorias de necessidades sociais
2.2.1.1
02
03
Explicar a importância da triangulação da fase de identificação e design do projeto
2.2.1.1
02
04
Identificar as diferenças entre os dados primários (qualitativos e quantitativos) e os dados secundários.
2.2.1.1
02
05
Explicar as categorias de critérios que determinam o que está incluído nas intervenções do projeto
2.2.1.2
02
06
Entender a lógica vertical e horizontal do quadro lógico do projeto
2.2.1.3
02
07
Explicar os benefícios das portas de decisão de gerenciamento no contexto do gerenciamento do projeto.
2.2.1.4
Ser capaz de aplicar e personalizar a fase de identificação e design do projeto a uma situação específica 03
01
Selecionar a ferramenta mais adequada para os objetivos pretendidos da coleta e análise de dados
2.2.1.1, 2.2.1.2
03
02
Identificar os elementos a serem incluídos nas intervenções do projeto com base em categorias de critérios de decisão identificadas claramente.
2.2.1.2
03
03
Dada uma situação específica, usar critérios de decisão prosseguir/não prosseguir para identificar se os projetos devem ser aprovados
2.2.1.4
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada da área do plano de estudos Fase de identificação e design do projeto a uma situação específica Especificamente para: 04
01
Diferenciar as vantagens de cada um dos tipos de coleta de dados
2.2.1.1
04
02
Comparar e contrastar as resultados/produtos e indicadores do quadro lógico do PMD Pro em cada um dos quatro níveis.
2.2.1.3
04
03
Explicar as variações da oportunidade de gerenciar as alterações economicamente durante a vida de um projeto
2.2.1
04
04
Dada uma situação específica de um projeto, diferenciar entre as 4 categorias de necessidades do projeto.
2.2.1.1
04
05
Interpretar a lógica vertical e horizontal de um quadro lógico.
2.2.1.3
04
06
Avaliar a qualidade dos indicadores do projeto com base no uso dos critérios SMART
2.2.1.3
Guia para o PMD Pro 145
Código da área do plano de estudos SU Nível
Área do plano de estudos: Definição do projeto
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à área de definição do projeto. 01
01
Conhecer os objetivos da fase de definição do projeto
2.2.2.1
01
02
Identificar as três perspectivas que devem ser representadas em um comitê de projetos.
2.2.2.2
01
03
Identificar o propósito das comunicações de lançamento do projeto
2.2.2.4
Entender a definição do projeto 02
01
Entender o propósito do documento básico do projeto
2.2.2.3
02
02
Explicar a importância da definição de uma estrutura de governança do projeto
2.2.2.2
02
03
Explicar a conexão entre as tolerâncias e a governança do projeto
2.2.2.1
02
04
Explicar as responsabilidades do patrocinador de um projeto e de um comitê de projeto
2.2.2.2
Ser capaz de aplicar e personalizar a definição do projeto a uma situação específica 03
01
Com base em uma situação do projeto, criar ou atualizar o documento básico do projeto.
2.2.2.3
03
02
Com base em uma situação do projeto, identificar estratégias para aprimorar o desempenho do projeto através de processos aprimorados de governança do projeto.
2.2.2.2
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada da área do plano de estudos da configuração do projeto a uma situação específica 04
01
Capacidade de avaliar a aplicação das ações da fase de definição do projeto ao se deparar com uma situação específica do projeto
Guia para o PMD Pro 146
2.2.2
Código da área do plano de estudos PP Nível
Área do plano de estudos Planejamento do projeto
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à área de planejamento do projeto. 01
01
Recordar fatos, termos e conceitos relacionados à importância e cronologia do plano de implementação do projeto.
01
02
Identificar os oito componentes de um plano de projeto abrangente.
01
03
Identificar as vantagens de desenvolver planos de projeto através de um processo participativo
2.2.3
2.2.3.3
2.2.3.5
Entender a fase de planejamento do projeto Especificamente para: 02
01
Explicar a importância de incorporar cada um dos princípios do gerenciamento de projetos do PMD Pro no processo de planejamento de projetos
02
02
Entender as vantagens do planejamento em ondas sucessivas
02
03
Comparar e contrastar os quadros lógicos, propostas e planos de implementação do projeto
2.2.3.2 -2.2.3.6
2.2.3.6
2.2.3
Ser capaz de aplicar e personalizar a fase de planejamento do projeto a uma situação específica Especificamente para: 03
01
Identificar situações em que se deve usar uma abordagem de planejamento em ondas sucessivas.
03
02
Com base nas situações do projeto, identificar os pontos positivos e negativos do plano do projeto em termos de equilíbrio, entendimento, integração, participação e iteração.
2.2.3.6
2.2.3.2 – 2.2.3.6
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada da área do plano de estudos do planejamento do projeto a uma situação específica para: 04
01
Comparar e contrastar o propósito da estrutura lógica, a proposta do projeto e o plano de implementação do projeto em termos de propósito, conteúdo, público e processo.
04
02
Explicar o relacionamento entre as áreas de disciplina do projeto e um plano de projeto abrangente.
2.2.3.3
04
03
Explicar o relacionamento entre o triângulo dos limites do projeto e um plano de projeto integrado.
2.2.3.4
Guia para o PMD Pro 147
2.2.3.3
Código da área do plano de estudos PI Nível
Área do plano de estudos: Implementação do projeto
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à área da fase de implementação do projeto. 01
01
Definir os termos relacionados à implementação do projeto, incluindo problemas, registros de problemas e controles internos
2.2.4.1 – 2.2.4.3
01
02
Identificar os quatro processos básicos no processo de gerenciamento de problemas
2.2.4.1
01
03
Identificar as atividades conduzidas para gerenciar pessoas durante a implementação do projeto
2.2.4.2
Entender a fase de implementação do projeto 02
01
Entender a importância do gerenciamento de problemas na implementação dos projetos de desenvolvimento
2.2.4.1
02
02
Explicar a sequência e a relação entre os quatro processos básicos do gerenciamento de problemas
2.2.4.1
02
03
Identificar os benefícios de sistemas de controle internos bem gerenciado
2.2.4.3
Ser capaz de aplicar e personalizar a fase de planejamento do projeto a uma situação específica 03
01
Desenvolver um registro de problemas com base em uma situação específica do projeto
2.2.4.1
03
02
Aplicar um processo de quatro etapas no gerenciamento de problemas em uma situação específica do projeto
2.2.4.1
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada da área do plano de estudos do planejamento do projeto a uma situação específica 04
01
Identificar alternativas para sistemas de controle interno com base nas categorias de sistemas administrativos, financeiros e logísticos
Guia para o PMD Pro 148
2.2.4.3
Código da área do plano de estudos ME Nível
Área do plano de estudos: Monitoramento, avaliação e controle do projeto
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à área da fase de monitoramento, avaliação e controle do projeto. 01
01
Recordar os fatos, termos e conceitos relacionados com os níveis de avaliação/monitoramento do projeto e sua conexão com a estrutura lógica do projeto.
2.2.5.1 – 2.2.5.3
01
02
Recordar fatos, termos e conceitos relacionados a diferentes abordagens de avaliação
2.25.2
01
03
Recordar fatos, termos e conceitos relacionados com o plano de monitoramento e avaliação do projeto
01
04
Recordar fatos, termos e conceitos relacionados com o gerenciamento do controle de mudanças
2.2.5.2
Entender a fase de monitoramento, avaliação e controle do projeto. 02
01
Identificar os seis elementos de um sistema de monitoramento do projeto
2.25.2
02
02
Identificar as seis áreas de tolerâncias do projeto
2.2.5.5
02
03
Explicar a troca entre custo e complexidade durante a coleta de dados de monitoramento
2.2..5.2
Ser capaz de aplicar e personalizar a fase de monitoramento, avaliação e controle do projeto a uma situação específica 03
01
Explicar a importância do plano de monitoramento do projeto e como seu conteúdo difere daquele contido no quadro lógico e no plano do projeto.
2.2.5.2
03
02
Entender os elementos que devem informar o plano de monitoramento e avaliação do projeto
2.2.5.2
03
03
Explicar as razões para avaliar os projetos
2.2.5.3
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada da área do plano de estudos do monitoramento, avaliação e controle do projeto 04
01
Comparar e contrastar o conteúdo, o processo e o propósito dos indicadores quantitativos e qualitativos
2.2.5.2
04
02
Comparar e contrastar o custo e a complexidade das diferentes abordagens de monitoramento
2.2.5.2
04
03
Comparar as diferenças entre o monitoramento, a avaliação e o controle do projeto.
2.2.5.1
04
04
Explicar o relacionamento entre o monitoramento e a avaliação do projeto e um processo de planejamento reiterativo.
2.2.5.1
Guia para o PMD Pro 149
04
05
Diferenciar entre os indicadores de monitoramento e avaliação em níveis diferentes da estrutura lógica do projeto
Código da área do plano de estudos EP Nível
Área do plano de estudos: Transição para o final do projeto
2.2.5.1
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à área da fase de transição para o final do projeto. 01
01
Recordar as 4 opções para transição do projeto
2.2.6.1
01
02
Recordar as atividades relacionadas ao encerramento administrativo, contratual e financeiro dos projetos
2.2.6.3
01
03
Identificar o processo de duas etapas para verificar as resultados/produtos do projeto.
2.2.6.2
Entender a fase de transição para o final do projeto 02
01
Distinguir entre as análises após a ação e as avaliações do final do projeto
2.2.6.4
02
02
Explicar o propósito e o conteúdo de uma matriz de planejamento de transição do projeto
2.2.6.1
Ser capaz de aplicar e personalizar a fase de transição para o final do projeto a uma situação específica 03
01
Criar uma estratégia de transição para o final do projeto
2.2.6.1
03
02
Selecionar entre as melhores ferramentas para coletar o aprendizado no final do projeto com base nos limites dos projetos e objetivos de aprendizagem.
2.2.6.4
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada da área do plano de estudos da fase de transição para o final do projeto a uma situação específica 04
01
Distinguir entre a aplicação adequada e inadequada do encerramento administrativo, contratual e financeiro de um projeto.
2.2.6.4
04
02
Comparar e contrastar as diferentes opções para a aprendizagem no final do projeto
2.2.6.5
04
03
Distinguir entre a aplicação adequada e inadequada do encerramento administrativo, contratual e financeiro.
3.3.6.4
Guia para o PMD Pro 150
Código da área do plano de estudos DO Nível
Área do plano de estudos: Visão geral das disciplinas de gerenciamento do projeto
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à área do plano de estudos. 01
01
Conhecer as seis disciplinas de gerenciamento de projetos.
3.0
Entender o tópico Visão geral das disciplinas e gerenciamento do projeto. 02
01
Entender como o ciclo de projeto do PMD Pro é apoiado pelas seis disciplinas de gerenciamento de projetos.
3.0
02
02
Explicar como as seis disciplinas podem ser aplicadas dentro do ciclo de projetos do PMD Pro.
3.0
Ser capaz de aplicar e personalizar o tópico Visão geral das disciplinas de gerenciamento do projeto a uma situação específica 03
01
Capacidade de aplicar as seis disciplinas a uma situação específica do projeto.
3.0
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do tópico Visão geral das disciplinas de gerenciamento de projeto a uma situação específica 04
01
Capacidade de avaliar a aplicação das seis disciplinas a uma situação específica do projeto.
Código da área do plano de estudos SM Nível
Área do plano de estudos: Gerenciamento do escopo
3.0
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados ao gerenciamento do escopo. 01
01
Recordar os fatos, termos e conceitos relacionados ao gerenciamento do escopo, incluindo o escopo do produto, o escopo do projeto e a EAP
3.1.1 – 3.1.2
01
02
Identificar os benefícios de uma estrutura de divisão do trabalho
3.1.2
Entender o gerenciamento do escopo 02
01
Entender a diferença entre o escopo do produto e o escopo do projeto.
3.1.1
02
02
Entender que o escopo do projeto deve ser confirmado, abrangente e detalhado.
3.1.1
Guia para o PMD Pro 151
02
03
Entender os três problemas mais comuns que surgem da ausência de um escopo definido claramente
3.1.1
02
04
Entender a composição de uma EAP (estrutura de divisão de trabalho).
3.1.2
02
05
Explicar as vantagens dos dois formados da EAP.
3.1.2
Ser capaz de aplicar e personalizar o gerenciamento do escopo a uma situação específica 03
01
Produzir uma Estrutura Analítica do Projeto (EAP)simples para uma situação específica do projeto em um formato encomendado.
3.1.2
03
02
Capacidade de produzir uma Estrutura Analítica do Projeto (EAP)simples para uma situação específica do projeto em um formato de diagrama gráfico.
3.1.2
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do gerenciamento do escopo a uma situação específica 04
01
Explicar o escopo abrangente e detalhado do produto e do projeto através do uso de uma situação específica do projeto.
3.1.1
04
02
Avaliar uma estrutura de divisão do trabalho em termos de abrangência e detalhes para uma situação específica do projeto.
3.1.2
Código da área do plano de estudos TM Nível
Área do plano de estudos: Gerenciamento do tempo
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados ao gerenciamento do tempo. 01
01
Conhecer as 5 etapas do planejamento do cronograma.
3.2.0
01
02
Definir os termos relacionados ao gerenciamento do tempo, incluindo os diagramas de rede, os caminhos críticos, o gráfico de Gantt, a folga do projeto, o procedimento acelerado e compressão de duração do projeto.
3.2.1-3.2.5
Entender o gerenciamento do tempo 02
01
Entender as cinco etapas do processo de planejamento do cronograma:
3.2.0
02
02
Explicar o relacionamento entre a estimativa de recursos e a criação do calendário
3.2.2 – 3.2.3
02
03
Entender o relacionamento entre o triângulo de limites do projeto e o desenvolvimento do cronograma
3.2..0
02
04
Entender o propósito, a estrutura e o conteúdo de um gráfico de Gantt.
3.2.4
02
05
Entender o propósito, a estrutura e o conteúdo de um diagrama de rede
3.2.1
Guia para o PMD Pro 152
Código da área do plano de estudos TM 02
06
Área do plano de estudos: Gerenciamento do tempo
PMD Pro1
PMD Pro2
Explicar o propósito e o processo de compressão de duração e procedimento acelerado
Referência manual primária 3.2.5
Ser capaz de aplicar e personalizar o gerenciamento do tempo a uma situação específica 03
01
Capacidade de construir um diagrama de rede simples dada uma situação específica do projeto.
3.2.1 – 3.2.4
03
02
Capacidade de construir um gráfico de Gantt simples dada uma situação específica do projeto.
3.2.4
03
03
Capacidade de identificar fatores de duração potenciais do projeto em uma dada situação específica do projeto.
3.2.3
03
04
Capacidade de identificar o caminho crítico de um projeto em um dado diagrama de rede para uma situação específica do projeto.
3.2.3
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do gerenciamento do tempo a uma situação específica 04
01
Discriminar quais tarefas de um dado diagrama de rede são parte do caminho crítico do projeto versus aqueles que são flutuação ou folga do projeto
3.2.3
04
02
Capacidade de explicar quando um gráfico de Gantt resumido é usado versus um gráfico de Gantt completo.
3.2.4
04
03
Identificar as oportunidades de gerenciar projetos atrasados através da compressão de duração e do procedimento acelerado.
3.2.5
Código da área do plano de estudos
Área do plano de estudos: Gerenciamento financeiro
PMD Pro1
PMD Pro2
Referência manual primária
FM Nível
Tópico
Conhecer fatos, termos e conceitos relacionados ao gerenciamento financeiro. 01
01
Definir os termos relacionados ao gerenciamento financeiro, incluindo custos diretos, indiretos, custos de transação, serviços compartilhados, tabelas de contas, variação e análise dos valores agregados
3.3.1 – 3.3.3
01
02
Definir as três abordagens para a realização de estimativas do projeto
3.3.2
Entender o gerenciamento financeiro
Guia para o PMD Pro 153
Código da área do plano de estudos TM
Área do plano de estudos: Gerenciamento do tempo
PMD Pro1
PMD Pro2
Referência manual primária
02
01
Explicar a vantagem de criar estimativas de fase de orçamento.
3.3.2
02
02
Entender as vantagens e desvantagens das três técnicas de estimativa
3.3.2
02
03
Explicar a importância do monitoramento do fluxo de caixa
3.3.3
02
04
Entender o significado da análise do valor agregado
3.3.3
Ser capaz de aplicar e personalizar a situação do gerenciamento financeiro 03
01
Capacidade de criar um orçamento simples
3.3.1
03
02
Explicar o processo de medição do valor agregado.
3.3.3
03
03
Explicar o propósito e criar uma tabela de contas
3.3.1
03
04
Dada uma situação específica do projeto, selecionar entre as estimativas com base nos resultados de cima para baixo, de baixo para cima e paramétricos
3.3.2
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do gerenciamento financeiro a uma situação específica 04
01
Capacidade de avaliar a aplicação da criação de um orçamento para uma dada situação específica do projeto
3.3.1
04
02
Identificar as vantagens da análise do valor agregado
3.3.3
04
03
Com os dados do orçamento, analisar a variação do custo cumulativo de um projeto.
3.3.3
04
03
Dado um orçamento e uma data calendário, analisar o status do valor agregado de um projeto
3.3.3
Código da área do plano de estudos FM Nível
Área do plano de estudos: Gerenciamento financeiro
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados ao gerenciamento financeiro. 01
01
Definir os termos relacionados ao gerenciamento financeiro, incluindo custos diretos, indiretos, custos de transação, serviços compartilhados, tabelas de contas, variação e análise dos valores agregados
3.3.1 – 3.3.3
01
02
Definir as três abordagens para a realização de estimativas do projeto
3.3.2
Guia para o PMD Pro 154
Entender o gerenciamento financeiro 02
01
Explicar a vantagem de criar estimativas de fase de orçamento.
3.3.2
02
02
Entender as vantagens e desvantagens das três técnicas de estimativa
3.3.2
02
03
Explicar a importância do monitoramento do fluxo de caixa
3.3.3
02
04
Entender o significado da análise do valor agregado
3.3.3
Ser capaz de aplicar e personalizar a situação do gerenciamento financeiro 03
01
Capacidade de criar um orçamento simples
3.3.1
03
02
Explicar o processo de medição do valor agregado.
3.3.3
03
03
Explicar o propósito e criar uma tabela de contas
3.3.1
03
04
Dada uma situação específica do projeto, selecionar entre as estimativas com base nos resultados de cima para baixo, de baixo para cima e paramétricos
3.3.2
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do gerenciamento financeiro a uma situação específica 04
01
Capacidade de avaliar a aplicação da criação de um orçamento para uma dada situação específica do projeto
3.3.1
04
02
Identificar as vantagens da análise do valor agregado
3.3.3
04
03
Com os dados do orçamento, analisar a variação do custo cumulativo de um projeto.
3.3.3
04
03
Dado um orçamento e uma data calendário, analisar o status do valor agregado de um projeto
3.3.3
Código da área do plano de estudos RM Nível
Área do plano de estudos: Gerenciamento de riscos
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados ao gerenciamento de riscos. 01
01
Identificar o processo de gerenciamento de riscos de quatro etapas
3.4.0
01
02
Definir os termos relacionados ao gerenciamento de riscos, incluindo os riscos positivos, riscos negativos, o registro de riscos, a matriz de avaliação e riscos e as tolerâncias aos riscos
3.4.1 - 3.4.4
01
03
Identificar as quatro estratégias de resposta aos riscos.
3.4.3
Entender o gerenciamento de riscos
Guia para o PMD Pro 155
02
01
Explicar a importância da probabilidade e o impacto no contexto do gerenciamento de riscos.
3.4.2
02
02
Explicar a natureza reiterativa do gerenciamento de riscos e sua importância e toda a vida do projeto.
3.4.4
02
03
Entender o conteúdo e a estrutura de um registro de riscos
3.4.1
02
04
Explicar o propósito, a estrutura e o conteúdo de uma matriz de avaliação de riscos
3.4.2
Ser capaz de aplicar e personalizar o gerenciamento de riscos a uma situação específica 03
01
Aplicar a matriz de avaliação de riscos em uma situação específica do projeto.
3.4.2
03
02
Organizar os riscos do projeto por categoria.
3.4.1
03
03
Capacidade de aplicar as quatro estratégias de gerenciamento de riscos em situações baseadas em casos.
3.4.1 – 3.4.4
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do gerenciamento de riscos a uma situação específica 04
01
Interpretar uma matriz de avaliação de riscos para diferenciar os riscos que podem ser tolerados versus os riscos que podem ser eliminados em uma situação não complexa do projeto.
3.4.2
04
02
Categorizar as estratégias de resposta ao risco
3.4.3
04
03
Interpretar o conteúdo de um registro de riscos
3.4.1
Código da área do plano de estudos JM Nível
Área do plano de estudos: Gerenciamento da justificativa
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à área do plano de estudos. 01
01
Definir os termos relacionados ao gerenciamento da justificativa do projeto, incluindo a identificação das necessidades baseadas em problemas, na identificação das necessidades baseadas nos ativos, árvores de problemas e árvores de objetivos
3.5.1 – 3.5.2
Entender o gerenciamento da justificativa do projeto 02
01
Entender a importância da justificativa do projeto para a equipe do projeto, assim como para seus interessados
3.5.0
02
02
Diferenciar as abordagens “baseadas em problema” e “baseadas em ativos” para a identificação de necessidades
3.5.1
Guia para o PMD Pro 156
02
03
Entender o relacionamento entre uma árvore de problemas e uma árvore de objetivos
3.5.2
02
04
Identificar e explicar os níveis da hierarquia no processo da árvore de problemas
3.5.2
Ser capaz de aplicar e personalizar o gerenciamento da justificativa a uma situação específica 03
01
Criar uma árvore de problemas básica dada uma situação específica do projeto
3.5.2
03
02
Criar uma árvore de objetivos baseada em uma árvore de problemas dada
3.5.2
03
03
Determinar como os objetivos de intervenção do projeto proposto atendem os critérios de justificativa do projeto em uma situação específica do projeto
3.5.2
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do gerenciamento da justificativa a uma situação específica 04
01
Capacidade de avaliar se existe uma justificativa adequada para a intervenção do projeto com base em uma abordagem baseada em necessidades para os problemas propostos de um projeto
3.5.2
04
02
Interpretar os relacionamentos de causa e efeito em uma árvore de problemas
3.5.2
Comparar e contrastar as abordagens baseadas em problemas com as abordagens baseadas em ativos para a identificação das necessidades
3.5.1
Código da área do plano de estudos SM Nível
Área do plano de estudos: Gerenciamento dos interessados
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados ao gerenciamento dos interessados 01
01
Listar as seis categorias de interessados
3.6.1
01
02
Conhecer os componentes de uma tabela RACI.
3.6.3
01
03
Saber que a comunicação com os interessados é essencial e exige planejamento e execução.
3.6.4
01
04
Recordar as ferramentas para identificar os interessados em termos de dependência, risco e poder do projeto
3.6.2
Entender o gerenciamento dos interessados 02
01
Entender as quatro funções chave identificadas na tabela RACI:
3.6.3
02
02
Entender os componentes de um plano de comunicação.
3.6.4
Guia para o PMD Pro 157
02
03
3.6.1 – 3.6.4
Explicar o propósito e a criação das ferramentas de análise dos interessados, incluindo as tabelas RACI, os diagramas de Venn, as matrizes de análise dos interessados e os planos de comunicação
Ser capaz de aplicar e personalizar o gerenciamento de interessados a uma situação específica 03
01
Categorizar grupos de interessados em uma dada situação específica do projeto
3.6.1
03
02
Criar um diagrama de Venn para uma situação específica do projeto
3.6.2
03
03
Criar uma matriz RACI de uma situação específica do projeto
3.6.3
03
04
Criar uma matriz de análise de interessados para uma situação específica do projeto
2.6.2
03
05
Aplicar os componentes recomendados em um plano de comunicação em uma situação específica do projeto
3.6.4
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do gerenciamento de interessados a uma situação específica Especificamente para: 04
01
Código da área do plano de estudos SC Nível
3.6.1 – 3.6.4
Interpretar o conteúdo das ferramentas de gerenciamento dos interessados incluindo a tabela RACI, o diagrama de Venn, a matriz de análise dos interessados e o plano de comunicação
Área do plano de estudos: Gerenciamento da cadeia de suprimentos
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados ao gerenciamento da cadeia de suprimentos. 01
01
Identificar os quatro componentes que compõem o gerenciamento da cadeia de suprimentos
3.7.0
01
02
Identificar as quatro etapas do gerenciamento dos serviços de suprimentos
3.7.1
Entender o gerenciamento da cadeia de suprimentos 02
01
Explicar os 4 elementos do gerenciamento da logística:
3.7.2
02
02
Identificar alternativas para identificar os fornecedores no processo de serviços de suprimento
3.7.1
Ser capaz de aplicar e personalizar o gerenciamento da cadeia de suprimentos a uma situação específica
Guia para o PMD Pro 158
03
01
3.7.1 – 3.7.4
Capacidade de aplicar os princípios do gerenciamento da cadeia de suprimentos a uma situação específica do projeto
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada do gerenciamento da cadeia de suprimentos a uma situação específica 04
01
Código da área do plano de estudos AD Nível
3.7.1 – 3.7.4
Capacidade de avaliar, usando o conteúdo recomendado, o uso dos seguintes processos da cadeia de suprimentos em uma situação específica do projeto: gerenciamento dos serviços de suprimento, gerenciamento de logística, gerenciamento de ativos e gerenciamento de informações
Área do plano de estudos: Adaptação ao PMD Pro
PMD Pro1
PMD Pro2
Referência manual primária
Tópico
Conhecer fatos, termos e conceitos relacionados à adaptação da área do plano de estudos do PMD Pro. 01
01
Recordar os princípios da adaptação
4.1
Entender a adaptação da área do plano de estudos do PMD Pro. 02
01
Entender os fatores a considerar ao se adaptar o PMD Pro aos projetos
4.4
02
02
Entender a função dos sistemas na adaptação das ferramentas e técnicas do PMD Pro
4.4
02
03
Entender o relacionamento entre um perfil de risco do projeto e a escolha das ferramentas e técnicas do PMD Pro
4.4
02
04
Apreciar as considerações necessárias durante a implementação de projetos usando o PMD Pro através dos parceiros de implementação
4.4
Ser capaz de aplicar e personalizar o modelo de fase de projeto do PMD Pro a uma situação específica 03
01
Adaptar as disciplinas do PMD Pro a situações individuais do projeto
4.1 – 4.4
03
02
Fazer as recomendações para aplicar os princípios do PMD Pro nos programas e na organização mais ampla
4.1 – 4.4
Ser capaz de identificar, analisar e distinguir entre a aplicação adequada e inadequada da área do plano de estudos a uma situação específica 04
01
Interpretar as aplicações das ferramentas e técnicas do PMD Pro a projetos específicos
4.1 – 4.4
04
02
Vincular as ferramentas e técnicas do PMD Pro a processos comerciais
4.4
Guia para o PMD Pro 159
5.3
A NEXO 3: L ISTA DE REFERÊNCIAS
Blackman, Rachel, 2003, Project cycle management, Teddington: Tearfund. Boston University Corporate Education Center, Project Management Competency Development Process. Britton, Bruce, Heaney, Deborah, Sterne, Rod, 2001, The Partnership Toolbox, London: WWF. Council of Europe and European Commission, 2000, Project Management T-Kit, Strasbourg: Council of Europe publishing. Dearden, Philip N., 2001, Program and Project Cycle management (PPCM): Lessons from DFID and other organizations, Tokyo: CIDT. Deming, W. Edwards, 1986,. Out of the Crisis, Boston: MIT Center for Advanced Engineering Study. Department for International Development (DFID), 2002, Tools for Development – version 15, DFID, Impact Assessment & Project Management Cycle (PMC). Emergency Capacity Building Project (ECB), 2007, Impact Measurement and Accountability in Emergencies The Good Enough Guide. London: Oxfam Publishing. Erwin, James, Smith, Michael L., Role & Responsibility Charting (RACI). European Commission, 2004, Aid Delivery Methods volume 1 Project Cycle Management Guidelines, Brussels: European Commission. Foundation Terre des Hommes, 2001, Project Cycle Handbook, Le Mont-sur-Lausanne: Foundation Terre des Hommes. Gardner, Alison, Greenblott, Kara, Joubert, Erika, 2005, What We Know About Exit Strategies Practical Guidance For Developing Exit Strategies in the Field, C -SAFE Regional Learning Spaces Initiative. GB Equal Support Unit, A Project Cycle Management and Logical Framework Toolkit – A practical guide for Equal Development Partnerships, Herefordshire: Local Livelihoods Ltd. Geyer, Yvette, 2005, Project Management, Pretoria: IDASA. GTZ, Manual of Project Management for Development Practitioners. International Fund for Agricultural Development (IFAD), Participatory Approaches for an Impact-Oriented Project Cycle International Fund for Agricultural Development, 2002, A Guide for Project M&E, Rome: IFAD. Levine, Carlisle J., 2007, Catholic Relief Services’ (CRS) Guidance for Developing Logical and Results Frameworks, Baltimore: CRS. Guia para o PMD Pro 160
Lipczinsky, Malte, 1996, Getting to Know PEMT, Berne: SDC, Evaluation Section. McMillan, Della E., Willard Alice, 2006, Preparing for the Evaluation Guidelines and Tools for PreEvaluation Planning, Baltimore: CRS. Mercy Corps, 2005, Design, Monitoring and Evaluation – Guidebook, Portland: Mercy Corps. Novartis Foundation for Sustainable Development, Project Management Handbook, A Working Tool for Project Managers. Pataki, George E., Dillon, James T., 2003, McCormack Michael, Project Management, Guidebook Release 2, New York: New York State Office for Technology. Picard, Mary, 2001, Course Materials for the Design, Monitoring and Evaluation (DME) Course, Kosovo: CARE. Plan International, 2002, Project Management Methodology Project Management Institute. 2004. A Guide to the Project Management Body of Knowledge: PMBOK® Guide – Third Edition. Rugh, J. 2002, Comparisons between Terminologies of Different Donor Agencies for Results/ Logical Frameworks, Atlanta: CARE International and InterAction’s Evaluation Interest Group. Saldanha, Cedric D., Whittle, John F., 1998, Using the Logical Framework for Sector Analysis and Project Design: A User’s Guide, Manila: Asian Development Bank. Siles R. 2004, Guidelines for Planning, Implementing and Managing a DME Project Information System. Atlanta: CARE. Standish Group. 1995. The Chaos Report. Boston: The Standish Group. Stetson, G. Sharrock, and S. Hahn, 2004, Propack The CRS Project Package: Project Design and Proposal Guidance for CRS Project and Program Managers. Baltimore: CRS. Stetson, S. Hahn, D. Leege, D. Reynolds and G. Sharrock, 2007, Propack II The CRS Project Package: Project Management and Implementation Guidance for CRS Project and Program Managers. Baltimore: CRS. The Centre for Development and Population Activities, 1994, Project Design for Program Managers, Washington, D.C.: The Centre for Development and Population Activities. United Nations Environment Program, 2005, UNEP project manual: formulation, approval, monitoring and evaluation. VCP, 2003, Facts for Projects (draft version). Verzuh, Eric, 2008, The Fast Forward Project Management-Third Edition, New Jersey: John Wiley & Sons, Inc. Guia para o PMD Pro 161
Wheelwright, S.C., Clark, K.B. 1995, LEADING Product Development: A Senior Manager's Guide to Creating and Shaping the Enterprise, New York: Free Press. Wideman, Max, 2001, Project Management Simply Explained A Logical Framework to Help Your Understanding, Vancouver: AEW Services World Bank, 2006, Managing the Implementation of Development Projects – New Edition. World Vision Development Resource Team, 2007, Learning through Evaluation with Accountability and Planning: World Vision’s Approach to Design, Monitoring and Evaluation (LEAP) – Second Edition, Washington, DC: World Vision International. World Vision Development Resource Team, 2009, LEAP Lexicon – Second Edition, Washington, DC: World Vision International. Youker, Robert, 1989, Managing the project cycle for time, cost and quality: lessons from World Bank experience, Butterworth & C. (Publishers) Ltd.
Guia para o PMD Pro 162
![[PDF] Guia para o PMD Pro - Free Download PDF (2024)](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/h8AAvMB+NzmkbcAAAAASUVORK5CYII=)