Gestão de Projetos 4 - Como Planejar Os Demais Aspectos Do Projeto

Curso 4 - Como planejar os demais aspectos do projeto?
Gesto de Projetos Curso 4: Como planejar os demais aspectos do projeto?
-1-
SUMRIO Viso Geral Qualidade Recursos Humanos Comunicao Riscos Aquisies Integrao Bibliografia/Sugesto Leitura
PG 03 04 14 18 30 46 52 55
-2-
Viso Geral
Objetivo
Conhecer: O que qualidade? Os equvocos comuns em qualidade. Os custos da qualidade. O que gerenciamento da qualidade. Como planejar a qualidade do projeto.
No primeiro curso Como trabalhar em projetos? aprendemos que um projeto deve levar em considerao outros aspectos que tambm merecem ateno, embora em menor intensidade, em sua fase inicial, uma vez que eles tambm so importantes no planejamento, pois uma falha neste grupo de processos poder afetar significativamente o projeto, por exemplo, o prazo ou os custos.
Conforme a figura ao lado, e recordando a questo das reas do conhecimento, o gerenciamento de projetos eficaz deve considerar nove disciplinas.
Anteriormente, focamos as trs que compem a chamada restrio tripla. So elas: Escopo. Tempo. Custo. Neste curso, trataremos das outras seis disciplinas: Qualidade. Recursos humanos. Comunicao.
-3-
Riscos. Aquisies. Integrao de todas elas.
Ao final deste mdulo, voc conhecer: O que qualidade. Os equvocos comuns em qualidade. Os custos da qualidade. O que gerenciamento da qualidade; Como planejar a qualidade do projeto.
O que qualidade?
No curso anterior, falamos do planejamento da restrio tripla (escopo, tempo e custo). A qualidade afetada por este trio de restries e uma preocupao que est presente em todos os projetos. normalmente ela que determina se as expectativas dos interessados foram atendidas. Respeitar prazos e oramentos uma coisa; se gerarmos um produto incorreto ou inferior, o prazo e o oramento de repente vo perder a importncia. Um aspecto que deve ser considerado no planejamento do projeto o que podemos fazer para garantir que as necessidades do cliente quanto aos resultados do projeto sejam alcanadas. Resumindo, devemos deixar o cliente satisfeito. Muitos poderiam dizer faa a coisa certa na primeira vez, outros diriam mantenha seu projeto alinhado com as expectativas do cliente.
O conceito moderno de qualidade tem foco na satisfao do cliente e na conformidade do projeto com as necessidades deste cliente, e no com padres previamente criados pela empresa ou pela equipe do projeto Lewis R. Ireland
O que deve ser feito para garantir que faremos certo j na primeira vez? Como saber se a abordagem adotada est realmente alinhada com as necessidades do cliente? Quais itens devem ser observados para avaliar se o trabalho est correto?
-4-
Traduzindo para a linguagem da qualidade: verificar a conformidade com o que foi solicitado. Vejamos um exemplo simples com o qual nos deparamos quase diariamente: a questo da temperatura de uma sala de aula. A expectativa dos alunos que a temperatura esteja em mdia 23 graus centgrados, com uma variao de 1 grau centgrado para cima ou para baixo. O dimensionamento e a instalao dos equipamentos tm que considerar este requisito de temperatura agradvel, com pouca variao. A mtrica a temperatura do ar, que deve ser acompanhada com certa periodicidade. Se estiver acima, os equipamentos sero ligados com mais ar frio, caso contrrio ser insuflado ar mais quente at que a temperatura retorne ao patamar determinado.
O que fazer para garantir que estes valores sejam alcanados?
Voc poderia sugerir a utilizao de um termmetro e algum de cinco em cinco minutos para observar a temperatura; se ela estiver abaixo da mdia, deve-se desligar o ar frio e ligar o ar quente, do contrrio deve-se manter mais ar frio.
Veja, a preocupao manter a conformidade (a temperatura em 23 graus), e no o desenvolvimento do produto que refrigerar a sala. Qualidade isso. Determinar a conformidade e garantir que as coisas se mantenham nela. Pense no que deve ser feito para cumpri-la e em quais atividades devem ser planejadas em seu projeto para assegurar a conformidade. Observe a seguir uma definio mais completa de qualidade.
Muito se fala em qualidade, mas um fato importante definir o que qualidade. Certamente, os clientes sabem o que quando a vem; os fornecedores prometem que seus bens e servios a incorporam. S que, na maioria das vezes, ambas as vises no tm uma definio clara e comum do que realmente qualidade, e isso acaba trazendo muitos problemas para os projetos. Um destes que cada organizao estabelece sua prpria definio. No final, contudo, todas elas levam base fundamental da qualidade, expressamente:
-5-
O cliente define qualidade e determina o que necessrio para que suas expectativas sejam satisfeitas.
A definio de qualidade do PMI, citada no Guia PMBOK, o grau at o qual um conjunto de caractersticas inerentes satisfaz s necessidades (American Society for Quality, 2000). Estas necessidades declaradas e implcitas so um insumo para o desenvolvimento dos requisitos do projeto. Portanto, um item importante do gerenciamento da qualidade do projeto transformar as necessidades, os desejos e as expectativas dos interessados em requisitos atravs da anlise dos stakeholders, realizadas durante o gerenciamento do escopo do projeto. Contudo, outras definies so tambm relevantes, como: Conformidade com as especificaes; Conformidade com expectativas mutuamente acordadas; Aptido para uso; Satisfao do cliente/servio ao cliente.
Para o PMI, um projeto com qualidade aquele que foi entregue em conformidade com os requisitos e especificaes (ele deve produzir o que foi estabelecido) e est adequado ao uso (deve satisfazer s reais necessidades dos clientes). No final, qualidade se resume em satisfazer s expectativas e especificaes do cliente, como diria a letra de uma msica do filme Mogli: o necessrio, somente o necessrio, o extraordinrio demais!. Portanto, na viso do PMI, exceder as expectativas do cliente no recomendvel. De fato, eles chamam isso de gold-plating, cuja traduo literal banhar a ouro. Na verdade, um trabalho desnecessrio e tipicamente leva a custos mais altos para o projeto, por exemplo, funcionalidades adicionais no solicitadas, escopo suplementar ou desempenho melhor do que o desejado. Esta prtica no recomendada, porque este trabalho no agrega valor ao projeto. O gerente de projeto deve dedicar seu tempo a garantir que os projetos estejam em conformidade com os requisitos e no entregando extras.
Equvocos comuns em qualidade

Muitas pessoas compreendem certos conceitos sobre qualidade de forma ambgua, o que acaba por produzir equvocos. Os mais comuns so listados a seguir:
-6-
Qualidade custa muito caro. talvez o equvoco mais comum. Esta noo provavelmente surgiu porque a ideia de se planejar um produto de qualidade, desde o princpio, sugere uma imagem de se dedicar muito(s) tempo, recursos e esforos no planejamento. Contudo, o fato que o planejamento antecipado da qualidade economiza dinheiro em longo prazo, porque ele reduz o retrabalho e acarreta menos rejeio e menos consumidores insatisfeitos. Qualidade um luxo. parente prximo do primeiro equvoco e tem sua origem, pelo menos em parte, na ideia de que a qualidade custa muito caro. Muitas pessoas associam itens caros com qualidade. Por exemplo, se uma pessoa compra uma casa cara, a deduo automtica que essa casa tem uma construo de alta qualidade. Contudo, se o mesmo empreiteiro construir uma casa mais barata, na mesma rua, quem pode dizer se a qualidade diferente ou a mesma? Categoria menor significa baixa qualidade. Essa uma confuso muito comum, categoria funcionalidades ou configuraes, no qualidade. menor significa ter menos
Por exemplo: Fusca e Mercedes. O Fusca tem menos qualidade do que o Mercedes? A resposta no: o Fusca tem menor grau, ou seja, menor quantidade de recursos. O Guia PMBOK define grau como uma categoria ou nvel usado para distinguir itens que tenham o mesmo uso funcional, mas no dividem os mesmos requisitos para qualidade. O grau determinado pelos requisitos funcionais do cliente. Baixa qualidade sempre um problema, mas grau baixo no . O gerente de projeto e a equipe determinam e entregam o grau e o nvel de qualidade exigidos. Manter a qualidade no to importante quanto o custo e o cronograma. O Guia PMBOK expressa que custo, tempo e qualidade so igualmente importantes. Projetos que entregam seus produtos ou servios no prazo e dentro do cronograma, mas so completamente inaceitveis pelo cliente, no so bem-sucedidos. No h tempo disponvel para produzir com qualidade. Este equvoco, com muita probabilidade, surgiu em reas com restries de tempo para comercializao (como a indstria de softwares). Em tais reas, a urgncia em se lanar produtos frente no mercado frequentemente ultrapassa o planejamento bsico do projeto e, ainda mais, o planejamento da qualidade. O resultado de no produzir com qualidade desde o princpio provoca defeitos constantes, refugo do trabalho e clientes insatisfeitos, mesmo quando o prazo final de comercializao cumprido.
-7-
Organizaes orientadas qualidade mudaram suas perspectivas sobre estes equvocos, especialmente os que dizem respeito ao custo. H claras evidncias de que o custo de se melhorar a qualidade menor do que a economia resultante. Joseph Juran, um dos gurus da qualidade, criou o conceito do custo da qualidade. Ele percebeu que os executivos jamais dariam ateno a aspectos como taxas de defeitos ou limites de controle. Ele decidiu traduzir a qualidade para uma linguagem que eles conseguiam entender: dinheiro, este o conceito de custo da qualidade.
Custo da qualidade
relacionado ao desembolso total com a qualidade dos produtos/servios, incluindo o que se gasta para melhorar a qualidade (conformidade), e com o prejuzo decorrente da falta dela (no-conformidade). A ideia fazer com que o custo da conformidade compense a perda oriunda da noconformidade. Por exemplo, gastar $50 para no perder $100. Custo da conformidade Os custos dos processos proativos de qualidade incluem: Custos de avaliao esto associados ao teste e ao controle de matrias-primas e produtos. Os gastos com laboratrios de qualidade, por exemplo, poderiam evitar que falhas internas se transformassem em falhas externas. Custos de preveno so decorrentes da preveno de falhas. Por exemplo: revises de concepo, treinamento e doutrinao, planejamento.
-8-
Custo da no-conformidade O custo da falta de qualidade dividido em: Custos de falhas internas so aqueles decorrentes de defeitos descobertos antes de o produto ser enviado para o cliente. O retrabalho e o expurgo de peas so exemplos. Custos de falhas externas so aqueles originados de defeitos descobertos aps a entrega para o cliente. Por exemplo: recall de produtos automobilsticos.
De qualquer forma, o custo da qualidade uma abordagem orientada a resultado para medir e estimar a efetividade e o benefcio dos processos de gerenciamento da qualidade do projeto da organizao. um meio til de trazer a ateno do gerenciamento para a necessidade da qualidade. Na opinio de Juran, colocar dinheiro em preveno e avaliao no , de maneira alguma, jogar dinheiro fora. Os investimentos so compensados por redues no custo das falhas. Por exemplo, voc gasta $ 1.000,00 no treinamento de uma equipe que reduz significativamente falhas na produo de um determinado item. O valor desta reduo de R$ 2.000,00. Portanto, a organizao ganhou R$ 1.000,00. Crosby, outro guru da qualidade, prega este princpio em seu livro A qualidade grtis.
O que gerenciamento de qualidade?

A gesto da qualidade trata de assegurar que o projeto satisfar a todas necessidades para as quais ele foi empreendido. Isso inclui todas as atividades, todos os nveis da gerncia, que determinem a poltica, os objetivos e responsabilidades e os implementem por meio dos processos de planejamento, controle, da garantia e melhoria da qualidade. as em as do
Com base nisso, o Guia PMBOK definiu trs processos para gerenciar a qualidade nos projetos: Planejamento da qualidade. Garantia da qualidade.
-9-
Controle da qualidade. O planejamento da qualidade crtico porque ele ser a base para o restante das iniciativas de qualidade. Envolve identificar padres de qualidade que o produto deve alcanar, para que o cliente fique satisfeito com o resultado final do projeto.
Como planejar a qualidade

