gerenciamento de riscos em projetos de ti

8
Gerenciamento de riscos em projetos de TI Marcio Antônio Molica Soares, [email protected] Resumo: Projetos em TI são difíceis por natureza e estão sendo entregues a fornecedores ao invés de serem desenvolvidos internamente. Os gestores em TI têm se transformado em gestores de contratos. Esse fator adiciona um risco adicional aos projetos. Em geral, o plano de contingência a riscos abrange a utilização de recursos financeiros extras ao projeto. Recursos estes que podem ser muito difíceis de serem obtidos durante o ciclo de vida do projeto. Este trabalho aborda este cenário e propõe uma solução para tratamento dos riscos em projetos de TI considerando-se a questão da terceirização. Palavras chaves: Riscos; Aquisições; Escopo; Mudanças; Recursos financeiros; 1. Introdução O gerenciamento de projetos em TI é uma atividade extremamente desafiante que exige muita agilidade, capacidade de negociação, conhecimento técnico e disposição para lidar com imprevistos. De acordo com o “Chaos Report 2009”, é baixa a taxa de sucesso na conclusão de projetos em TI. Ilustração 1 - Chaos Report 2009, fonte Revista Mundo PM A revista Exame publicou uma reportagem em 23/02/2011 cujo título é: 15 bytes de fama para os CIOs, link aqui . Abaixo segue a transcrição literal de um parágrafo retirado do texto e que resume bem o cenário: Cada vez mais, esse padrão vem se repetindo em empresas de todo o mundo. Serviços que antes eram executados internamente sob a supervisão de CIOs hoje vão parar nas mãos de terceiros. Segundo a consultoria de tecnologia Gartner, foram investidos em 2008 no Brasil 15,8 bilhões de dólares em serviços na área de tecnologia da informação — dinheiro que, em boa medida, antes ficava dentro das empresas. Em 2013, a cifra deve chegar a 22 bilhões de dólares. Tamanho volume de projetos repassados a fornecedores criou um jargão para o novo papel do diretor de TI: “um gestor de contratos”. “Os CIOs viraram uma espécie de rainha da Inglaterra”, diz Avritchir. “Reinam,

Upload: pmimg

Post on 22-Mar-2016

221 views

Category:

Documents


8 download

DESCRIPTION

Gerenciamento_de_Riscos_em_projetos_de_TI_Marcio_Molica

TRANSCRIPT

Page 1: Gerenciamento de Riscos em projetos de TI

Gerenciamento de riscos em projetos de TI

Marcio Antônio Molica Soares, [email protected]

Resumo: Projetos em TI são difíceis por natureza e estão sendo entregues a fornecedores ao invés de serem desenvolvidos internamente. Os gestores em TI têm se transformado em gestores de contratos. Esse fator adiciona um risco adicional aos projetos. Em geral, o plano de contingência a riscos abrange a utilização de recursos financeiros extras ao projeto. Recursos estes que podem ser muito difíceis de serem obtidos durante o ciclo de vida do projeto. Este trabalho aborda este cenário e propõe uma solução para tratamento dos riscos em projetos de TI considerando-se a questão da terceirização. Palavras chaves: Riscos; Aquisições; Escopo; Mudanças; Recursos financeiros;

1. Introdução O gerenciamento de projetos em TI é uma atividade extremamente desafiante que exige muita agilidade, capacidade de negociação, conhecimento técnico e disposição para lidar com imprevistos. De acordo com o “Chaos Report 2009”, é baixa a taxa de sucesso na conclusão de projetos em TI.

Ilustração 1 - Chaos Report 2009, fonte Revista Mundo PM

A revista Exame publicou uma reportagem em 23/02/2011 cujo título é: 15 bytes de fama para os CIOs, link aqui. Abaixo segue a transcrição literal de um parágrafo retirado do texto e que resume bem o cenário:

Cada vez mais, esse padrão vem se repetindo em empresas de todo o mundo. Serviços que antes eram executados internamente sob a

supervisão de CIOs hoje vão parar nas mãos de terceiros. Segundo a consultoria de tecnologia Gartner, foram investidos em 2008 no Brasil

15,8 bilhões de dólares em serviços na área de tecnologia da informação — dinheiro que, em boa medida, antes ficava dentro das empresas. Em 2013, a cifra deve chegar a 22 bilhões de dólares.

