Définition : L’identification des risques est le processus de détermination des risques qui pourraient potentiellement empêcher le programme, l’entreprise ou l’investissement d’atteindre ses objectifs. Cela comprend la documentation et la communication de la préoccupation.
Mots clés: risque, identification des risques, gestion des risques
Rôles MITRE SE & Attentes: Les ingénieurs systèmes MITRE (SES) travaillant sur des programmes gouvernementaux sont censés identifier les risques qui pourraient avoir une incidence sur le projet et le programme. On s’attend à ce qu’ils rédigent et examinent des énoncés de risque clairs, sans ambiguïté et étayés par des preuves.
Contexte
L’identification des risques est la première étape critique du processus de gestion des risques illustré à la figure 1.
L’objectif de l’identification des risques est l’identification précoce et continue des événements qui, s’ils se produisent, auront des répercussions négatives sur la capacité du projet d’atteindre les objectifs de rendement ou de rendement. Ils peuvent provenir de l’intérieur du projet ou de sources externes.
Il existe plusieurs types d’évaluations des risques, y compris les évaluations des risques liés aux programmes, les évaluations des risques à l’appui d’une décision d’investissement, l’analyse des solutions de rechange et les évaluations de l’incertitude opérationnelle ou des coûts. L’identification des risques doit correspondre au type d’évaluation requis pour appuyer la prise de décision éclairée par les risques. Pour un programme d’acquisition, la première étape consiste à identifier les buts et objectifs du programme, favorisant ainsi une compréhension commune au sein de l’équipe de ce qui est nécessaire à la réussite du programme. Cela donne un contexte et limite la portée par laquelle les risques sont identifiés et évalués.
Identification des risques dans le Programme d’ingénierie des systèmes
Les sources de risque sont multiples. Pour l’identification des risques, l’équipe de projet doit examiner la portée du programme, les estimations des coûts, le calendrier (pour inclure l’évaluation du chemin critique), la maturité technique, les paramètres de performance clés, les défis de performance, les attentes des parties prenantes par rapport au plan actuel, les dépendances externes et internes, les défis de mise en œuvre, l’intégration, l’interopérabilité, la supportabilité, les vulnérabilités de la chaîne d’approvisionnement, la capacité à gérer les menaces, les écarts de coûts, les attentes des événements tests, la sûreté, la sécurité, etc. De plus, les données historiques de projets similaires, les entrevues avec les intervenants et les listes de risques fournissent des informations précieuses sur les domaines à prendre en compte.
L’identification des risques est un processus itératif. Au fur et à mesure que le programme progressera, on obtiendra plus d’informations sur le programme (p. ex., sa conception spécifique) et l’énoncé des risques sera ajusté pour refléter la compréhension actuelle. De nouveaux risques seront identifiés à mesure que le projet progressera tout au long du cycle de vie.
Meilleures pratiques et leçons apprises
Risque opérationnel. Comprenez la nature opérationnelle des capacités que vous prenez en charge et le risque pour les utilisateurs finaux, leurs missions et leurs opérations des capacités. La compréhension du besoin / de la mission opérationnelle (voir le sujet de développement de concept du Guide d’ingénierie des systèmes) vous aidera à apprécier la gravité des risques et l’impact qu’ils pourraient avoir sur les utilisateurs finaux. Il s’agit d’une partie essentielle de l’analyse des risques la réalisation de l’impact réel qui peut se produire si un risque survient pendant l’utilisation opérationnelle. Généralement, les utilisateurs opérationnels sont prêts à accepter un certain niveau de risque s’ils sont en mesure d’accomplir leur mission (par exemple, l’assurance de la mission), mais vous devez aider les utilisateurs à comprendre les risques qu’ils acceptent et à évaluer les options, les soldes et les alternatives disponibles.
Maturité technique. Travailler avec l’industrie et le milieu universitaire et en tirer parti pour comprendre les technologies envisagées pour un effort et la transition probable de la technologie au fil du temps. Une approche consiste à travailler avec les fournisseurs dans le cadre d’un accord de non-divulgation pour comprendre les capacités et où ils vont, afin que le risque puisse être évalué.
Éléments non développementaux (IDN). L’IDN comprend des articles commerciaux et des articles gouvernementaux. Pour gérer les risques, tenez compte de la viabilité du fournisseur de NDI. Le fournisseur a-t-il des parts de marché? Le fournisseur a-t-il une longévité appropriée par rapport à ses concurrents? Comment le fournisseur résout-il les problèmes de capacité et les correctifs de publication, etc.? Quelle est la base d’utilisateurs pour le NDI particulier ? Le fournisseur peut-il démontrer le NDI, de préférence dans un cadre similaire à celui de votre client? Le gouvernement peut-il utiliser l’IDN pour créer un prototype? Tous ces facteurs aideront à évaluer le risque de viabilité de l’IDN et du fournisseur. Demandez des réponses à ces questions à d’autres membres du personnel de MITRE qui ont travaillé dans la région ou qui ont utilisé l’IDN évaluée.
Pilotes d’acquisition. Mettre l’accent sur les facilitateurs de capacités critiques, en particulier ceux qui ont des alternatives limitées. Évaluer et déterminer les principaux moteurs d’une acquisition et mettre l’accent sur le risque associé lors de la formulation de recommandations d’atténuation des risques. Si un aspect particulier d’une capacité n’est pas essentiel à son succès, son risque doit être évalué, mais il n’est pas nécessaire qu’il soit le principal objectif de la gestion des risques. Par exemple, s’il existe un risque pour une interface utilisateur proposée, mais que le marché offre de nombreuses solutions de rechange, le succès de l’approche proposée est probablement moins critique pour le succès global de la capacité. D’un autre côté, une fonctionnalité de sécurité de l’information est susceptible d’être critique. Si une seule autre approche répond au besoin, l’accent devrait être mis sur celle-ci. Déterminez les principaux facteurs de réussite en évaluant les besoins et les conceptions et en déterminant les alternatives qui existent. Une solution unique est-elle sur le chemin critique du succès? Assurez-vous que les analyses du chemin critique comprennent l’ensemble du cycle d’ingénierie du système et pas seulement le développement (c.-à-d. que le développement du système, en soi, peut être un « morceau de gâteau », mais que le déploiement dans une situation opérationnelle active peut représenter un risque majeur).
Utiliser l’évolution des capacités pour gérer les risques. Si des exigences particulières entraînent la mise en œuvre de capacités à haut risque en raison d’un développement unique, de besoins de performances à la limite de l’enveloppe, etc., les exigences doivent être discutées avec les utilisateurs pour leur criticité. Il se peut que le besoin soit reporté, et la communauté du développement devrait évaluer quand il pourrait être satisfait à l’avenir. Aidez les utilisateurs et les développeurs à évaluer le risque (et l’impact sur le calendrier et les coûts) qu’une capacité particulière devrait assumer par rapport aux exigences pour recevoir des capacités moins risquées plus tôt. En élaborant vos recommandations, tenez compte de la faisabilité technique et de la connaissance des succès et des échecs de mise en œuvre connexes pour évaluer le risque de mise en œuvre maintenant plutôt que dans le futur. En différant les capacités, veillez à ne pas tomber dans le piège de reporter l’échec final en échangeant des succès faciles à court terme contre un avenir de multiples exigences à haut risque qui peuvent être essentielles à la réussite globale.
Paramètres de performance clés (KPPs). Travailler en étroite collaboration avec les utilisateurs pour établir des KPP. Le risque global d’annulation du programme peut être centré sur le non-respect des PPC. Travailler avec les utilisateurs pour s’assurer que les paramètres sont adaptés aux besoins de la mission et techniquement réalisables. Les paramètres ne doivent pas être si indulgents qu’ils peuvent facilement être respectés, mais ne répondent pas aux besoins de la mission; ils ne doivent pas non plus être si rigoureux qu’ils ne peuvent être respectés sans un effort important ou une technologie poussée ce qui peut mettre un programme en danger. Rechercher les résultats des opérations passées, des expériences, des évaluations des performances et des implémentations industrielles pour aider à déterminer la faisabilité des performances.
Dépendances externes et internes. Avoir une perspective d’entreprise peut aider les acquéreurs, les gestionnaires de programmes, les développeurs, les intégrateurs et les utilisateurs à apprécier les risques liés aux dépendances d’un effort de développement. Avec l’émergence d’approches axées sur les services, un programme deviendra plus dépendant de la disponibilité et de l’exploitation des services fournis par d’autres personnes qu’ils ont l’intention d’utiliser dans les efforts de développement de leur programme. Travailler avec les développeurs de services pour assurer la création de services de qualité et réfléchir à la maintenance et à l’évolution de ces services. Travailler avec le personnel du programme de développement pour évaluer les services disponibles, leur qualité et le risque qu’un programme présente en utilisant et en s’appuyant sur le service. De même, il existe un risque associé à la création du service et au fait de ne pas utiliser les services d’une autre entreprise. Aider à déterminer les risques et les avantages potentiels de la création d’un service interne au développement avec éventuellement une transition vers le service d’entreprise à un moment donné.
Intégration et interopérabilité (I &I). I & Je serai presque toujours un facteur de risque majeur. Ce sont des formes de dépendances dans lesquelles la valeur de l’intégration ou de l’interopérabilité a été jugée supérieure à leurs risques inhérents. Des techniques telles que l’architecture de la fédération d’entreprise, les capacités composables à la demande et les modèles de conception peuvent aider le gouvernement à planifier et à exécuter un itinéraire pour naviguer dans les risques I & I. Reportez-vous à la section Ingénierie d’entreprise du Guide d’ingénierie des systèmes pour des articles sur les techniques permettant de traiter les risques associés à I &I.
Sécurité de l’information. La sécurité de l’information est un risque dans presque tous les développements. Cela est en partie dû au caractère unique des besoins et des exigences du gouvernement dans ce domaine. Cela s’explique en partie par les difficultés inhérentes à la lutte contre les cyberattaques. Créer des capacités défensives pour couvrir le spectre des attaques est difficile et risqué. Aider le gouvernement à élaborer des approches de résilience (p. ex. plans d’urgence, mesures de secours/rétablissement, etc.). Permettre le partage d’informations entre les systèmes dans le cadre d’opérations de coalition avec des partenaires internationaux présente des défis techniques et des problèmes de politique qui se traduisent par des risques de développement. Les problèmes de sécurité de l’information associés à la gestion de la chaîne d’approvisionnement sont si vastes et complexes que même le maintien d’une connaissance rudimentaire des menaces est un défi énorme.
Niveau de compétence. Le niveau de compétence ou d’expérience des développeurs, des intégrateurs, du gouvernement et d’autres parties prenantes peut entraîner des risques. Soyez à l’affût des compétences insuffisantes et atteignez l’ensemble de la société pour combler les lacunes. Ce faisant, aidez à éduquer les membres de l’équipe gouvernementale tout en mettant à profit vos compétences et votre expérience en entreprise.
Risques liés aux coûts. Les programmes créent généralement une estimation des coûts du gouvernement qui tient compte du risque. Au fur et à mesure que vous élaborez et affinez les risques techniques et autres du programme, les estimations de coûts connexes devraient également évoluer. L’estimation des coûts n’est pas une activité ponctuelle.
Informations historiques comme guide pour l’identification des risques. Les informations historiques provenant de programmes gouvernementaux similaires peuvent fournir des informations précieuses sur les risques futurs. Recherchez des informations sur les défis opérationnels et les risques dans diverses leçons d’exploitation apprises, des rapports d’action, des résumés d’exercices et des résultats d’expérimentation. Les clients ont souvent accès à des référentiels de ceux-ci. Les dirigeants du gouvernement communiquent normalement leurs besoins et leurs défis stratégiques. Comprenez et intégrez-les dans votre évaluation des capacités les plus importantes dont votre client a besoin et comme base pour l’évaluation des risques.
Des données historiques pour aider à évaluer les risques sont fréquemment disponibles à partir des évaluations de rendement passées et des leçons apprises des programmes d’acquisition et des entrepreneurs. Dans de nombreux cas, le personnel du MITRE aidera le gouvernement à préparer des informations sur le rendement pour une acquisition particulière. La FA dispose d’un Guide d’évaluation du rendement passé (GEPP) qui identifie le type d’information à saisir qui peut être utilisé pour la sélection future de sources gouvernementales. Ce répertoire d’informations peut aider à fournir des informations de base sur les défis antérieurs et les endroits où ils pourraient se présenter à nouveau tant pour le type particulier d’activité de développement que pour les contractants particuliers.
Il existe de nombreuses évaluations techniques pour les produits des fournisseurs accessibles pour déterminer le risque et la viabilité de divers produits. Un référentiel MITRE d’évaluations d’outils est l’ensemble d’outils d’analyse qui contient des conseils et de l’expérience avec les outils d’analyse. L’utilisation de ressources comme celles-ci et la recherche d’autres personnes qui ont essayé des produits et des techniques dans des prototypes et des expériences peuvent aider à évaluer les risques pour un effort particulier.
Comment écrire un risquea une meilleure pratique. Un protocole de bonnes pratiques pour la rédaction d’une déclaration de risque est la construction Condition-Si-Alors. Ce protocole s’applique aux processus de gestion des risques conçus pour presque tous les environnements. C’est une reconnaissance du fait qu’un risque, de par sa nature, est probabiliste et que, s’il se produit, il a des conséquences indésirables.
Quelle est la construction Condition-Si-Alors? La condition reflète ce qui est connu aujourd’hui. C’est la cause première de l’événement à risque identifié. Ainsi, la Condition est un événement qui s’est produit, qui se produit actuellement ou qui se produira avec certitude. Les événements à risque sont des événements futurs qui peuvent survenir en raison de la condition présente. Vous trouverez ci-dessous une illustration de ce protocole.
La Fi est l’événement à risque associé à la condition présente. Il est extrêmement important de reconnaître le Si et la condition comme un double. Lorsqu’il est examiné conjointement, il peut y avoir des moyens d’intervenir directement ou de remédier à la racine (Condition) sous-jacente de l’événement à risque de sorte que les conséquences de cet événement, s’il se produit, ne menacent plus le projet. La FI est la partie probabiliste de l’énoncé de risque.
C’est alors la conséquence, ou l’ensemble des conséquences, qui aura une incidence sur le projet de système d’ingénierie si l’événement à risque se produit. Un exemple de construction de Condition-Si-Alors est illustré à la figure 2.
Encourage les équipes à identifier les risques. La culture de certains projets et programmes gouvernementaux décourage l’identification des risques. Cela peut survenir parce que les activités de gestion des risques de suivi, de surveillance et d’atténuation des risques sont considérées comme lourdes et inutiles. Dans cette situation, il peut être utile de parler aux équipes des avantages de l’identification des risques et de l’incapacité à tout gérer dans vos têtes (p. ex., déterminer la priorité, qui doit être impliqué, mesures d’atténuation). Aider les équipes gouvernementales à exécuter un processus qui équilibre l’investissement de la gestion avec la valeur des résultats du projet. En général, un bon équilibre est atteint lorsque la portée, le calendrier et les objectifs de coûts du projet sont atteints ou atténués avec succès par des plans d’action, et l’équipe de projet croit que les activités de gestion des risques apportent une valeur au projet. La représentation inter-équipe est indispensable; les risques ne doivent pas être identifiés par un individu, ni strictement par l’équipe d’ingénierie des systèmes (examiner les sources de risque ci-dessus).
Tenir compte des facteurs organisationnels et environnementaux. Les facteurs organisationnels, culturels, politiques et autres facteurs environnementaux, tels que le soutien des intervenants ou les priorités organisationnelles, peuvent présenter autant ou plus de risques pour un projet que les facteurs techniques seuls. Ces risques devraient être identifiés et atténués activement tout au long de la durée du projet. Les activités d’atténuation pourraient comprendre la surveillance des mandats législatifs ou des changements d’urgence qui pourraient avoir une incidence sur la mission du programme ou du projet, des changements organisationnels qui pourraient avoir une incidence sur les besoins des utilisateurs ou l’utilité des capacités, ou des changements dans le soutien politique qui pourraient avoir une incidence sur le financement. Dans chaque cas, tenez compte du risque pour le programme et déterminez les options d’action à discuter avec les intervenants. Pour plus d’informations, consultez l’article Planification de l’atténuation des risques, Mise en œuvre et Suivi des progrès.
Inclure les parties prenantes dans l’identification des risques. Les projets et les programmes ont généralement plusieurs intervenants qui apportent diverses dimensions de risque aux résultats. Il s’agit notamment des opérateurs, qui pourraient être submergés par les nouveaux systèmes; des utilisateurs, qui pourraient ne pas être correctement formés ou avoir des craintes pour leur emploi; des superviseurs qui pourraient ne pas soutenir une nouvelle capacité car elle semble diminuer leur autorité; et les décideurs, qui sont préoccupés par l’approbation législative et le coût. De plus, il est important d’inclure tous les intervenants, tels que les autorités de certification et d’accréditation, qui, s’ils sont négligés par inadvertance, peuvent poser des risques majeurs plus tard dans le programme. Les intervenants peuvent être très conscients de divers facteurs environnementaux, tels que des mesures législatives en cours ou un soutien à un programme politique, qui peuvent présenter des risques pour un projet inconnus du gouvernement ou de l’équipe de projet MITRE. Inclure les intervenants dans le processus d’identification des risques pour aider à faire ressortir ces risques.
Rédigez des énoncés de risque clairs. L’utilisation du format Condition-If-Then permet de communiquer et d’évaluer un énoncé de risque et d’élaborer une stratégie d’atténuation. La cause première est la condition sous-jacente qui a introduit le risque (p. ex., une approche conceptuelle pourrait en être la cause), la Fi reflète la probabilité (p. ex., évaluation de la probabilité que la partie de la Fi de l’énoncé de risque devait se produire), puis communique l’impact au programme (p. ex., augmentation des ressources pour soutenir les tests, calendrier supplémentaire et souci d’atteindre le rendement). La stratégie d’atténuation est presque toujours meilleure lorsqu’elle est basée sur une déclaration de risque clairement articulée.
Attendez-vous à des modifications de l’énoncé des risques au fur et à mesure de l’élaboration de la stratégie d’évaluation et d’atténuation des risques. Il est courant que les énoncés de risque soient affinés une fois que l’équipe en a évalué l’impact. Lors de l’évaluation et de la documentation de l’impact potentiel du risque (coût, calendrier, technique ou calendrier), la compréhension et l’énoncé du risque peuvent changer. Par exemple, lors de l’évaluation d’un impact sur le risque d’un glissement de calendrier logiciel, l’énoncé de risque pourrait être affiné pour inclure la date limite de nécessité et/ ou des précisions supplémentaires sur l’impact (par exemple, si le logiciel xyz n’est pas livré d’ici mars 2015, il n’y aura pas suffisamment de temps pour tester les échanges d’interface avant un test limité par l’utilisateur).
N’incluez pas l’énoncé d’atténuation dans l’énoncé de risque. Veillez à ne pas tomber dans le piège de l’introduction de la déclaration d’atténuation dans la déclaration de risque. Un risque est une incertitude avec un impact négatif potentiel. Certains sautent rapidement à la conclusion de l’atténuation du risque et, au lieu d’identifier le risque qui devrait être atténué (avec des options d’atténuation identifiées), ils identifient le risque comme une approche de conception sous-optimale. Par exemple, une déclaration de risque pourrait être la suivante : Si l’entrepreneur n’utilise pas XYZ pour le test, le test échouera. La préoccupation est vraiment la suffisance des tests. Si l’entrepreneur n’effectue pas le test avec des résultats mesurables pour l’analyse, le programme peut ne pas réussir le test d’utilisateur limité. L’utilisation de XYZ peut être une option d’atténuation pour réduire le risque de suffisance du test.
Ne passez pas à une stratégie d’atténuation avant d’évaluer la probabilité de risque et l’impact. Un risque peut être affiné ou modifié à la suite d’une analyse plus approfondie, ce qui pourrait influer sur l’atténuation la plus efficace / souhaitée. Les ingénieurs passent souvent à la solution ; il est préférable de passer à l’étape suivante abordée dans l’article Évaluation de l’impact des risques et établissement des priorités pour décomposer et comprendre le problème en premier. En fin de compte, cela conduira à une stratégie qui correspond étroitement à la préoccupation.
Références & Ressources
- L’Institut MITRE, 1er septembre 2007, Modèle de compétences en ingénierie des systèmes MITRE (SE), Version 1, pp. 10, 40-41.
- Garvey, P.R., 2008, Méthodes analytiques pour la gestion des risques: Une perspective d’ingénierie des systèmes, Chapman-Hall / CRC-Press, Taylor & Francis Group (Royaume-Uni), Boca Raton, Londres, New York, ISBN: 1584886374.U.S. Air Force, janvier 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315.305(a).
- U.S. Air Force, janvier 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315.305(a).
Références supplémentaires & Ressources
MITRE E520 Listes de contrôle de l’Équipe Technique d’Analyse et de Gestion des Risques, Vérifications des Risques, Documents d’Analyse et de Gestion des Risques.
Project Management Institute, A Guide to the Project Management Body of Knowledge, (Guide PMBOK), Quatrième édition, ANSI/PMI 99-001-2008, pp. 273-312, consulté le 2 mars 2010.
SEPO, « Processus standard/ Étapes du Processus, Étape 2: Identifier les risques & Dangers », Boîte à outils de gestion des risques SEPO MITRE, consulté le 5 mai 2010.
