O objetivo desta SP é identificar e documentar os riscos [SEI01]. A identificação de potenciais questões, perigos, ameaças e vulnerabilidades, com base na taxonomia que a organização definiu na estratégia de gerência de risco, que poderiam afetar negativamente os esforços ou plano de trabalho é a base para a gerência de risco.
Os riscos devem ser identificados e descritos de uma forma fácil de entender, antes que possam ser analisados e gerenciados de forma apropriada. Os riscos são documentados em uma declaração concisa que inclui o contexto, as condições e as conseqüências da ocorrência do risco.
Os riscos são identificados e analisados para determinar sua importância relativa
Atividades
O primeiro passo, segundo o CMMI-SE/SW [SEI01], é identificar os riscos associados a custo, cronograma e desempenho em todas as fases apropriadas do ciclo de vida do projeto para verificar a extensão do seu impacto nos objetivos do projeto. Porém a organização pode ter outras categorias de riscos identificadas na taxonomia que sejam prioritários. Com base nestas categorias, a organização deve buscar informações que podem ser usadas para identificar riscos. São exemplos de fontes de informação [PMI04] [SEI01]:
Fatores ambientes da organização - As informações publicadas, inclusive bancos de dados comerciais, estudos acadêmicos, benchmarking ou outros estudos do setor podem também ser úteis para a identificação de riscos;
Histórico de riscos em outros projetos - As informações sobre projetos anteriores podem estar disponíveis em arquivos de projetos anteriores, inclusive dados reais e lições aprendidas. Este histórico pode ser disponibilizado no RCO da organização; Declarações do escopo do projeto - A incerteza nas premissas do projeto deve ser
avaliada como causa potencial de riscos do projeto;
Plano de Gerência de Riscos - as atribuições de funções e responsabilidades, provisão para atividades de gerência de riscos no orçamento e no cronograma e categorias de risco podem ser fontes de riscos;
Plano de Gerência do Projeto - As saídas dos processos de outras áreas de conhecimento devem ser revisadas para identificar possíveis riscos em todo o projeto; WBS – Work Breakdown Structure do projeto – Cada elemento da estrutura de
decomposição do trabalho (WBS) deve ser revisado para descobrir riscos; Especialistas no assunto – Especialistas nos assuntos relacionados ao projeto;
Especificações de design e requisitos de acordos - Examinar especificações de design e requisitos
Para coletar informações nestas fontes, podem ser usadas as seguintes técnicas [PMI04] [MACHADO02]:
Revisão da documentação - Pode ser realizada uma revisão estruturada da documentação do projeto, incluindo planos, premissas, arquivos de projetos anteriores, taxonomias e outras informações. A qualidade dos planos e também a consistência entre esses planos e com as premissas e requisitos do projeto podem ser indicadores de risco do projeto;
Brainstorming - A meta do brainstorming é obter uma lista abrangente de riscos do projeto. A equipe do projeto normalmente realiza o brainstorming, freqüentemente com um conjunto multidisciplinar de especialistas que não fazem parte da equipe. Idéias sobre o risco do projeto são geradas sob a liderança de um facilitador, que pode ser o gerente do projeto ou o gerente de riscos, ao depender do porte. A taxonomia de riscos, definida pela organização, pode ser usada como uma referência. Em seguida, os riscos são identificados e categorizados por tipo de risco e suas definições são refinadas; Técnica Delphi - A técnica Delphi é um meio de alcançar um consenso entre
especialistas. Nesta técnica, os especialistas em riscos de projetos participam anonimamente. Um facilitador usa um questionário para solicitar idéias sobre os riscos importantes do projeto. As respostas são resumidas e então redistribuídas para os especialistas para comentários adicionais. O consenso pode ser alcançado após
algumas rodadas desse processo. A técnica Delphi ajuda a reduzir a parcialidade nos dados e evita que alguém possa indevidamente influenciar o resultado;
Entrevistas - As entrevistas com participantes experientes do projeto, partes interessadas no projeto e especialistas no assunto podem identificar os riscos. As entrevistas são uma das principais fontes de coleta de dados sobre identificação de riscos;
Taxonomias de risco – A organização pode se basear na taxonomia de riscos para coletar informações necessárias para a identificação de riscos;
Análise das premissas (cenários) - Todos os projetos são concebidos e desenvolvidos com base em um conjunto de hipóteses, cenários ou premissas. A análise das premissas é uma ferramenta que explora a validade das premissas conforme elas se aplicam ao projeto. Ela identifica os riscos do projeto causados pelo caráter inexato, inconsistente ou incompleto das premissas;
Comparação Análoga – Esse método identifica riscos com base na idéia que nenhum projeto representa um sistema totalmente novo, independente do quão avançado ou único ele seja. Para tanto, o método prevê a identificação de projetos similares, de modo que os dados destes projetos possam ser utilizados pelo projeto atual para a sua revisão ou para a sua própria elaboração.
Análise causal – Estes método mostra a relação entre um efeito e sua possível causa para que seja, verificada a origem e o risco. Entre os métodos empregados na análise causal estão: o diagrama de causa e efeito e os 6 W.
o Diagrama de causa e efeito - também conhecido como Espinha de peixe ou Diagrama de Ishiwaka (Figura 20). A filosofia da análise causal é que se um erro ocorrer, ele irá acontecer novamente, ao menos que se faça alguma coisa para evitá-lo.
o 6 Ws - baseada também em encontrar a origem das incertezas do projeto, e endereça-las por meio de 6 questões básicas: Who (Quem são os
stakeholders?), Why (O que os stakeholders querem alcançar?), What (No que
os stakeholders estão interessados?), Which way (De que maneira será feito?), Where whital (Quais recursos serão necessários?) e When (Quando terá que ser feito?).
Figura 20 - Diagrama de Causa e Efeito [MACHADO02].
Com base nestas técnicas, os stakeholders selecionados para a identificação de riscos na SP1.1, devem coletar informações sobre riscos e então identificar os riscos pertinentes ao
projeto. Para evitar que seja realizada uma outra reunião, esta SP pode ser executada durante a reunião de revisão das fontes de riscos e categorias.
Os riscos são incertezas relacionadas às fontes de risco. Por exemplo, uma incerteza sobre o perfil da mão de obra, ou sobre a data de entrega firmada com o cliente. Os riscos não necessariamente são iguais às fontes de riscos encontradas. As fontes de riscos e categorias servem como base para identificar os riscos. É necessário detalhar os riscos conforme as situações específicas encontradas pelos stakeholders durante a reunião. A Tabela 7mostra exemplos de riscos em projetos de software.
Tabela 7 - Exemplo de fontes de riscos, categorias e riscos
Categoria Fontes de Risco Risco
Equipe Novas tecnologias A equipe do projeto pode não se
adaptar a tempo a tecnologia Java Web Prazo Falta ou insuficiência de tempo para assegurar a
implementação das mudanças
Não há tempo suficiente para entregar o módulo 5
Técnico Dependência do sistema Não pode dar suporte a ferramenta
MobileCom, pois não apresenta rodar em sistemas operacionais UNIX
Projeto Tamanho do projeto Projeto grande (maior que 1 ano), com
atividades complexas (Mais de 20 pessoas)
Uma forma de descrever riscos é através de frases SE-ENTÃO (if-then) [ENGERT99]. Ao invés de apenar citar o problema ou causa, é criada uma descrição onde é apresentado o problema que pode ocorrer, e a consequência do problema caso ocorra. Como por exemplo: SE o contrato não for fechado antes do dia 30 de setembro, ENTÃO o programa perde
$8 milhões em investimentos;
SE notebooks comerciais sem customizações forem utilizados, ENTÃO a disponibilidade operacional não será adequada ao ambiente;
SE a versão 1.1 do programa X não for entregue com 1 mês de atraso, ENTÃO o projeto sofrerá um atraso significativo.
Após a identificação dos riscos, deve-se documentar o contexto, condições e impactos potenciais dos riscos identificados, de forma que os riscos possam ser facilmente entendidos. Nesta documentação do contexto do risco, deve ser considerado o intervalo de tempo relativo do risco, as circunstâncias ou condições em torno do risco e quaisquer dúvidas ou incertezas [SEI01]. Além disso, os stakeholders devem ser identificados e associados a cada risco. Com base nas informações coletadas até o momento da identificação de riscos, a
Tabela 8 mostra um exemplo de risco identificado. Os riscos podem ser documentados no registro de riscos.
A identificação de riscos deve ser feita em todas as iterações. Novos riscos podem surgir ao longo do ciclo de vida do projeto.
Tabela 8 - Exemplo de Risco (SP 2.1)
Id 1
Risco Falta de Envolvimento do usuário
Descrição do Risco Se o usuário não se envolver no projeto, então os requisitos podem não atender ao próprio usuário
Categoria Cliente/Usuário
Fonte de Risco Envolvimento do usuário
A Figura 21 apresenta um exemplo de registro de riscos usado pela organização para documentação dos riscos em uma lista.
Riscos identificados Id
Categoria Fonte de
Risco Se... Então... Probabilidade Impacto
Fator de Exposição << identificador único do risco >> << categoria do risco encontrado >> << fonte de risco >> << se determinada condição acontecer >> << então determinado impacto acontecerá >> << probabilidade do risco acontecer com base na escala definida >> << impacto caso o risco aconteça com base na escala definida >> << cálculo baseado na probabilidade e no impacto definido >>
Figura 21 - Exemplo de template para o registro dos riscos
SP 2.2 – Avaliar, Categorizar e Priorizar Riscos