Tamanho volume de projetos repassados a fornecedores criou um jargão para o novo papel do diretor de TI: “um gestor de contratos”. “Os CIOs viraram uma espécie de rainha da Inglaterra”, diz Avritchir. “Reinam,

Page 2: Gerenciamento de Riscos em projetos de TI

mas não governam.” Em janeiro, o engenheiro deixou o emprego na Dell. “Voltar a ser CIO é só a última das minhas opções.”

Em resumo, os projetos em TI são difíceis por natureza e estão sendo transferidos para terceiros. Como gerenciar o risco neste cenário? A gestão de contratos (aquisições) passa a ser o principal fator a ser levado em consideração para garantir o sucesso de um projeto. O PMO das organizações pode ter um importante papel na gestão do risco em portfólios de projetos de TI.

2. A TI dentro de uma organização Em geral, a TI dentro das organizações funciona como um departamento de suporte e apoio ao negócio. A sua importância esta relacionada ao quanto às ferramentas e serviços disponibilizados influenciam nos resultados do negócio. Devido ao grande avanço tecnológico, independentemente do tipo de empresa, a TI tem se tornado um fator crítico de sucesso para o negócio. Os projetos de TI fornecem soluções tanto para clientes internos, tais como outros departamentos (rh, marketing, vendas, engenharia, etc.), quanto para clientes finais da empresa. Isto faz com que a gestão eficiente de projetos influencie diretamente os resultados da organização. As empresas têm buscado cada vez mais focar esforços no núcleo de negócios da área onde atua. A terceirização de atividades “não-fins” é um exemplo desse tipo de orientação. Dentro da TI, muitas empresas optam por terceirizar atividades que não são entendidas como fundamentais ao funcionamento da área. Entre estas atividades estão, por exemplo, o desenvolvimento de sistemas, operação e manutenção do parque de computadores, o atendimento a clientes (internos ou externos), a implementação de projetos, etc. Para efeito desse trabalho, projetos de TI são entendidos como sendo aqueles que envolvem o fornecimento por terceiros de hardware, software ou serviços necessários ao desenvolvimento do projeto. Portanto, a gestão de aquisições é uma disciplina fundamental para o sucesso do projeto. Selecionar, gerir e acompanhar o trabalho dos fornecedores é atividade crítica neste modelo de atuação. O problema é que a relação com os fornecedores nem sempre é saudável, especialmente quando ela não é vista como uma parceria em que ambas as partes tem muito a ganhar com o sucesso do projeto, os problemas começam a pipocar, os ânimos se exaltam, a relação se degrada, o projeto não anda e todos perdem. Uma breve descrição de um processo de contratação de fornecedores possui, em geral, os seguintes pontos:

• Uma vez identificada uma demanda dentro da empresa, os fornecedores de TI previamente cadastrados são avisados para enviarem uma proposta de solução através de uma RFP (Request for Proposal);

• Os fornecedores que responderam a RFP são classificados de acordo com as propostas fornecidas;

• Normalmente alguma prova de conceito é solicitada, isto é, algum tipo de projeto piloto é exigido para validar a solução proposta;

Page 3: Gerenciamento de Riscos em projetos de TI

• Os fornecedores são classificados de acordo com critérios técnicos e o departamento de suprimentos ou compras da empresa é acionado para verificação dos critérios e cláusulas comerciais;

• Os fornecedores são classificados também por critérios comerciais; • O fornecedor vencedor (conjunto entre critérios técnicos e comerciais) firma contrato

com a empresa prevendo multa e penalidades legais em caso de descumprimento das cláusulas pré-estabelecidas;

Embora a empresa esteja protegida contratualmente em relação a não entrega do produto/serviço por parte do fornecedor, isto não quer dizer que exista uma garantia de que o projeto será entregue no prazo acordado com a qualidade e escopo definido. Ao contrário, o que nota-se na prática são atrasos nas entregas, o escopo e qualidade não são respeitados. Em muitos casos a empresa é forçada a renegociar o contrato na tentativa de “salvar” o projeto. Em situações críticas o impasse acaba sendo resolvido judicialmente. Este tipo de situação configura a relação como perde-perde, isto é, independentemente da forma como a situação é analisada todos os envolvidos perdem algo e não há vencedores. Para evitar todos estes transtornos a TI precisa efetivamente cuidar do gerenciamento de riscos e, em especial, da gestão de aquisições dos projetos de sua alçada. O objetivo desse trabalho é propor um meio para gerir os riscos e as aquisições em projetos de TI de forma a, ao menos, minimizar os problemas acima relacionados, aumentando a taxa de sucesso de projetos ofertados pela TI aos seus clientes. Esta proposta surgiu da observação e análise dos processos para gestão de portfólios de projetos de um departamento de uma grande empresa de telecomunicações. Neste departamento, a qualquer tempo, existem mais de 100 projetos em execução que são alimentados por um orçamento anual próximo a R$40 milhões. A gestão financeira é feita através do provisionamento de verba para cada projeto. Uma parte do budget de cada projeto é reservada para a gestão de riscos. Quando eles ocorrem, os recursos financeiros reservados para riscos são utilizados, mas frequentemente são insuficientes. Neste caso, verbas de outros projetos menos prioritários são utilizadas. Uma vez validada, esta proposta deverá ser efetivamente implementada e seus resultados medidos.