O Guia PMBOK define o planejamento da qualidade como a identificao dos padres de qualidade relevantes para o projeto e a determinao de como satisfaz-los (Guia PMBOK, seo 8.1). Um princpio do pensamento moderno sobre o gerenciamento da qualidade em projeto que qualidade no inspecionar, e sim prevenir. No entanto, a inspeo certamente parte do gerenciamento da qualidade, porm ela geralmente no considerada o melhor caminho para aprimorar a qualidade. Planejar a qualidade significa preparar um documento (plano do gerenciamento da qualidade) que descreva: Os padres de qualidade adotados para o projeto; Os critrios para medir se a qualidade est sendo alcanada; Lista de verificao usada para observar se um conjunto de etapas foi cumprido; Mtricas de qualidade que informem ao gerente de projeto se o projeto est fora de controle, visando recomendar aes corretivas e/ou preventivas.
Para se preparar um bom plano, o PMI recomenda algumas ferramentas e tcnicas, incluindo o conceito do custo da qualidade. Anlise de custo-benefcio: a anlise de custo-benefcio deve ser considerada no processo de planejamento da qualidade do projeto. O principal benefcio de atingir os requisitos de qualidade um menor retrabalho. O custo primrio a despesa associada com as atividades do gerenciamento da qualidade do projeto. Benchmarking: envolve a comparao de atividades do projeto reais ou planejadas quelas de outros projetos, para gerar ideias de melhorias e fornecer um padro de mensurao de desempenho. Algumas pessoas descrevem este processo como uma busca por melhores prticas. Projeto de experimentos: uma tcnica analtica que ajuda a identificar quais variveis possuem mais influncia no resultado total. Por exemplo, designers podem querer determinar qual combinao de carroceria com pneus produz o veculo com as caractersticas mais desejveis a um custo razovel. Diagrama de causa e efeito: conhecido por Diagrama de Ishikawa ou Diagrama de Espinha
- 10 -
de Peixe. um tipo especial de fluxograma que apresenta como causas e subcausas se relacionaram para criar problemas ou efeitos potenciais. Elaborao de fluxogramas: fluxogramas so diagramas que mostram como vrios elementos de um sistema se relacionam. Os tipos mais conhecidos so os fluxogramas de sistema ou processo, que mostram os elementos inter-relacionados. Outras ferramentas adicionais, como o brainstorming, tambm so recomendadas no Guia PMBok (seo 8.1.2.5) para serem utilizadas no planejamento da qualidade.
Filosofia da qualidade A cultura organizacional deve apoiar a noo de que a qualidade deve ser planejada no projeto, desde o princpio. essencial para um planejamento de sucesso analisar cuidadosamente as especificaes do cliente e os padres de qualidade que apiem a entrega do servio ou produto, como foi acordado. E, antes que qualquer iniciativa de qualidade seja implementada em uma organizao, os nveis mais altos da direo devem estar comprometidos com ela.
A filosofia da qualidade estabelece os padres na organizao e para cada indivduo a ela integrado. Veja o exemplo da Johnson & Johnson: uma companhia com uma forte filosofia corporativa e uma vontade de implementar e segui-la. Sua filosofia de qualidade no colocar o pblico em perigo. De acordo com ela, quando os vidros de Tylenol foram contaminados com cianeto, todos eles foram retirados das prateleiras, com uma tremenda perda de lucros no curto prazo. A resposta positiva do pblico a este ato foi to poderosa que a companhia recuperou suas perdas iniciais dezenas de vezes. A EAP fundamental para implementar a qualidade Ferramentas e tcnicas bsicas de gerenciamento de projetos so a sustentao de todos os processos de boa qualidade, e a ferramenta mais importante entre todas a EAP. Geralmente, as primeiras ideias sobre as expectativas do cliente quanto qualidade tomam forma quando da anlise de uma declarao de trabalho, documento gerado na maioria das vezes pelo cliente. No entanto, o planejamento
- 11 -
real da qualidade ocorre depois que a EAP desenvolvida, porque a ento que a equipe do projeto define o sistema e desenvolve padres que garantam a qualidade ao longo do ciclo de vida do projeto. Identificando o cliente Conhecer o cliente a chave para se fornecer um produto ou servio de qualidade, mas muitas pessoas no percebem que tm mltiplos clientes. Eles incluem: O cliente do projeto pessoa ou organizao que a usuria final do produto ou servio criado pelo projeto; Clientes internos, que so os que recebem as tarefas ou os servios que os indivduos fornecem; Clientes ocultos, como stakeholders, que so indivduos ou organizaes que podem afetar significativamente o futuro do projeto.
Projetos, com frequncia, fracassam ou ficam aqum das expectativas porque os stakeholders no so identificados. A equipe do projeto deve identificar todos os stakeholders (e todos os que pensam que o so) e trat-los como clientes. Clientes e stakeholders (os termos so intercambiveis) podem ser externos organizao ou internos. Eles tambm podem ser invisveis; isto , eles podem ter um interesse no projeto, mas no tm contato direto com as atividades dele. Por exemplo, um grupo ambientalista pode ter um interesse vital em um projeto que pode afetar o ecossistema.
O que uma especificao?

Especificaes conduzem o projeto e os padres com os quais a equipe do projeto define o projeto e a sua qualidade. Uma especificao algo que um produto ou servio deve fazer ou uma qualidade que um produto ou servio deve ter. Geralmente, definir especificaes em termos de funcionalidade de produtos melhor do que defini-las em termos de especificaes de engenharia, porque especificaes funcionais fornecem equipe mais flexibilidade para criar solues inovadoras. Quando possvel propor alternativas, as equipes do projeto podem frequentemente desenvolver solues melhores a custos mais baixos. Especificaes podem vir de diversas fontes. Normalmente, a maioria das especificaes fornecida pelo cliente ou pela rea de negcios da organizao; elas podem ser encontradas nos contratos, nas declaraes de trabalho, na declarao de escopo ou em comentrios feitos pelo cliente durante as negociaes de pr-projeto.
- 12 -
Identificando as especificaes do cliente Os gerentes de projeto devem identificar todas as especificaes de um projeto, envolvendo o cliente neste processo. Apesar de parecer trivial, escrever ou interpretar especificaes pode ser muito difcil. A melhor abordagem listar tantas especificaes quanto possvel e, ento, pedir ao cliente para verific-las e esclarec-las. O objetivo definir claramente o produto antes que ele entre em produo; fazer isso custa menos e cria menos stress. Lembre-se de incluir fornecedores internos e externos potenciais durante a fase de determinao das especificaes; eles podem lhe dar perspectivas valiosas.
Resumindo
A qualidade importante para o sucesso dos projetos, o papel dela garantir que as expectativas dos interessados sejam atendidas. Ela pode ser definida pelos stakeholders, pela equipe do projeto, pelo patrocinador, pelos padres de qualidade e por uma combinao desses e de outros fatores. Se o projeto envolve a produo de um novo instrumento de cirurgia cardaca, por exemplo, provavelmente haver uma srie de padres de qualidade que devero ser atendidos. As partes devem ter tamanho e formato especficos, o instrumento deve ser construdo com um determinado material etc. Geralmente, existe um dilema no qual a qualidade uma preocupao. Atender aos padres de qualidade para o projeto vai custar alguma coisa tempo ou recursos. Isso conhecido como custo da qualidade, mas no atender aos padres tambm vai ter um custo, porque o projeto ser considerado malsucedido, podendo haver a necessidade de reparos, descartes e retrabalho. O custo dividido em duas categorias custo da conformidade e custo da no-conformidade. O planejamento da qualidade abrange a identificao de clientes e especificaes. Existem clientes com caractersticas diferentes, e eles devem participar na definio e aprovao das especificaes. Padres de qualidade fornecem a linha base com a qual medimos o desempenho. O foco do planejamento da qualidade identific-los para cada pacote de trabalho da EAP.
- 13 -
Recursos humanos
Objetivo
Conhecer: Como se faz o planejamento dos recursos humanos.
Planejamento dos recursos humanos

