Competências de um Gerente de Projetos

Posted on outubro 5, 2012. Filed under: Artigos, gerenciamento, Gerenciamento de Projetos, PMBoK, PMI, Project, projetos, Treinamentos | Tags:, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , |

Competência: segundo o dicionário Houaiss “soma de conhecimentos ou de habilidades.”.

Na área de conhecimento de Gestão de Pessoas, competência é amplamente conhecida pelo conjunto de conhecimentos, habilidades e atitudes – também conhecido pela sigla CHA – (ou de acordo com diversas literaturas: é a capacidade de mobilizar conhecimentos, valores e decisões para agir de modo pertinente numa determinada situação.).

  1. Conhecimento está relacionado à Qualificação/Conceito;
  2. Habilidade está relacionada ao Fazer, ou seja, as Experiências daquele indivíduo;
  3. Atitude está relacionada ao Agir, ou seja, capacidade que o indivíduo possui de obter Resultados;

Peter Drucker, pai da administração moderna, disse que “somos contratados pelas competências técnicas e somos demitidos pelas nossas competências comportamentais“.

QUAIS SÃO AS COMPETÊNCIAS DE UM GERENTE DE PROJETOS?

Com o intuito de facilitar a visualização de como alcançar e desenvolver as competências necessárias para a Gestão, separei algumas competências classificando-as como “técnicas” e “não técnicas”, onde as “técnicas” podem ser alcançadas por meio de cursos e capacitações e as “não técnicas” (no inglês é conhecido como soft skill) que são inerentes ao individuo mas que podem ser desenvolvidas a partir de mudança de comportamentos. É praticamente impossível elencar todas as competências necessárias, mas abaixo listei algumas imprescindíveis:

COMPETÊNCIAS NÃO TÉCNICAS

  • Gerenciar pessoas;
  • Capacidade de motivar pessoas; Diferente de manipular ou intimidar as pessoas;
  • Capacidade de identificar falta de motivação;
  • Capacidade de passar conhecimento para as pessoas;
  • Justo e imparcial;
  • Liderança;
  • Comunicação – Oral e Escrita;
  • Postura/Presença/Visual/Referência;
  • Organização;
  • Proatividade;
  • Confiabilidade;
  • Franqueza;
  • Ética profissional;
  • Habilidade para Gestão do Tempo;
  • Estar à disposição, mas saber falar não, dosando os limites;
  • Ser objetivo;
  • Ambição/Foco no objetivo; (cuidado para não ser negativo, parecer negativo);
  • Pensamento Crítico;
  • Habilidades de colaboração – Trabalhar em equipe;
  • Persistência/Persuasão;
  • Percepção e intuição;
  • Capacidade de gerenciar o poder;
  • Prezar pelo sigilo que este poder lhe confere; Visto que se trata de um cargo de Gestão/Gerenciamento é possível que tenha acesso a informações privilegiadas, desta forma, o sigilo é essencial e altamente inerente ao cargo;
  • Capacidade de gerenciar o stress;
  • Capacidade de gerenciar mudanças;
  • Capacidade de Influenciar a organização/empresa;
  • Assumir a responsabilidade;
  • Lealdade e solidariedade;

COMPETÊNCIAS TÉCNICAS

  • MS Project/Primavera/SAP (Ferramenta de Gestão de Projetos);
  • Softwares de produtividade (Word, Excel, PowerPoint, Outlook);
  • Negociação/Argumentação;
  • Apresentação;
  • Gerenciar/Resolver conflitos; Pensando em conflitos, estes podem vir de lados diversos, seja para alcançar objetivos comuns, seja por discordância de opiniões os motivos podem ser diversos…
  • Planejamento;
  • Organização;
  • Atitude diante do risco (Antes e depois de acontecer);
  • Conhecimento em Gerenciamento de Projetos (Teoria);
  • Pensamento Crítico;
  • Administração;
  • Alocação de recursos;
  • Empreendedorismo;
  • Construção de equipes;

Caso queira desempenhar o papel de Gerente de Projetos com excelência, a busca pelo desenvolvimento destas e de outras competências deve ser diária, mas garanto que será altamente compensadora.

Espero que tenha ajudado.

Fábio Gomes

Anúncios
Ler Post Completo | Make a Comment ( None so far )

Instalei o Project, e agora?

Posted on setembro 18, 2012. Filed under: Artigos, Dicas de Project, gerenciamento, Gerenciamento de Projetos, ms project, PMBoK, PMI, Project, projetos, Treinamentos | Tags:, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , |

Sim, os softwares produzidos pela Microsoft geralmente possuem uma semelhança que beneficiam seus usuários, mas sempre existem algumas especificidades que emperram, com o Microsoft Project não é diferente.

Por vezes ouvi esta frase: Fábio, instalei o Project, e agora? Por onde começo?

Quando vejo, o indivíduo está preenchendo linha a linha do projeto, ou seja, colocando a atividade, duração, data de inicio, data fim, predecessora (quando coloca) e o nome do recurso, quando eu digo que não é assim, vejo aquela cara de indignação: Como assim?

Ai eu começo… vamos lá, é jogo rápido…