3. Os desafios dos projetos de TI Projetos em TI são desafiantes porque lidam com o imponderável. Os cenários mudam muito rapidamente, o dinamismo, o avanço, a obsolescência tecnológica, o curto ciclo de vida das tecnologias torna muito instável a previsão de demandas e a escalabilidade em projetos mesmo em um curto espaço de tempo. Em geral um projeto de médio/grande porte dura em torno de 1 a 2 anos. Neste ínterim, devido a diversos fatores como os acima expostos ou mesmo mudanças no negócio da empresa podem tornar inválidas as premissas originais do escopo do projeto. As coisas costumam mudar muito rapidamente durante o ciclo de vida do projeto! Um exemplo para a indústria de telecomunicações seria os sistemas de billing e análise estatística de CDRs (Call Data Records). Estes sistemas são baseados na análise de pequenos arquivos que registram os dados de uma chamada telefônica. Em resumo, uma chamada telefônica envolve a criação de algumas dezenas de CDRs que informam os números dos assinantes que iniciaram e receberam a chamada, a data e hora de início e fim, se era ligação de telefone fixo para móvel ou fixo para fixo, etc. Baseado nestes arquivos, o sistema de billing enviará a cobrança ao assinante, sistemas estatísticos analisarão o comportamento da

Page 4: Gerenciamento de Riscos em projetos de TI

rede através de indicadores e outros sistemas podem verificar se esta ocorrendo perda de receita na operadora devido a algum problema operacional (sistemas de garantia da receita). Em projetos desse tipo, durante a fase de fechamento de escopo, considera-se como requisito básico a capacidade do sistema processar uma determinada quantidade de CDRs. Para estimar esse número, conta-se a quantidade de CDRs escoados no momento pela rede e acrescenta-se uma generosa margem de segurança que garantirá que o sistema possa funcionar bem mesmo ocorrendo uma determinada taxa de crescimento de CDRs na rede. Um exemplo de requisito poderia ser:

• O sistema deve tratar 1 bilhão de CDRs/dia

O problema é que, durante o ciclo de vida do projeto, muitos fatores podem ocorrer e tornar esta premissa inválida. Por exemplo, uma promoção do departamento de marketing, uma resolução da anatel pedindo para que os CDRs sejam fechados por minuto ao invés de serem fechados por chamada (o que aumentaria muito a quantidade de CDRs escoados) ou mesmo uma demanda inesperada podem fazer com que, no meio do projeto, o volume de CDRs/dia escoados pela rede da empresa passe a ser 5 vezes maior! Neste momento, a declaração de escopo já foi emitida, os servidores para processamento já foram dimensionados e comprados para processar 1 bilhão de CDRs, os módulos de sistemas já estão em desenvolvimento. O hardware previamente alocado e comprado não suporta mais a carga de armazenamento e processamento! O software desenvolvido tornou-se extremamente lento visto que fora projetado para outro cenário! A sensação da equipe de projeto é de estar no meio do oceano dentro de um barco a remo e com uma tempestade se aproximando! Neste ponto, pouco ou nada pode ser feito a não ser tentar viabilizar internamente um novo “subprojeto” para salvar o sistema original. Isto é, será preciso mobilizar os clientes internos já insatisfeitos, a equipe de projeto que esta com moral baixo e, principalmente, os decepcionados patrocinadores para conseguir nova injeção de recursos ao projeto. Aquisição de novo hardware ou expansão do atual, contratação de novos módulos de sistema, alocação de mão de obra extra, redução de escopo, diminuição de SLA (Service Level Agreement) são decisões comuns quando problemas como estes ocorrem. Em algumas situações, o plano de gerenciamento de riscos chegou a ser previsto no plano de gerenciamento do projeto, mas torna-se inócuo visto que o X da questão está relacionado à gestão de mudanças, escopo e aquisições! Na maioria das situações não há plano para gerenciamento de riscos! Projetos de TI, quando comparados a outras indústrias, apresentam um reduzido conjunto de riscos. Catástrofes naturais, guerras, epidemias, inundações, logística, clima, etc. em geral afetam pouco ou não afetam a maioria dos projetos em TI. Em contrapartida, as mudanças no escopo e nas premissas básicas do projeto são uma constante. Os riscos associados a projetos de TI são, em sua maioria, dos tipos: - Obsolescência de hardware/software; - Mudanças constantes de requisitos de escopo; - Alta rotatividade de membros da equipe; - Mal desempenho de fornecedores; - Oscilações da cotação do câmbio (insumos como hardware e softwares básicos são geralmente importados);