Todo projeto requer pessoas. O processo de planejamento de recursos humanos documenta as funes e responsabilidades das pessoas ou dos grupos envolvidos nos diversos elementos do projeto, apresentando as relaes de subordinao para cada um deles. Nos projetos, os recursos esto organizados em estruturas organizacionais temporrias, portanto necessrio a cada projeto planejar como distribuir os recursos humanos, identificando a sua posio na estrutura do projeto, seu papel e sua responsabilidade. Estes processos tm como objetivo tornar mais efetivo o uso das pessoas envolvidas nos projetos, que fracassam muitas vezes por falhas na definio da equipe ou por pouca participao dos interessados. uma influncia decisiva para o sucesso ou o fracasso. De pouco adianta informar a um gerente de departamento que sua rea tem um papel fundamental em uma atividade do projeto que comea amanh. As pessoas devem ser envolvidas o mais cedo possvel, inform-las uma tarefa do gerente de projetos. O planejamento de recursos humanos est fortemente associado com o planejamento de comunicao (que ser tratado em seguida) e deve responder a trs perguntas simples: 1. Quem faz o qu? 2. Quem se reporta a quem no projeto? 3. Em que momento as pessoas devem participar no projeto? Definio de responsabilidades e papis A pergunta 1 (Quem faz o qu?) a mais importante no planejamento de recursos humanos. Aqui existem duas premissas para o sucesso:
- 14 -
1) Os recursos para cada atividade do projeto devem estar disponveis quando necessrio, nem antes ou depois, e a quantidade deve ser a absolutamente necessria, nem mais e nem menos. 2) Cada atividade deve possuir uma pessoa como responsvel, que deve: Tomar providncias para garantir que a tarefa tenha sucesso; Responder pelo fracasso ou pelos problemas da atividade; Tomar decises que afetem positivamente a probabilidade de sucesso da tarefa.
A figura a seguir exemplifica as responsabilidades associada EAP para o projeto Festa.
A definio de responsabilidades usa como ferramenta a Matriz de Responsabilidades. Ela conecta a EAP a pessoas ou grupos responsveis pelas atividades do projeto. Matriz de Responsabilidades um mtodo utilizado para exibir, na forma de tabelas, as pessoas responsveis pela realizao dos itens de trabalho na EAP. uma ferramenta til, pois enfatiza quem responsvel em cada item de trabalho e mostra o papel de cada um na realizao do projeto global.
Algumas matrizes de responsabilidades usam um X ou R para mostrar quem responsvel pelos itens de trabalho; outras utilizam um P ou R para designar responsabilidade principal e um S ou A para indicar a secundria de assessoria ou o apoio em cada pacote de trabalho especfico.
- 15 -
uma boa ideia designar apenas uma pessoa como lder ou o principal responsvel para cada pacote de trabalho. A dupla designao aumenta o risco de que determinado trabalho fique rfo. Como diz o ditado, co que tem dois donos morre de fome. Quem trabalha em projetos ouve isso frequentemente. Depois da expresso mais perdido do que cachorro que caiu do caminho de mudana, essa outra referncia aos caninos das mais ilustrativas de uma situao comum no ambiente de projetos: a falta de um nico responsvel para cada pacote de trabalho na EAP. perfeita a imagem do animal que sucumbe dvida de seus donos, que no sabem quem tem que lhe dar comida.
O objetivo deste provrbio alertar para os problemas que advm da falta de definio de quem deve cumprir uma tarefa. A falta do responsvel designado gera problemas tanto no caso de ningum cuidar do assunto quanto na possibilidade de haver excesso de pessoas querendo tratar o problema. H situaes em que o responsvel no cuida da tarefa porque ele desconhece que foi incumbido dela. s vezes, ningum se sente responsvel por uma tarefa pelo simples motivo de que ela efetivamente no tem dono, o que acontece porque no foi dito quem deve faz-la ou se entregou o trabalho de forma ambgua a mais de uma pessoa. A responsabilidade por definir o responsvel sempre do gerente do projeto, por isso todos os projetos devem ter as atribuies de responsabilidades claramente definidas, e o melhor jeito de fazer isso utilizando a Matriz de Responsabilidades. A figura a seguir ilustra uma matriz com atribuies primrias (P) e secundrias (s).
Organograma do projeto A ferramenta utilizada para a segunda questo (Quem se reporta a quem no projeto?) pode ser facilmente respondida elaborando-se um organograma.
- 16 -
Este um tipo de grfico bastante popular, que apresenta os relacionamentos de reporte do projeto (Quem manda em quem?). Nos projetos, as estruturas so temporrias e mltiplas, em muitas situaes o recurso pode estar comprometido com mais de um projeto. Portanto, importante saber como as pessoas esto hierarquicamente distribudas naquele projeto em particular. Em projetos maiores, onde o trabalho de gerenciamento dividido, o organograma pode tornarse altamente complexo. J em projetos menores, esta estrutura pode ser to simples e conhecida que at dispense a criao deste diagrama. Cronograma na forma histograma de recursos de
A terceira pergunta trata do momento em que as pessoas devem se envolver com o projeto isso parte do cronograma. Usando um grfico conhecido por histograma de recursos, que mostra os perodos nos quais os recursos so necessrios no projeto e quando o processo de recrutamento deve comear. Em geral, o histograma de recursos exibido na forma de um grfico com recursos especficos, que apresenta a linha de tempo do projeto no eixo horizontal e a quantidade de trabalho em horas no eixo vertical. Veja o exemplo.
Resumindo
Todo projeto requer pessoas. O processo de planejamento de recursos humanos documenta as funes e responsabilidades das pessoas ou dos grupos envolvidos nos diversos elementos do projeto, apresentando as relaes de subordinao para cada um deles. Nos projetos, os recursos esto organizados em estruturas organizacionais temporrias, portanto necessrio a cada projeto planejar como distribuir os recursos humanos, identificando a sua posio na estrutura do projeto, seu papel e sua responsabilidade. Estes processos tm como objetivo tornar mais efetivo o uso das pessoas envolvidas nos projetos, que fracassam muitas vezes por falhas na definio da equipe ou por pouca participao dos interessados. Seres humanos geralmente so o elo mais fraco do projeto, mas certo que o fator humano tem uma influncia decisiva para o sucesso ou o fracasso. O planejamento de recursos humanos est fortemente associado com o planejamento de comunicao e deve responder a trs perguntas simples: quem faz o qu? Quem se reporta a quem no projeto? Em que momento as pessoas devem participar no projeto? A pergunta quem faz o qu? a mais importante no planejamento de recursos humanos.
- 17 -
Existem duas premissas para o sucesso: 1 os recursos para cada atividade do projeto devem estar disponveis quando necessrio, nem antes ou depois, e a quantidade deve ser a absolutamente necessria, nem mais e nem menos; 2 cada atividade deve possuir uma pessoa como responsvel, que deve tomar providncias para garantir que a tarefa tenha sucesso, responder pelo fracasso ou pelos problemas da atividade e tomar decises que afetem positivamente a probabilidade de sucesso da tarefa.
Comunicao
Objetivo
Conhecer: O que comunicao. Estilos de comunicao. O gerenciamento das comunicaes do projeto. O planejamento das comunicaes. O plano de comunicao.
Comunicao
Bons projetos so o resultado da combinao de aes, decises e estratgias, executadas por equipes com uma variedade de papis e responsabilidades, que se relacionam com outras pessoas e buscam um resultado bem-sucedido. Para que isso acontea com sucesso, fundamental um bom processo de comunicao, ou seja, a informao correta para as pessoas certas, relatando-se o progresso e o andamento do projeto de forma adequada para os diferentes interessados e identificando-se claramente as preferncias de cada envolvido. Os gerentes de projeto precisam desenvolver boas habilidades de comunicao e aplicar os processos recomendados para melhorar os resultados do projeto, planejando o que, como e para quem comunicar. Mas, antes de abordarmos sobre como planejar a comunicao, vamos discutir alguns conceitos fundamentais sobre este tema.
O que comunicao?
Comunicao: afinal de contas, o que isso?
- 18 -
Todo projeto precisa de um bom plano de gerenciamento de comunicao que documente as necessidades de informao dos interessados, quando distribu-la e a forma como ser transmitida. Ele deve abordar as necessidades de todas as partes interessadas. As informaes comunicadas normalmente abrangem:
Andamento do projeto. Declaraes de escopo e suas atualizaes. Informaes bsicas do projeto. Riscos, aes. Medidas de desempenho. Aceitao do projeto.
Um
plano
de
gerenciamento
das
comunicaes
normalmente
descreve:
O que deve ser comunicado? De que forma deve ser comunicado e mtodo de transmisso (como). Propsito da comunicao (por qu). Frequncia das comunicaes, perodo de distribuio, incluindo datas de incio e trmino (quando). Pessoa responsvel pela distribuio da informao.
A palavra oriunda do latim (comunicare) e significa compartilhar, tornar comum. um esforo bidirecional que envolve: A transmisso da informao utilizando um conjunto de smbolos (verbais, no-verbais, grficos); O entendimento comum para uma ou mais pessoas (receptores), por meio de mecanismos (meios) adequados; O posterior recebimento do feedback pelo emissor.
Por se achar que a gesto das comunicaes no projeto j est implcita e uma coisa automtica, ela frequentemente ignorada.
- 19 -
Sempre que falamos em projetos, as lembranas que vm mente so EAP, cronogramas, recursos, plano de projetos, riscos etc. Mas e a comunicao? Onde est? Por que quase no se fala no plano de comunicaes ou na reunio de kick-off? Lembrem-se de que no haver escopo ou cronograma sem comunicao. Como elaborar planos e desejar obter resultados se as pessoas no se relacionarem e compartilharem seus conhecimentos? Comunicao O PMI destaca a importncia de uma comunicao efetiva, pois a maioria dos gerentes dos projetos concludos com sucesso gastou aproximadamente 90% do seu tempo envolvido em algum tipo de comunicao, seja ela escrita, falada, de forma noverbal, com um estilo formal ou informal. Os gerentes devem saber aplicar os diferentes tipos e estilos de comunicao, assim como desenvolver um ambiente que propicie uma comunicao franca e aberta entre os participantes do projeto. Ento, a comunicao de extrema importncia para o projeto e seu planejamento essencial. O PMI, talvez sem querer, deu o destaque merecido para a disciplina, colocando-a no Guia PMBOK como captulo 10. Portanto, em projetos, a comunicao DEZ! O fato que no importa quanto a tecnologia avance, projetos so e sero executados por pessoas e dependero muito delas para que sejam implementados com sucesso. Saber lidar com os desafios da comunicao impostos em cada empreendimento um fator crtico de sucesso no s para o projeto, mas tambm para a vida profissional. Lembrem-se de que nem s do caminho crtico vive um projeto, algum precisa dizer onde ele est!. Modelo de comunicao Aristteles foi o primeiro a citar um modelo de comunicao, ao dizer que o processo requer pelo menos trs elementos: aquele que fala, o que foi dito e aquele que escuta. Assim, ele criou a base dos modelos de comunicao atuais, reconhecida pela maioria dos autores com quatro partes principais, conforme o mostrado na figura a seguir:
- 20 -
Emissor ou transmissor: aquele que origina a mensagem, determinando qual ideia dever ser transmitida e compartilhada com o receptor e de que forma esta ser codificada, considerando qual ser o meio utilizado para transmisso e as particularidades do receptor. Mensagem: so os pensamentos, sentimentos ou ideias transformados em um cdigo, que deve ser compreensvel tanto pelo emissor quanto pelo receptor. Meio ou mdia: o veculo ou mecanismo usado para encaminhar a mensagem. A escolha do meio vai destacar e influenciar o efeito da mensagem. Os meios mais comuns so o visual, o auditivo e o ttil. Receptor: aquele para o qual a mensagem destinada. Utilizando os sentidos ele decodifica e aplica a ela sua percepo (funo ou efeito mental de representao dos objetos, sensao, senso), ou seja, a sua compreenso da ideia recebida. Este processo bastante varivel e dependente de formao cultural, estresse, emoes, humor, aceitao, preconceitos etc. Essas variveis fazem com que algumas vezes a ideia originalmente transmitida possa ser percebida de forma diferente, criando uma espcie de filtro e produzindo uma falsa compreenso. Este efeito de filtragem cria as barreiras de comunicao. Barreiras de comunicao importante que o gerente de projeto reconhea a existncia delas e saiba como codificar sua mensagem de forma a minimizar ou contornar os efeitos produzidos pelas barreiras. o que costumeiramente dizemos falar com jeito, saber como falar. Claro que estas barreiras no aparecem somente do lado do receptor. Muitas vezes, ao transmitirmos a mensagem, inserimos alguns sinais de forma proposital ou no, dependendo do nosso estado de esprito, que podem produzir um falso entendimento da ideia e, algumas vezes, provocar desentendimentos srios. O nvel de conflito no projeto tende a aumentar quando h barreiras de comunicao. A seguir, temos alguns tipos de barreiras:
- 21 -
Barreiras de conhecimento Incluem o despreparo para lidar com o processo oral ou escrito da comunicao. So cenrios tpicos: Uso inadequado de linguagem tcnica no familiar aos interessados; Desconhecimento do assunto a ser comunicado; Excesso de informao; Falta de habilidades para lidar com equipamentos e tecnologia no dominados pelo emissor. Barreiras comportamentais So casos tpicos de barreiras comportamentais: Desconfiana entre os envolvidos. Atitudes preconceituosas ou hostis. Desinteresse, ansiedade. Omisso intencional de fatos e informaes. No saber ouvir. Falta de ateno ao assunto e prejulgamentos. Uma das recomendaes para reluzi-las pode ser o uso mais intenso da comunicao face a face, que possui recursos diferentes da comunicao impressa e escrita, muito utilizada no gerenciamento de projetos. Na comunicao escrita, necessrio haver objetividade, clareza, detalhamento e visualizao grfica para que a comunicao seja eficaz, pois ela se dar exclusivamente por meio do que estiver impresso ou escrito, quer seja num documento ou numa tela de computador. Barreiras organizacionais Alguns exemplos deste tipo de barreira so: Falta de flexibilidade da estrutura organizacional, excessivamente burocrtica, com excesso de regras, padres e procedimentos. Difcil acesso aos equipamentos de comunicao. Uma cultura organizacional que desestimula ou desfavorece o processo de comunicao na empresa. Barreiras tcnicas Alguns exemplos de barreiras tcnicas: Uso incorreto de padres tcnicos, equipamentos ultrapassados.
- 22 -
Baixa qualidade de transmisso, distores de sinal ou desconhecimento da tecnologia empregada. Verses conflitantes de sistemas informatizados.
O que pode ser feito para superar as barreiras comunicao? Algumas dicas para minimizar as barreiras incluem: Definir claramente o tipo de informao a ser enviada para cada interessado. Usar um estilo de redao claro e objetivo em toda comunicao escrita, com frases bem estruturadas e escolha adequada das palavras, facilitando a compreenso pelo receptor. Utilizar tcnicas de apresentao fazendo um preparo antecipado, adotar um design adequado nos recursos audiovisuais; uso adequado de cores e tamanhos de letra, boa linguagem verbal e corporal. Uso adequado de cores e tamanhos de letra, boa linguagem verbal e corporal. Evitar o excesso de termos tcnicos ou de siglas ou de jarges fora de contexto. Evitar o uso de piadas que envolvam questes de raa, sexo, nacionalidade e que possam deixar a pessoa sem graa. Quando utilizar a comunicao oral, observe princpios definidos para a comunicao escrita, como clareza, objetividade e construo adequada de frases, mas tomando cuidado, pois este processo ocorre ao vivo e sem chances de se reescrever ou apagar o que foi dito, o que recomenda cautela, refletir antes de falar e cuidado permanente com a compreenso e feedback fornecidos pelo receptor sobre a mensagem que lhe transmitida. Falar e ouvir na hora certa, responder a perguntas. Ser pontual e honesto quando ocorrem atrasos ou qualquer outro problema que possa ser recebido pelos interessados atravs de outros meios, portanto no os omita. O emissor deve deixar clara a existncia e disponibilidade de um canal aberto (como encontros pessoais previamente acertados) para o esclarecimento e sanamento de dvidas quando os interessados desejarem. Considerar que aspectos polticos e estruturas de poder podem influir na conduo de projetos, o que recomenda cuidado na forma e maneira de abordar assuntos polmicos, controvertidos ou passveis de gerar conflitos e desentendimentos. Adotar uma estratgia proativa de comunicao, considerando:
- 23 -
(1) a identificao de eventos (marcos) de comunicao, onde o gestor deve reportar o andamento e progresso do projeto. (2) a criao de um canal de comunicao direto entre os gerentes de projeto e os interessados, para esclarecimentos imediatos. (3) manter algum tipo de boletim informativo do projeto de linguagem simples e familiar a todos os envolvidos. Avaliar constantemente aperfeioar suas habilidades tcnicas e comportamentais ao lidar com o processo de comunicao, incorporando e fazendo uso de tcnicas e lies aprendidas cada vez que ele ocorre. Estabelecer um canal de comunicao pessoal rpido e direto entre os gerentes do projeto e esses interessados.
Tipos de comunicao A comunicao quanto classificada como: ao tipo pode ser
Verbal, que faz uso apenas da palavra, seja ela escrita ou falada. No-verbal, quando faz uso de sinais, e paralingustica, que faz uso de entonaes vocais. Comunicao verbal Esta pode ser oral ou escrita e ainda o tipo mais utilizado para transmitir informaes, bem como um dos mais eficazes. Nos dias de hoje, em decorrncia das facilidades tecnolgicas como e-mail e SMS (short message, por meio de pagers e celulares), a forma escrita est aumentando significativamente. comum observarmos pessoas prximas uma da outra utilizando a comunicao escrita muitas vezes por meio de e-mails. Manter comunicaes orais e presenciais extremamente importante para aumentar o esprito de equipe. Um gerente no deve s pilotar seu projeto por meio da escrita ou simplesmente do celular; a presena fsica e os milhares de sinais no-verbais que so transmitidos ampliam a confiana dos envolvidos no processo. O PMI destaca a importncia da proximidade do time (tight matrix) para manter uma comunicao eficaz. Na medida do possvel, muito saudvel manter contatos presenciais com os envolvidos. Isso faz uma grande diferena. A comunicao oral mais rpida, pois permite mantermos a mensagem simples e apresentar os pensamentos de forma mais organizada e rpida. Na maioria das vezes, um mecanismo de duas vias, possibilitando a obteno do feedback por parte do receptor durante sua transmisso.
- 24 -
Durante os processos de negociao, a comunicao oral fundamental, pois auxilia a desenvolver um processo de entendimento do problema. Muitos dos conflitos podem ser minimizados quando do uso deste veculo. J a comunicao escrita mais detalhada do que a oral, sendo utilizada para explicar temas de maior complexidade e quando necessrio algum tipo de formalizao. Geralmente, mais organizada e de melhor entendimento, permitindo ao receptor a reviso da mensagem, absorvendo-a em seu prprio ritmo. Comunicao no-verbal Tambm conhecida como a linguagem corporal, aquela que se d sem o uso de palavras. O termo no-verbal pode induzir a erro, pois a definio no-verbal exclui sinais vocais ou paralingusticos e indicaes como tom de voz emocional, que so obviamente muito importantes. A linguagem do corpo tambm exclui sinais vocais. Este tipo de comunicao mais primitivo e eficiente do que a comunicao verbal. A riqueza de smbolos enorme, alguns pesquisadores afirmaram que existem mais de 700.000 sinais diferentes! notrio que muitas coisas podem ser mais bem expressas de uma maneira no-verbal (dor, sentimentos, emoes, cansao etc.). Comunicao paralingustica aquela que utiliza sons ou qualidade de voz que acompanha a fala e revela a situao em que o falante se encontra (se ele est bem, mal, alegre, triste, cansado etc.). Aspectos como velocidade e entonao so considerados paralingusticos.
Estilos de comunicao
O gerente de projeto, dependendo da mensagem verbal, poder empregar o estilo mais apropriado, e este poder ser formal ou informal. Comunicao formal aquela onde um conjunto de regras e procedimentos devem ser seguidos, exigindo um formato, um protocolo. Muitas metodologias de gesto de projetos determinam certa sequncia de eventos e/ou procedimentos com documentos formatados. No ambiente de projetos, toda a comunicao formal deve veicular por meio dos gerentes de projeto de todas as organizaes envolvidas no projeto. Por exemplo: se um executivo da organizao A e um executivo da organizao B, durante um jantar, resolvem formalizar mudanas no projeto, estas s podero ser consideradas oficiais se os gerentes de projeto participarem do processo.
- 25 -
Comunicao informal aquela onde no h um conjunto de regras, a comunicao livre. A maioria dos gerentes de projeto prefere comunicar-se verbal e informalmente, pois a comunicao formal pode alcanar custos elevados. Metodologias eficientes de gesto de projetos promovem no s uma gesto mais informal, mas igualmente uma comunicao eficiente, lateral e verticalmente. Se utilizada adequadamente, a comunicao informal pode trazer muitos benefcios para o projeto. uma comunicao construda na base da confiana mtua entre todos os envolvidos. Claro que isso no significa que voc ir abolir a comunicao formal do projeto, ela necessria no devido momento.
O gerenciamento das comunicaes do projeto

