Você já trabalhou em um projeto de desenvolvimento de software que teve a gestão de riscos adequadamente utilizada no início e durante o projeto? Por incrível que possa parecer, gestão de riscos em projeto de desenvolvimento de software ainda é coisa rara, pois nós seres humanos tendemos a super estimar nossas habilidades e subestimar nossas dificuldades.

Segundo o PMBOK risco é do projeto é um evento ou condição incerta que se ocorrer, terá um efeito positivo ou negativo em pelo menos um objetivo do projeto. É importante saber que em um projeto podemos ter também as ameaças, que é algo feito por um concorrente do seu projeto visando interferir no sucesso do projeto. Embora riscos e ameaças sejam tecnicamente diferentes, para fins de gestão de projetos, eles podem ser tratados juntos na mesma análise.

risk

Para identificar riscos de um projeto faça-se uma simples pergunta: O que pode dar errado e impactar o cronograma, o custo, a performance ou o escopo do projeto? em seguida pergunte-se o que deve ser feito para evitar esse efeitos. Se não for possível evitá-los, você pode reduzir os seus impactos? É sempre melhor evitar um risco do que administrá-lo, entretanto isso deve ser feito através de um bom planejamento e não evitando-se uma boa oportunidade.

Análise de efeito de ocorrências é uma técnica simples para a identificação de riscos de um projeto, a partir de uma lista levantada pela equipe de projeto sobre quais são as ocorrências, ou eventos que o projeto está exposto. Embora essa técnica não permita quantificar objetivamente, é um metodo subjetivo que funciona muito bem. Vejamos como.

Determinando a probabilidade dos riscos

Após identificar os possíveis riscos através de um “brainstorm” com a equipe de projeto, deve-se estimar a probabilidade de ocorrência desses riscos, utilizando-se para isso da tabela abaixo:

Probabilidade de Ocorrência

Possíveis taxas de ocorrência

Peso

Muito alta: ocorrência é quase certa

>= 1 em 2

 

10

1 em 3

9

Alta: possibilidade de ocorrências repetitivamente

1 em 8

8

1 em 20

7

Moderada: ocorrências ocasionais

1 em 80

 

6

1 em 400

5

1 em 2000

4

Baixa: relativamente poucas ocorrências

1 em 15000

3

1 em 150000

2

Remota: ocorrência é improvável

<= 1 em 1.500.000

1

 

Determinando a severidade de um risco

Em seguida deve-se considerar qual a severidade do efeito de uma ocorrência para o projeto. Assim um evento que tem alguma probabilidade de ocorrência porém, um baixo impacto no projeto não deve gerar grande preocupação; já um evento de baixa probabilidade, mas de alto impacto gera uma grande preocupação para o gerente do projeto. Veja a tabela abaixo:

Efeito

Critério: Severidade do Efeito

Peso

Perigoso – sem aviso

Projeto severamente impactado, possível de cancelamento sem aviso

10

Perigoso – com aviso

Projeto severamente impactado, possível de cancelamento com aviso

9

Muito alta

Impacto maior no prazo do projeto, custo ou performance; pode causar atrasos severos, retrabalhos ou degradação da performance

8

Alto

Impacto significativo nos prazos, custos ou performance do projeto. Trabalho pode ser finalizado, mas o cliente ficará insatisfeito

7

Moderado

Algum impacto nos prazos, custos ou performance. Cliente insatisfeito

6

Baixo

Leve impacto nos prazos, custos ou performance. Cliente um pouco insatisfeito

5

Muito baixo

Algum impacto no projeto. Cliente estará ciente do impacto

4

Menor

Pequeno impacto no projeto. Alguns clientes estarão cientes do impacto

3

Muito menor

Impacto tão pequeno que será notado apenas por um cliente muito atento

2

Nenhum

Sem impacto no projeto

1

 

Determinando a facilidade de detecção de um risco