Antes de tudo você deve cadastrar todos os feriados, emendas e qualquer outra data que não será dia útil no calendário do projeto, segue uma dica de link para o site da Microsoft onde tem uma explicação bacana a respeito disso: Visão Geral: Usando Calendário no Project
Depois, em “Informações do Projeto” na guia “Projetos” do MS Project, você informa a “data de inicio” OU a “data de término” do seu projeto, sim, uma ou outra… isso faz diferença! Se o projeto tem data para começar, o MS Project indicará quando terminará! Mas, se o seu projeto tem data para acabar, o MS Project indicará quando ele deve começar! Fique atento a isso.

Você pode se perguntar, mas que tipo de projeto tem data para acabar… Festa de Final de Ano, Aniversários, Eventos, Shows e etc, organizar um evento é um projeto, caso queira colocar no MS Project, indique em qual data este evento ocorrerá, ou seja, qual a data fim do projeto que ele lhe indicará quando você deverá começar… mas não antes de você concluir os passos a seguir…

  1. Você deve digitar todas as atividades – procure estrutura-las pensando na execução, ou seja, em uma linha do tempo. Mas não tem problema caso encontre alguma atividade que conflita com outra, isso é normal;
  2. Depois que estiver digitado todas as atividades, volte e insira a duração em cada uma – A duração é o tempo que será investido para a realização da atividade;
  3. Em seguida, volte e indique as pessoas que irão realizar cada uma das atividades na coluna de recursos – caso tenha mais de uma pessoa por atividade, use ponto-e-vírgula para separá-las;
  4. Agora, aponte quais são as predecessoras das atividades de forma linear. Isso mesmo! (Com a experiência este passo torna-se desnecessário) – Mas porque de forma linear? Essa ideia é para facilitar o próximo passo. Neste ponto, você colocará todas as atividades de maneira sequenciada, ou seja, uma seguida da outra;
  5. Estruture as atividades de maneira que identifique paralelismos – Reveja as predecessoras de todas as atividades com o intuito de criar paralelismos entre as atividades, com isso, você terá um cronograma mais enxuto;
    Está pronto o seu cronograma… tudo bem, não é tão simples assim, existem algumas coisas que você deve ter atenção, abaixo algumas dicas, mas veja, não é um bicho de 7 cabeças!

Dicas:

Evite alterar as datas de inicio ou fim de uma atividade, fazendo isso você criará uma restrição em seu projeto, leia mais a respeito;

Todas as atividades, obrigatoriamente, devem possuir predecessoras, salvo a primeira atividade. Com isso, complemento essa dica com a criação da primeira atividade de seu cronograma sendo uma atividade do tipo “marco” (duração = 0) chamada de “Iniciar o projeto” e a última atividade, sendo também um “marco” chamada “finalizar o projeto”, com isso, a primeira atividade do seu cronograma será “Iniciar o projeto” e não terá predecessora.

Superalocado está o recurso com mais atividades do que o que pode realizar, o MS Project 2010 apresenta um bonequinho vermelho na linha da atividade onde o recurso está superalocado, mas em todas as versões existe um relatório que provê esta informação, leia mais;

Espero que tenha ajudado.

Fábio Gomes

Ler Post Completo | Make a Comment ( None so far )

Quando um Gerente de Projetos “erra a mão”?

Posted on setembro 11, 2012. Filed under: Artigos, gerenciamento, Gerenciamento de Projetos, PMBoK, PMI, projetos, Treinamentos | Tags:, , , , , , , , , , , , , , , , , , , , , , , , , , , |

Gerente de Projetos é o nome dado àquele cara que deve trabalhar para que um determinado projeto seja realizado com sucesso, ou seja, dentro do prazo, de acordo com o escopo definido, atendendo a um orçamento e principalmente, dentro da qualidade esperada, esta não é uma definição oficial, mas é assim… o principal ponto é que o Gerente de Projetos possui equipe e partes interessadas (positiva ou negativamente).

No que diz respeito a equipe, um Gerente de Projetos pode “errar a mão” em diversas situações, listei algumas que vejo e passo com certa frequência:

Errar na comunicação ou mesmo no planejamento das atividades e forçar sua equipe a trabalhar até tarde para entregar o que ele prometeu. Apesar de ser o Gerente responsável pelo projeto, não significa que o planejamento não possa ser compartilhado, principalmente porque, na maioria das vezes, não será ele que realizará as atividades listadas no cronograma do projeto. Fazer com que a equipe participe do planejamento evita erros e faz com que tenham tanto comprometimento com as atividades quanto você, Gerente de Projetos, terá com o todo;

Não comunicar de forma assertiva. É um tanto subjetivo, mas de qualquer forma, se pensarmos que a comunicação dever ser 90% do trabalho do Gerente de Projetos, estamos tratando de uma competência que é e deve ser trabalhada constantemente, ou seja, em algum momento, depois de tanta comunicação, a informação deve chegar ao receptor de maneira clara;

Não realizar reuniões de alinhamento a respeito do projeto. É imprescindível reunir toda a equipe de tempos em tempos e repassar o status do projeto, replanejar se for preciso, rever as atividades e seus responsáveis, predecessoras, analisar os riscos e o plano de comunicação do projeto, mais uma vez, envolver a equipe do projeto neste tipo de atividade faz com que todos se sintam parte daquilo, trazendo comprometimento e revendo as responsabilidades;

