No post anterior, conversamos sobre o plano de gerenciamento dos riscos de projeto e a governança de riscos de uma organização.

A identificação dos riscos deve envolver os stakeholders do projeto, dentre eles: patrocinador, cliente, usuários, equipe e outros. Uma das técnicas mais tradicionais de identificação de riscos é o brainstorming e suas variações. Além disso, podemos utilizar também revisão de documentação, legislação e padrões, análise de histórico e lições aprendidas de projetos, comparação com outros projetos e / ou produtos relacionados.

É importante percorrer toda a documentação do projeto para identificar riscos. Os riscos devem ser pontuais, específicos. Procuramos riscos na Declaração de Escopo, na EAP, no Cronograma e suas tarefas, no Orçamento e nos recursos do projeto (RH, fornecedores etc). As outras áreas também podem trazer riscos. No livro Risk Management (2010), a Rita Mulcahy diz que se você identificou menos de 300 riscos, então não está fazendo gerenciamento de riscos do projeto.

Entretanto, é comum vermos os gerentes fazerem o plano de riscos como uma atividade burocrática, apenas para cumprir um checklist (ou para “inglês ver”). São pessoas que acreditam na sorte ou que enxergam “apagar incêndios” como sendo mais eficiente do que o gerenciamento de riscos.

Essa atitude é prejudicial ao projeto, pois o gerenciamento adequado dos riscos pode poupar muitos dissabores, além de permitir a melhor visualização de cenários, identificação de alternativas e as próprias respostas aos riscos. A maturidade em gerenciamento dos riscos poderia ser classificada em cinco níveis:

• Gerência de crise
• Corrigir falhas
• Mitigação de riscos
• Prevenção
• Eliminação da raiz do problema

Para nos ajudar nesta identificação, podemos utilizar checklists de riscos, Estrutura Analítica de Riscos e outras ferramentas.

As organizações criam, a partir do histórico e lições aprendidas, checklists de riscos mais completos para os próximos projetos, além de melhores e mais detalhadas estruturas analíticas de riscos. O Registro dos Riscos deve ser bem detalhado para possibilitar a análise dos riscos e o planejamento das respostas a eles. Um registro de riscos pode ter a forma abaixo:

Eu costumo indicar os riscos de escopo (pacotes de trabalho), cronograma (tarefas) e recursos no próprio MS-Project para projetos pequenos. Basta utilizar o campo de anotações das tarefas, descrevendo os riscos para tarefas, recursos, tarefa-resumo (pacotes de trabalho). Também é possível criar uma coluna customizada de riscos para isso, facilitando a visualização. A idéia de criar campos no MS-Project é para facilitar a visualização.

Embora seja possível incluir os riscos no MS-Project Professional, como mostrado acima, pode não ser suficiente. Para projetos maiores, um plano de riscos mais completo e detalhado, bem como o uso de uma ferramenta de monitoramento e controle dos riscos específica podem ser necessários. O MS-Project Server 2010 possui suporte para o gerenciamento de riscos dos projetos, utilizando páginas do Sharepoint e permitindo o armazenamento e uso de lições aprendidas, histórico e a criação de estruturas analíticas de riscos. Além disso, o MS-Project Server 2010 permite especificar a probabilidade e o impacto de cada risco, calculando a exposição de riscos dos projetos. Também é possível especificar acionadores (gatilhos) para identificar quando ocorreu um risco e qual plano de respostas ou contingências deve ser adotado para o mesmo.

Na próxima semana, conversaremos sobre análise de riscos.

Até lá!