Projets SIG : série « Considérations sur le triage » : partie 2

Suite de cette série en six parties sur un cadre à six piliers pour aider à naviguer et à hiérarchiser les projets SIG. La partie 2 traite de la compréhension des risques. À la fin de la série, vous disposerez d’un guide pratique pour vous aider à trier les projets, ce qui rendra le processus plus fluide et plus facile à gérer. Si vous restez à l’écoute jusqu’à la fin, j’inclurai également pour vous un aide-mémoire.

Comme indiqué dans la première partie, il est important de noter que ce cadre se fonde sur mes expériences en tant que conseiller et spécialiste en solutions technologiques. Il s’appuie sur une expérience personnelle sur les projets et l’évaluation des risques connexes et peut ne pas correspondre totalement à la position de votre organisation en matière de technologie, de formation et de capacité, de flux de travaux ou de sécurité et de protection de la vie privée.

Les six piliers du triage de projets SIG

Le cadre de triage comprend six piliers

Pour revenir à mon billet précédent, ce cadre prend en compte six piliers pour le triage des demandes de projets SIG :

• Rendement de l’investissement : Le projet a-t-il un rendement de l’investissement tangible?

• Risque : Quels sont les risques associés au projet?

• Intervenants : Quelles sont les capacités requises pour le projet et son maintien tout au long de son cycle de vie typique?

• Technologie : Quels sont les éléments de technologie ou d’équipement nécessaires à la réussite du projet?

• Données : Les données impliquées dans le projet sont-elles exactes, sécurisées, accessibles et opportunes?

• Application et projet : Quels sont les livrables, les résultats et les mesures de réussite du projet?

Ce billet de blogue traite de la compréhension des risques possibles pour une mise en œuvre réussie du projet.

Comprendre le risque

Comprendre le risque

En tant que professionnel certifié de la gestion des risques de sécurité, j’ai passé de nombreuses années à aider mes clients à réduire les risques d’entreprise et à éviter de manière proactive les événements ou les scénarios qui pourraient avoir un impact négatif sur leur capacité à atteindre leurs objectifs commerciaux. Les risques peuvent provenir de nombreuses sources et créer une réaction en chaîne connue sous le nom de risque associé. Ces sources sont appelées menaces et leur gestion implique de comprendre le risque (ou la probabilité) que ces menaces se concrétisent.

Lorsqu’un projet tourne mal, il peut avoir des conséquences négatives pour l’organisation, telles qu’une perte financière, une atteinte à la réputation, des perturbations opérationnelles, des problèmes juridiques et de conformité, un épuisement des ressources et même une baisse du moral des employés. En évaluant un projet potentiel à l’aide d’un cadre de risque (probabilité), nous pouvons classer les projets par ordre de priorité de manière plus efficace. Je présente une manière très simplifiée de comprendre le risque, qui permet de décider rapidement si un projet proposé doit faire l’objet d’une analyse plus approfondie des menaces ou s’il peut être mis en œuvre.

La matrice des risques

Matrice des risques

L’image ci-dessus illustre les quadrants dans lesquels un projet potentiel peut se situer dans la matrice des risques. Sur l’axe horizontal, nous évaluons si un projet sera facile ou difficile à lancer et s’il sera gérable ou ingérable après sa mise en œuvre. Sur l’axe vertical, nous évaluons si le projet présente un avantage faible et incertain ou un avantage élevé et clair.

Un projet facile à lancer et dont les avantages sont clairs et importants sera probablement plus prioritaire qu’un projet dont les avantages sont moindres et dont la capacité de lancement est plus difficile. Les projets faciles à lancer mais dont les bénéfices sont incertains peuvent nécessiter plus de temps de recherche pour développer leur proposition de valeur commerciale. Les projets proposés qui sont considérés comme ayant une grande valeur mais dont le calendrier de mise en œuvre est plus risqué doivent être abordés avec prudence et peuvent nécessiter une méthodologie de gestion de projet plus formelle.

Comprendre les besoins du public

Besoins du public

L’illustration ci-dessus montre comment je pourrais évaluer les risques différemment d’une organisation publique. Alors que je pourrais considérer qu’un projet qui étend les données ouvertes au public présente un risque plus élevé, une organisation tournée vers le public pourrait considérer qu’il s’agit d’une activité qui réduit les risques, en particulier en ce qui concerne sa réputation et son engagement en faveur de la transparence.