O próximo passo na análise de riscos é estimar a facilidade de detectar que  a ocorrência de um evento irá ocorrer, antes que ele realmente ocorra. Por exemplo, se o seu saldo no banco ficará negativo, o efeito será severo (juros bancários). Se você  tiver uma planilha de controle de despesas poderá agir antes da situação se torna grave. Sem uma planilha de controle, não será fácil detectar o problema antes do mesmo ocorrer.

Nos projetos, acontecimentos indesejáveis podem ser previstos com alguma precisão, e então ações podem ser tomadas para compensação. A tabela abaixo é usada para medir a capacidade de se detectar um risco em um projeto. Observe que é uma escala reversa, ou seja, quanto mais certo que você pode detectar um perigo para o projeto, mais baixo é o número

Detecção

Peso

Absolutamente incerto

10

Muito remoto

9

Remoto

8

Muito baixo

7

Baixo

6

Moderado

5

Moderado alto

4

Alto

3

Muito alto

2

Quase certeza

1

 

Determinando a Magnitude do Risco

Para cada risco identificado temos três medidas: o nível de probabilidade a medida de severidade e um índice de capacidade de detecção. Para se obter a magnitude de um risco efetua-se a multiplicação desses três números. Quanto mais alta é a magnitude, mais sério é o risco identificado. Para entender como isso funciona considere a tabela abaixo:

Risco identificado

Probabilidade

Severidade

Detecção

Magnitude

Previsão de tempo ruim

3

2

4

24

Perda de um elemento chave da equipe

2

8

8

128

Falha de tecnologia

6

10

8

480

 

A abordagem para tratar a magnitude dos riscos é verificar se um dos três números (probabilidade, severidade ou detecção) pode ser reduzido, ou seja, podemos reduzir a probabilidade ou severidade, ou aumentar a capacidade de detecção de um determinado risco?

No exemplo da tabela acima a magnitude para uma previsão de tempo ruim é tão pequena que pode ser ignorada, entretanto os outros dois riscos têm magnitudes significativas e devemos considerar como tratá-los. Vamos avaliar primeiramente o risco da perda de um elemento chave da equipe de projeto: embora sua probabilidade de ocorrência seja de apenas 2, ele tem tanto a severidade quanto a detecção altas. Como regra geral considere que se a severidade é alta, independentemente da magnitude, uma atenção especial deve ser dada ao risco.

Uma forma de se reduzir o risco da perda de um elemento chave da equipe é ter alguém disponível que substitua esse elemento. Não será possível reduzir a detecção nesse caso, mas reduzindo-se a severidade já será suficiente.

Quanto ao risco de falha na tecnologia que apresenta um probabilidade moderada de 6 pontos de ocorrência, não deve nos causar muitas preocupações, entretanto se a probabilidade fosse de em torno de 8 ou 9 pontos, seria recomendado realizar um estudo de viabilidade da tecnologia antes da sua aplicação real em um determinado projeto. Como regra básica, vale que se o cronograma do projeto deve ser cumprido, atividades de pesquisas devem ser separadas das atividades de desenvolvimento.

Embora a probabilidade da falha de tecnologia ser moderada, sua severidade é a mais elevada possível e uma forma de tratar isso é ter uma alternativa pronta nas mãos. Em projeto de alto risco, onde não é possível conduzir estudos de viabilidade de tecnologia, pode-se adotar um caminho paralelo de desenvolvimento com uma segunda tecnologia, assim a primeira tecnologia que se demonstrar viável será a adotada. Logicamente isso custo um bocado de dinheiro e somente é viável quanto o prazo é mais importante que o custo.

Por fim pode-se detectar a falha de uma determinada tecnologia com alguma facilidade? Provavelmente não, mas é prudente estabelecer um critério de decisão sobre um número de quantidade de falhas que serão toleradas em uma determinada tecnologia antes de a mesma ser abandonada em detrimento a uma outra que se demonstre como uma alternativa.

Artigo adaptado de :
Mastering Project Management – Applying Advanced Concepts to Systems Thinkin, Control & Evaluation, Resource Allocation, Second Edition; Lewis, James P.; McGraw-Hill; 2008