Ele proporciona interfaces entre as pessoas, ideias e informaes que so necessrias para que o projeto tenha sucesso. Compreende a transmisso de mensagens com o uso adequado dos meios, aplicando o tipo e o estilo mais adequados para o momento. A publicao do PMI Roles and Responsibilities of the Project Manager afirma que o gerente do projeto deve ser um comunicador para os executivos, para a equipe do projeto e para todos os interessados no projeto. Ele deve prover direo, organizar reunies e retransmitir as informaes e ideias de/para todos os interessados. O gerente do projeto tem a responsabilidade de saber quais mensagens devem ser enviadas, para quem e em que momento, bem como traduzi-las para uma linguagem que todos possam compreender. A definio encontrada no Guia PMBOK que o gerenciamento das comunicaes do projeto um conjunto de processos necessrios para assegurar a gerao, a coleta, a divulgao, o armazenamento e a disposio final apropriada e oportuna das informaes do projeto. Ele estabelece vnculos importantes entre as pessoas, ideias e informaes necessrias para o sucesso do projeto. Todas as pessoas envolvidas no projeto devem estar preparadas para enviar e receber informaes e devem compreender tambm como as informaes em seu poder podem afetar o projeto como um todo. Os processos que compem o gerenciamento das comunicaes incluem: Planejamento da comunicao; Distribuio da informao; Relatrio do desempenho; Gerenciamento dos interessados.
- 26 -
Todos esto associados s habilidades de comunicao genricas, mas no significam a mesma coisa que elas. Estas aptides so consideradas parte da administrao geral que o gestor de projeto faz uso no seu dia-a-dia de trabalho. J os processos definidos pelo PMI cuidam da questo administrativa da comunicao: preparar um plano, execut-lo durante a execuo do projeto, manter os envolvidos informados do progresso, andamento e das tendncias (forecast). Tambm buscam garantir que todas as informaes necessrias pelo projeto, incluindo a planos de projeto, registros das reunies (atas), avaliaes dos riscos, documentaes tcnicas etc., sejam controladas e documentadas. Eles no se preocupam apenas com a documentao escrita, mas tambm como a informao de uma forma geral dever fluir e ser compartilhada no ambiente de projeto, minimizando assim os impactos causados por rudos e os mal-entendidos que podem levar os projetos ao fracasso. Neste mdulo, ser discutido o processo de planejamento da comunicao.
Planejamento das comunicaes

O objetivo do planejamento das comunicaes determinar quais sero as necessidades de comunicao dos interessados. O principal documento gerado por ele o plano de comunicaes, que indicar: quem precisar, qual a informao, quando, como ela dever ser fornecida e por quem. As necessidades de informao e os mtodos de distribuio variam muito de um projeto para outro. Para se fazer planejamento das comunicaes, necessrio conhecer como est estruturado o projeto e as organizaes que dele dependem. Ou seja, ele est estreitamente ligado ao planejamento organizacional porque a estrutura organizacional dos envolvidos tem um efeito importante sobre a comunicao do projeto. Dentre as diferentes estruturas organizacionais (projetizada, matricial e funcional), a comunicao ser mais complexa no ambiente matricial. Identificar as necessidades de informaes e a maneira de disponibiliz-las aos interessados considerado fator importante para o sucesso do projeto. Muitos executivos definem um bom gerente de projeto como aquele que os mantm informados e no aquele que resolve tudo sozinho. Todo projeto precisa de um bom plano de comunicao, mas nem todos podem contar com os mesmos tipos de comunicao ou os mesmos mtodos para a distribuio das informaes. O plano de gerenciamento das comunicaes documenta as necessidades de informao dos interessados, quando distribu-la e a forma como ser transmitida. Como as comunicaes nos projetos so complexas, um plano de gerenciamento das comunicaes deve estar por escrito na maioria dos projetos.
- 27 -
Ele deve abordar as necessidades de todas as partes interessadas. As informaes comunicadas normalmente abrangem: Andamento do projeto. Declaraes de escopo e suas atualizaes. Informaes projeto. Riscos, aes. Medidas de desempenho. Aceitao do projeto etc. Os interessados e sua necessidade em termos de comunicao devem ser identificados logo ao incio dos processos de planejamento, facilitando o desenvolvimento dos novos documentos. A elaborao de um plano de comunicao eficaz deve ter em mente atingir os seguintes propsitos: Garantir que informaes relevantes sejam disponibilizadas s partes interessadas na sequncia, no prazo e momento adequados. bsicas do
Identificar e indicar problemas potenciais, por meio de relatrios de damento (status report).
Facilitar a tomada de deciso e o controle das mudanas.
Oferecer um processo especfico para feedback e mecanismos para a resoluo de conflitos.
Melhorar e facilitar o trabalho em equipe, a cooperao e colaborao.
O Guia PMBOK recomenda que um plano de gerenciamento das comunicaes contenha os seguintes elementos: O que deve ser comunicado?
- 28 -
De que forma? Propsito da comunicao (por qu). Frequncia das comunicaes. Perodo de distribuio, incluindo datas de incio e trmino. Formato da comunicao e mtodo de transmisso. Pessoa responsvel pela distribuio da informao. As informaes a serem compartilhadas com os interessados e os mtodos de distribuio adotados dependem das necessidades dos stakeholders, da complexidade do projeto e das polticas organizacionais. Determinadas comunicaes podem ser informais, ao passo que outras devem ser escritas e manter uma cpia includa nos arquivos do projeto.
Resumindo
A palavra comunicao vem do latim (comunicare) e significa compartilhar, tornar comum. um esforo bidirecional que envolve a transmisso da informao utilizando um conjunto de smbolos de entendimento comum para uma ou mais pessoas (receptores), atravs de mecanismos (meios) adequados, e o posterior recebimento do feedback pelo emissor. O PMI destaca a importncia de uma comunicao efetiva, pois a maioria dos gerentes dos projetos concludos com sucesso gastou aproximadamente 90% do seu tempo envolvido em algum tipo de comunicao, seja ela escrita, falada, de forma verbal, no-verbal, com um estilo formal ou informal. Os gerentes devem saber aplicar os diferentes tipos e estilos de comunicao, assim como desenvolver um ambiente que propicie uma comunicao franca e aberta entre os participantes do projeto. Ento, comunicao de extrema importncia para o projeto e seu planejamento essencial. importante que o gerente de projeto reconhea a existncia das barreiras de comunicao e saiba como codificar sua mensagem, de forma a minimizar ou contornar os efeitos produzidos pelas barreiras. A comunicao quanto ao tipo pode ser classificada como verbal, que faz uso apenas da palavra, seja ela escrita ou falada, no-verbal, quando faz uso de sinais, e paralingustica, que faz uso de entonaes vocais. O gerenciamento das comunicaes do projeto proporciona interfaces entre as pessoas, ideias e informaes que so necessrias para que o projeto tenha sucesso. Compreende a transmisso de mensagens com o uso adequado dos meios, aplicando o tipo e o estilo mais adequados para o momento.
Riscos
No primeiro curso, quando foi apresentada a definio de projeto, aprendemos que cada projeto nico e possui certo grau de exclusividade. Isso faz com que os projetos
- 29 -
estejam repletos de incertezas e, no que se refere a tarefas futuras, com que os custos, a durao e o impacto sobre o fluxo de caixa no sejam completamente conhecidos. Os gerentes de projetos deveriam estar aptos a lidarem com elas, em todas as suas dimenses. Estes cenrios so facilitados por conta do ambiente em que vivemos hoje, o qual apresenta alta volatilidade e competitividade, desafiando a cada momento os objetivos do projeto. Muitos dos profissionais que gerenciam projetos dentro das organizaes aprenderam o ofcio como consequncia de um longo e caro processo na base de tentativas e erros. Falta a eles: o conhecimento conceitual das tcnicas, dos mtodos e das ferramentas que permitem a identificao e anlise de incertezas e de um mecanismo estruturado que auxilie neste ambiente; um processo que os prepare para encarar os mltiplos cenrios que se apresentam, facilitando a identificao; o aprendizado a partir de experincias passadas.
Conforme dito por George Santayana, "aqueles que no podem lembrar o passado so condenados a repeti-lo.
Objetivo
Conhecer: a definio de risco; as caractersticas dos riscos; a exposio ao risco; os benefcios do gerenciamento de riscos; o gerenciamento de riscos integrado ao planejamento do projeto; o planejamento do gerenciamento dos riscos; a identificao dos riscos; a anlise dos riscos; o desenvolvimento de respostas a riscos; o plano de gerenciamento de riscos; a responsabilidade pelo gerenciamento de riscos.
- 30 -
Definio de riscos
Risco um evento de condio incerta, ou seja, poder ou no ocorrer. No caso de sua manifestao, ter um impacto de efeito positivo ou negativo nos objetivos do projeto. Na verdade, os riscos so incertezas. Quanto mais conhecer sobre riscos e suas consequncias, mais preparado se est para lidar com eles, caso ocorram. Note que, na definio, claramente explicitado que h tanto um efeito positivo como um negativo. Risco uma palavra que assusta e imediatamente evoca uma imagem de algo ruim, mas importante lembrar que risco pode tambm fornecer benefcios. O gerenciamento de riscos, conforme o citado no Guia PMBOK, o processo de identificao, anlise, desenvolvimento de respostas e monitoramento dos riscos em projetos, com o objetivo de diminuir a probabilidade e o impacto de eventos negativos e de aumentar a probabilidade e o impacto de eventos positivos. Ou seja, um processo sistemtico que consiste em identificar as possveis incertezas e tentar control-las por meio das etapas: (1) identificar, (2) analisar e (3) responder ao risco do projeto. Os riscos se manifestam por vrios motivos, alguns so internos ao projeto e outros externos. O ambiente do projeto, o planejamento, o processo de gerenciamento, recursos inadequados, entre outros, podem contribuir nesse sentido. Se tudo fosse puramente uma questo de sorte ou azar, o gerenciamento de riscos no teria sentido e analisar tendncias tampouco. Um projeto que ultrapasse seu oramento, no entregue dentro do prazo ou faz uso dos recursos financeiros fora das datas estabelecidas coloca em perigo os processos organizacionais que dependam da sua concluso. Comentar sobre risco falar sobre: A identificao de fatores que podem afetar o sucesso de um projeto; A probabilidade deles assumirem valores que venham prejudicar ou favorecer, total ou parcialmente, o projeto; As consequncias destes fatores assumirem aqueles valores em particular. Portanto, um risco tem trs caractersticas que o definem:
um evento que se pode definir. O evento o fato que pode ocorrer, tanto bom como ruim. Lembre-se de que risco por si mesmo uma palavra neutra: pode ser algo devastador; poderia se constituir numa oportunidade para melhorar a capacidade e o lucro da organizao. No importa a condio, o evento de risco o que pode acontecer ao projeto. H uma probabilidade de que ele ocorra.
- 31 -
A probabilidade do risco simplesmente definida como as chances que o evento tem de ocorrer. Claramente, pode haver um evento potencial, mas se as chances de que ele ocorra forem quase nulas, ento no realmente um risco na prtica, importante considerar este aspecto. H uma consequncia ou impacto para o projeto, caso ele se manifeste. As consequncias de o evento acontecer so mensuradas em termos de seu impacto no projeto. H um evento de risco identificado, com alta probabilidade de acontecer; mas, se o impacto (mesmo que ele ocorra) for baixo, ele pode ser ignorado ou pelo menos tolerado. Com estas caractersticas assim descritas, o teor de exposio ao risco, no projeto e na organizao, pode ser determinado. Observe que nesses componentes possvel notar que a probabilidade est diretamente associada causa, assim como o efeito est para o impacto. Isso significa que, se forem tomadas aes sobre a causa, ser afetada a probabilidade e, se forem sobre o efeito, o impacto que sofrer alterao. Um dos desafios que o gerente e a equipe de projetos enfrentam definir risco. Embora estejamos oferecendo uma definio e descrevendo suas caractersticas, a realidade que cada pessoa tem sua prpria viso de risco. Por exemplo, se algum pergunta qual o risco?, estar pedindo uma descrio do evento. Outra faria a mesma pergunta e estaria se referindo ao impacto ou exposio de sua organizao. Assim sendo, imperativo que o gerente do projeto seja bem experiente no assunto e particularmente inclinado a determinar exatamente o que a pessoa quer saber.
Exposio ao risco
Este conceito outra forma de descrever o impacto da ocorrncia de um evento de risco. Ela determinada multiplicando-se a probabilidade pelo impacto. Colocando de outra forma: a maioria dos gerentes de projeto iguala a exposio ao risco ao valor esperado (que uma medida comum usada em avaliao de risco e qualidade e ser tratado posteriormente).
- 32 -
Quando um executivo questiona qual nossa exposio ao risco?, o interesse dele est em determinar qual seria o custo disso para o projeto. O risco uma funo de seu impacto versus a probabilidade
Benefcios do gerenciamento de riscos