Lors de l’évaluation d’un projet proposé, la compréhension du public principal auquel il s’adresse peut permettre de déterminer le niveau de risque perçu. Une application destinée à un ensemble précis d’employés et de services internes peut être considérée comme présentant un risque faible, car elle n’a pas besoin d’adhérer aux mêmes normes web qu’une application destinée au grand public. Les risques augmentent à mesure que le public cible s’élargit, ce qui nécessite probablement davantage d’exigences fonctionnelles et non fonctionnelles. Si un projet implique un public de sous-traitants et de conseillers, il présente des risques particuliers liés à la sécurité et à la confidentialité de l’organisation.

La compréhension du public cible du projet permettra de mieux cerner la nature des risques qu’il comporte.

Comprendre l’adhésion

Comprendre l’adhésion

Pour qu’un projet réussisse, il doit obtenir le soutien, l’approbation et l’accord des parties prenantes. En l’absence de consensus ou d’alignement entre les membres de l’équipe, le risque d’échec augmente.

Si un projet ne nécessite qu’une adhésion interne (il s’agit généralement d’un petit projet touchant un public limité), le risque est faible. Toutefois, le risque augmente à mesure que le profil des parties prenantes devient plus important. Par exemple, un projet SIG peut être mandaté par une autorité supérieure, telle qu’une province ou un État légiférant sur des objectifs de logements abordables pour chaque municipalité, ce qui pourrait l’emporter sur tout plan communautaire officiel. Ce mandat peut déclencher un projet SIG qui ne correspond pas à la mission de la municipalité, mais qui est exigé par une autorité supérieure. Le risque augmente si ces objectifs en matière de logement doivent être atteints dans des délais très courts.

Un projet SIG peut également comporter un risque important si le livrable répond à une demande du public. La synthèse des exigences fonctionnelles et non fonctionnelles du public peut nécessiter des ressources importantes et exiger un engagement et des efforts substantiels de la part du service SIG.

Comprendre le risque de réussite d’un projet par rapport à ses parties prenantes permet de prendre des décisions éclairées sur la meilleure façon de hiérarchiser le projet.

Comprendre l’équipe

Comprendre l’équipe

L’inefficacité du parrainage, du championnat ou de la direction est un obstacle fréquent à l’achèvement d’un projet. L’équipe de projet doit avoir un parrain qui collabore avec le champion du domaine d’activité et la direction technique pour créer un environnement dans lequel l’équipe SIG peut travailler efficacement.

• Le parrain ou promoteur de la haute direction doit clairement expliquer comment le projet s’inscrit dans la vision stratégique de l’organisation. Il doit détenir l’influence et l’autorité nécessaires pour obtenir les ressources requises, vaincre les résistances et défendre le projet au plus haut niveau.

• Le champion du domaine d’activité doit fournir une expertise en la matière et communiquer clairement la valeur du projet pour motiver le soutien. Il doit défendre les intérêts de l’entreprise, en identifiant et en traitant les problèmes potentiels à un stade précoce. Idéalement, le champion implique les utilisateurs finaux et les autres parties prenantes dès le début du processus de proposition afin de s’assurer que le projet qu’il répond à leurs besoins.

• Les responsables techniques doivent posséder des connaissances techniques approfondies et guider l’équipe à travers les défis du projet. Ils doivent combler le fossé entre les parties prenantes techniques et non techniques, en assurant une communication claire et efficace. Les responsables techniques protègent l’équipe technique et gèrent les exigences de changement du projet par le biais de méthodologies de gestion de projet établies.

Le projet proposé, quelle que soit sa taille, doit pouvoir compter sur une équipe soudée qui s’engage à le mener à bien. 

Comprendre le niveau d’effort de la solution

Comprendre le niveau d’effort de la solution

Il est essentiel de comprendre le niveau d’effort d’un projet SIG pour en évaluer les risques. Il convient de noter que les besoins ou les capacités techniques de votre entreprise peuvent ne pas correspondre aux évaluations que j’ai faites. Considérez ceci :

• Configurer uniquement (risque faible) – Ces projets impliquent des configurations, des fonctionnalités et des modèles prêts à l’emploi de l’écosystème ArcGIS qui requièrent peu ou pas de codage. Ils offrent une grande prévisibilité grâce à des caractéristiques standardisées et une moindre complexité en évitant un codage ou un développement important. Ces projets peuvent être mis en œuvre rapidement, car le travail porte principalement sur la configuration, ce qui permet de réduire les coûts en raison de la réduction du besoin d’experts en développement. Cependant, il peut y avoir un certain risque, car les projets de configuration uniquement peuvent ne pas offrir la flexibilité ou la fonctionnalité complète requise.

