definição: identificação de risco é o processo de determinação de riscos que podem potencialmente impedir o programa, empresa ou investimento de atingir os seus objectivos. Inclui documentação e comunicação da preocupação.
palavras-chave: risco, identificação de Risco, Gestão de risco
MITRE se Papéis & expectativas: os engenheiros de sistemas MITRE (SEs) que trabalham em programas governamentais são esperados para identificar riscos que poderiam impactar o projeto e programa. Espera-se que escrevam e revejam declarações de risco claras, inequívocas e apoiadas por elementos de prova .A identificação do risco é a primeira etapa crítica do processo de gestão do risco descrito na Figura 1.
o objetivo da identificação do risco é a identificação precoce e contínua de eventos que, se ocorrerem, terão impactos negativos na capacidade do projeto para alcançar objetivos de desempenho ou de resultados de capacidade. Podem ser provenientes do projecto ou de fontes externas.
existem vários tipos de avaliações de risco, incluindo avaliações de risco de programas, avaliações de risco para apoiar uma decisão de investimento, análise de alternativas e avaliações de incerteza operacional ou de custos. A identificação dos riscos deve corresponder ao tipo de avaliação necessário para apoiar a tomada de decisões com base nos riscos. Para um programa de aquisição, o primeiro passo é identificar as metas e objetivos do programa, promovendo assim um entendimento comum em toda a equipe do que é necessário para o sucesso do programa. Isto dá contexto e limites ao âmbito em que os riscos são identificados e avaliados.
identificar riscos no Programa de Engenharia de Sistemas
existem múltiplas fontes de risco. Para a identificação do risco, a equipe do projeto deve rever o escopo do programa, as estimativas de custos, o cronograma (para incluir a avaliação do caminho crítico), a maturidade técnica, os principais parâmetros de desempenho, os desafios de desempenho, as expectativas dos stakeholders vs. plano atual, dependências externas e internas, os desafios de implementação, integração, interoperabilidade, suporte, vulnerabilidades da cadeia de suprimentos, capacidade de lidar com ameaças, desvios de custos, expectativas de eventos de teste, segurança, e muito mais. Além disso, dados históricos de projetos semelhantes, entrevistas às partes interessadas e listas de risco fornecem informações valiosas sobre áreas para a consideração do risco.
a identificação do risco é um processo iterativo. À medida que o programa progride, mais informações serão obtidas sobre o programa (por exemplo, design específico), e a declaração de risco será ajustada para refletir o entendimento atual. Serão identificados novos riscos à medida que o projecto progride ao longo do ciclo de vida.
melhores práticas e lições aprendidas
Risco Operacional. Entenda a natureza operacional das capacidades que você está apoiando e o risco para os usuários finais, suas missões e suas operações das capacidades. A compreensão da necessidade/missão operacional (veja o tema de desenvolvimento de conceitos do Guia de Engenharia de Sistemas) irá ajudá-lo a apreciar a gravidade dos riscos e o impacto que eles poderiam ter para os usuários finais. Esta é uma parte crítica da análise de riscoperceber o impacto real que pode ocorrer se um risco surge durante a utilização Operacional. Normalmente os usuários operacionais estão dispostos a aceitar algum nível de risco se eles são capazes de cumprir a sua missão (por exemplo, garantia de missão), mas você precisa ajudar os usuários a entender os riscos que eles estão aceitando e para avaliar as opções, equilíbrios e alternativas disponíveis.
prazo de vencimento técnico. Trabalhar com e alavancar a indústria e a academia para entender as tecnologias que estão sendo consideradas para um esforço e a transição provável da tecnologia ao longo do tempo. Uma abordagem é trabalhar com fornecedores sob um acordo de não divulgação para entender as capacidades e para onde eles estão indo, de modo que o risco pode ser avaliado.
itens não relacionados com o desenvolvimento (NDI). O NDI inclui itens comerciais e governamentais. Para gerir o risco, considere a viabilidade do Fornecedor de NDI. O fornecedor tem quota de mercado? O prestador dispõe de uma longevidade adequada em comparação com os seus concorrentes? Como o provedor lida com problemas de capacidade e correções de lançamento, etc.? O que é a base de usuário para o NDI em particular? O provedor pode demonstrar a NDI, de preferência num ambiente semelhante ao do seu cliente? O governo pode usar a NDI para criar um protótipo? Todos estes factores ajudarão a avaliar o risco de viabilidade da NDI e do Fornecedor. Procurar respostas a estas perguntas de outros funcionários da MITRE que trabalharam na área ou utilizaram o NDI a ser avaliado.
controladores de aquisição. Enfatizar capacitadores de capacidade crítica, particularmente aqueles que têm alternativas limitadas. Avaliar e determinar os condutores primários para uma aquisição e enfatizar o risco associado na formulação de recomendações de mitigação de riscos. Se um aspecto específico de uma capacidade não for fundamental para o seu sucesso, o seu risco deve ser avaliado, mas não tem de ser o foco principal da gestão do risco. Por exemplo, se houver risco para uma interface de usuário proposta, mas o mercado tem inúmeras alternativas, o sucesso da abordagem proposta é provavelmente menos crítico para o sucesso global da capacidade. Por outro lado, é provável que um recurso de segurança da informação seja crítico. Se apenas uma abordagem alternativa satisfizer a necessidade, deve ser dada ênfase à mesma. Determinar os principais condutores de sucesso avaliando necessidades e projetos, e determinar as alternativas que existem. É uma solução única no caminho crítico para o sucesso? Certifique-se de que as análises do caminho crítico incluem todo o ciclo de engenharia do sistema e não apenas o desenvolvimento (ou seja, o desenvolvimento do sistema, por si só, pode ser um “pedaço de bolo”, mas fielding em uma situação operacional ativa pode ser um grande risco).
Use capability evolution to manage risk. Se os requisitos específicos estiverem a conduzir a implementação de capacidades de alto risco devido a um desenvolvimento único, necessidades de desempenho de topo de gama, etc., os requisitos devem ser discutidos com os usuários por sua criticidade. Pode ser que a necessidade possa ser adiada, e a comunidade para o desenvolvimento deve avaliar quando poderá ser satisfeita no futuro. Ajudar os usuários e desenvolvedores a avaliar quanto risco (e impacto de programação e custo) uma capacidade particular deve assumir em relação aos requisitos para receber capacidades menos arriscadas mais cedo. Ao desenvolver as suas recomendações, considere a viabilidade técnica e o conhecimento de sucessos de implementação relacionados e falhas para avaliar o risco de implementação agora em vez do futuro. Ao adiar as capacidades, tome cuidado para não cair na armadilha de adiar o fracasso final negociando sucessos fáceis a curto prazo para um futuro de múltiplos requisitos de alto risco que podem ser essenciais para o sucesso global.
Principais Parâmetros De Desempenho (PPP). Trabalhar em estreita colaboração com os utilizadores para estabelecer as PPP. O risco geral de cancelamento do programa pode ser centrado no fracasso em atender às PPP. Trabalhar com os usuários para garantir que os parâmetros são sensíveis às necessidades da missão e tecnicamente exequíveis. Os parâmetros não devem ser tão brandos que possam ser facilmente atendidos, mas não satisfazer a necessidade da missão; nem devem ser tão rigorosos que não possam ser atendidos sem um esforço extensivo ou empurrando Tecnologiaqualquer um dos quais pode colocar um programa em risco. Procurar resultados de operações passadas, experimentos, avaliações de desempenho e implementações da indústria para ajudar a determinar a viabilidade de desempenho.
dependências externas e internas. Ter uma perspectiva empresarial pode ajudar acquirers, gerentes de programas, Desenvolvedores, integradores e usuários a apreciar o risco de dependências de um esforço de desenvolvimento. Com o surgimento de abordagens orientadas a serviços, UM programa se tornará mais dependente da disponibilidade e operação de serviços prestados por outros que eles pretendem usar nos esforços de desenvolvimento de seu programa. Trabalhar com os desenvolvedores de serviços para garantir serviços de qualidade estão sendo criados, e pensamento foi colocado na manutenção e evolução desses serviços. Trabalhar com a equipe do programa de desenvolvimento para avaliar os serviços disponíveis, sua qualidade e o risco que um programa tem em usar e confiar no serviço. Do mesmo modo, existe um risco associado à criação do serviço e não à utilização de serviços de outro esforço empresarial. Ajudar a determinar os riscos e benefícios potenciais da criação de um serviço interno para o desenvolvimento com, possivelmente, uma transição para o serviço da empresa em algum momento futuro.
integração e interoperabilidade (i&I). Quase sempre serei um factor de risco. Trata-se de formas de dependências em que o valor da integração ou interoperação foi considerado como ultrapassando os seus riscos inerentes. Técnicas como a arquitectura da Federação empresarial, capacidades de compostagem a pedido e padrões de design podem ajudar o governo a planear e executar uma rota para navegar pelos riscos i&I. Consultar a secção de Engenharia Empresarial do Guia de Engenharia de sistemas para artigos sobre técnicas de abordagem dos riscos associados i&I.Segurança da Informação. A segurança da informação é um risco em quase todos os desenvolvimentos. Parte disso deve-se à singularidade das necessidades e exigências do governo nesta área. Parte disso deve-se às dificuldades inerentes à luta contra os ciberataques. Criar capacidades defensivas para cobrir o espectro de ataques é desafiador e arriscado. Ajudar o governo a desenvolver abordagens de resiliência (por exemplo, planos de contingência, backup/recuperação, etc.). Permitir o compartilhamento de informações entre sistemas em operações de coalizão com parceiros internacionais apresenta desafios técnicos e questões políticas que se traduzem em risco de desenvolvimento. As questões de segurança da informação associadas à gestão da cadeia de abastecimento são tão amplas e complexas que mesmo manter uma consciência rudimentar das ameaças é um tremendo desafio.
nível de habilidade. O nível de habilidade ou experiência dos desenvolvedores, integradores, governo e outros stakeholders pode levar a riscos. Esteja atento a habilidades insuficientes e alcance através da corporação para preencher quaisquer lacunas. Ao fazê-lo, ajude a educar os membros da equipe do governo ao mesmo tempo que você está trazendo habilidades corporativas e experiência para suportar.
riscos de custo. Programas tipicamente criam uma estimativa de custos do governo que considera o risco. À medida que você desenvolver e aperfeiçoar os riscos técnicos e outros do programa, as estimativas de custos associadas devem evoluir, também. A estimativa dos custos não é uma actividade única.
informação histórica como guia de identificação de riscos. Informações históricas de programas semelhantes do governo podem fornecer informações valiosas sobre os riscos futuros. Procurar informações sobre desafios e Riscos Operacionais em várias lições de operação aprendidas, após relatórios de ação, resumos de exercícios e resultados de experimentação. Os clientes muitas vezes têm repositórios destes para acessar. Os líderes governamentais normalmente comunicam as suas necessidades e desafios estratégicos. Compreenda e integre estes elementos na sua avaliação das capacidades mais importantes necessárias para o seu cliente e como base para a avaliação de riscos.Dados históricos para ajudar a avaliar o risco estão frequentemente disponíveis a partir das avaliações de desempenho anteriores e lições aprendidas sobre programas de aquisição e contratantes. Em muitos casos, os funcionários da MITRE ajudarão o governo na preparação de informações de desempenho para uma determinada aquisição. O AF tem um guia de Avaliação de desempenho passado (PPEG) que identifica o tipo de informação a capturar que pode ser usado para futuras seleções de fontes governamentais . Este repositório de informações pode ajudar a fornecer informações de base sobre desafios anteriores e onde eles podem surgir novamentetanto para o tipo particular de atividade de desenvolvimento, bem como com os contratantes particulares.
existem numerosas avaliações técnicas para produtos de fornecedores que podem ser acessados para determinar o risco e viabilidade de vários produtos. Um repositório MITRE de avaliações de ferramentas é o divisor de ferramentas de análise que contém orientação e experiência com ferramentas analíticas. Utilizar recursos como estes e procurar outros que tenham experimentado produtos e técnicas em protótipos e experiências pode ajudar a avaliar os riscos para um esforço particular.
como escrever um risco — uma melhor prática . Um protocolo de melhores práticas para escrever uma declaração de risco é a condição-se-então construir. Este protocolo aplica-se a processos de gestão de riscos concebidos para quase qualquer ambiente. É um reconhecimento de que um risco, pela sua natureza, é probabilístico e que, se ocorrer, tem consequências indesejadas.
Qual é a condição-se – então construir? A condição reflete o que é conhecido hoje. É a causa principal do evento de risco identificado. Assim, a condição é um evento que ocorreu, está ocorrendo atualmente, ou irá ocorrer com certeza. Eventos de risco São eventos futuros que podem ocorrer devido à condição presente. Segue – se uma ilustração deste protocolo.
o acontecimento de risco associado à condição presente. É extremamente importante reconhecer o se e a condição como um dual. Quando examinados em conjunto, podem existir formas de intervir directamente ou remediar a raiz (condição) subjacente do evento de risco, de modo a que as consequências deste acontecimento, se ocorrer, deixem de ameaçar o projecto. A Fi é a parte probabilística da declaração de risco.
The Then is the consequence, or set of consequences, that will impact the engineering system project if the risk event occurs. Um exemplo de uma condição-se-então a construção é ilustrada na Figura 2.
incentivar as equipas a identificar os riscos. A cultura em alguns projetos e programas governamentais desencoraja a identificação de riscos. Isso pode acontecer porque as atividades de gestão de risco de rastreamento, monitoramento e mitigação dos riscos são vistas como onerosas e inúteis. Nesta situação, pode ser útil falar com as equipes sobre os benefícios da identificação de riscos e a incapacidade de geri – lo tudo em suas cabeças (e.g., determinar a prioridade, quem precisa estar envolvido, ações de mitigação). Ajudar as equipes do governo na execução de um processo que equilibre o investimento de gestão com valor para os resultados do projeto. Em geral, está a ser alcançado um bom equilíbrio quando o âmbito, o calendário e os objectivos de custos do projecto estão a ser cumpridos ou mitigados com êxito por planos de acção, e a equipa do projecto considera que as actividades de gestão de riscos dão valor ao projecto. A representação entre equipas é uma obrigação; os riscos não devem ser identificados por um indivíduo ou estritamente pela equipa de engenharia de sistemas (ver fontes de risco acima).
considere fatores organizacionais e ambientais. Os factores organizacionais, culturais, políticos e outros factores ambientais, tais como o apoio das partes interessadas ou as prioridades organizacionais, podem representar tanto ou mais risco para um projecto do que apenas factores técnicos. Estes riscos devem ser identificados e activamente atenuados ao longo da vida do projecto. As atividades de mitigação podem incluir o monitoramento de mandatos legislativos ou mudanças de emergência que possam afetar o programa ou missão de projeto, mudanças organizacionais que possam afetar as exigências do usuário ou a utilidade de capacidade, ou mudanças no apoio político que possam afetar o financiamento. Em cada caso, considere o risco para o programa e identifique opções de ação para discussão com os stakeholders. Para informações adicionais, consulte o artigo de Planejamento, Implementação e monitoramento de progresso da mitigação de riscos.
incluem as partes interessadas na identificação dos riscos. Projetos e programas geralmente têm vários stakeholders que trazem várias dimensões de risco para os resultados. Incluem os operadores, que podem estar sobrecarregados com novos sistemas; os utilizadores, que podem não ter formação adequada ou têm receios pelos seus empregos; os supervisores que podem não apoiar uma nova capacidade porque parece diminuir a sua autoridade; e os decisores políticos, que estão preocupados com a aprovação legislativa e os custos. Além disso, é importante incluir todos os stakeholders, tais como as autoridades de certificação e acreditação que, se inadvertidamente negligenciadas, podem colocar riscos importantes mais tarde no programa. As partes interessadas podem ser conscientes dos diversos fatores ambientais, tais como legislação pendente ou programa político de apoio que podem representar riscos para um projeto que são desconhecidos para o governo ou MITRE equipe do projeto. Incluir as partes interessadas no processo de identificação de riscos para ajudar a emergir esses riscos.
escreva declarações de risco claras. O uso do formato condição-If-então ajuda a comunicar e avaliar uma declaração de risco e desenvolver uma estratégia de mitigação. A causa é a Condição subjacente, que introduziu o risco (por exemplo, uma abordagem de design pode ser a causa), o que Se reflecte a probabilidade (por exemplo, a probabilidade avaliação de que a parte Se da declaração de risco ocorrer), e, em Seguida, comunica o impacto do programa (por exemplo, o aumento de recursos para oferecer suporte a testes adicionais agenda, e a preocupação em satisfazer o desempenho). A estratégia de mitigação é quase sempre melhor quando baseada em uma declaração de risco claramente articulada.
esperar alterações na declaração de riscos à medida que a estratégia de Avaliação e mitigação de riscos é desenvolvida. É comum ter declarações de risco aperfeiçoadas uma vez que a equipe avalia o impacto. Ao avaliar e documentar o potencial impacto do risco (custo, calendário, técnico ou calendário), a compreensão e a declaração do risco podem mudar. Por exemplo, ao avaliar o risco de impacto de software de alteração de cronograma, a declaração de risco pode ser refinado para incluir a necessidade-por data e/ou esclarecimento adicional de impacto (por exemplo, se o software xyz não é entregue até Março de 2015, então não haverá tempo suficiente para testar a interface de trocas antes de Usuário Limitado de Teste).
não incluem a declaração de mitigação na declaração de risco. Tenha cuidado para não cair na armadilha de ter a declaração de mitigação introduzida na declaração de risco. Um risco é uma incerteza com potencial impacto negativo. Alguns saltam rapidamente para a conclusão da mitigação do risco e, em vez de identificar o risco que deve ser mitigado (com opções de mitigação identificadas), identificam o risco como uma abordagem de projeto sub-ótima. Por exemplo, uma declaração de risco pode ser: se o CONTRATANTE não usar XYZ para o teste, então o teste vai falhar. A preocupação é realmente testar a suficiência. Se o CONTRATANTE não realizar o teste com resultados mensuráveis para a análise, então o programa não pode passar no teste do usuário limitado. O uso de XYZ pode ser uma opção de mitigação para reduzir o risco de suficiência do teste.
não Saltar para uma estratégia de mitigação antes de avaliar a probabilidade de risco e o impacto. Um risco pode ser refinado ou alterado em função de uma análise mais aprofundada, o que pode afetar o que a mitigação mais eficiente/desejada pode ser. Engenheiros muitas vezes saltam para a solução; é melhor passar para o próximo passo discutido no artigo de Avaliação de Impacto de risco e priorização para decompor e entender o problema primeiro. Em última análise, isso conduzirá a uma estratégia que esteja estreitamente alinhada com a preocupação.
References & Resources
- The MITRE Institute, September 1, 2007, MITRE Systems Engineering (SE) Competency Model, Version 1, pp. 10, 40-41.
- Garvey, P. R., 2008, Analytical Methods for Risk Management: A Systems Engineering Perspective, Chapman-Hall/CRC-Press, Taylor & Francis Group (UK), Boca Raton, London, New York, ISBN: 1584886374.U. S. Air Force, January 2008, Air Force Past Performance Evaluation Guide(PPEG), IG5315.305 (a).
- U. S. Air Force, January 2008, Air Force Past Performance Evaluation Guide( PPEG), IG5315.305(a).
Referências adicionais& recursos
MITRE E520 Análise de risco e Gestão listas técnicas de Controlo da Equipa Técnica, verificações de Risco, Análise de risco e documentos de gestão.
Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK Guide), 4th Edition, ANSI/PMI 99-001-2008, pp. 273-312, accessed March 2, 2010.
SEPO, “Standard Process/Steps of Process, Step 2: Identify Risks & Hazards,” MITRE SEPO Risk Management Toolkit, accessed May 5, 2010.