Minimizar gerenciamento por crises Quando um evento de risco ocorre, h sempre uma resposta reativa se o risco no foi previsto.
Minimizar surpresas e problemas Como voc vai logo descobrir, identificar o risco e planejar-se para ele a melhor maneira de evitar surpresas. Como diz o adgio, no ser pego de calas curtas.
Ganhar vantagem competitiva Todo processo de risco bem desenvolvido, documentado e implementado, reduz impactos de eventos de risco no cronograma e no custo, melhorando a vantagem da organizao diante do mercado.
Diminuir varincias do projeto em geraL Um dos maiores problemas do gerenciamento de projeto manter o progresso do projeto dentro das varincias de custo e prazo planejadas.
- 33 -
O gerenciamento de riscos uma das principais formas para manter essas variaes dentro da tolerncia. Caso o risco se manifeste, a resposta ser aplicada, garantindo a manuteno do planejado.
Aumentar a probabilidade de sucesso Manter o projeto dentro do cronograma e oramento planejados garante que ele seja concludo com sucesso.
Aumentar a lucratividade Um planejamento de risco ineficiente leva ao retrabalho, a desvios no cronograma e ao aumento nos custos, enquanto um eficiente minimiza estes problemas, contribuindo diretamente para um excelente resultado final.
A responsabilidade pelo gerenciamento de riscos

O gerente do projeto que tem a responsabilidade final pelo gerenciamento de riscos em seu projeto. No recomendvel que este papel seja delegado a uma pessoa em especial ou a um grupo, porque a tendncia presumir que algum est resolvendo os problemas de risco, quando, na verdade, isso pode no estar acontecendo. No entanto, isso no significa que o gerente do projeto no possa designar lderes de tarefas ou outros membros da equipe para se encarregarem da observao de riscos potenciais, identificados em suas tarefas, e implantarem resposta estratgica ao risco, caso venha a ocorrer. O gerente do projeto responsvel pela iniciao e liderana do processo de riscos. Isso feito pela integrao de um plano de gerenciamento de riscos no plano do projeto, garantindo ento que cada membro da equipe esteja familiarizado com os riscos identificados e cientes de quando podem ocorrer durante o projeto, que tarefas seriam afetadas e qual a estratgia de reao a ser adotada. Os membros da equipe do projeto so responsveis por: garantir o desempenho do processo de gerenciamento de riscos; observar os indicadores de que o evento possa ocorrer; implementar estratgias apropriadas de reao ao risco;
- 34 -
relatar o status do risco ao gerente do projeto, atividade considerada como uma das mais importantes.
O gerenciamento de riscos integrado ao planejamento do projeto

O gerenciamento de riscos tem de ser executado em todo o ciclo de vida do projeto. A identificao de eventos potenciais de risco comea durante os estgios iniciais do planejamento do projeto. H diversas etapas no processo de planejamento de risco e cada uma delas discutida a seguir. importante lembrar que este procedimento no pode ser executado isoladamente; deve ser feito de forma completa, sendo cada etapa reavaliada toda vez em que o risco seja considerado durante o projeto. As etapas do processo de risco so divididas em: 1. Identificao dos fatores de risco. 2. Quantificao do impacto e da probabilidade de ocorrncia. 3. Desenvolvimento de respostas ou aes que favoream os objetivos do projeto. 4. Aplicao e controle das respostas durante a execuo do projeto. Estas so as etapas importantes que sero abordadas, discutindo os seus resultados e como obt-los. O detalhamento do assunto pode ser obtido em treinamentos mais avanados ou consultando a bibliografia sugerida. As trs primeiras etapas so realizadas durante o planejamento do projeto. Elas esto documentadas no Guia PMBOK por meio dos seguintes processos de planejamento: Planejamento do gerenciamento dos riscos. Identificao dos riscos. Anlise qualitativa dos riscos. Anlise quantitativa dos riscos. Planejamento de respostas a riscos. A quarta etapa ser abordada no Monitoramento e controle do projeto.
- 35 -
1-Planejamento do gerenciamento dos riscos
Categorias de risco Esta a primeira etapa do processo. O Guia PMBOK o define como deciso de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto. Ele deve ser completado, de maneira que a anlise e planejamento de riscos no se tornem reflexo posterior ao projeto. importante separar tempo e processos para planejar os riscos do projeto. Isso pode ser feito pela realizao de uma reunio da equipe, tratando especificamente de questes de risco. A agenda para a reunio deve incluir: Anlise de lies aprendidas de projetos similares. Reviso de todos os documentos dos projetos (declarao de trabalho, contratos, especificaes, grficos de disponibilidade de recursos etc.) para garantir que a equipe esteja ciente de todas as fontes de risco em potencial. Concluir com um acordo a respeito do processo que ser seguido e das ferramentas e tcnicas que sero adotadas no planejamento dos riscos associados ao projeto em questo. Os fatos aqui so: Como se preparar para os riscos do projeto. Qual metodologia de trabalho ser utilizada. Assegurar que o nvel, tipo e a visibilidade do gerenciamento de riscos estejam de acordo com o risco e a importncia do projeto em relao organizao, para fornecer tempo e recursos suficientes para as atividades de gerenciamento de riscos e para estabelecer uma base acordada de avaliao de riscos. Portanto, o esforo dedicado ao seu gerenciamento deve ser condizente ao tamanho, complexidade do projeto e, principalmente, experincia e s habilidades da equipe do projeto.
- 36 -
O resultado do processo um plano de gerenciamento de riscos, que est includo no plano geral do projeto. Os pontos a destacar neste plano so a categorizao dos riscos e a questo da tolerncia e percepo dos interessados aos riscos. Representam uma forma de identificar os riscos de uma maneira sistemtica e servem de base para a sua compreenso. O uso dessas categorias contribui para a eficcia e qualidade do processo, ou seja, melhora a determinao e identificao de riscos, pois estabelece uma linguagem comum de descrio destes para todos os envolvidos. Existem diversos modelos de categorias de risco. O Guia PMBOK sugere um modelo que inclui as seguintes: Riscos de gerenciamento do projeto incluem o planejamento incorreto do cronograma e recursos, projetos mal planejados, disciplinas ou metodologias de gerenciamento de projeto inadequadas e desconhecimento do assunto pelo gerente de projetos e partes interessadas. Riscos tcnicos, de qualidade ou desempenho incluem aqueles associados s tecnologias desconhecidas/complexas ou a modificaes tecnolgicas previstas no decorrer do projeto. Um exemplo tpico so as constantes verses de hardware e software que prometem compatibilidade com a verso anterior, mas quase nunca cumprem. Os riscos de desempenho incluem objetivos de performance pouco realistas. Riscos organizacionais aqui podem ser citados os conflitos de recursos decorrentes de projetos ocorrendo simultaneamente na organizao; objetivos de escopo, tempo e custos pouco realistas em relao aos recursos ou estruturas reais da organizao. Riscos externos nessa categoria entram fatores externos ao projeto, tais como dificuldades trabalhistas, questes polticas e climticas, novas legislaes ou regulamentaes. Os riscos catastrficos conhecidos como fora maior em geral ficam fora do escopo do gerenciamento de riscos, pois envolvem tcnicas de recuperao de desastres. A se incluem eventos da natureza de grande impacto, tais como terremotos, furaces, tornados, erupes vulcnicas, inundaes, agitaes sociais, terrorismo etc. Outros formatos muitos gerentes classificam os riscos de acordo com as diferentes reas de conhecimento, por exemplo: risco de escopo, de prazo, de custo, qualidade etc.
Tolerncia dos interessados ao risco Cada atividade tem um benefcio e/ou uma utilidade que so percebidos e tolerados de modo diferente por pessoas diferentes. O mesmo resultado pode ser mais til para uma pessoa do que para outra. Exemplo: para algumas pessoas, andar de elevador pode ser um risco alto (percepo) e que no seria tolerado, portanto, a atividade deve ser evitada. J
- 37 -
para outras pessoas, isso pode ser uma atividade absolutamente normal que no oferece nenhum tipo de ameaa, sendo tolerada. importante que o gerente de projetos identifique e documente a percepo e a tolerncia ao risco dos principais interessados no projeto. Lembre-se de que elas mudam ao longo do projeto, por serem afetadas por inmeros fatores, por isso, mantenha controle sobre este item durante todo o projeto, e no apenas no seu incio.
2 - Identificao dos riscos