Page 5: Gerenciamento de Riscos em projetos de TI

- Riscos associados a fornecedores de tecnologia (falência, descontinuidade de produtos, abandono de tecnologia, etc.); - Dificuldade na delimitação do escopo do projeto; De uma forma ou de outra, a solução para todos estes problemas resume-se em basicamente alocar recursos extras ao projeto como pode ser ilustrado pela tabela abaixo. O problema é que os recursos geralmente não estão disponíveis no momento em que os problemas acontecem. A equipe de projeto é então forçada a improvisar soluções, o que nem sempre traz bons resultados especialmente quando analisados em longo prazo. Um exemplo é “tomar um hardware emprestado temporariamente” de alguma outra área ou projeto. Em geral, o temporário torna-se definitivo e geralmente o hardware utilizado também não esta de acordo com as especificações originais do projeto. Em suma, problemas a vista!

Risco Solução Obsolescência de hardware Aquisição de novo hardware Mudanças constantes de requisitos de escopo Desenvolvimentos adicionais para atender as

novas demandas Turnover elevado de membros da equipe Contratar e treinar novos membros Má performance de fornecedores Reduzir escopo, contratar outro fornecedor,

executar judicialmente o contrato Oscilações da cotação do câmbio (produtos são geralmente importados)

Alocar mais recursos para cobrir o aumento do câmbio

Riscos associados a fornecedores de tecnologia Trocar a tecnologia escolhida, trocar de fornecedor, redesenvolvimento do sistema

Tabela 1 - Riscos e possíveis soluções Desconsiderando o grave efeito do estouro no orçamento do projeto, o gerente de projetos ainda tem que enfrentar a própria dinâmica de funcionamento das organizações que dificulta muito a alocação de novos recursos ao projeto após o fechamento do orçamento. É árdua a tarefa de angariar novos recursos ao projeto. O gerente de projetos e, principalmente, os patrocinadores precisarão “passar o pires” pedindo novas contribuições ao departamento financeiro. Na prática o que ocorre é a realocação de verbas de outros projetos, especialmente aqueles que estão em fases iniciais, para o projeto problemático. É o velho ditado: veste-se um santo enquanto o outro fica nú. A gestão financeira dos recursos alocados para gerenciamento dos riscos é, portanto, fator crucial para o sucesso do projeto.

4. Uma proposta para gestão de riscos de projetos de TI A revista PM Network de janeiro de 2011 traz em sua reportagem de capa a importância da questão do gerenciamento de riscos especialmente em um ano (2010) em que ocorreram muitas tragédias naturais ou causadas pelo homem. A revista cita lições que as empresas escolheram para tratar o gerenciamento de riscos em seus projetos. Em especial, a Siemens passou a tratar o gerenciamento de riscos como um processo dentro da gestão de portfólios ao invés de tratá-los como processos dentro do gerenciamento do projeto. Esta nova perspectiva faz sentido para projetos de TI. A migração para portfólio das verbas alocadas para tratamento de riscos dentro dos projetos é claramente benéfica. Provisionar 10, 20 ou 25% do orçamento de um projeto para gestão de risco faz pouco sentido quando se olha o conjunto de projetos da empresa. Riscos podem ou não ocorrer, se ao invés de provisionar um percentual (geralmente alto) em cada projeto fosse provisionado uma verba geral para riscos da carteira de projetos o valor final alocado pela empresa poderia ser muito menor.

