O teu projeto precisa mesmo de gestão de risco? - Profissional Moderno
Pois é, o dia em que vos viria falar de riscos tinha que chegar. Este é o típico tema em que qualquer gestor de projetos se orgulha de apregoar aos sete ventos que é muito importante, mas que na realidade acaba por quase nunca o fazer da forma mais correta.
Com isto não digo que não se faça de todo uma gestão de riscos, mas que em muitas empresas não se faz da melhor forma.
É comum no início de um projeto, existir um investimento de tempo elevado na identificação de possíveis riscos de projeto, contudo, todo esse esforço é desperdiçado a partir do momento em que, durante o ciclo de vida do projeto, se deixa de fazer um acompanhamento ao plano de risco.
Um bom acompanhamento de um plano de risco, envolve por exemplo em todos os pontos de situação que fazes, reservar tempo para falar dos riscos que tens em aberto. Se forem muitos, fala dos que têm maior impacto no teu projeto. Já te vou explicar o que significa isto de ter mais impacto, mas por agora lembra-te também de outro ponto, os riscos não devem apenas ser identificados no início do projeto, mas também durante. Também não devem ser identificados somente pelo gestor de projeto, mas sim pelos restantes stakeholders. A equipa é sempre uma excelente fonte de possíveis riscos, pergunta-lhes, não te vais arrepender.
Respondendo um pouco à questão que coloquei no título deste post, o teu projeto necessita mesmo de gestão de risco? Claro que sim! A gestão de risco é importantíssima num projeto. Lembra-te sempre de uma coisa, o trabalho do gestor de projeto é bastante difícil, afinal de contas, és pago para tentar adivinhar o futuro. Quanto traças um plano, não passa disso mesmo, um plano. Depois disso a realidade acontece e tudo o que planeaste é voltado do avesso. Se conseguisses adivinhar tudo eras vidente e não gestor de projetos. E sabemos bem o jeito que daria ser vidente, principalmente para adivinhar a combinação de uns quantos números e estrelas do euromilhões certo ? Como adivinhar o futuro é muito difícil, resta preparares-te muito bem para o que der e vier, e os riscos servem para isso mesmo. Não é fantástico acontecer um problema no teu projeto e já teres um plano de resposta e saberes exatamente o que fazer? Garanto-te que para além de ser ótimo para o teu projeto, também te dá uma imagem de gestor de projeto muito profissional.
Desmistificada a questão se o teu projeto precisa ou não de gestão de riscos, quero falar-te das fases que deves seguir ao realizar uma excelente gestão de risco:
3. Análise Quantitativa
4. Planeamento de respostas
Para que possas entender melhor do que falo, vou-te falar um pouco de cada uma dessas fases.
Não deixa de ser óbvio que se pretendes fazer um bom levantamento de riscos, deves começar por uma correta identificação do que é ou não um risco. Muitas vezes vejo alguma confusão junto dos gestores de projeto relativamente a este ponto. Por exemplo, frequentemente leio riscos que na realidade já aconteceram, e como tal, deixam de ser riscos e passam a ser problemas. Um risco é sempre um evento incerto, provável e com um impacto. Incerto na medida em que não é controlado pelo gestor de projeto, provável porque tem uma determinada probabilidade de acontecer e com um impacto pois caso aconteça pode prejudicar o teu projeto (quer no âmbito, custo, prazo ou qualidade).
Na fase de identificação de riscos deves obter um entendimento global sobre os riscos do projeto, assim como documentar bem quais as causas que podem originar todos eles. Relembro mais uma vez que a identificação deve ocorrer durante o ciclo de vida do projeto, e pode e deve ser um exercício também executado pela equipa.
Existem algumas técnicas que podes utilizar nesta fase, entre as quais o brainstorming, diagramas de causa-efeito, análise SWOT ou mesmo consulta de riscos em projetos análogos. Pesquisa um pouco sobre cada uma das técnicas para teres uma ideia do que se trata. Por exemplo, numa análise SWOT são sempre identificados quatro vértices, as forças, fraquezas, oportunidades e ameaças. Para riscos que se encaixem nas forças e oportunidades deves tentar explorá-los ou potenciá-los, enquanto que riscos resultantes das fraquezas e ameaças devem a todo o custo ser eliminados ou mitigados. Lembra-te sempre de uma coisa, os riscos não são sempre negativos! Também podem ser registados riscos positivos.
Análise Qualititiva
Após serem identificados riscos, normalmente é feita uma primeira análise a nível qualitativo. Tipicamente os riscos são analisados de acordo com duas variáveis, a probabilidade e o impacto. Multiplicando estas duas variáveis podes obter um score para o teu risco, que te vai mostrar se é um risco que deves ou não ter especial cuidado. Podes usar uma escala que represente cada uma destas variáveis, como por exemplo:
2 - Pouco Provável
3 - Provável
4 - Muito Provável
5 - Quase certo
2 - Mínimo
5 - Catastrófico
Imagina que identificas um risco com uma probabilidade pouco provável (2) e com um impacto alto (4). Este risco representaria um score de 2x4, ou seja 8.
Se tivesses agora outro risco, com uma probabilidade muito provável (4) e impacto alto (4) resultaria num score 16.
Só por si esta análise permite-te de uma forma célere perceber quais são os riscos onde deves dedicar mais atenção. Nos exemplos que dei, o risco com score 16 resulta num perigo maior para o teu projeto, portanto deves dedicar-lhe especial atenção.
Finalmente, e por uma questão de leitura, podes colocar os teus riscos numa matriz como apresento na imagem acima. Assim, de uma forma muito visual tens informação sobre quais os riscos que representam um maior perigo para o teu projeto.
O objetivo da análise quantitativa é detalhar o que resultou da análise qualitativa. Como é uma análise de execução mais morosa, não deve ser realizada a todos os riscos identificados, já que irias dispender muito tempo. A ideia é selecionares da análise qualitativa os riscos com scores maiores, para depois fazeres um levantamento de impactos reais que vão ter no teu projeto. Utilizando os riscos que dei como exemplo acima, deves chegar a uma possível probabilidade e a um possível valor de impacto:
Risco 1 - Probabilidade pouco provável e impacto alto
Análise Quantitativa Risco 1 resulta numa probabilidade de 15% e num impacto de 10.000€
Multiplicando 15% por 10.000€ obténs 1.500€. Este número representa a contingência que deverias reservar no teu projeto para este risco.
Risco 2 - Probabilidade muito provável e impacto alto
Análise Quantitativa Risco 2 resulta numa probabilidade de 80% e num impacto de 11.000€
Multiplicando 80% por 11.000€ obténs 8.800€. Este número representa a contingência que deverias reservar no teu projeto para este risco.
Assim, somando ambas as contingências, para fazer face aos riscos deverias ter uma reserva de contingência no teu projeto de 10.300€.
Repara que tanto a probabilidade como o impacto de alguns riscos podem variar ao longo do projeto. Por exemplo, se um dos riscos que tens é a falta de conhecimento da equipa num determinado software, podes optar por tomar uma medida que é dar formação a toda a equipa a fim de reduzir a probabilidade do risco acontecer.
Planeamento de respostas
É nesta fase que deves desenvolver respostas para os teus riscos. Relembro uma vez mais que podes ter riscos positivos e riscos negativos. Na grande maioria das vezes os riscos positivos são esquecidos e apenas nos focamos no que pode correr mal.
Os tipos de resposta que podes ter face a um risco negativo são:
Evitar - O grande objetivo é suprimir o impacto ou a probabilidade do risco. Este tipo de resposta normalmente tem como reverso da medalha um trade-off com algo que pode ser importante para o projeto. Um bom exemplo deste tipo de resposta é reduzir o âmbito de forma a evitar atividades de alto risco, ou também evitar o uso de tecnologias mais inovadoras e ao invés disso adotar algo já conhecido.
Transferir - Trata-se de transferir a responsabilidade do risco para uma terceira parte. Um bom exemplo é fazer subcontratação, seguros, cauções, garantias entre outros.
Mitigar - A grande diferença entre este tipo de resposta e o primeiro que abordámos, deve-se ao facto de ao invés de suprimir um risco tenta-se reduzir o impacto e/ou probabilidade. Normalmente este tipo de resposta envolve algum tipo de custo associado. Um bom exemplo é o de formar utilizadores de uma nova aplicação para mitigar o seu uso incorreto, ou aumentar recursos ou prazo para mitigar atrasos no projeto.
Aceitar - Aqui aceita-se o risco, não alterando de todo o plano inicial. Normalmente executa-se esta ação quando a probabilidade do risco é muito baixa, ou quando não se conhecem respostas eficazes. Podes aceitar um risco de forma passiva, isto é, não fazer rigorosamente nada, ou podes aceitar de forma ativa, adicionando por exemplo contingência ao teu projeto.
Quanto aos tipos de resposta que podes ter face a um risco positivo são:
Explorar - Explorar a oportunidade para a conseguir garantir
Expandir - Tentar expandir ou aumentar a oportunidade
Partilhar - Partilhar o risco com outra parte que esteja mais bem posicionada para o aproveitar
Aceitar - Aceitar o risco positivo, sem influenciar
Finalmente quero só falar-te de vários tipos de planos de resposta a riscos que podes ter:
Plano de contingência - Plano de ações para riscos previstos
Fallback Plan - Plano alternativo caso o plano de contingência não funcione
Workaround plan - Atuação imediata e não planeada sobre um risco não previsto
Risco secundário - Risco despoletado por uma determinada resposta a outro risco
Risco residual - Risco que se mantém, mesmo após a resposta
Aqui falo novamente da importância de existirem revisões regulares aos teus riscos, já que deve ser sempre um tópico muito importante nas reuniões da equipa. Outro ponto muito importante é o de cada risco ter um owner, ou seja, uma pessoa que é responsável pelo desenvolvimento da resposta ao risco e pela monitorização dos seus triggers (eventos que fazem o risco acontecer).
Finalmente deverias fazer uma auditoria às respostas dos teus riscos. A ideia é que se examine e que se documente a eficácia dos planos de resposta ao risco utilizados. Uma auditoria permite ainda retirar lições aprendidas que serão úteis a este e a outros projetos futuros.
Bom, este post já vai longo, se chegaste até aqui muitos parabéns , espero que tenhas aprendido algo novo.