Este o passo mais importante de um bom gerenciamento de riscos, sendo vital para todos os demais processos. Se no souber quais so as ameaas ao projeto, como se preparar para elas? comprovadamente a etapa mais importante por diversas razes: uma das funes iniciais que o gerente do projeto deve desempenhar; se o gerente e a equipe do projeto no identificarem riscos, eles no podem tomar as medidas reativas que sejam necessrias; o simples fato de se identificarem riscos comea a reduzir, desde o comeo, a possibilidade de sua ocorrncia. Albert Einstein tem uma citao que tem muito a ver com a questo dos riscos desconhecidos: Eu no me preocupo com as coisas que sei que no sei. Eu s me preocupo com as coisas que no sei que no sei. Porque as coisas que sei que no sei, fcil s procurar que vou saber. Porm, as coisas que no sei que no sei, no tenho nem por onde comear! (Einstein, circa 1940) Portanto, para transformar as coisas que no sei que no sei (desconhecidodesconhecido), importante ter um bom processo de identificao dos riscos. O objetivo identificar e documentar todos os riscos capazes de afetar o projeto e document-los, bem como as suas caractersticas. um processo iterativo, envolvendo tcnicas de dinmicas de grupo, pois as pessoas tm percepes e tolerncias diferentes. A identificao de riscos continua a ser importante ao longo de todo o projeto. Apesar da fase inicial do planejamento de projeto ser o melhor momento para se identificarem riscos, no somente nela que isso deve acontecer, mas sim em toda a vida do projeto,
- 38 -
de forma contnua. Somando-se a isso, a listagem inicial de riscos deve ser usada e atualizada at que o projeto seja concludo. O resultado do processo uma lista de eventos de risco especificamente descritos. Devem ser colocados desta forma: 1. Algo que pode ou no acontecer. 2. 3. Em um tempo especfico determinado. Causando um impacto particular ao projeto.
Por exemplo, se responsveis pela validao de software no estiverem disponveis, os testes no podero ser conduzidos, resultando em atrasos no cronograma. Vale ressaltar que neste momento as declaraes no quantificam a probabilidade e o impacto. Estes sero determinados nos processos de anlise qualitativa e quantitativa, realizados aps a identificao dos riscos. Como identificar riscos? Conforme explicado anteriormente, a identificao de riscos um processo que utiliza dinmicas de grupo, e deve seguir diretrizes para descrever os eventos de risco, pois a eficincia deste processo se relaciona diretamente exatido desta descrio. Se eles no forem especificados, como a equipe do projeto poder desenvolver uma reao ao risco? Como a organizao ser capaz de usar as lies aprendidas no futuro? As diretrizes para identificao e descrio incluem o seguinte: Apontar o evento que pode acontecer, quando provvel que ocorra e qual o impacto que ele ter. Por exemplo, no projeto de construo de um quiosque de auto-atendimento, o fornecedor do vidro resistente a temperatura difcil de ser encontrado poderia deixar o negcio antes de entregar o produto e assim causar atrasos no cronograma. Identificar os riscos relacionados aos pacotes de trabalho da EAP uma boa alternativa. Isso garante a cobertura de todos os riscos significativos e facilita a anlise de seus efeitos potenciais no custo e no cronograma do projeto. Ao identificar riscos, seja abrangente, mas no absurdo. fcil comear um processo de brainstorming sobre riscos, baseado em cada pacote da EAP, desenvolvendo uma longa lista de riscos insignificantes. A identificao deve focar os itens que tenham uma probabilidade de ocorrer e um impacto razovel sobre o projeto. O processo de identificao de riscos deve ser concludo pela equipe em um trabalho de grupo, e no de forma individual.
Existem inmeras ferramentas e tcnicas utilizadas para a identificao dos riscos, que ajudam a equipe do projeto no processo. Incluem o seguinte:
- 39 -
Entrevistas com especialistas este mtodo comea com a identificao das pessoas adequadas entrevista. No considere somente aqueles indivduos que tm conhecimento pertinente. Convide tambm pessoas que desejam voluntariamente partilhar informaes na entrevista.
Tcnica Delphi a forma mais envolvente de tcnicas de entrevista de especialistas. A origem de seu nome devida a um orculo grego que ficava aos ps do Monte Parnaso, cuja predio mais famosa foi a de que dipo mataria seu pai e se casaria com sua me. A tcnica busca alcanar um consenso de especialistas que participam de forma annima e remota. O questionamento enviado por um moderador para os participantes, suas respostas so compiladas e os dados so redistribudos para revises adicionais, at que um resultado seja alcanado. Brainstorming tcnica bastante aplicada, relatada anteriormente. Implica reunir em um local um pequeno grupo de pessoas (em geral de sete a dez), especialistas no assunto, incluindo indivduos de fora do projeto (pelo menos duas). O fundamento por detrs desta tcnica que a ideia de um pode inspirar outra e assim por diante, de modo que, at o final da sesso, voc tenha identificado todos os riscos possveis. Tcnica de Grupo Nominal similar ao brainstorming e tcnica Delphi, mas aqui a participao mais silenciosa no sentido que coleta informaes extras buscando insights de outras pessoas. Usa grupos que esto fisicamente prximos, como no brainstorming, porm similar tcnica Delphi no que tange ao pensamento individual e ao registro de informaes por escrito. Um grupo pequeno de cinco a sete pessoas o tamanho ideal da equipe.
Ferramentas e tcnicas para identificar riscos Anlise SWOT (foras, fraquezas, oportunidades e ameaas) tcnica que avalia o projeto para identificar seus pontos fortes, fracos, quais oportunidades podem ser perseguidas e quais so as fraquezas. muito utilizada na avaliao inicial dos projetos. Analogia busca em projetos similares eventos de risco que tenham acontecido e baseia-se no processo de lies aprendidas. O fundamento deste processo to antigo quanto o livro de Eclesiastes, na Bblia, em seu captulo 1, versculo 9: O que tem sido, isso o que h de ser; e o que se tem feito, isso se tornar a fazer; nada h que seja novo debaixo do Sol. Na verdade, poucos processos so totalmente nicos. Mesmo o projeto Apolo de ida Lua usou tecnologia j existente e previamente implementada.
- 40 -
Checklists, questionrios e modelos so ferramentas adicionais que, como no processo de analogia, baseiam-se na ideia de que nenhum projeto novo representa um conjunto de riscos completamente novo. Pessoas e companhias frequentemente compilam listas de riscos que ocorreram em projetos anteriores, e ento criam checklists, questionrios e modelos extrados destas listas. Organizaes e associaes do ramo tambm produzem tais tipos de informao.
As ferramentas e tcnicas apresentadas so todas comprovadas e cada uma delas tem diferentes aspectos na exposio dos riscos, permitindo que a equipe do projeto identifique-os de formas diferentes. O gerente do projeto deve ser cuidadoso ao escolher a ferramenta mais adequada para cada situao. Para saber mais sobre elas, consulte a bibliografia sugerida.
3- Analisando os riscos
Um dos resultados mais importantes no gerenciamento de riscos decidir o que deve ser feito com eles, em outras palavras, como reagir aos riscos. Infelizmente, no possvel tratar de todos. Isto ficaria muito dispendioso e demorado para o projeto. Em funo disto, necessrio identificar aqueles que realmente merecero a ateno do gerenciamento. Provavelmente, a identificao no mais difcil no planejamento do que determinar como atribuir algum valor, numrico ou de outra natureza, para o evento de risco. Sem uma forma de quantificar este aspecto, impossvel analisar o impacto dele sobre o projeto e determinar uma prioridade e relevncia necessria para um gerenciamento eficiente. A informao sobre riscos em geral apresentada em uma destas trs formas ou em uma combinao das mesmas: Narrativa Tipo de informao que, em alguns aspectos, til, pois oferece um jeito fcil de coletar dados sobre um evento de risco. Por exemplo, uma pessoa pode fornecer uma descrio completa de um risco potencial, sua fonte e o que deve ser feito para prevenir e controlar. A maior desvantagem deste formato que no contempla ferramentas para mensurar a probabilidade do risco ou seu impacto no projeto. Qualitativa A informao qualitativa faz uso de termos como alta, mdia ou baixa, para descrever a probabilidade e/ou o impacto da ocorrncia de eventos de risco. Este formato de apresentar a informao sobre os riscos melhor do que a narrativa, para explicar a severidade do impacto destes. Entretanto, este formato tem suas limitaes. Descrever um evento de risco como tendo uma probabilidade mdia de ocorrncia d uma ideia de sua grandeza, mas deixa uma vasta gama de possibilidades a serem consideradas. O que mdio? Quanto vale?
- 41 -
Os termos alta, mdia e baixa so muito subjetivos. Um risco alto para uma pessoa pode ser um risco mdio para outra. Mesmo na forma qualitativa de apresentao, mais prtico se a sua escala seja definida mais quantitativamente. Por exemplo, definir riscos baixos como sendo aqueles que esto entre zero e 20% de probabilidade de ocorrncia esclarece o que significa baixo risco. Contudo, ainda melhor usar um nmero especificamente quantificado do que uma escala (0% a 20%). Quantitativa Em uma anlise quantitativa, nmeros so usados para a avaliao de probabilidade (em percentuais, onde 0% e 100% esto descartados, pois representam respectivamente nenhuma chance de ocorrncia e ocorrncia garantida) e impacto. Isto til por duas razes importantes: Atribuir um nmero probabilidade de risco permite que sejam usadas mais ferramentas para avali-lo. Quantificar a probabilidade de risco fornece mais objetividade sua avaliao.
Gostando ou no, temos de entender que sempre haver certa subjetividade ao se atribuir probabilidades s ocorrncias de risco, mas existem ferramentas poderosas que ajudam a mitigar riscos, se primeiro pudermos quantific-los. Uma apresentao quantitativa de risco aquela associada a nmeros. Por exemplo, se podemos dizer que um evento tem 15% de probabilidade de ocorrncia e que seu impacto teria um custo de $10,000 para o projeto, ento ns teremos definido o risco quantitativamente. Da mesma forma que na anlise qualitativa, difcil atribuir uma probabilidade exata a um evento de risco; uma questo de experincia, opinio de especialistas, lies aprendidas etc. Quanto melhor as informaes histricas, mais exatas as avaliaes de probabilidade e impacto sero. O resultado deste processo ter uma listagem de riscos priorizados e classificados. A organizao poder decidir quais deles tero respostas. Quando eles so analisados de forma quantitativa, o valor do risco calculado multiplicando-se a probabilidade versus o impacto. Este conceito conhecido por valor monetrio esperado. Por exemplo: em um evento A existem 40% de chances de que o programa no seja aprovado nos testes e isso causaria o impacto de R$ 200.000,00. O valor em risco ser de R$ 200.000,00 x 0,4 = R$ 80.000,00. Em um evento B, existem 80% de chances de que ocorra um atraso na entrega do produto, causando assim um impacto de R$ 50.000,00. O seu valor monetrio esperado ser de R$ 40.000,00. Se for possvel escolher apenas um risco, o evento A seria o escolhido.
- 42 -
4- Desenvolvimento de resposta a riscos