Não assumir para terceiros que a culpa por qualquer falha de um membro da sua equipe é falha sua também. É fácil apontar o culpado e puni-lo, mas o responsável direto pelo projeto é o Gerente de Projetos, logo, o erro de um membro da sua equipe é erro seu sim. O monitoramento e controle das atividades do projeto deve ser constante, além da revisão dos riscos do projeto e do plano de comunicação, todos esses itens são ferramentas que ajudam a mitigar as falhas. É importante lembrar que expor um membro de sua equipe por ter cometido um erro, pode caracterizar assédio moral, com penas previstas em leis, desta forma, cuidado com os métodos utilizados em situações como estas;

Certamente existem vários outros casos em que um Gerente de Projetos pode “errar a mão”, mas o mais importante é que existem formas de evitar que isso ocorra, exercitar essas formas deve ser um trabalho diário.

Você já presenciou alguma situação onde o Gerente de Projetos “errou a mão” com sua equipe? Compartilhe…

Abraço.

Fábio Gomes

Ler Post Completo | Make a Comment ( None so far )

Quem são os stakeholders?

Posted on março 14, 2012. Filed under: Artigos, gerenciamento, Gerenciamento de Projetos, PMBoK, PMI, projetos | Tags:, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , |

Você se arriscaria a dizer quem são os stakeholders do seu projeto?

De maneira geral, os stakeholders são todos os envolvidos ou impactados de forma direta ou indireta nos projetos. É um tanto abrangente, mas é exatamente isso, pensando de maneira simplista e rápida, listei alguns aqui:

  • PMO da sua empresa e/ou da empresa contratante;
  • O patrocinador do projeto;
  • A pessoa que contratou o projeto (pode ser diferente de quem vai pagar);
  • A pessoa que gerenciará o projeto (Gerente de projeto do lado do cliente);
  • Departamento financeiro de ambas as empresas (os pagamentos poderão estar vinculados a entregáveis do projeto);
  • RH (Por conta de novas contratações, seguro de viagens e etc);
  • A equipe do projeto;
  • As pessoas que se beneficiarão com os resultados do projeto;
  • As pessoas que utilizarão o resultado do projeto;
  • Familiares (Sim! sua esposa, seus filhos são partes interessadas no projeto, trabalhe no fim de semana ou viaje que você verá os impactos);

Alguns stakeholders podem variar de acordo com o tipo de projeto:

  • Reforma da fachada de um prédio: Os moradores, vizinhos, em caso de prédios tombados, temos ONGs, Prefeitura, Governo, havendo a necessidade de interditar vias públicas, CET, Polícia;
  • Em projetos relacionados ao meio ambiente, temos vários destes que já citei até comunidades inteiras, tribos indígenas, órgãos fiscalizadores;

A identificação dos stakeholders do projeto é o primeiro passo para a confecção do plano de comunicação do projeto, no PMBOK este plano está descrito no capítulo 10. É importante ressaltar que o processo de identificar os stakeholders do projeto deve ser contínuo. Sim! É possível que no meio do seu projeto surjam novos interessados e o papel do Gerente de Projeto é acompanhar, monitorar, registrar e se comunicar com todos eles.

A tradução para a palavra stakeholder é “parte interessada”, de acordo com o PMBOK 2008, “As partes interessadas são pessoas ou organizações (por exemplo, cliente, patrocinadores, organização executora ou o público) ativamente envolvidas no projeto ou cujos interesses podem ser positiva ou negativamente afetados pela execução ou término do projeto. Elas também podem exercer influência sobre o projeto, suas entregas e sobre os membros da equipe do projeto.”

Fábio Gomes

Ler Post Completo | Make a Comment ( None so far )

Quando um PMO “erra a mão”?

Posted on março 12, 2012. Filed under: Artigos, gerenciamento, Gerenciamento de Projetos, PMI, projetos | Tags:, , , , , , , , , , , , , , , , , , , , , , , |

É sabido que PMO é um escritório de projetos responsável por todos os projetos que estão em andamento dentro da empresa, além de ser o mantenedor da metodologia e padronização da documentação. Em matéria anterior, cito todas as atribuições deste departamento. O ponto é que este escritório possui grande poder de decisão sobre o projeto que é de responsabilidade de um gerente de projetos, mas, qual o limite? De que forma essa intervenção ocorre? Como fazer para não desmotivar a equipe envolvida naquele projeto?

Em uma estrutura funcional, o responsável pelo PMO da empresa pode ser o superior direto do Gerente de Projetos, desta forma, as cobranças podem ir além das atribuições que cabem ao PMO, é comum que neste modelo o Gerente de Projetos seja cobrado por resultados que não sejam inerentes ao projeto que é de sua responsabilidade. Citando um exemplo simples, onde um PMO cobra de um Gerente pontualidade com relação ao horário de entrada na empresa. Pensando nas atribuições que lhe cabem, seria comum se o RH da empresa fizesse isso, visto que o PMO olhe para resultados e auxilie os Gerentes de Projeto em estratégias para auxilia-los na entrega do projeto.

Mas isso ainda pode piorar, principalmente quando o PMO começa a interferir no dia-a-dia do projeto, tirando a autoridade do Gerente perante sua equipe, ou quando cobra resultados, expondo os erros dos membros das equipes de projeto, como forma de punição, quando na verdade o seu papel é o de orientação, é o de manter a padronização, garantir qualidade e auxiliar o Gerente de Projetos na finalização dos projetos de uma forma que garanta a qualidade esperada pela empresa.