Page 6: Gerenciamento de Riscos em projetos de TI

Fazendo uma analogia com o seguro de automóveis podemos notar as vantagens desse modelo. Pensando nos sinistros mais comuns que podem ocorrer quando utilizamos um automóvel de R$50.000 poderíamos concluir que um valor razoável para verba de riscos seria de aproximados R$30.000, ou seja, 60% do valor do bem! Se optarmos por usar os serviços de uma seguradora este valor pode cair para uns 3% do valor do veiculo e estaremos garantidos quase na integralidade do valor do bem (danos contra terceiros e proteção do auto de acordo com preços de mercado, neste caso, R$50.000). A idéia básica é que dividir o custo dos riscos entre mais projetos diminui significativamente o valor financeiro alocado pela TI para a gestão de riscos e, ao mesmo tempo, protege de maneira mais eficiente os projetos. Em uma empresa de grande porte onde a qualquer tempo, algumas centenas de projetos estão em desenvolvimento, a gestão centralizada da verba para risco pode ser muito vantajosa. A gestão do “pool de recursos” para riscos deve estar atrelada ao escopo dos projetos. Para efeito de riscos que afetam o escopo, os projetos devem ser planejados para atender minimamente a um subconjunto de requisitos listados na declaração de escopo. Ela deve conter todo o escopo do produto do projeto, porém, para efeito de gestão de riscos (decisão de interromper o projeto e/ou alocar mais recursos) um subconjunto desse escopo tem necessariamente que ser atendido. As funcionalidades constantes no escopo do projeto devem ser classificadas, por exemplo, em fundamental, importante e desejável. Durante o desenvolvimento do projeto, de acordo com as entregas das funcionalidades fica fácil tomar decisões sobre a gestão dos riscos. Se, por exemplo, em um projeto que esta apresentando problemas, várias funcionalidades fundamentais (mas não todas) já foram implementadas pode ser razoável continuar investindo recursos no projeto a fim de alcançar o mínimo desejado. Caso todas as funcionalidades fundamentais tenham sido atendidas, talvez seja uma boa idéia suspender o projeto e alocar os recursos para riscos em outro projeto que esteja em situação mais crítica. Claro que as prioridades dos projetos devem ser consideradas na tomada de decisão. O gerenciamento dessa verba dentro da gestão de portfólios deveria ser feito levando-se em consideração certas premissas:

• Existência de um pool de recursos para tratamento de riscos da carteira de projetos; • Uma vez alcançado o núcleo mínimo de funcionalidades (escopo) os recursos passarão

gradativa e progressivamente a ser retirados do projeto retornando ao pool global; • A gestão do pool deve estar intimamente ligada à gestão de mudanças; • A quantidade de recursos requerida junto ao pool pelo gerente de projeto é fator para a

tomada de decisão sobre conceder ou não o recurso solicitado; • Cada projeto tem uma cota reservada no pool de recursos. Esta cota leva em

consideração diversos fatores entre eles: prioridade, custo total e porte do projeto; • A gestão do pool deve ser feita pelo PMO da organização;

A tabela abaixo indica um exemplo hipotético do percentual de verba reservada a cada um dos projetos dentro do pool de recursos para gerenciamento de riscos:

Page 7: Gerenciamento de Riscos em projetos de TI

Projeto % alocado Valor reservado 1 17% R$510.000,00 2 15% R$450.000,00 3 13% R$390.000,00 4 30% R$900.000,00 Pool Global 25% R$750.000,00

total 100 R$3.000.000,00 Tabela 2 - Um exemplo de alocação de recursos em pool