Aps finalizar a anlise e priorizao de riscos, o gerente do projeto conduz a equipe no planejamento de estratgias de resposta a riscos. Isso envolve definir o que deve ser feito em relao a cada risco principal. O procedimento exige a avaliao das opes de resposta e a documentao das estratgias a serem adotadas. Para realizar esta funo, o gerente do projeto deve conhecer todos os tipos de resposta a riscos e escolher a que melhor se adapte, baseado na natureza dos riscos envolvidos. Esta parte do processo pode ser considerada como uma tentativa de responder a questes como: A ameaa: Pode ser aceita? Pode ser evitada ou minimizada? Pode ser transferida para outra parte? A oportunidade: Pode ser ignorada? Pode ser maximizada? Gatilho de risco Como os riscos nem sempre ocorrem isoladamente, uma estratgia de resposta a um risco pode afetar outros, aumentando-os ou tornando-os mais tolerveis. Elas podem tambm criar um risco inteiramente novo. Portanto, aps tomar decises preliminares sobre a resposta, o gerente do projeto deve conduzir uma avaliao de seus efeitos nos demais riscos do projeto. A avaliao de cada estratgia em relao outra deve continuar at se definir um conjunto adequado. Este deve ser incorporado ao plano de gerenciamento de riscos. A documentao de todas as opes de resposta deve ser reservada, independentemente do conjunto escolhido. Se a resposta escolhida falhar, a equipe do projeto ir examinar a documentao, reavaliar suas opes e substitu-las por outra resposta de risco. Estratgias de resposta para ameaas Considerando-se os riscos para ameaas, h quatro tipos de estratgias de respostas ao risco que podem ser usadas, de acordo com o Guia PMBOK: preveno, transferncia, mitigao, aceitao.
Preveno: a resposta mais direta ao risco. Significa eliminar o risco ou, no mnimo, a possibilidade de ter qualquer impacto sobre o projeto.
- 43 -
Como possvel evitar um risco? Por exemplo, substituir um produto mais sofisticado e no testado previamente por um componente mais simples e testado. Isso pode eliminar a possibilidade de atrasos em um projeto de integrao de sistemas. Em geral, qualquer risco significativo deve ser evitado se a abordagem de preveno for relativamente simples e no tiver outros efeitos adversos. Transferncia Diferente da preveno, a transferncia no elimina o risco. Em vez disto, transfere o risco e a responsabilidade de reao para outros. A transferncia envolve algum tipo de relacionamento legal ou contratual. O mais bvio o seguro de responsabilidade, por exemplo, transferir o risco de dano propriedade para uma companhia de seguros. Ao adotar este tipo de estratgia, lembre que ela provavelmente no ser gratuita. A parte para quem o risco transferido negociar algo em troca, isso normalmente significa alguma forma de pagamento.
Mitigao Mitigar significa tanto reduzir a probabilidade da ocorrncia do risco quanto minimizar seu impacto. Em outras palavras, a tentativa de reduzir a exposio a um risco alto demais para ser aceito. A probabilidade da ocorrncia de um evento de risco pode ser reduzida usando tcnicas similares s adotadas na preveno. Por exemplo, utilizar abordagens mais simples ou acrescentar recursos ao projeto pode minimizar problemas. A diferena entre preveno que as chances de ocorrncia do evento de risco so apenas reduzidas, mas no eliminadas em definitivo. Aceitao s vezes um gerente de projeto deve aceitar a ameaa de um risco simplesmente porque no h estratgias disponveis para enfrent-la. Em outro momento, ele pode decidir aceit-la por ser a abordagem mais sensata. Isto deve ocorrer se a anlise de todas as estratgias anteriormente apresentadas revelarem que seus custos sero mais altos do que o do risco tolerado. Em qualquer caso, o gerente de projeto e a organizao devem estar preparados para as consequncias do evento aceito, caso ocorra. H, no entanto, mais de um modo de aceitar um risco. Conforme explicado no Guia PMBOK, o risco pode ser aceito ativa ou passivamente. A aceitao passiva significa que nada ser feito para se preparar antecipadamente para o risco, ele ser enfrentado se e quando ocorrer.
- 44 -
A aceitao ativa significa que o risco aceito quando ele ocorre, porm um plano de contingncia foi elaborado antecipadamente para este momento. Isto pode ser feito com a reserva de alguma quantia em dinheiro ou com recursos a serem usados quando o risco ocorrer. Estratgias de resposta para oportunidades Da mesma forma que as ameaas, as oportunidades tambm podem ser enfrentadas usando-se vrias estratgias de resposta. As abordagens bsicas incluem as seguintes: ignorar, melhorar e buscar. As estratgias para se lidar com as oportunidades so conceitualmente opostas s correspondentes para enfrentar as ameaas. Buscar: o oposto a prevenir uma ameaa, pois deve garantir que o evento ocorra, em vez de que no ocorra. Melhorar: significa tentar aumentar o valor esperado. oposto mitigao, porque se tenta aumentar em vez de diminuir tanto a probabilidade e/ou o impacto da oportunidade. Ignorar: significa escolher no fazer nada a respeito de um risco desejvel, corresponde a aceitar a ameaa. Voc simplesmente decide lidar com o assunto se e quando surgir.
Plano de gerenciamento de riscos
O plano de gerenciamento de riscos o resultado final de todo o trabalho de resposta ao risco. Deve conter os resultados dos passos precedentes de identificao, anlise e priorizao de riscos. So documentadas quais respostas sero dadas para se gerenciar os vrios riscos, como sero implementadas e quem ser responsvel por cada uma delas. Finalmente, o plano de gerenciamento de riscos deve especificar como as reservas sero usadas e quem gerenciar seu uso.
Resumindo
Risco um evento de condio incerta, poder ou no ocorrer. No caso de sua manifestao, ter um impacto de efeito positivo ou negativo nos objetivos do projeto. Quanto mais conhecer sobre riscos e suas consequncias, mais preparado se est para lidar com eles, caso ocorram. Na definio, explicitado que h tanto um efeito positivo como um negativo. importante lembrar que risco pode tambm fornecer benefcios. O gerenciamento de riscos, conforme o Guia PMBOK, o processo de identificao, anlise, desenvolvimento de respostas e monitoramento dos riscos em projetos, com o objetivo de diminuir a probabilidade e o impacto de eventos
- 45 -
negativos e de aumentar a probabilidade e o impacto de eventos positivos. Ou seja, um processo sistemtico que consiste em identificar as possveis incertezas e tentar control-las por meio das etapas: (1) identificar, (2) analisar e (3) responder ao risco do projeto. Os riscos se manifestam por vrios motivos, alguns so internos ao projeto e outros externos. O ambiente do projeto, o planejamento, o processo de gerenciamento, recursos inadequados, entre outros, podem contribuir nesse sentido. Se tudo fosse puramente uma questo de sorte ou azar, o gerenciamento de riscos no teria sentido, e analisar tendncias tampouco. Um dos desafios que o gerente e a equipe de projetos enfrentam definir risco, pois cada pessoa tem sua prpria viso de risco. O gerente do projeto responsvel pela iniciao e liderana do processo de riscos. Isso feito pela integrao de um plano de gerenciamento de riscos no plano do projeto, garantindo, ento, que cada membro da equipe esteja familiarizado com riscos identificados e ciente de quando podem ocorrer durante o projeto, que tarefas seriam afetadas e qual a estratgia de reao a ser adotada. O plano de gerenciamento de riscos o resultado final do trabalho de resposta ao risco. Deve conter os resultados dos passos precedentes de identificao, anlise e priorizao de riscos. So documentadas quais respostas sero dadas, para se gerenciar os vrios riscos, como sero implementadas e quem ser responsvel por cada uma delas. Finalmente, o plano de gerenciamento de riscos deve especificar como as reservas sero usadas e quem gerenciar seu uso.
Aquisies
Cada vez mais as organizaes esto focadas em sua linha de negcios e no mantm mais em seus quadros certas especializaes que no fazem mais parte dessa linha. Isso faz com que os profissionais necessrios para o projeto sejam terceirizados. Surge ento a necessidade de uma gesto que tenha a preocupao de: Decidir se para uma determinada parte do projeto deve ser feita a contratao ou o projeto utilizar recursos j disponveis internamente; Preparar um documento de aquisio que detalhar o que ser contratado e quais critrios sero adotados para escolha do fornecedor, assim como modalidades de contratao e pagamentos; Determinar quais documentos devem ser preparados para se fazer a contratao e disponibiliz-los para os candidatos; Solicitar e avaliar as propostas de cada proponente.
Objetivo
Conhecer:
- 46 -
Como planejar compras e aquisies; Sobre fazer ou comprar? (make or buy?); Os tipos de contratos; O plano de gerenciamento das aquisies e a declarao do trabalho; Como planejar contrataes.
O PMI define o gerenciamento de aquisies do projeto como os processos exigidos para comprar ou adquirir os bens e servios necessrios para desempenhar o trabalho. Bens e servios so tipicamente referidos como produto e so obtidos fora da organizao executora. tambm objetivo deste gerenciamento a construo e a manuteno de relaes comerciais slidas e equilibradas entre cliente e fornecedor, permitindo assim a concluso do projeto com sucesso. Neste curso, o gerenciamento de projeto visto na perspectiva do comprador na relao entre comprador e fornecedor. Geralmente, o fornecedor chamado de subcontratado, vendedor ou terceiro e, normalmente, gerencia seu trabalho no projeto.
Aquisies X Contratos
Muita gente conhece gerenciamento das aquisies por gerenciamento de contratos. Gerenciamento de contratos so instrumentos que possibilitam, sob o ponto de vista legal, firmar acordo entre cliente e fornecedor, sendo uma forma de garantir que as partes, que concordaram em trocar produtos e servios por dinheiro (tecnicamente, isso chamado de considerao), cumpram o acordo final. Os termos e as condies de um contrato so a principal entrada para os processos do vendedor, descrevem os principais marcos, entregas e objetivos ou, ainda, podem ser uma restrio, pois limitam as opes da equipe do projeto (por exemplo, solicitando a aprovao do comprador para decises ou mudanas de pessoal). Contratos so passveis de execuo em um Tribunal de Justia e garantem que o resultado seja entregue e que o dinheiro seja pago. O gerenciamento das aquisies na viso do Guia PMBOK se constitui por dois processos: Planejar compras e aquisies. Planejar contrataes.
- 47 -
Planejar compras e aquisies

Determina se algo deve ser contratado (aquisio de recursos e/ou materiais) ou produzido internamente, alm de definir o que adquirir e quando (Guia PMBOK, seo 12.1). Identifica os bens ou servios a serem comprados fora da organizao e as necessidades do projeto que podem ser atendidas pela equipe. Isto feito durante o esforo de definio do escopo e envolve a determinao de adquirir ou no, como adquirir, o que adquirir, quanto adquirir e onde adquirir. O documento declarao do escopo do projeto proporciona informaes importantes sobre as necessidades e estratgias do projeto que devem ser consideradas durante o planejamento. Ela tambm fornece a lista de entregas e critrios de aceitao do projeto e seus produtos, servios e resultados. Se a deciso tomada a de no obter produtos e servios de fora da organizao executora, os demais processos do gerenciamento da aquisio no sero desempenhados. As aquisies influenciam o cronograma do projeto e vice-versa. Por exemplo, a disponibilidade de um fornecedor ou de materiais pode causar um impacto significativo no cronograma e na estimativa de recursos e das duraes da tarefa.
Uma preocupao que o gerente do projeto deve ter quanto a aquisies so as polticas e normas relacionadas a compras na organizao, porque muitas vezes elas podem causar impacto no planejamento. A organizao pode, por exemplo, exigir que sejam seguidos procedimentos de aprovao de compras quando ultrapassarem determinados limites. Outro cuidado quanto aos riscos que surgem, que muitas vezes influenciam o tipo de contrato que ser adotado na negociao com o fornecedor.
Fazer ou comprar? (Make or buy?)