• Configurer et plus (risque accru) – Pour ajouter plus de souplesse et de fonctionnalité, un certain niveau de personnalisation peut être envisagé. Cela peut inclure la rédaction de scripts avec Arcade, l’édition de fichiers JSON pour les applications et les couches de carte (l’utilisation d’un outil comme ArcGIS Assistant pourrait accidentellement supprimer ou mettre à jour quelque chose qui a des conséquences imprévues), l’automatisation avec Python ou l’intégration d’outils et de modules d’extension de partenaires. La prévisibilité devient variable avec ces éléments personnalisés, ce qui accroît la complexité du projet et les besoins de gestion. Par conséquent, les délais peuvent être plus longs et les coûts plus élevés par rapport aux projets de configuration uniquement, en raison de la nécessité de disposer de ressources spécialisées pour le développement et les essais.

• Personnaliser (risque plus élevé) – Projets nécessitant un important effort de développement, consistant notamment en création de nouvelles fonctionnalités, d’interfaces personnalisées et d’intégrations d’API complexes. Les applications développées sur mesure sont les moins prévisibles et les moins fiables en raison de l’importance du travail de développement, qui nécessite un codage, des tests et un débogage approfondis en cas de complications imprévues. L’adoption d’une méthodologie de projet formelle permet d’atténuer les risques et de gérer les délais plus longs et les coûts plus élevés, car ces projets nécessitent des ressources hautement spécialisées pour un développement approfondi et des tests itératifs. En outre, la dérive des objectifs est un problème courant dans ce type de projet.

Comprendre le niveau d’effort du projet aide à évaluer son risque, ce qui permet aux parrains, aux champions et aux dirigeants de prendre des décisions éclairées sur la manière de procéder.

Comprendre la criticité

Comprendre la criticité

La compréhension de la criticité d’un produit ou d’une application SIG est essentielle pour l’évaluation des risques, car elle permet de déterminer l’impact potentiel d’une défaillance ou d’un problème. Voici comment les différents niveaux de criticité représentent divers degrés de risque :

• Déploiement non critique (faible risque) – En général, les déploiements non critiques sont considérés comme présentant un faible risque, car leur défaillance ou leurs problèmes n’ont pas d’impact significatif sur les activités de l’entreprise. Par exemple, une application SIG utilisée aux fins de formation interne peut entrer dans cette catégorie. Cependant, même les déploiements non critiques peuvent présenter un risque élevé s’ils impliquent des données sensibles, s’ils ont des implications réglementaires ou si leur échec peut nuire à la réputation. Par exemple, une carte SIG destinée au grand public et comportant des erreurs mineures peut néanmoins être source de confusion ou d’insatisfaction pour le public.

• Livrable critique pour l’entreprise (risque moyen) – Les livrables critiques sont ceux qui sous-tendent directement les fonctions essentielles de l’entreprise. Leur défaillance peut perturber les opérations, mais ne constitue généralement pas une menace immédiate pour la survie de l’organisation. Il peut s’agir, par exemple, d’une application SIG utilisée pour l’analyse et la prise de décision au quotidien. Le niveau de risque peut varier en fonction de facteurs tels que la complexité de l’application, la disponibilité des sauvegardes et la facilité de récupération. Si l’application est complexe et manque de redondance, le risque peut être plus élevé.

• Application critique à la mission (risque plus élevé) – Les applications critiques à la mission sont celles dont la défaillance peut avoir de graves conséquences, menaçant potentiellement la survie de l’organisation ou lui causant des dommages importants. Les applications SIG utilisées pour les interventions d’urgence, la gestion des infrastructures critiques ou la sécurité nationale en sont des exemples. Ces applications exigent le plus haut niveau de fiabilité, de sécurité et de performance. Tout temps d’arrêt ou toute panne peut avoir des conséquences catastrophiques, telles que la perte de vies humaines, des pertes financières importantes ou de graves répercussions juridiques.

Il est essentiel de comprendre les risques pour gérer efficacement les projets SIG. En évaluant l’impact potentiel d’une défaillance, les organisations peuvent mettre en œuvre des stratégies de gestion des risques appropriées. Comprendre l’évaluation des risques est une étape fondamentale pour aborder les autres sujets qui seront traités dans les prochains billets. Dans mon prochain billet, j’examinerai l’évaluation de la capacité des ressources humaines à mener à bien un projet, en me concentrant sur la manière dont la disponibilité et l’expertise de l’équipe influencent les risques et la réussite du projet.

Ce billet a été écrit en anglais par Nathan Enge et peut être consulté ici.