Ferramentas para auxiliar o PMO e o Gerente de Projetos a estruturar melhor os seus projetos são e serão sempre bem-vindas, mas é importante preocupar-se em não onerar as atividades do dia-a-dia das equipes de projetos e, principalmente, desmotiva-los com relação a um monitoramento mais intenso a respeito de suas atividades, pois por si só ferramentas não fazem sentido, digo isso pois precisarão de intervenção humana para que possam refletir a real situação do projeto, desta forma, caso a equipe de projetos não esteja de acordo com a nova ferramenta, seu uso poderá não fazer mais sentido ou, funcionará baseado em um monitoramento muito forte de uma pessoa frente a equipe de projeto, além do Gerente.

Com base em bibliografias, seminários e estudos a respeito de PMO, definitivamente, é este o trabalho de um PMO?

O que você acha?

Abraço.

Fábio Gomes

Ler Post Completo | Make a Comment ( 4 so far )

Premissas x Riscos x Restrições

Posted on dezembro 27, 2010. Filed under: Artigos, gerenciamento, Gerenciamento de Projetos, PMBoK, PMI, projetos, Treinamentos | Tags:, , , , , , , , , , , , , , , , , , , , , , , , , |

Por vezes me pego pensando na definição de Premissas, Riscos e Restrições, pensei então em criar um exemplo simples para que eu possa me lembrar de forma rápida na definição de cada um…. fiz isso:

Premissas
Toda premissa gera um risco

É um fator que você considera como verdade sem necessariamente ter condições de assegurar que aquilo poderá acontecer. P.ex.:

  • Amanhã não vai chover!

Quando você adquire um bem por meio de financiado assume a seguinte premissa:

  • Terei condições de pagar!

Riscos
Partindo do principio que toda premissa gera um risco, é preciso ficar atento as premissas geradas e investir muito tempo elencando premissas ao seu projeto, ao final, a lista dos principais riscos de seu projeto estará praticamente pronta.

Continuando com o exemplo anterior:

  • Se amanhã chover todos os equipamentos serão danificados.

Ao adquirir um bem por meio de financiamento alguns riscos serão assumidos, dentre eles:

  • Se eu ficar desempregado não terei condições de pagar o financiamento.

Restrições
As restrições determinam limites às suas ações e entregas relacionadas ao projeto.
Os itens das restrições devem estar sob o seu controle e sua documentação ocorre para proteger o gerente do projeto dos possíveis riscos atrelados, desta forma, pode-se concluir que uma restrição pode ser criada como proteção a um risco.

Seguindo a linha dos exemplos anteriores:

Criei uma restrição, um limite, para proteger os equipamentos do projeto da possibilidade de chuva, fechando o ciclo Premissas x Riscos x Restrições.

  • O local a ser utilizado para os equipamentos deverá ter cobertura de proteção contra a chuva.

Evitando que eu não tenha condições de cumprir com o compromisso do financiamento do bem que adquiri.

  • Pagarei à vista

Espero que seja útil!

Ler Post Completo | Make a Comment ( None so far )

MS Project 2010 – Notícias sobre a nova versão

Posted on outubro 24, 2009. Filed under: Artigos, Dicas de Project, Gerenciamento de Projetos, ms project, Project, projetos | Tags:, , , , , , , , , , , , , , , , , , , , , , , , , |

A nova versão do MS Project está no forno, abaixo notícias relacionadas:

http://olhardigital.uol.com.br/digital_news/noticia.php?id_conteudo=8844

http://blogs.msdn.com/project/archive/2009/07/13/announcing-microsoft-project-2010-technical-preview.aspx

http://www.microsoft.com/project/2010/en/us/default.aspx

http://info.abril.com.br/noticias/ti/ms-faz-teste-privado-do-office-project-2010-28072009-33.shl

http://webworkerdaily.com/2009/09/16/microsoft-project-2010-promises-significant-improvement/

http://www.cmswire.com/cms/enterprise-20/ms-project-2010-goodbye-portfolio-server-hello-sharepoint-005536.php

Ler Post Completo | Make a Comment ( None so far )

Participe da Enquete: Qual software você utiliza para lhe auxiliar no Gerenciamento de Projetos?

Posted on fevereiro 10, 2009. Filed under: gerenciamento, Gerenciamento de Projetos, projetos | Tags:, , , , , , , , |

Ler Post Completo | Make a Comment ( None so far )

Grupo de Usuários de Microsoft Office Project agora no Brasil!

Posted on janeiro 30, 2009. Filed under: Artigos, Dicas de Project, gerenciamento, Gerenciamento de Projetos, ms project, Project, projetos, Treinamentos | Tags:, , , , , , , , , , , , , , , , , , , , , , |

Fonte: http://blogs.technet.com/lpalma/archive/2008/06/19/grupo-de-usu-rios-de-microsoft-office-project-agora-no-brasil.aspx

Acaba de ser fundado o Capítulo MPUG Brazil (Microsoft Project User Group), sob a liderança de Marconi Fábio Vieira.

Se você é usuário de MS Project / EPM, ou se pertence à comunidade brasileira de Gestão de Projetos, vai apreciar a proposta do MPUG de realizar eventos locais, regionais e nacionais, que gerarão oportunidades para aprender e trocar experiências.

Segue uma descrição do MPUG Brazil, pelo próprio Marconi:

“O MPUG Brazil é o Capítulo brasileiro representante de uma associação mundial (MPA) líder na indústria composta de profissionais que utilizam o Microsoft Office Project e EPM em seus negócios e em suas carreiras.
Os membros se associam ao MPUG para aumentar sua experiência em Project e EPM através de uma organizada rede de recursos e conhecimento gerenciado.
Ao se associar como membro, você receberá todos os privilégios e um pacote de benefícios divididos nas seguintes áreas:

  • Members-only Knowledge Library – Um portal gerenciado contendo informações preciosas e recursos da indústria.
  • The Project Network – Os membros recebem uma assinatura trimestral da newsletter do MPUG com artigos da Microsoft, estudos de casos, dicas e mais.
  • MPUG Ezine for Microsoft® Office Project – Member’s Edition — newsletter eletrônica do MPUG enviada mensalmente via e-mail para os membros. Ela contém as últimas dicas do Microsoft Project, eventos e notícias.
  • Reuniões dos Capítulos – Membros podem participar de reuniões dos capítulos no mundo sem custo. Recebem informações mais atualizadas sobre o Microsoft Project, obtem respostas a questões técnicas e participa da comunidade do Microsoft Project community.
  • Event Invitations – Os membros recebem convites especiais da Microsoft e de outras indústrias. Os convites são incluídos no Microsoft’s Annual Project Technical Briefing no Campus da Microsoft em Redmond.
  • Members Forum – os membros podem postar e visualizar questões relacionadas ao Microsoft Project.
  • Blog – opiniões pessoais e web links de experts em Project.
  • Job Board – Os membros podem procurar e postar ofertas de emprego através de recursos online.
  • PMI PDUs – MPUG é um PMI Registered Education Provider (R.E.P.). Adquira créditos PDUs através de várias atividades do MPUG.
  • Leadership Opportunities – Desenvolva suas habilidades através do MPUG. Publique artigos, apresente uma reunião, seja um palestrante dos eventos do MPUG.
    Últimas Informações sobre o Produto / Recursos
  • Members-only Offers – Oportunidades de participar em beta teste, web casts and pesquisas de opinião sobre o produto. Inclui o recebimento de trial software (sujeito a disponibilidade).
  • Recursos / Links – Uma seção dedicada no site da MPA que contém recursos de Microsoft Project e de Gestão de Projetos.
  • Bookstore – Uma loja online com bibliografia relacionada ao Microsoft Project e Gestão de Projetos e software.
  • Branded Merchandise – Em breve. Aquisição de uma variedade de merchandise do MPUG através da loja online.

Para maiores informações sobre a associação ao MPUG Brazil, acesse:

http://www.mpug.com

Seja bem-vindo!

Cordialmente,
Marconi Fábio Vieira, PMP
MPUG Brazil Chapter Leader”

Ler Post Completo | Make a Comment ( None so far )

Plano de Gerenciamento de Riscos do Projeto

Posted on setembro 1, 2008. Filed under: Artigos, gerenciamento, Gerenciamento de Projetos, Project, projetos | Tags:, , , , , , , , , , , , , , , , , , , , , , , , , , , , |

 

INTRODUÇÃO

 “Riscos são eventos ou condições não planejadas, que podem ter um efeito positivo ou negativo no seu sucesso” (Phillips, Joseph. Project Management Professional – Guia de Estudo. P. 438. Ed. Campus)

O intuito de iniciar o texto com esta frase é apresentar as duas faces do risco. Constantemente associamos o risco a fatos que nos fazem, de alguma forma, perder algo, no entanto, existem momentos em que os riscos podem nos trazer benefícios, ou pelo menos nos apontar que podemos deixar passar uma oportunidade de ganhar.

Com este pensamento, podemos concluir que existe risco em tudo, desde o momento em que decidimos nos levantar da cama até o momento de pra ela voltar. Sim, parece exagero, mas faça uma análise do que isso significa.

Não podia ser diferente em Gerenciamento de Projetos. Quando decidimos iniciar um projeto (ou quando nos dizem que seremos responsáveis por um), é inevitável não pensar em alguns riscos que podem acontecer.

O PMBOK apresenta um Plano de Gerenciamento de Riscos do Projeto que descreve e documenta como serão desenvolvidos os seis processos desta área:

·         Planejamento do Gerenciamento de Riscos

·         Identificação dos Riscos

·         Análise Qualitativa dos Riscos

·         Análise Quantitativa dos Riscos

·         Planejamento das Respostas aos Riscos

·         Monitoramento e Controle de Riscos

A seguir, será apresentado de forma sucinta, mas não superficial, cada um destes seis processos:

PLANEJAMENTO DO GERENCIAMENTO DE RISCOS

 “Planejar qual abordagem dar à gestão de risco do projeto e executá-la” (Rabechini)

No inicio do desenvolvimento do plano é necessário alinhar os objetivos de todas as partes interessadas, é para isso que o Planejamento do Gerenciamento de Riscos do Projeto existe. Nesta parte do documento deverão ser colocadas todas as informações que dizem respeito ao “como”. p.ex.:

·         Como os riscos serão identificados

·         Como a análise qualitativa será desenvolvida

·         Como a análise quantitativa será criada

·         Como será realizado o planejamento de resposta ao risco

·         Como monitorar os riscos

É importante que nesta fase seja refletido a opinião de todos os envolvidos para que posteriormente não se tenha problemas com o não cumprimento do que foi acordado.