A gestão do pool de recursos deve ser feita com cuidado. O objetivo é deixar disponível para o projeto certa quantidade de recursos a qualquer momento e sem burocracia. Desta forma os gerentes de projetos terão a agilidade necessária para enfrentar os principais riscos do projeto. A gestão do pool deve ser feita pelo PMO devido à centralização do controle sobre o mesmo. O PMO pode criar um indicador para a utilização do pool. Através desse indicador a alta administração poderá ter uma noção da qualidade dos projetos que são executados em determinado momento na empresa. A premissa básica é a devolução ao pool dos valores não utilizados. Deixar a gestão dos recursos diretamente nas mãos dos gerentes de projetos pode ser uma estratégia perigosa. Um gerente pode ser tentado a “inventar” um risco para justificar a utilização da verba a que tem direito. O PMO deve estar à frente desse processo para analisar a requisição criticamente confrontando com o escopo já entregue para permitir ou negar a liberação da verba. Na tabela 2, suponha que o projeto 4 tenha duração de 1 ano e que o escopo mínimo tenha sido atingido no 6º mês (mês atual). O PMO decidiu que, ao atingir o escopo mínimo, os recursos podem retornar ao pool gradativamente, pois como se trata de um projeto muito importante a completude do Escopo é desejável. Suponha que o projeto já consumiu R$300.000,00 dessa verba, restando, portanto R$600.000,00. A cota alocada para risco desse projeto junto ao pool deverá ser gradativa e progressivamente deslocada desse projeto e retornada ao pool global conforme tabela abaixo. Mês % alocado do pool Valor reservado ao projeto 6º 20% (R$3.000.000 * 0,20) R$600.000,00 7º 18% (R$3.000.000 * 0,18) R$540.000,00 8º 15% R$450.000,00 9º 11% R$330.000,00 10º 7% R$210.000,00 11º 2% R$60.000,00 12º 0% R$0,00

Tabela 3 - Um exemplo de utilização do pool Ou seja, a cada mês o projeto terá uma verba menor para tratamento dos riscos do projeto, o que é razoável porque à medida que o projeto avança os riscos diminuem e o projeto já conseguiu entregar as funcionalidades fundamentais requeridas. Exemplos de políticas para liberação de verba do pool de recursos podem conter regras do tipo:

§ Projetos que tenham alta prioridade e cujo valor requisitado seja pequeno para que as funcionalidades mínimas sejam alcançadas;

§ O valor liberado é pequeno para atingir as funcionalidades mínimas independente do porte do projeto;

§ Etc.

Page 8: Gerenciamento de Riscos em projetos de TI

A tabela abaixo ilustra possíveis critérios para liberação de recursos do pool: Prioridade do projeto

Funcionalidades básicas

Completude do Escopo

Valor a ser liberado

Prioridade para liberação

Alta Atingidas Falta pouco Pequeno 1 Alta Falta pouco Falta muito Pequeno 2 Alta Falta pouco Falta muito Médio 3 Média Atingidas Falta pouco Pequeno 4 Baixa Falta pouco Falta muito Pequeno 5 Média Falta pouco Falta muito Grande 6 Alta Falta muito Improvável Médio 7 Alta Falta muito Impossível Grande 8 Média Falta muito Improvável Grande 9

Tabela 4 - Exemplo de critérios para liberação de recursos As sugestões de critérios e prioridades acima expostas têm caráter meramente didático. Cada organização é única e tem identidade própria ficando somente sob sua responsabilidade a escolha dos critérios/prioridades que melhor se encaixam na sua realidade. Trata-se apenas de uma sugestão para entendimento da proposta.

5. Conclusão Por sua natureza projetos em TI possuem riscos cuja solução envolve a aplicação de recursos financeiros extras ao projeto. A alocação e disponibilização de tais recursos na quantidade e no momento adequado pode ser um problema para o gerente de projetos. A maioria das empresas trabalha com orçamentos anuais e os recursos alocados aos projetos geralmente não prevêem uma reserva para contingência destinada ao gerenciamento de riscos. Alocar recursos para riscos dentro da verba destinada aos projetos pode ser uma forma ineficiente de gestão financeira especialmente em empresas onde a quantidade de projetos em desenvolvimento é grande. Melhor seria alocar um pool de recursos que serviria a todos os projetos e cuja administração é delegada ao PMO da organização. Com essa estratégia, os projetos teriam a disposição, a qualquer momento, certo volume de recursos para tratamento de riscos. A centralização da gestão de riscos traz também outras vantagens tais como:

• Visão panorâmica do andamento dos projetos; • Possibilidade de criação de indicadores de gestão de riscos; • Economia de recursos; • Uso eficiente dos recursos para minimizar efeitos negativos dos riscos; • Disponibilização segundo critérios pré-estabelecidos de recursos extras aos projetos a

qualquer momento; Principais Referências Bibliográficas: - PMBOK Forth Edition - Revista MundoPM, edição 33, 06 de 2010, http://www.mundopm.com.br/Busca.jsp#edicao?33 - Revista Exame, 23/02/2011, http://exame.abril.com.br/revista-exame/edicoes/0986/noticias/15-bytes-de-fama?page=1&slug_name=15-bytes-de-fama