Esta pergunta nem sempre relevante para o projeto, mas em alguns casos pode se aplicar a determinados aspectos dele.
- 48 -
A questo : os produtos ou servios necessrios ao projeto devem ser feitos ou adquiridos? Decidir sobre isso um aspecto fundamental do gerenciamento, esta uma ferramenta essencial do processo. Dependendo das condies, mais barato comprar embora em outras faa mais sentido elaborar uma soluo interna. Essa deciso pode ser tomada no nvel do recurso individual, para uma entrega inteira ou mesmo para o projeto em si. Fazer ou comprar deve ser preferencialmente feito no incio da definio do escopo para que seja determinado se o projeto inteiro deve ser executado internamente ou contratado. medida que o projeto evoluir, decises de fazer-ou-comprar adicionais podem ser necessrias. Existem vrios fatores que devem ser considerados com respeito a essas decises. Obviamente que o fator principal o custo. Voc deve consider-los para gerar o produto ou servio: Produtos, materiais, equipamentos, instalaes, salrios dos empregados; custos indiretos. Estes incluem itens como custos de treinamento, custos de gerenciamento, despesas administrativas (o custo de comprar) e manuteno permanente. importante observar que o custo no deve ser o nico fator a ser considerado nas decises make or buy. Leve em considerao itens como controles de processos, segredos comerciais, habilidades, treinamentos, riscos de se ter outra organizao envolvida no dia-a-dia da empresa, questes de capacidade e disponibilidade. Estes so pontos que devem ser avaliados antes que a deciso seja tomada.
Tipos de contratos
Se a deciso de comprar foi tomada, importante que seja definido tambm como sero as condies comerciais, portanto devem ser avaliadas as diferentes modalidades contratuais. Elas incluem desde contratos de preo fechado que minimizam o risco do cliente, pois o preo determinado e fixo, independentemente dos cenrios que porventura surjam, at contratos onde o cliente deve reembolsar todos os custos do fornecedor e ainda lhe pagar um adicional a ttulo de comissionamento. Obviamente que isso traz para o cliente a maior parcela de risco do contrato. Outro tipo de contrato bem popular o de preo unitrio (chamado de Time & Material). Comumente
- 49 -
negociado um valor por hora trabalhada. Aqui o risco corre por conta do comprador, pois na maioria das vezes a quantidade total de horas no conhecida. Para maiores informaes sobre as diferentes modalidades contratuais envolvidas no processo de aquisies, recomendamos consultar a bibliografia sugerida. O processo de planejar as compras e aquisies tem como um dos resultados um plano para gerenciar as aquisies que, de acordo com o Guia PMBOK, descreve como os processos de aquisio sero gerenciados desde o desenvolvimento da documentao de aquisio at o encerramento do contrato. O plano de gerenciamento de aquisies pode incluir, dentre outros: Tipos de contratos a serem usados, quem deve preparar estimativas independentes (ter uma ideia de quanto custa) e se elas so necessrias como critrios de avaliao; As aes que a equipe de gerenciamento de projetos poder tomar sozinha (nvel de autoridade em aquisies); Documentos de aquisio padronizados, caso sejam necessrios; restries e premissas que poderiam afetar as compras e aquisies planejadas.
Plano de gerenciamento das aquisies e a declarao do trabalho

Outro item importante a declarao de trabalho, abordada no grupo de processos de iniciao. Ela dever conter uma descrio do item a ser comprado em detalhes suficientes que permita aos potenciais fornecedores tomar a deciso de participar ou no da oferta. Uma declarao de trabalho deve ser redigida de forma clara e concisa evitando ambiguidades, contendo, entre outras informaes: Uma especificao tcnica detalhada pode ser apresentada no formato de figura, grfico ou texto, incluindo especificaes de projeto, de desempenho ou funcionais. A quantidade desejada, a qualidade requerida e os critrios de aceitao do produto. As condies de realizao do trabalho incluindo o perodo, local e prazo de entrega, bem como o processo de pagamento. Questes gerenciais, incluindo como deve ser feita a
- 50 -
comunicao, o acompanhamento do trabalho, as reunies e quais relatrios devero ser produzidos. Como ser o suporte, a garantia e os treinamentos necessrios.
Planejar contrataes
O processo de planejar contrataes, conforme definio do Guia PMBOK, tem como funo preparar os documentos necessrios para dar suporte solicitao de respostas de fornecedores e de sua seleo. Estes documentos contm os requisitos do produto e definem critrios para a avaliao dos fornecedores e suas propostas, pois eles devem ser devidamente instrudos sobre as necessidades do comprador antes de fazer as propostas. Quando tratamos sobre ciclo de vida, foi comentado da possibilidade do fornecedor no se interessar pela oferta do cliente. A documentao deve ser detalhada o suficiente para que no existam mal-entendidos sobre as caractersticas do produto ou servio que est sendo comprado, mas, cuidado, pois um excesso de detalhamento pode ser prejudicial capacidade do fornecedor de buscar solues melhores e mais criativas.
Resumindo
Neste mdulo de planejamento das aquisies, vimos como determinar o que deve ser contratado no projeto, por meio da seleo dos pacotes de trabalhos e recursos que sero obtidos fora da equipe do projeto. O gerenciamento de contratos so instrumentos que possibilitam, sob o ponto de vista legal, firmarem acordo entre cliente e fornecedor, sendo uma forma de garantir que as partes, que concordaram em trocar produtos e servios por dinheiro (tecnicamente, isso chamado de considerao), cumpram o acordo final. Os termos e as condies de um contrato so a principal entrada para os processos do vendedor, descrevem os principais marcos, as entregas e os objetivos ou, ainda, podem ser uma restrio, pois limitam as opes da equipe do projeto (por exemplo, solicitando a aprovao do comprador para decises ou mudanas de pessoal). Contratos so passveis de execuo em um Tribunal de Justia e garantem que o resultado seja entregue e que o dinheiro seja pago. Uma ferramenta importante neste processo a anlise do fazer-ou-comprar. Seus resultados so um plano de aquisies e uma declarao do trabalho, que contm a especificao desejada.
- 51 -
Integrao
Objetivo
Conhecer: A integrao de todas as reas de conhecimento em um nico plano do projeto.
Integrao
Quando foram apresentadas as diferentes reas do conhecimento, destacamos que todas interagem entre si e que uma mudana em uma delas inevitavelmente produz alteraes em todas as demais. Torna-se necessria uma rea que integre todos os esforos de planejamento em um nico documento, conhecido como o plano do projeto. Rita Mulcahy, conhecida autora de livros para o gerenciamento de projetos, faz um comentrio interessante sobre integrao. Se algum perguntasse a voc qual a principal funo do gerente de projetos, o que voc diria? A resposta : fazer a integrao. Enquanto o trabalho do projeto est sendo feito, a funo dos membros da equipe concentrar-se em completar os pacotes de trabalho. O patrocinador do projeto deve proteger o projeto contra mudanas e perda de recursos. A funo do gerente de projetos reunir todas as peas do projeto em uma unidade coesa (que faz com que o projeto seja realizado mais rapidamente, a um custo mais baixo e com menos recursos) e, ao mesmo tempo, cumprir os objetivos do projeto. A reunio de todos estes elementos o plano do projeto. Plano do Projeto Este documento, na verdade, a integrao de todos os demais planos produzidos em cada uma das reas de conhecimento tratadas anteriormente. Esses planos devem ser integrados, facilitando a visualizao do projeto como um todo. Na definio do Guia PMBOK, o plano de gerenciamento do projeto define como o projeto executado, monitorado, controlado e encerrado. Esse plano documenta o conjunto de sadas dos processos de planejamento do grupo de processos de planejamento. Muitas pessoas confundem o cronograma com o plano do projeto o cronograma parte dele. O plano do projeto inclui outros elementos, tais como: Declarao de escopo do projeto, EAP.
- 52 -
Cronograma. Custos e oramento. Plano da qualidade do projeto. Plano de recursos, matriz de responsabilidades, organogramas. Plano de comunicaes. Plano de gerenciamento de riscos. Plano de gerenciamento das aquisies.
O plano a linha mestra do projeto (linha de base) e determina como o trabalho ser executado para atingir os objetivos do projeto e como as mudanas devem ser monitoradas e controladas. Ao longo dos processos de execuo, o plano dever ser rigorosamente acompanhado, os desvios devem ser gerenciados e as aes devem ser tomadas para que eles no aconteam (aes preventivas) ou para colocar o projeto de volta no planejado (aes corretivas). Para que o projeto possa iniciar sua execuo, o plano deve ser apresentado e aprovado formalmente pelos participantes. Esta apresentao chamada de reunio de lanamento ou kick-off. A integrao necessria desde a iniciao do projeto, quando os diversos aspectos deste devem ser atrelados aos interesses das organizaes envolvidas, at o encerramento, quando o projeto retorna organizao para sua validao e posterior uso. O contedo do plano do projeto pode variar de organizao para organizao, sendo geralmente definido pela metodologia escolhida pela organizao.
Resumindo
Quando foram apresentadas as diferentes reas do conhecimento, destacamos que todas interagem entre si e que uma mudana em uma delas inevitavelmente produz alteraes em todas as demais. Torna-se necessria uma rea que integre todos os esforos de planejamento em um nico documento, conhecido como o plano do projeto. O plano de gerenciamento do projeto define como o projeto executado, monitorado, controlado e encerrado. Esse plano documenta o conjunto de sadas dos processos de planejamento do grupo de processos de planejamento. Muitas pessoas confundem o cronograma com o plano do projeto o cronograma parte dele. O plano do projeto
- 53 -
inclui outros elementos, tais como: a declarao de escopo do projeto, o plano de comunicaes, o plano de gerenciamento de riscos, o plano de qualidade, a matriz de responsabilidades, organogramas e o plano de recursos. O plano a linha mestra do projeto (linha de base) e determina como o trabalho ser executado para atingir os objetivos do projeto e como as mudanas devem ser monitoradas e controladas. Ao longo dos processos de execuo, o plano dever ser rigorosamente acompanhado, os desvios devem ser gerenciados e aes devem ser tomadas para que eles no aconteam (aes preventivas) ou para colocar o projeto de volta no planejado (aes corretivas).
REFERNCIA BIBLIOGRFICA -Guia PMBOK Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos-3 edio. Publicado por Project Management Institute, Inc. SUGESTO DE LEITURA - PETERS, Tom Rompendo as Barreiras da Administrao. So Paulo: Harbra, 1993. -VALERIANO, Dalton. Moderno Gerenciamento de Projetos, So Paulo: Prendice Hall, 2005. -RABECHINI Jr., Roque. O Gerente de Projetos na Empresa. So Paulo: Atlas, 2005. -DINSMORE, Paul Campbell. Gerenciamento de Projetos: Como Gerenciar seu Projeto com Qualidade, dentro do Prazo e Custos Previstos.Rio de Janeiro: Qualitymark, 2004. -MEREDITH, Jack R; Mantel, Samuel J. Jr. Administrao de Projetos: Uma Abordagem Gerencial. 4 edio. Rio de Janeiro: LTC, 2003. -HIGA, Francisco, Vai dar M... Solues para seu Projeto No Afundar. Editora GENTE.
ESPECIFICAO DE PUBLICAO
a. Documento: apostila do curso Como planejar os demais aspectos do projeto? Vlido at: indeterminado. c. Responsabilidade: 4636-1/Departamento de Treinamento. d. Seo/ramal do responsvel: Ramal 43840 e. Homologado por: Departamento de Desenvolvimento de Sistemas f. Restrito aos participantes do TreiNet Como planejar os demais aspectos do projeto? g. Pblico alvo: Agncias
- 54 -
Departamentos Usurios especficos (contas de e-mail) Todos os usurios h. Classificao Confidencial Uso interno Uso pblico i. Tamanho do arquivo: 1.522 KB j. Criado no MS Word 97 e convertido em PDF
- 55 -

Gestão de Projetos 4 - Como Planejar Os Demais Aspectos Do Projeto

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Gestão de Projetos 4 - Como Planejar Os Demais Aspectos Do Projeto

Încărcat de

Drepturi de autor:

Formate disponibile

Curso 4 - Como planejar os demais aspectos do projeto?

Gesto de Projetos Curso 4: Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Riscos. Aquisies. Integrao de todas elas.

Curso 4 - Como planejar os demais aspectos do projeto?

O que fazer para garantir que estes valores sejam alcanados?

Curso 4 - Como planejar os demais aspectos do projeto?

Equvocos comuns em qualidade

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

O que gerenciamento de qualidade?

Curso 4 - Como planejar os demais aspectos do projeto?

Como planejar a qualidade

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

O que uma especificao?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Planejamento dos recursos humanos

Curso 4 - Como planejar os demais aspectos do projeto?

A figura a seguir exemplifica as responsabilidades associada EAP para o projeto Festa.

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Tipos de comunicao A comunicao quanto classificada como: ao tipo pode ser

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

O gerenciamento das comunicaes do projeto

Curso 4 - Como planejar os demais aspectos do projeto?

Planejamento das comunicaes

Curso 4 - Como planejar os demais aspectos do projeto?

Facilitar a tomada de deciso e o controle das mudanas.

Oferecer um processo especfico para feedback e mecanismos para a resoluo de conflitos.

Melhorar e facilitar o trabalho em equipe, a cooperao e colaborao.

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Benefcios do gerenciamento de riscos

Curso 4 - Como planejar os demais aspectos do projeto?

A responsabilidade pelo gerenciamento de riscos

Curso 4 - Como planejar os demais aspectos do projeto?

O gerenciamento de riscos integrado ao planejamento do projeto

Curso 4 - Como planejar os demais aspectos do projeto?

1-Planejamento do gerenciamento dos riscos

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

2 - Identificao dos riscos

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?

Curso 4 - Como planejar os demais aspectos do projeto?