Para a produção deste plano as informações do Termo de Abertura, o Plano do Projeto, da área de Integração, a declaração do escopo e a EAP serão imprescindíveis.

Neste ponto serão documentadas informações a respeito da equipe que estará envolvida com o gerenciamento do risco e suas responsabilidades, informações relevantes a risco sobre a empresa, as fontes de dados que serão utilizadas, qual será a metodologia utilizada para gerenciar os riscos elencados e a definição de padrões para todos os documentos que serão utilizados nas questões referentes a risco.

Sendo relevante a risco, outras informações ou documentos poderão fazer parte deste plano.

 IDENTICAÇÃO DOS RISCOS

 “Determinar quais riscos podem afetar o projeto e documentar suas características” (Rabechini)

O processo de identificação de riscos é semelhante ao processo de planejamento de gerenciamento de riscos, pois nele também será de suma importância que todas as partes interessadas participem identificando riscos para o projeto, em alguns casos, por conta da complexidade do projeto, é interessante que se tenha presente um especialista em determinados assuntos para que nenhum risco seja deixado de fora da análise.

A principal característica deste processo é que ele é finalizado junto com o projeto, pois durante todo o ciclo de vida do projeto, identificação de riscos poderá ser realizada. Além disso, atualizações nos status dos riscos ocorrerão constantemente. Isso ocorre devido a um risco identificado no inicio do projeto poder assumir baixa probabilidade de ocorrer naquele momento, no entanto, com o avanço no desenvolvimento do projeto, este pode ter seu grau de probabilidade modificado para altamente provável, com isso, a atualização do seu status se faz necessária.

Para auxiliar neste processo será necessário ter o Plano de Gerenciamento de Riscos, Plano de Gerenciamento do Projeto e a Declaração do Escopo do Projeto, além de conhecimentos sobre os processos e cultura da empresa e informações históricas provindas de conhecimentos acumulados de projetos anteriores.

De acordo com o PMBOK, este processo utiliza cinco ferramentas e técnicas:

·         Revisões da documentação
Consistem em analisar o que já foi produzido até o momento. O intuito é o de buscar riscos associados aos objetivos do projeto. Este pode ser o momento de analisar a qualidade dos planos produzidos e quem sabe até rever alguns itens que estejam não consistentes entre si.

 

·         Técnicas de coleta de informações

A intenção é coletar informações para criar uma lista de riscos formada pelas idéias que o grupo expôs. O PMBOK propõe que se utilizem as seguintes técnicas: Brainstorming, Técnica Delphi, Entrevistas com especialistas, Identificação da causa-raiz e Análise dos pontos fortes e fracos, oportunidades e ameaças (SWOT).

 

·         Análise da lista de verificação

A lista de verificação é um documento formado por riscos apontados em projetos anteriores ou informações históricas que possam ser acrescidas a ela. Com esta lista será possível realizar rapidamente a identificação de alguns riscos em seu projeto, no entanto, é importante que não a tenha como única fonte de riscos, pois desta forma, certamente será surpreendido por algum risco que não estava nesta lista.

 

·         Análise das premissas

Esta ferramenta consiste em validar as premissas identificadas no planejamento, pois em sua maioria, apresentam incertezas e isso é um risco que deve ser registrado e mitigado.

 

·         Técnicas com diagramas

O PMBOK indica três técnicas de diagramação: diagramas de causa e efeito, diagramas do sistema ou fluxogramas e diagramas de influência. Em todos a idéia é a de ajudar a identificar os riscos do projeto, possuem algumas peculiaridades que ajudam a trabalhar incertezas e visualizar causas e efeitos dos riscos para o projeto.

Passando por todas essas técnicas e ferramentas um registro de riscos com as listas dos riscos identificados, as listas das possíveis respostas, causas-raiz do risco e as categorias de risco atualizadas estarão confeccionados e prontos para passar para a próxima etapa do plano.

ANÁLISE QUALITATIVA DE RISCOS

 “Priorizar os riscos do projeto, com base na análise conjunta da probabilidade de ocorrência e seu impacto nos objetivos do projeto” (Rabechini)

Nesta frase, Marly Monteiro e Roque Rabechini, definem exatamente quais são os objetivos nesta fase do plano.

Após produzir o Planejamento do Gerenciamento de Riscos, que contém o processo e a metodologia que será utilizada, e identificar quais os riscos que permeiam seu projeto, a partir destes documentos, chega o momento de verificar e priorizar os riscos. O intuito é confeccionar um documento que aponte numericamente qual a probabilidade e o impacto de cada um dos riscos identificados ocorrerem.

O segundo passo é organizar estas informações em uma Matriz de Probabilidade e Impacto para que os riscos que devem ser priorizados fiquem organizados e sejam mais facilmente identificados. No que diz respeito a “organizados”, significa que se pode, nesta matriz, separar os riscos por Ameaças x Oportunidades, Custo, Tempo, Escopo ou por outro critério que lhe atenda. É possível também categorizar os riscos para se obter um maior controle sobre eles, as boas práticas indicam que a categorização pela origem dos riscos é uma das mais funcionais, pois tornará seu plano de respostas a riscos mais eficaz, porém, nada impede que você realize um outro tipo de categorização.

É importante também analisar a qualidade dos dados sobre os riscos, caso se tenha obtido informações fracas a respeito dos riscos, o trabalho realizado até este momento poderá ter sido em vão.

Todos os documentos produzidos até aqui serão necessários para iniciar a próxima fase do Plano de Gerenciamento de Riscos do Projeto, porém, conforme será visto, esta análise poderá ser substituída por informações de especialistas no assunto.

ANÁLISE QUANTITATIVA DE RISCOS

 “Analisar numericamente o impacto dos riscos identificados nos objetivos do projeto” (Rabechini)

O objetivo da Análise Quantitativa de Riscos é o de pontuar numericamente os riscos identificados e categorizados do projeto, sendo este um grande reforço no intuito de verificar cada risco e seu impacto nos objetivos do projeto, esta análise também gera uma avaliação de risco geral do projeto. Pode ser realizada em todos os riscos do projeto, mas por ser mais elaborada, por conta das técnicas e ferramentas envolvidas, pode se tornar dispendiosa, desta forma, a atenção é dada aos riscos identificados pela Análise Qualitativa com prioridades altas e médias.

Por meio de grande experiência, opinião especializada ou mesmo por conta da complexidade do projeto, é possível realizar a Análise Quantitativa após a Identificação dos Riscos sem que o projeto passe por uma Análise Qualitativa.

De acordo com o PMBOK 2004, o intuito desta análise é obter as seguintes informações sobre o projeto:

·         Quantificar os possíveis resultados do projeto e suas probabilidades;

·         Avaliar a probabilidade de atingir objetivos específicos do projeto

·         Identificar os riscos que exigem mais atenção quantificando sua contribuição relativa para o risco total do projeto.

·         Identificar metas realistas e alcançáveis de custo, cronograma ou escopo, quando fornecidos os riscos do projeto

·         Determinar a melhor decisão de gerenciamento de projetos quando algumas condições ou resultados forem incertos.

Para alcançar estes objetivos algumas ferramentas e técnicas são indicadas e para um melhor entendimento são organizadas em dois grandes grupos:

·         Técnicas de representação e coleta de dados

o   Entrevistas – Discute-se com as partes interessadas do projeto e especialistas sobre sua experiência em projetos anteriores do assunto em questão;

o   Distribuições de probabilidades – São apresentações gráficas que representam a probabilidade, o tempo e elementos de custo;

o   Opinião especializada – Busca de opinião especializada interna ou externa ao projeto;

·         Análise quantitativa de riscos e técnicas de modelagem

o   Análise de sensibilidade – Apresenta o impacto dos riscos sobre o projeto e quais são os riscos que podem prejudicar mais o projeto;

o   Análise do valor monetário esperado – De forma estatística, apresenta qual é o  resultado médio do impacto da decisão, ao final, tem-se resultados positivos e negativos que são entendidos como oportunidades e ameaças respectivamente;

o   Análise da árvore de decisão – Método utilizado na escolha da melhor entre duas decisões;

o   Modelagem e simulação – “Uma simulação do projeto utiliza um modelo que traduz as incertezas especificadas em um nível detalhado do projeto para seu impacto potencial nos objetivos do projeto.” (PMBOK, 2004);

“Se você optar por utilizá-lo, certifique-se de repeti-lo toda vez que o processo de Planejamento de Respostas a Riscos for executado e como parte do Monitoramento e Controle de Riscos.” (Kim Heldman).

Esta é a única maneira de avaliar se o risco total do projeto diminuiu satisfatoriamente.

As informações geradas por meio desta análise serão insumos para o registro de riscos do projeto:

·         Análise probabilística do projeto – é o grau de certeza de cada uma das afirmações feitas sobre o projeto. p. ex.: datas e custos;

·         Probabilidade de realização dos objetivos de custo e tempo – é a probabilidade de alcançar o cumprimento dos objetivos de custos e tempo;

·         Lista de classificação dos riscos quantificados – apresenta os riscos classificados por probabilidade e impacto;

·         Tendência dos resultados da Análise Quantitativa de Riscos – apresenta a tendência de cada um dos riscos ocorrer, esta informação vai se evidenciando de acordo com a repetição desta análise.

PLANEJAMENTO DAS RESPOSTAS AOS RISCOS

 “Desenvolver as alternativas e planos de ações necessários para maximizar as oportunidades e minimizar as ameaças aos objetivos do projeto” (Rabechini)

Este é o momento de definir qual será a ação a ser tomada com o intuito de reduzir as ameaças ao projeto e aproveitar as oportunidades destacadas nas análises anteriores, além disso, será definido um responsável pela execução do plano de resposta ao risco, seja ele uma pessoa, departamento ou entidade agregada ao projeto.

Neste processo, as ferramentas e técnicas indicadas pelo PMBOK são:

·         Estratégias para riscos negativos ou ameaças:

o   Prevenção: eliminando de qualquer forma o risco do projeto;

o   Transferência: repassar os riscos para um terceiro;

o   Mitigação: reduzir a probabilidade e o impacto de que o risco ocorra;

·         Estratégias para riscos positivos ou oportunidades:

o   Exploração: buscar impactos positivos;

o   Compartilhamento: compartilhar a oportunidade identificada com alguém que tenha mais experiência em tratar esse tipo de assunto;

o   Melhoria: busca direcionar os riscos em prol de benefícios ao projeto;

·         Estratégias tanto para ameaças quanto para oportunidades:

o   Também conhecida como Aceitação, esta estratégia diz que aceitará o risco, os motivos para isso pode ser diversos: não encontrou uma formar de mitigar, transferir, prevenir, não tem oportunidades ou conhecimento suficiente sobre o risco para desenvolver uma estratégia sobre ele, tudo isso pode levar a conclusão de que é mais simples aceitar o risco;

·         Estratégia de resposta para contingências:

o   É a preparação para a ocorrência efetiva do risco.

Ao final de todo o processo atualizações do registro de risco serão necessárias, pois nele entrarão novas informações sobre os riscos e os planos de respostas desenvolvidos, optando por transferir ou compartilhar riscos, é possível que contrações sejam necessárias, estas informações deverão constar no plano de gerenciamento do projeto.

MONITORAMENTO E CONTROLE DE RISCOS

 “Rastrear os riscos identificados, monitorar o risco residual, identificar novos riscos, executar os planos de resposta aos riscos e avaliar sua eficácia ao longo do ciclo de vida do projeto” (Rabechini)

Com o Plano de Gerenciamento de Riscos em mãos, este é o momento de monitorar o projeto em busca de riscos que estejam a ponto de ocorrer ou já ocorrendo em seu projeto para que possa assim fazer uso das respostas documentas neste plano ou mesmo, identificar novos riscos, gerando assim uma atualização do registro de riscos.

Monitoramento e Controle de Riscos é um processo que conta com a participação de todas as partes interessadas no projeto, mas de qualquer forma, cada risco possui um responsável por monitorá-lo.

Em riscos, este processo é o que o PMBOK mais recomenda ferramentas e técnicas, analisando, chega-se a conclusão de que a maioria visa a qualidade deste documento e, principalmente, a garantia de que as respostas sejam eficazes no momento que forem utilizadas, são elas:

·         Reavaliação de riscos – “A idéia é monitorar os riscos e seu status e verificar se suas conseqüências ainda causariam impacto idêntico ao originalmente planejado nos objetivos do projeto.” (Kim)

·         Auditoria de riscos – “Essas auditorias examinam especificamente a implementação e o uso efetivo das estratégias de riscos.” (Kim)

·         Análise das tendências e da variação – É o monitoramento do desempenho geral do projeto utilizando técnicas como a Análise do Valor Agregado e outros métodos;

·         Medição do desempenho técnico – “Esta ferramenta e técnica compara as realizações técnicas alcançadas durante os processos de Execução com os marcos definidos no processo de Planejamento do projeto.”(Kim)

·         Análise das reservas – É a verificação das reservas e contingências com base nos riscos que ainda restam no projeto;

·         Reuniões de andamento – É uma sugestão de inserir em pauta de reuniões do projeto o item “Gerenciamento de Riscos”, o intuito é o de amadurecer o entendimento sobre os riscos que existem no projeto e quem sabe até propor soluções melhores do que aquela indicada anteriormente.

Ao final da utilização das técnicas e ferramentas propostas alguns documentos serão gerados e atualizações em documentos existentes serão necessárias.

·         Atualizações nos registros de riscos;

·         Mudanças solicitadas por conta de novas alternativas no monitoramento dos riscos;

·         Ações corretivas recomendadas;

·         Ações preventivas recomendadas;

·         Atualizações nas informações de ativos de processos organizacionais;

·         Atualizações no Plano de Gerenciamento do Projeto.

A principal característica do processo de Monitoramento e Controle de Riscos é que ele deve ocorrer durante todo o ciclo de vida do projeto, pois só monitorando os riscos identificados, buscando novos riscos e revendo o plano de respostas aos riscos é que se terá de maneira adequada um documento que lhe auxilie.

“O gerenciamento de riscos é uma forma organizada de identificar e medir os riscos e de desenvolver, selecionar e gerenciar as opções para seu controle” (Herzner, Harold. Gestão de Projetos, As melhores Práticas – 2ª Ed. Bookman, 2006. P. 328 )

REFERÊNCIAS

Construindo Competências para Gerenciar Projetos – Teoria E Casos
Carvalho, Marly Monteiro & Rabechini Jr. , Roque
ISBN: 8522441685
Publicação: 2006
Editora: Atlas

Páginas: 320

Gestão de Projetos – As melhores práticas – 2 ed.
Kerzner, Harold
ISBN: 9788536306186
Publicação: 2006
Editora: Bookman

Páginas: 824

Gerência de Projetos: guia para o exame oficial do PMI – 3 ed.
Heldman, Kim
ISBN: 8535220399
Publicação: 2006
Editora: Elsevier

Páginas: 530

Project Management Professional: Guia de estudo
Phillips, Joseph
ISBN 8535214100
Publicação: 2004
Páginas: 610

Fábio Gomes

Ler Post Completo | Make a Comment ( 3 so far )

« Entradas Anteriores

    Sobre

    Informações relacionadas ao Microsoft Office Project (Standard, Professional e Server) e Gerenciamento de Projetos com suas ferramentas.

    RSS

    Subscribe Via RSS

    • Subscribe with Bloglines
    • Add your feed to Newsburst from CNET News.com
    • Subscribe in Google Reader
    • Add to My Yahoo!
    • Subscribe in NewsGator Online
    • The latest comments to all posts in RSS

    Meta

Liked it here?
Why not try sites on the blogroll...