ARCHIVÉE - À notre sujet

Audit De L'Initiative Catalytique AMICAN

Annexe A

Matrice de Risques AMICAN / DNF

Table des Matières

Introduction

• 1. Risques Associés À La Gouvernance (AMICAN/DNF)
  • 1.1 Cadre de contrôle de la Direction
  • 1.2 Gestion du changement et de la portée
  • 1.3 Gestion investissements-bénéfices
• 2. Risques Associés À AMICAN
  • 2.1 Risques opérationnels d'AMICAN
  • 2.2 Risques associés au projet AMICAN
  • 2.3 Risques associés aux tests d'AMICAN
• 3. Risques Associés Au DNF
  • 3.1 Risques opérationnels du DNF
  • 3.2 Risques associés au projet DNF
• 4. Risques Associés À La Technologie
  • 4.1 Infrastructure
  • 4.2 Transition technologique

Introduction

Les résultats détaillés de l'étude préliminaire du projet AMICAN/DNF sont présentés sous forme de matrice de risques. Ces résultats sont un portrait de la situation au 30 mars 2007. L'étude s'est déroulée du 29 janvier au 16 mars, et considère que la situation décrite dans la matrice continue d'évoluer rapidement.

L'objectif de la matrice est d'identifier les facteurs qui pourraient avoir une influence sur le succès de la livraison de solutions fonctionnelles pour AMICAN/DNF, en respectant les échéances, les contraintes budgétaires et les besoins des utilisateurs. Le cadre de risque utilisé pour réaliser l'étude comporte cinq catégories de risques : les risques associés à la gouvernance, aux opérations, au projet, aux tests et à la technologie. Chaque catégorie de risque a été ventilée en trois colonnes indiquant : les activités du projet; les conclusions de l'étude et l'évaluation du risque; et une mention à l'effet qu'aucune recommandation n'est nécessaire, ou des suggestions ou recommandations visant à réduire le risque à un niveau acceptable.

L'évaluation de risque décrit la nature de la menace, la probabilité qu'elle se réalise, et les conséquences de cette menace. L'évaluation de risque s'appuie sur l'expérience de l'évaluateur. L'utilisation de méthodes d'évaluation fondées sur des statistiques ne convient pas à ce genre d'étude, en raison de la trop grande diversité des situations : projets générés par des problèmes spécifiques à une organisation et pour lesquels on cherche des solutions, diversité des domaines d'intervention et des approches organisationnelles, styles personnels de gestion de projet, et diversité des méthodes d'élaboration de systèmes et de contrôle des projets. Dans le cadre de cette étude, nous avons utilisé les définitions suivantes.

Probabilité que le risque se matérialise

Faible

Réduction des risques grâce à diverses mesures en gestion de projet, ou grâce à des influences provenant de l'environnement. Par exemple, les risques associés au projet sont réduits par l'action conjuguée d'une méthodologie reconnue, d'un programme d'assurance de la qualité et d'une équipe expérimentée connaissant bien l'organisme et la technologie. Il est peu propable que le risque se matérialise.

Modérée

Considérant la présence du risque, le projet prend les mesures appropriées pour gérer ce risque et il n'y a aucune influence inhabituelle provenant de l'environnement. Le risque se matérialisera si les circonstances sont favorables.

Élevée

Le risque est combiné avec l'absence de mesures appropriées ou la présence d'influences inhabituelles provenant de l'environnement. Par exemple, les risques opérationnels, dans le cas d'un système financier essentiel à la mission, seraient plus élevés en l'absence d'un processus de contrôle bien documenté. De même, les risques d'ordre technique seraient augmentés par l'usage de technologies mal maîtrisées par l'organisme, ou par la dépendance à des versions non officielles provenant d'un fournisseur de logiciels promettant l'efficacité de son infrastructure. Le risque se matérialise déjà ou est très susceptible de le faire.

Répercussions si le risque se matérialise

Faibles

Conformité générale aux principes de contrôle reconnus, mais comportant des problèmes pouvant être résolus à l'interne.

Modérées

Conformité partielle aux principes de contrôle reconnus, qui pourrait générer une faiblesse en matière de gestion, mais qui ne causerait pas de dommages sérieux au projet.

Élevées

Non-conformité aux principes de contrôle reconnus, qui pourrait causer des dommages au projet, tels que la non-livraison du produit, un retard dans la livraison, des augmentations de coûts inacceptables, etc.

Pour chacune des catégories et sous-catégories de risques, plusieurs mesures individuelles sont décrites dans la matrice qui suit. Certaines mesures ne sont pas exclusives à une catégorie en particulier et apparaissent à plusieurs endroits; cette duplication est intentionnelle et vise à assurer une meilleure compréhension du document.

---

1. Risques Associés À La Gouvernance (AMICAN/DNF)

1.1 Cadre de contrôle de la Direction

Activités

La structure de gouvernance, telle que décrite dans la charte du projet, est composée d'un Comité directeur (représentants de la haute direction de l'organisation), d'un Comité directeur du projet (composé de représentants de la gestion des opérations, présidé par des membres du Comité directeur) et d'un groupe de responsables et de gestionnaires de projet pour chaque sous-projet.

• Le rôle du Comité directeur (CD) est d'établir la portée du projet AMICAN/DNF et d'allouer les ressources.
• Le CD a changé d'orientation à l'automne 2006 en fusionnant les projets DNF et AMICAN. La structure de gouvernance du DNF n'était pas aussi souple que celle d'AMICAN; la surveillance faisait défaut. Les membres du CD interviewés se sentent maintenant plus à l'aise dans la nouvelle structure de gestion.
• Actuellement, les informations reçues par le CD sont suffisantes et assez précises pour la prise de décisions. Les questions de développement, de risque et de budget sont claires. Les problèmes et les crises sont bien gérés, et des solutions sont trouvées rapidement. On a mis en place un registre des risques et le CD est informé des enjeux et des recommandations du Comité d'examen du projet (CEP).
• Les membres se sentent consultés et ont suffisamment d'occasions d'exprimer leur point de vue; les enjeux potentiels sont transmis rapidement au CEP; le lobbying et les consultations sont faits avant chaque réunion, ainsi personne n'est pris au dépourvu par une question qu'il n'anticipait pas.

Conclusions

La structure de gouvernance et les processus du projet AMICAN/DNF sont généralement bien organisés et conformes aux meilleures pratiques.

Les projets AMICAN et DNF ont tous les deux émergé de l'exercice de transition menant à la fusion de la Bibliothèque et des Archives. AMICAN fut le premier projet à aller de l'avant et à se doter d'un solide modèle de gouvernance. En partie à cause de cela, le DNF a été rattaché à AMICAN, malgré le fait que certains estiment que le mandat du DNF ne cadre pas vraiment avec celui d'AMICAN.

• La direction de BAC doit être consciente des changements de portée et de mandat. Elle doit s'adapter aux nouvelles situations qui se présentent. Ceci peut vouloir dire réduire l'ampleur de certains éléments d'AMICAN/DNF pour que le projet puisse atteindre ses objectifs.
• La direction doit être sensible au risque que représente un certain alourdissement de la gouvernance, suite à la fusion des deux projets. Ce risque sera atténué si la gouvernance joue bien son rôle.

Risques

Impact: M
Probabilité: M

Recommandation:

Il est recommandé que BAC examine et confirme les rôles des divers comités.

---

Activités

La structure du CD est relativement nouvelle et son rôle, par rapport à celui du CEP, n'a été complètement défini que tout récemment. En conséquence, certains membres du comité avaient l'impression que leur rôle et responsabilités n'étaient pas bien compris par tous.

• Un examen des procès-verbaux du CD révèle qu'ils sont généraux et imprécis, et ne contiennent aucune information détaillée sur les enjeux clés de gestion (aucun suivi systématique des coûts, aucune vérification du calendrier de projet ni de celui des produits livrables, attention insuffisante portée au registre des risques). Par conséquent, le suivi du projet semble faible.
• En ce qui concerne le DNF en particulier, les risques sont très bien documentés dans le registre, mais ne sont pas suffisamment étudiés en comité, comme ils le devraient. Un gestionnaire de groupe prépare plutôt un résumé des risques associés à la technologie de l'information (TI) et un résumé des risques opérationnels; ces résumés sont ensuite examinés par un comité de gestion du DNF, mis sur pied par le Dirigeant principal de la technologie (ce comité s'ajoute à ceux prévus par la charte).
• De plus, nous avons observé que le CEP est présidé par un membre du CD. Ceci pourrait empêcher les gestionnaires intermédiaires de discuter en toute franchise de problèmes potentiels.
• Les opinions divergent quant au niveau hiérarchique optimal des membres du CEP. Ce niveau a changé pour inclure principalement des directeurs plutôt que des directeurs généraux. Certains estiment qu'en conséquence, le CEP gère trop de dossiers opérationnels.

Conclusions

Le rôle des comités prévus dans la charte du projet, et de certains extérieurs à la charte, semble créer de la confusion parmi les intervenants.

• Par exemple, il existe un comité d'examen du projet DNF, un comité de gestion du DNF et des comités de groupes du projet DNF. Il pourrait y avoir des chevauchements entre ces comités.

La façon dont le CEP fait rapport au CD et le niveau hiérarchique des représentants sur le CEP devraient être examinés et précisés.

• Le CEP devrait être un groupe de travail ayant la capacité de bien comprendre les problèmes que rencontre le projet, et la compétence pour formuler des recommandations éclairées.
• L'évaluation de l'audit est que c'est exactement à ce niveau que les questions de détail devraient être examinées.

Risques

Impact: F
Probabilité: M

Suggestions:

Il est suggéré qu'une fois leurs rôles confirmés, les membres du CD et du CEP, élaborent des lignes directrices, concernant le niveau et la portée des discussions.

• Les membres devraient être encouragés à signaler les problèmes et à exprimer leur opinion, peu importe qui préside la réunion.
• Il doit être clair que tout représentant a le droit de d'avoir une opinion impopulaire et qu'il sera soutenu par le comité s'il a raison.

---

Activités

Bien que le flux d'informations soit jugé adéquat pour les membres du comité, l'information est peut-être trop volumineuse ou mal adaptée pour les cadres supérieurs et intermédiaires.

• L'examen des rapports du CEP et du CD, dans le cadre de cet audit, révèle une organisation inadéquate des informations qui les rend difficiles à comprendre.

Conclusions

L'information transmise au comité devrait être mieux structurée et inclure une vue d'ensemble de l'échéancier, des coûts et des fonctionnalités réalisées, suivie des risques et des enjeux.

Risques

Impact: F
Probabilité: M

Suggestion:

Il est suggéré que les rapports du comité soient courts, présentés sous forme de puces, et portent sur les jalons, les résultats, les échéanciers, les principaux défis, les décisions requises et, au besoin, sur des problèmes spécifiques.

---

1.2 Gestion du changement et de la portée

Activités

Tout changement ayant des répercussions sur la portée du projet doit suivre le processus de demande de modification. Les demandes de changement sont présentées de façon formelle et font l'objet d'un suivi (le formulaire de demande de changement est décrit dans le plan de projet et le processus d'approbation des changements est décrit dans la charte du projet). Un registre des demandes de changements est tenu à jour.

• La portée a récemment été définie de façon plus précise; l'exercice est encore plus récent pour le DNF. L'objectif du projet DNF est de créer, sur trois ans, les composantes servant à l'alimentation, à la préservation et à l'accessibilité du DNF. Cela exigera la mise en place d'une infrastructure appropriée.
• Les membres du CD interviewés connaissaient le plan du projet et son échéancier. Au comité, ils ont discuté des modules et du calendrier des travaux, ce qui leur a permis d'en mieux saisir les interdépendances.
• Les changements sont généralement discutés en profondeur aux niveaux inférieurs avant d'être présentés au CEP ou au CD. Le CEP ne signe pas officiellement le formulaire de demande de changement, mais sa décision est consignée au procès-verbal.
• Un changement majeur a été discuté récemment au CEP (sur la question des conteneurs). Il semble que le processus de changement ait bien fonctionné dans ce cas, à l'exception du fait que le formulaire de modification a été rempli après avoir été discuté au CEP plutôt qu'avant.

Néanmoins, le président du comité directeur estime que la gestion de la portée est limitée. Des décisions à court terme sont prises sans tenir compte de l'ensemble du portrait. Lorsqu'une décision est prise concernant une série de fonctionnalités pour un module en particulier, les effets en aval sur les futurs modules sont incertains; il n'y a pas de vision globale

Conclusions

La méthode de gestion du changement est conforme aux standards de l'industrie et semble bien fonctionner, même si elle n'a pas été beaucoup utilisée pour AMICAN. En fait, très peu de changements ont été apportés au projet depuis la fin du travail initial de définition des besoins.

• Le projet semble tirer profit d'une solide structure de gestion et d'une équipe d'individus qualifiés. Des outils existent pour gérer les changements de portée.
• BAC s'appuie sur une équipe de consultants et d'employés professionnels qui doivent livrer un ensemble déterminé de produits, dans le cadre d'un contrat pour le DNF. Les cadres supérieurs se sont engagés à suivre les recommandations du document concernant la portée, présenté par Deloitte, et ont émis des directives pour que le CEP s'en tienne au plan.

Bien qu'il soit difficile d'évaluer indépendamment si l'approche adoptée pour la gestion de la portée est limitée, il est clair que les incertitudes quant au financement (voir la section suivante) ont entraîné un processus de prise de décisions à court terme. Ce qui est important de noter ici, c'est que le président du CD gère en situation d'incertitude, et que ceci devrait être amélioré grâce, entre autres, à une meilleure information.

Risques

Impact: M
Probabilité: M

Recommandation:

Il est recommandé que les gestionnaires du projet répondent aux inquiétudes du sous-ministre adjoint, concernant la nécessité d'adopter une vision suffisamment large lors des prises de décision impliquant des changements au projet.

---

1.3 Gestion investissements-bénéfices

1.3.1 Financement - Décisions coûts-bénéfices

Activités

Toutes les personnes interviewées conviennent que le financement du projet est dangereusement irrégulier. Les fonds sont versés par à-coups et de manière imprévisible, car l'institution modifie en cours d'année l'allocation des fonds destinés à AMICAN.

• Du point de vue des membres du CEP, il semble que les demandes de financement des TI soient toujours présentées en mode de crise et que plus de temps soit consacré à la gestion du budget qu'aux dossiers de TI eux-mêmes. Les coûts sont plus élevés qu'ils ne devraient l'être, en raison de cette approche irrégulière.
• La majeure partie du budget du projet sert à embaucher des consultants en développement d'applications. Des dépenses inutiles sont effectuées pour garder sous contrat des consultants connaissant bien BAC, même durant les périodes où il y a peu de travail à leur confier ou, au contraire, pour former de nouveaux consultants à cause du roulement de personnel.
• En ce qui a trait aux infrastructures, les fonds arrivent en quantités imprévues, souvent en fin d'année. On s'empresse alors d'acheter de l'équipement et le projet est retardé à cause de la formation du personnel, de l'installation, de la mise en fonction et de la vérification des nouveaux appareils.

La haute direction se dit convaincue que la soumission au CT sera acceptée. Aucun plan de rechange n'a été prévu. En conséquence, les attentes de l'équipe du projet sont élevées. En cas de refus, la déception sera grande, l'élan sera brisé et le moral tombera.

• Coût-bénéfice. Le comité directeur est satisfait du processus et des produits présentés au CT. Le dossier présenté est crédible et le CD en est raisonnablement satisfait.

Conclusions

Le principal risque du projet, le financement, n'a pas reçu suffisamment d'attention. Si la demande au Conseil du Trésor échoue, l'institution va très probablement continuer à financer le projet (tel qu'affirmé dans le dossier). Le risque touche non seulement l'aspect financier, mais aussi les ressources humaines.

Malgré tout, aucun plan de financement spécifique n'a encore été préparé, ce qui provoquera des délais dans la réalisation du projet et la perte de personnel spécialisé, et brisera l'élan du projet.

Risques

Impact: É
Probabilité: M

Recommandation:

La principale cause de problèmes pour ce projet est l'irrégularité du financement. Le projet a besoin d'un financement stable et d'un plan stratégique de financement sur plusieurs années, que la demande au Conseil du Trésor soit acceptée ou non.

Plus précisément, il est recommandé que BAC assure un financement stable (que ce soit par une allocation du CT ou par des fonds internes), afin de permettre l'embauche de consultants pour tout le temps nécessaire.

---

1.3.2 Évaluation des coûts et suivi des dépenses

Activités

Le financement et l'utilisation des fonds sont des sujets de préoccupation. La relation entre les sommes investies et les résultats obtenus à ce jour n'est pas clairement établie.

• Nous avons examiné les procès-verbaux du CEP, de 2005 à aujourd'hui, pour analyser les discussions concernant le financement du projet. Dans la plupart des réunions, le financement a été effectivement discuté et un plan des dépenses a été présenté. En général, ces discussions traitaient des fonds alloués par la direction de la gestion ou par la Direction de la technologie de l'information (DTI). On estimait le temps requis pour finaliser certains modules, et l'échéancier était adapté selon les ressources disponibles. Cependant, on ne retrouve pas de rapports de dépenses, en relation avec les plans.
• Le directeur des finances vient de créer un nouveau comité de gestion des finances qu'il présidera, et qui aura pour mandat de surveiller de plus près la situation financière du projet. Ce comité devra veiller à ce que le budget soit respecté et bien suivi, et les demandes de fonds correctement justifiées. Afin que les priorités de financement soient établies en toute indépendance, le comité ne sera pas présidé par les TI. Ce comité se rapportera au Comité directeur.

Conclusions

Les risques de mauvaise gestion des dépenses sont élevés, mais la création du nouveau comité devrait permettre un meilleur suivi.

Risques

Impact: É
Probabilité: M-F

Suggestion:

Il est suggéré que la DTI établisse, pour l'évaluation des coûts, des normes compréhensibles à des non-initiés, et décrive en détail l'objectif fonctionnel de chaque proposition.

---

1.3.3 Bénéfices obtenus

Activités

Il n'est certainement pas facile de départager les aspects financiers d'AMICAN de ceux du DNF. La principale motivation de ce projet est la réalisation du mandat de BAC, soit la préservation du patrimoine canadien, plus précisément de son patrimoine numérique.

• Le dossier du projet s'appuie surtout sur les coûts et la réduction des risques. Les opinions sont partagées au sein de la haute direction de BAC concernant l'approche du tout ou rien adoptée dans ce dossier, c'est-à-dire que les options y sont présentées comme des éléments isolés plutôt que comme des composantes d'un ensemble.

Depuis qu'AMICAN est devenu un modèle de bonne gestion d'un projet TI, plusieurs autres projets lui ont été rattachés, même si certaines personnes interviewées croient que ces projets ne cadrent pas vraiment avec le mandat d'AMICAN.

• En conséquence, la portée et le budget d'AMICAN ont tellement changé qu'il est impossible d'évaluer ses progrès par rapport à ses objectifs initiaux.
• Il est difficile de séparer les deux portefeuilles puisqu'AMICAN et le DNF partageront la même infrastructure et certains logiciels (comme ceux de sécurité et de détection des virus).

La façon dont sera mesurée l'atteinte des bénéfices ne semble pas avoir été abordée au CEP. Cela fait apparemment partie du nouveau mandat du comité directeur, mais celui-ci n'en a pas encore discuté.

• La haute direction considère généralement comme un bénéfice une augmentation de productivité, c'est-à-dire la possibilité de faire plus avec moins de personnel, et donc de réaliser des économies. L'instrument de mesure qu'elle propose est simple, soit le calcul de l'équivalent temps plein (ÉTP) par tâches réalisées; par exemple, le nombre d'acquisitions et le temps requis par un employé pour faire une acquisition, le nombre d'acquisitions par année, et le coût par acquisition.
• La qualité du service aux usagers : l'opinion des utilisateurs à propos de l'amélioration des services constitue une autre mesure importante.
• Cependant, les exemples cités semblent être des mesures informelles et générales. Il n'y a aucun mécanisme en place permettant d'identifier précisément, à des fins de comparaison, les coûts par fonction avant la mise en œuvre.

Conclusions

Puisque le dossier de projet ne porte pas exclusivement sur AMICAN, il en résulte une certaine confusion quant aux aspects financiers. Par exemple, il n'y a pas d'explication claire des coûts actuels d'entretien d'AMICUS, et les coûts d'entretien du nouveau système n'apparaissent nulle part. Il est donc difficile de justifier les coûts-bénéfices, si l'on veut considérer uniquement le projet AMICAN. Par ailleurs, le dossier est raisonnablement convaincant en ce qui concerne les autres arguments.

Certains membres du projet AMICAN croient que la portée et le budget ont tellement changé qu'il est maintenant beaucoup plus difficile d'évaluer ses progrès par rapport aux objectifs initiaux. Ceci augmente les risques de ne pas pouvoir identifier et mesurer les bénéfices.
L'échéancier du projet risque aussi d'en être affecté.

Risques

Impact: M
Probabilité: M

Recommandation:

Il est recommandé que BAC élabore un plan détaillé pour mesurer les bénéfices obtenus grâce au projet AMICAN/DNF, et commence immédiatement à recueillir certaines données afin de documenter la situation précédant la mise en application.

Suggestions:

Puisque le dossier de projet est finalisé, il est impossible de le modifier, mais il est suggéré que BAC prévoie des coûts de fonctionnement et d'entretien, au cas où le CT le demanderait, ou pour de futures prévisions budgétaires.

Il est suggéré que BAC prépare des lignes directrices afin de déterminer ce qui fait partie ou non du mandat d'AMICAN, et que ces lignes directrices s'appliquent à tout nouveau projet éventuellement proposé.

---

2. Risques Associés À AMICAN

2.1 Risques opérationnels d'AMICAN

2.1.1 Gestion des exigences fonctionnelles

Activités

Les exigences fonctionnelles ont été définies selon une démarche répondant aux normes de l'industrie. Le processus a commencé avec les exigences décrites en format papier sous le nom des anciens modules (AMICUS).

• Dans le cas des plus importants sous-projets, les spécifications fonctionnelles ont été identifiées au moyen d'entrevues avec des experts de l'institution. Ces spécifications ont ensuite été définies plus précisément par la technique du prototypage et par des séances de conception d'application commune (CAC). On a ensuite préparé des études de cas d'utilisation avec des représentants des usagers, afin de valider les exigences.
• Les plus petits sous-projets ont pu être élaborés grâce à des techniques de développement rapide d'applications, telles que le prototypage. Les spécifications, très détaillées, comprennent les documents approuvés décrivant les exigences des systèmes, et sont classées par ordre d'importance, d'essentielles à désirables.

Ces exigences fonctionnelles ont ensuite été incorporées dans le nouvel ensemble de six modules AMICAN, et dans les nouvelles versions de chaque module. Le calendrier d'élaboration a été établi selon un ordre logique, puisque chacun des modules comporte des éléments préalables aux autres. Un autre facteur a influencé l'établissement des priorités, soit la volonté de fournir aux Archives le même degré d'automatisation qui existe déjà à la Bibliothèque.

• En général, les personnes interviewées dans les unités fonctionnelles estiment que leurs exigences ont été prises en compte et que les nouveaux processus vont bien fonctionner. Elles ont l'impression que leurs employés sont satisfaits de la façon dont ils ont été impliqués, et du degré de précision de la description des exigences.

Ce projet a redéfini les processus opérationnels de BAC - dont certains étaient déjà très complexes - et relevé le défi d'intégrer des processus, auparavant distincts, à la Bibiothèque et aux Archives.

Conclusions

Le projet dans son ensemble est une entreprise très complexe, au point de vue fonctionnel, si l'on considère le nombre de ses composantes et leurs interrelations, ainsi que le défi de faire migrer les nombreuses données auparavant conservées dans des bases de données distinctes et incompatibles. Dans certains cas, le projet touche à des secteurs qui n'étaient même pas informatisés auparavant.

En ce qui concerne le risque associé aux exigences fonctionnelles, il s'agit d'un projet à risque modéré à élevé : l'ampleur du changement organisationnel est considérable, puisque le projet AMICAN s'inscrit dans le grand projet de transformation de l'institution. Les règles de fonctionnement définies dans le projet sont d'une grande complexité et, de surcroît, elles doivent intégrer les différentes règles de fonctionnement utilisées auparavant par les parties de l'institution, lorsqu'elles étaient indépendantes. Cependant, le risque est géré efficacement dans le cas des modules mis en application au printemps 2007.

Des changements de personnel en cours pourraient toutefois avoir des répercussions négatives sur l'analyse des spécifications pour les modules à venir.

Risques

Impact: M
Probabilité: F

Suggestion:

Il est suggéré que BAC s'assure que les nouveaux gestionnaires responsables aient une connaissance générale suffisante de l'organisation et que les autres employés impliqués aient une " vision d'ensemble ", possèdent de l'expérience à la fois en bibliothéconomie et en archivistique, et comprennent les relations entre les différents catalogues.

---

2.1.2 Élaboration des solutions

Activités

Après avoir terminé la rédaction des exigences fonctionnelles, un concept de solution détaillé a été élaboré, puis révisé par un nombre choisi d'utilisateurs privilégiés. Ensuite, on a sollicité des commentaires d'autres utilisateurs à l'aide de prototypes. Enfin, un dernier examen des exigences est en cours, avant la mise en application.

• Tous les utilisateurs interviewés se sont montrés satisfaits de l'importance accordée à leurs commentaires. Par conséquent, ils ont demandé très peu de changements.

Les éléments de contrôle interne ont été renforcés dans la nouvelle architecture. Tous les modules sont munis de contrôles d'accès en fonction des utilisateurs et des documents. Les bases de données produiront des pistes de vérification pour protéger l'intégrité des données.

• Trois évaluations de la menace et des risques (EMR) ont été effectuées : une sur les données IADAS et une sur AMICAN en général; pour ce qui est du CIM, on a réalisé une EMR, mais aussi une Analyse des données préliminaires (ADP). Les exigences de tous les EMR ont été satisfaites; dans le cas des ADP pour le CIM, les exigences ont été partiellement satisfaites, et les plans pour y arriver sont en place.

Il est difficile d'évaluer la relation entre l'investissement en argent et en temps pour les fonctionnalités reçues, car il n'y a pas de mécanisme pour mesurer les coûts par fonction. Cependant, plusieurs directeurs de projets en TI ont dit que le coût a été plus élevé que nécessaire à cause de l'irrégularité du financement, laquelle a entraîné un taux de roulement plus élévé parmi les consultants, ou l'obligation de les payer durant les temps morts afin de les garder dans le projet.

Conclusions

Il y a très peu à reprocher à la façon dont le concept de solution a été élaboré. Les utilisateurs sont extrêmement satisfaits, et des mesures de sécurité appropriées ont été mises en place. On peut toutefois s'inquiéter, même si c'est un aspect mineur, qu'il n'y ait pas de mécanisme de mesure de coût par fonction.

L'élaboration de la solution est influencée directement, et de façon négative, par l'irrégularité du financement. La résolution de ce problème aurait certainement un effet bénéfique.

Risques

Impact: M
Probabilité: F

Suggestion:

Il est suggéré que BAC conçoive des mécanismes servant à mesurer les coûts par fonction, pour les projets à venir.

---

2.1.3 Gestion du changement organisationnel

Activités

Ce projet a, de toute évidence, d'énormes répercussions sur les principaux processus opérationnels de BAC; ces importants changements sont une conséquence des objectifs de la Transformation. Parmi toutes les personnes interviewées, aucune ne doutait de la capacité de l'organisation à faire face au changement ou de la volonté du personnel d'accepter ce changement. L'acceptation du changement a été promue par différents moyens :

• il y a eu une participation importante des unités fonctionnelles;
• les décisions concernant le processus ont été prises au Comité d'examen du projet, en collaboration avec des représentants de tous les secteurs de l'institution;
• les utilisateurs ont travaillé avec des démos du système;
• une équipe de communication intervient activement depuis le début du projet.

Conclusions

Alors que les répercussions sur les processus opérationnels sont majeurs, le projet a préparé de manière plus que satisfaisante ses procédures et ses utilisateurs. Le risque est plutôt faible que l'adoption du nouveau système rencontre de la résistance ou que cette résistance ait un effet négatif sur les bénéfices attendus.

Risques

Impact: F
Probabilité: F

Recommandation:

Aucune recommandation n'est requise.

---

2.2 Risques associés au projet AMICAN

2.2.1 Organisation et gestion du projet

Activités

Les rôles et responsabilités des dirigeants du projet, des gestionnaires, des chefs d'équipe et des membres des divers comités, ainsi que les réunions de projet, à tous les niveaux, sont bien documentés et compris de tous les participants.

• La majorité des personnes interviewées a le sentiment que le projet est extrêmement bien géré.

On s'inquiète cependant de l'insuffisance de ressources humaines allouées au projet, tant en nombre de personnes qu'en expertise.

• Le projet manque de ressources humaines dans tous les secteurs. Les directeurs d'équipes sont surchargés de tâches et de responsabilités.
• Il y a des tensions entre les employés permanents en TI et les contractuels. Les débats concernant le recours à des ressources externes pour le développement des systèmes, plutôt qu'à des ressources internes moins coûteuses, entraînent des retards de livraison.

L'incertitude liée au financement du projet est la principale source de problèmes. La disponibilité des fonds est toujours irrégulière. Les responsables de projet doivent souvent retravailler leur plan pour s'ajuster au fonds disponibles.

• Le projet AMICAN repose largement sur des consultants externes; le personnel affecté au développement des systèmes se compose à 80 % de consultants, alors que 80 % de la gestion du projet est confiée à des employés permanents de l'institution. La réussite du projet dépend de la capacité à retenir les consultants les plus expérimentés. L'embauche de consultants est un processus long et contraignant. Le présent accord d'approvisionnement en consultants est sur le point de prendre fin, et un nouvel accord devra être préparé.
• Des retards ou des dépenses inutiles se produisent lorsque le financement n'est plus disponible, parce que les consultants doivent être congédiés puis engagés de nouveau, ou parce qu'ils sont gardés, mais payés pour du temps mort.

Le projet ne semble pas avoir prévu de soutien technique adéquat pour l'entretien des applications, ni pour celui de l'infrastructure.

Conclusions

Les rôles et responsabilités des dirigeants du projet, des gestionnaires, des chefs d'équipe et des membres des divers comités, ainsi que les réunions de projet, à tous les niveaux, sont parfaitement compris et fonctionnent extrêmement bien.

La plupart des inquiétudes concernent le recrutement du personnel; elles se répartissent en trois catégories : l'insuffisance de ressources, la dépendance excessive aux consultants externes et les difficultés entourant l'embauche de ressources contractuelles. Le projet ne semble pas avoir prévu de soutien technique adéquat pour l'entretien.

L'irrégularité du financement a entraîné des retards et des coûts plus importants que nécessaire. Le recrutement du personnel et le financement du projet, ainsi que le manque de prévisions en matière de soutien et d'entretien des systèmes après leur mise en œuvre, constituent des risques importants.

Risques

Impact: É
Probabilité: É

Recommandations:

Il est recommandé que BAC règle les problèmes de ressources humaines de la manière suivante :

• en élaborant un plan et des mécanismes d'approvisionnement qui permettent d'engager des contractuels pour une longue période,
• en assurant le transfert des compétences au personnel permanent,
• en informant le personnel du plan du directeur général concernant la relève,
• en élaborant un plan pour fournir du personnel de soutien technique pour les nouveaux systèmes en production.

---

Contrôle du projet

Activités

Des réunions se tiennent régulièrement à tous les niveaux et elles sont bien contrôlées. Les problèmes et les obstacles sont présentés, et les interdépendances entre les équipes sont identifiées. Les responsables de projets produisent des rapports d'étape hebdomadaires et rencontrent les deux gestionnaires du projet toutes les deux semaines.

Les plans sont décrits en détail dans MS Project. Cependant, les estimations budgétaires doivent être préparées avec un minimum de ressources et de temps, et sans pouvoir y intégrer suffisamment de marge ou de plans de secours. L'incertitude à propos du budget complique la planification.

Les données devant être transférées dans les nouveaux systèmes, proviennent de nombreuses petites bases de données non compatibles entre elles, et qu'il est donc difficile de combiner.

La gestion de risque répond aux normes du Cadre amélioré de gestion (CAG) et du plan de gestion de risque d'AMICAN. Alors que la gestion de risque est faite de façon très consciencieuse au niveau des modules, le CEP discute rarement de risques, tel que révélé par l'examen des procès-verbaux de ses réunions tenues entre octobre 2005 et octobre 2006.

• Le registre de risques du CEP n'a pas changé durant cette période et a été mentionné lors de quelques réunions seulement.

Conclusions

La gestion du projet est faite aussi efficacement que possible dans les circonstances, mais elle serait encore plus efficace si la question du financement était réglée.

• Les prévisions et l'élaboration de solutions ont été affectées, dans une certaine mesure, par des problèmes d'incompatibilité de données impossibles à prévoir. La situation pourrait se répéter dans le cas des transferts des données de conservation. Des difficultés imprévisibles avec les données peuvent être considérées comme un risque modéré pour le projet.
• Alors que la gestion de risque est faite de façon très consciencieuse au niveau des modules, le CEP discute rarement de ce sujet. La plupart du temps, la stratégie de gestion de risque consiste tout simplement à reconnaître l'existence du risque. Par conséquent, le processus de gestion du risque ne peut pas être entièrement efficace.
• Les gestionnaires de projet sont généralement satisfaits de la gestion et des communications du projet. Toutefois, l'incertitude du financement cause certains problèmes dans la gestion du projet. Les employés n'ont pas confiance en leurs estimations, parce les plans doivent être préparés avec un strict minimum de ressources.

Risques

Impact: M
Probabilité: M

Recommandation:

Il est recommandé que BAC renforce les procédures de gestion de risque au CEP.

Suggestion:

Il est suggéré que BAC intègre suffisamment de mesures en cas d'imprévu dans ses futurs projets impliquant le transfert de nombreuses bases de données, p. ex. de données de conservation.

---

2.2.3 Processus de développement

Activités

Les solutions sont bien intégrées, mais très modulaires, parce qu'elles ont été pensées pour être mises en œuvre graduellement, en raison du manque de financement. Alors qu'il n'y a aucun cycle de développement de systèmes à proprement dit, le processus de construction peut être décrit comme un modèle " en cascade ", et les étapes correspondent généralement aux normes de l'industrie. La méthodologie et les outils ont été normalisés. Une structure de répartition du travail a été établie pour chaque module et l'équipe du projet se réunit une fois par semaine pour en suivre l'évolution. Tous les gestionnaires, ceux des TI et ceux des unités fonctionnelles, sont constamment informés de toutes les activités.

Conclusions

La définition et le contrôle du processus de développement sont satisfaisants.

Risques

Impact: F
Probabilité: F

Recommandation:

Aucune recommandation n'est requise.

---

2.3 Risques associés aux tests d'AMICAN

2.3.1 Stratégie et organisation des tests

Activités

Les tests sont d'abord effectués par les développeurs et ensuite par une Équipe d'acceptation par les utilisateurs (UAT). La Direction de la technologie de l'information a obtenu l'engagement des unités fonctionnelles à effectuer des tests.

• Dans le cas du module CoC, dont la production est prévue en mai 2007, l'équipe qui procèdera aux tests se compose d'environ 40 personnes des unités fonctionnelles. Cette équipe a été mise en place dès l'étape de définition des exigences; ces personnes connaissent très bien le système et le travail à faire. Elles forment les utilisateurs privilégiés qui, à leur tour, forment ceux vont procéder aux tests; elles préparent aussi les études de cas d'utilisation.

Cependant, certaines réserves ont été exprimées, compte tenu de mauvaises expériences dans le passé, notamment, des résultats insatisfaisants qui ont été constatés sur AMICUS, lequel contenait apparemment des erreurs lorsqu'il a été mis en service en 1995, et la période de test du prototype de FS/PAM qui a été écourtée.

Conclusions

Dans l'ensemble, la méthode adoptée pour les tests est détaillée et conforme aux pratiques généralement reconnues. La direction soutient entièrement cette méthode, comme en témoigne le fait qu'elle a assigné un nombre important d'employés à l'UAT. Il semble que les gestionnaires du projet aient tiré des leçons des tests effectués sur les modules précédents.

Risques

Impact: F
Probabilité: F

Recommandation:

Aucune recommandation n'est requise.

---

2.3.2 Plan de test et résultats

Activités

La méthodologie de test pour le CoC et le CIM, lesquels sont sur le point d'être mis en production, consiste à faire d'abord tester ces technologies par les développeurs.

• Les utilisateurs privilégiés ont été impliqués et ils ont procédé à des tests tout au long du processus de développement. Ils ont aussi formé d'autres évaluateurs. Ensuite, ces derniers testent le système à l'aide de scénarios de test préparés par des utilisateurs.
• L'équipe de formation et de documentation informe l'équipe UAT du moment où on aura besoin des évaluateurs pour procéder aux tests.

Un système de repérage de bogues et de modifications a été utilisé par l'équipe d'acceptation par les utilisateurs. Des examens hebdomadaires sont effectués en collaboration avec les utilisateurs, où l'on examine la gravité et l'importance des bogues décelés. Ceux-ci sont consignés et placés dans des documents à diffuser.

L'environnement d'assurance de la qualité (AQ) est rigoureusement contrôlé par le groupe de gestion de la configuration. En matière de test d'assurance de la qualité, les différences qui existent entre les environnements de développement et de production constituent un risque :

1. Absence d'une base de données complète pour la production. Il se peut qu'il y ait un problème de performance, car les tests ont été faits uniquement sur une base de données de production partielle.
2. Oracle RAC n'est pas disponible pour effectuer des tests sur la plateforme de développement, alors qu'il sera utilisé en production.

Conclusions

Les plans de test sont conformes aux meilleures pratiques. Le degré d'engagement des utilisateurs et des gestionnaires est impressionnant. Tout a été mis en œuvre pour éviter les risques associés aux tests.

Le seul risque potentiel est associé à l'assurance de la qualité. Le manque d'espace pour utiliser une version complète de la base de données de production, ainsi que l'absence d'Oracle RAC, peuvent causer des problèmes. Cependant, la question entourant Oracle RAC a perdu un peu de son acuité, en raison d'une décision récente de mettre AMICAN en application d'abord dans un environnement sans Oracle RAC, puis de le faire avec Oracle RAC ultérieurement.

Risques

Impact: M
Probabilité: F

Suggestions:

Il est suggéré que la Direction de la technologie de l'information s'assure d'obtenir un bon soutien d'Oracle et de HP quand Oracle RAC sera testé et mis en service.

Il est suggéré que la Direction de la technologie de l'information soit prête à surveiller et à diagnostiquer les problèmes de performance, et à augmenter rapidement la capacité, si nécessaire.

---

3. Rosques Associés Au DNF

3.1 Risques opérationnels du DNF

3.1.1 Gestion des exigences fonctionnelles

Activités

Le DNF fournira plusieurs des outils requis pour la livraison du service. Le groupe de projets DNF comprend quatre sous-projets et l'approche utilisée pour identifier les exigences fonctionnelles varie d'un projet à l'autre à cause de la nature de chacun. D'une manière générale, le projet DNF en est encore aux toutes premières étapes de définition des besoins et de proposition des solutions.

• Les sous-projets DNF constituent une situation très complexe à cause du nombre de composantes et des relations entre ces composantes. Cependant, les unités fonctionnelles ont travaillé en étroite collaboration avec les représentants de la TI, et assuré une bonne liaison entre les exigences fonctionnelles et les exigences techniques.

Malgré l'impression générale que la situation a changé et que les choses s'améliorent depuis six mois, plusieurs indices de risques sont manifestes.

• Selon le point de vue des gestionnaires des unités fonctionnelles, le travail de base avance normalement, mais n'est certainement pas terminé. D'autres recherches seraient nécessaires pour préciser les exigences relatives aux collections numériques.
• Certains membres du comité d'examen du projet DNF estiment qu'il est risqué de poursuivre le développement du système, alors que les exigences fonctionnelles ne sont pas encore suffisamment précisées.
• Le DNF est un projet encore jeune et ses exigences ne sont pas aussi bien définies que celles d'AMICAN.

Conclusions

Les quatre sous-projets progressent relativement bien, même s'ils ont été gérés indépendamment dans le passé. Avec l'arrivée d'un nouveau comité d'examen du projet, et de la structuration en un seul groupe DNF l'automne dernier, on devrait constater l'apparition d'une approche plus homogène.

• Au total, beaucoup de travail a été consacré en comité à l'identification des exigences fonctionnelles. On constate la présence d'une bonne structure de gestion. Cependant, les procès-verbaux des réunions ne sont pas toujours rédigés, et cela pourrait avoir comme conséquence que certains sujets tombent entre deux chaises.
• Les gestionnaires font une bonne évaluation des défis. En pratique, cependant, nous constatons une différence entre l'état d'achèvement du développement et celui des exigences fonctionnelles. Il existe un risque important que le produit ne réponde pas adéquatement à plusieurs exigences fonctionnelles lors de l'échéance de septembre prochain pour la livraison des produits.

Risques

Impact: É
Probabilité: M

Recommandation:

Il est recommandé que les exigences fonctionnelles et les produits livrables par contrat en septembre soient réexaminés. Il est aussi recommandé qu'une analyse de concordance-écart soit menée afin de préciser les exigences actuelles et futures auxquelles BAC aura à répondre.

Suggestion:

Il est suggéré que le comité directeur soit prudent et qu'il applique les décisions qui vont dans le sens de réduire les risques.

---

3.1.2 Élaboration des solutions

Activités

La Direction de la technologie de l'information (DTI) estime que Deloitte a produit un bon document sur les exigences fonctionnelles du concept de dépôt numérique fiable.

• La solution demande un procédé d'acquisition (la plate-forme de chargement virtuelle - PCV) pour charger et entreposer toutes les collections. Il est important que BAC se dote d'un énoncé des attentes des utilisateurs et qu'il réponde à toutes les questions concernant la nature et l'état d'avancement des produits, les pistes de vérification, les normes OAIS, et la responsabilité institutionnelle d'archiver.
• Les employés interviewés ont expliqué qu'au cours de la phase 1, les modules d'infrastructure, tels que sécurité, détection des virus et instruments d'acquisition, ont été livrés en premier. L'utilisateur sera moins en contact avec la fonctionnalité finale. Ceci accordera à BAC le temps de finaliser en parallèle ses exigences fonctionnelles.

On trouve de nombreuses preuves d'une bonne documentation sur la portée du DNF, incluant une architecture conceptuelle, des exigences concernant l'équipement et les logiciels, etc. Un contrat a été octroyé pour certaines des composantes du volet PCV, et la livraison est prévue en septembre par l'intégrateur.

• Certains membres du comité directeur ont identifié que le transfert des données constituait un risque majeur. Il faudra peut-être choisir, soit d'effectuer un transfert parfait, soit de continuer d'avancer avec un certain degré de confiance.
• À l'heure actuelle, la solution DNF est fondée principalement sur des technologies encore expérimentales.
• Quelques questions se posent à propos de la capacité de stockage requise et des coûts associés à la publicité sur Internet et à la récolte de données sur le web. Les coûts sont élevés et le succès est lié à l'achat d'une nouvelle infrastructure grâce à un financement par le CT. Autrement, BAC court le risque, avec ses infrastructures actuelles, de ne pas pouvoir effectuer du tout de récolte.

Conclusions

Même si la feuille de route démontre une approche " progressive ", nous avons remarqué que le travail de développement avance plus rapidement que l'analyse et l'identification des spécifications, essentiellement à cause des ententes contractuelles et des disponibilités budgétaires.

• La PCV constitue le risque no 1 pour l'organisme. Si elle ne fonctionne pas, tout le concept du dépôt numérique est en péril. C'est la composante clé de la collection numérique.
• Pourtant, le travail d'identification des exigences pour la PCV est toujours au stade conceptuel, alors que le produit livrable PCV sera disponible en septembre 2007. Cela soulève quelques questions. De quelle manière seront intégrées plus tard les composantes manquantes lors de cette première livraison? À quel prix? Comment les tests seront-ils menés? … au niveau conceptuel?

Le projet de DNF est soit en mode expérimental, soit en mode de relations de bonne foi avec l'intégrateur.

• Une relation de bonne foi se fonde sur la confiance en l'expertise de l'intégrateur pour ce qui est de livrer les divers modules des futures collections numériques, tels que la sécurité, la détection des virus, les outils d'acquisition, etc. (pour lesquels il n'existe aucune spécification fonctionnelle détaillée). Dans ce type de relation, BAC se doit de compléter ses exigences fonctionnelles en parallèle. Le risque de ce genre de relation n'a pas été examiné.

Risques

Impact: É
Probabilité: M

Recommandation:

Il est recommandé que les gestionnaires du projet terminent, en priorité, l'identification des exigences de la PCV.

• Une liste de tâches détaillée pour chacune des solutions livrables pour la PCV devrait être préparée.

Suggestion

Il est suggéré que BAC établisse des relations plus étroites avec l'intégrateur, et qu'il soit plus proactif dans l'identification de ce que chacune des parties fournira, et dans le choix des moyens techniques qu'utilisera l'intégrateur pour se conformer aux attentes quant aux produits livrables.

Voir aussi le processus de développement.

---

3.1.3 Gestion du changement organisationnel

Activités

Les personnes interviewées estiment que BAC n'a pas été très efficace dans sa gestion des changements induits par le système, et des impacts de ces changements sur les processus opérationnels. Par exemple, après avoir réalisé quelques projets pilotes pour déterminer les coûts-bénéfices du stockage numérique, le CD cherche maintenant à accélérer l'ensemble du projet, de façon à capitaliser sur ces bénéfices.

Cependant, les gestionnaires des unités fonctionnelles ont l'impression que le projet vise un objectif qui n'est pas bien compris. D'autres recherches sont requises.

• La direction estime que le changement technologique des collections de documents papier vers des documents électroniques ne représente pas un grand risque pour les ressources humaines de BAC; les personnes trouveront le moyen de s'adapter. C'est la conception adéquate des outils qui représente le principal risque.
• Malgré tout, il y a un risque certain à abandonner toute forme de document papier et à garantir que la technologie choisie aujourd'hui pour le stockage numérique, pourra conserver les collections dans 50 ans.
• Le format modulaire du nouveau système permet de réduire quelque peu ce risque. Gérer le projet de façon modulaire implique que les changements seront progressifs.

Conclusions

Il est encore trop tôt, dans le projet de DNF, pour tirer des conclusions sur la manière dont le changement est géré.

• Il y a un aspect encourageant : l'existence d'un registre des risques très bien organisé, lequel permet de documenter tout ce qui se rapporte aux changements, aux gestes à poser et au suivi des décisions.

Les représentants des unités fonctionnelles considèrent les choix technologiques comme un risque. Cependant, il n'est pas possible de revenir en arrière à des méthodes de gestion des documents sur papier pour réduire ce risque, parce qu'aujourd'hui plusieurs sources d'information ne sont disponibles que sur les sites web et en format numérique. Les gestionnaires devront donc être prudents et procéder avec soin au choix des prochaines technologies.

Risques

Impact: É
Probabilité: M

Recommandation:

Il est recommandé que les gestionnaires de BAC se préoccupent de réduire les risques induits par les changements technologiques :

• en décrivant clairement ces risques et en les discutant au sein du CD et du CEP;
• en incitant les gestionnaires du DNF et tout le personnel à s'intéresser de près aux groupes internationaux de discussion.

---

3.2 Risques associés au projet DNF

3.2.1 Organisation et gestion du projet

Activités

Le projet DNF comporte une gamme de sous-projets, sous l'autorité des gestionnaires du groupe DNF (opérations et technologie de l'information), lesquels se rapportent au Comité d'examen du projet (CEP).

• La plateforme de chargement virtuelle (PCV) constitue l'élément le plus crucial et le plus essentiel pour le futur dépôt numérique. Actuellement, 80 % de l'activité du projet se rapporte au sous-projet PCV, ce qui représente donc le principal risque de tout le projet.

Les rôles et responsabilités semblent clairs. Cependant, le projet dans son ensemble constitue une situation très complexe en ce qui concerne la coordination des interdépendances et les rôles et responsabilités de chacun des intervenants.

• D'une manière générale, le partenariat entre BAC et son fournisseur de services externe, et celui entre les unités fonctionnelles et la Direction de la technologie de l'information, fonctionnent bien et sont fondés sur la bonne foi, mais il existe des enjeux de ressources.
• La gestionnaire du groupe des technologies de l'information doit travailler avec des personnes " empruntées "; d'ailleurs, aucun employé ne se rapporte à elle dans l'organigramme. Il arrive souvent, quand elle a besoin de ressources humaines, que ces personnes ne soient pas disponibles ou qu'elle doive négocier avec des personnes qui ont d'autres priorités.

Conclusions

Il existe une bonne collaboration entre la Direction de la technologie de l'information et les unités fonctionnelles, et les membres du CD sont satisfaits de la structure organisationnelle du projet DNF.

Même si, d'une manière générale, la gestion de l'ensemble du projet fonctionne bien, la gestionnaire du groupe des technologies de l'information doit travailler avec des ressources humaines empruntées de la Direction de la technologie de l'information, ce qui la relègue à l'occasion en seconde priorité. Puisque le sous-projet PCV représente la première priorité, on peut se demander pourquoi cette gestionnaire responsable ne peut compter sur du personnel se rapportant directement à elle, pour garantir le succès de ce projet.

• Cette situation représente le point faible de la structure organisationnelle et constitue un risque majeur, notamment quand les produits livrables commenceront à arriver.

Risques

Impact:M
Probabilité: M

Recommandation:

Il est recommandé que la Direction de la technologie de l'information assigne des ressources humaines au projet PCV et que celles-ci se rapportent à la gestionnaire responsable du groupe des technologies de l'information.

---

3.2.2 Contrôle du projet

Activités

Un plan et une approche pour le projet ont été préparés conjointement avec l'intégrateur. Ce plan du DNF se situe à un niveau de généralité très élevé et nous n'avons pas pu y trouver de précisions quant aux produits livrables, ni de listes de tâches associées.

• La Direction de la technologie de l'information estime que ce plan devrait comprendre les produits livrables des unités fonctionnelles.
• Les scénarios de tests font partie des produits livrables par l'intégrateur. Cependant, on voit mal comment ils pourront être alignés sur les exigences très générales du plan actuel. Il a été question d'une stratégie pour améliorer cet alignement, qui consisterait à faire rédiger des spécifications détaillées par le personnel de BAC.

Jusqu'à tout récemment, il y avait peu de contrôles de gestion pour le projet DNF. Le gestionnaire du groupe DNF se propose d'instaurer un système de contrôle à compter du prochain exercice financier. Les contrôles actuels sont les suivants :

• les gestionnaires du groupe se réunissent chaque semaine en compagnie de tous les responsables d'équipes des opérations et des technologies de l'information;
• un registre des risques est tenu à jour et fait l'objet de discussions à chaque réunion du comité de gestion du DNF;
• des feuilles de temps et des rapports d'étape permettent d'évaluer l'avancement du travail;
• le contrôle de qualité est un domaine où ils estiment avoir bien travaillé durant la phase de planification; ce travail pourra servir de nouveau lors de la phase " assurance de la qualité ";
• des spécialistes des unités fonctionnelles et des experts en TI ont travaillé ensemble pour identifier les exigences en matière de contrôle, et des utilisateurs ont participé à leur validation.

Conclusions

Le plan se situe à un niveau tellement élevé (aucune description détaillée de produit livrable, ni aucune liste de tâches), que l'intégrateur pourrait, en toute légalité, livrer un produit qui ne répondrait pas du tout aux attentes de BAC. Même si les équipes ont travaillé de bonne foi depuis le début, et de façon très professionnelle, les produits livrés pourraient être inattendus ou insatisfaisants.

• La gestion du projet n'a pas évolué dans le sens où elle aurait dû. Ceci représente maintenant un risque, car il existe un " flou " en ce qui concerne l'identification des produits livrables.
• Même si tout semble s'être bien passé jusqu'à maintenant, le problème est que les travaux de conception et de réalisation ont été octroyés au même fournisseur. Le résultat est une situation où BAC n'a pas le contrôle sur l'aspect fonctionnel de ce qu'il recevra et ouvre la porte à un risque potentiel. Le produit pourrait ne pas satisfaire les attentes de BAC, tout en répondant aux spécifications.

Dans l'ensemble, l'expertise et les contrôles sont en place pour suivre le projet. Un examen de la documentation disponible révèle que de bonnes présentations concernant l'état du projet ont été faites, afin d'informer la Direction des résultats obtenus et de l'avancement des activités. On trouve des plans de projets et de rapports d'étape pour tous les sous-projets du DNF.

• Cependant, les procès-verbaux des réunions ne sont pas toujours rédigés systématiquement. Ces procès-verbaux vont jouer un rôle important dans la finalisation du projet, étant donné le grand nombre d'intervenants.

Risques

Impact: M
Probabilité: M

Recommandations:

Il est recommandé que les dirigeants du projet améliorent le contrôle des risques du projet :

• en préparant une liste de tâches associées aux produits livrables;
• en assignant des ressources à la mise en oeuvre d'un plan de réalisation des tâches de cette liste pendant la durée du projet;
• en se fiant au registre des risques pour réviser régulièrement ledit plan de réalisation des tâches.

Il est aussi recommandé que les gestionnaires responsables s'assurent que les procès-verbaux des réunions et les rapports d'étape soient bien rédigés et communiqués à la Direction.

---

3.2.3 Processus de développement

Activités

BAC est partenaire avec Deloitte et TPSGC pour la livraison du DNF. Une telle collaboration permet de profiter d'une large gamme d'expertise pour le développement du DNF.

• La conception se fonde sur un seul dépôt central et une seule architecture; Deloitte utilise une technologie (Interwoven) qui a fait ses preuves pour réduire les risques. Une feuille de route pour les produits livrables a été préparée et une solide documentation accompagne le tout.
• Pour les autres projets (WH et JPEG 2000), BAC procède à de bonnes recherches et prépare diverses recommandations, avant d'aller plus loin, en vue du processus de décision.

Cependant, faire affaire avec un intégrateur comporte des risques en soi, et ceux-ci doivent être gérés par BAC. Deloitte a fait plusieurs promesses pour obtenir ce contrat et doit maintenant tenir parole. La Direction de la technologie de l'information estime que BAC s'expose à un risque important en confiant, par impartition, le travail de développement à un intégrateur externe, car alors il n'est pas possible d'exercer un contrôle et une supervision globale du projet.

• La Direction a imposé un calendrier de réalisation dont les échéances sont très serrées. À ce jour, le projet a été reporté trois fois (essentiellement par manque de financement), de janvier à mars, puis à juillet et maintenant à septembre 2007.
• En conséquence, l'intégrateur jouit de beaucoup moins de temps pour réaliser son mandat, et il y a lieu de s'inquiéter qu'il ne puisse pas respecter les échéances prévues.
• De plus, la portée du projet est ambiguë, avec comme conséquence probable que les résultats seront différents de ce qui est attendu.

Conclusions

D'une manière générale, le travail de développement fait par l'intégrateur semble géré adéquatement. Il semble toutefois exister un manque de confiance entre l'intégrateur et la Direction de la technologie de l'information, et les dirigeants de BAC devront s'intéresser à ce problème afin de le résoudre.

• Ce genre de situation peut constituer un sérieux risque pour le projet, si les énergies ne sont pas dirigées au bon endroit.

D'une manière générale, la documentation, les stratégies d'action et les méthodes employées par l'intégrateur semblent bonnes. Cependant, la livraison d'une solution acceptable par le fournisseur pourrait présenter un risque d'affrontement. Même si tout s'est bien passé jusqu'à maintenant, ce genre de situation où les exigences ne sont pas spécifiées concrètement, présente toujours un risque potentiel.

• Le risque existe que BAC n'ait pas assez de contrôle sur les fonctionnalités du produit qu'il va recevoir. Le produit pourrait ne pas satisfaire les attentes de BAC, mais se conformer tout de même aux spécifications du contrat.

Risques

Impact: É
Probabilité: É

Recommandation:

Il est recommandé que la direction de BAC s'intéresse de près aux risques du processus de développement :

• en tissant des liens plus étroits avec l'intégrateur;
• en adoptant des mesures de contrôle réalistes pour les deux parties.

---

4. Risques Associés À La Technologie (AMICAN/DNF)

4.1 Infrastructure

Activités

La capacité est insuffisante pour accepter la charge actuelle ou celle à venir. La performance et le temps de disponibilité sont insatisfaisants. L'infrastructure ne semble pas fiable pour le moment; il y a de nombreux temps d'arrêt imprévus. L'infrastructure est sous-financée; elle est tout de même conçue pour être extensible et pourrait donc croître rapidement si les fonds devenaient disponibles.

• La Direction de la technologie de l'information estime que la configuration et la gestion de l'infrastructure du DNF ne présentent pas de risques sérieux, même si des problèmes ont été constatés lors de la deuxième récolte web. La nouvelle infrastructure devrait régler ce problème.

HP a réalisé une étude de volume de la technologie Oracle, afin d'évaluer les besoins en capacité de l'environnement de production pour le projet AMICAN. Deux des trois serveurs requis sont en place et adéquats pour le démarrage de la technologie CoC en mai 2007. Cependant, il n'y aura pas assez de capacité disponible pour l'ensemble du projet AMICAN; les études de capacité ont indiqué le besoin d'un autre serveur, mais la date d'acquisition de celui-ci n'a pas été fixée précisément.

• Les environnements pour le développement et les tests d'assurance de la qualité se trouvent sur le même serveur; la performance de celui-ci est faible et sa capacité insuffisante pour tester adéquatement de grands volumes. Cependant, un nouveau serveur sera bientôt disponible pour le développement.
• Les attentes du public vont sans doute augmenter en octobre prochain, au moment où la CBC va diffuser son émission sur la généalogie. C'est une question qui devrait être clarifiée par un ANS.

Un bon document définissant les exigences avait été rédigé pour la première phase du projet DNF. Mais la Direction de la technologie de l'information s'inquiète entre autres du fait que les exigences à long terme pour les infrastructures ne soient pas bien analysées. Par exemple, l'exigence concernant le réseau de stockage SAN présente un risque. Voilà un bon exemple de ce qui arrive lorsqu'un projet est réalisé par étapes séparées et dépendantes du financement.

• Si la Direction de la technologie de l'information ne reçoit pas le financement requis du CT, elle pourrait tout de même aller de l'avant avec les fonds internes de BAC; la principale composante, le réseau de stockage SAN, pourrait encore être mise en place. La Direction pourrait alors soutenir la phase un du projet DNF. Cependant, le risque encouru serait grand et, en cas de crise, les réserves disponibles ne seraient pas énormes.

Conclusions

De l'avis général, c'est bien l'infrastructure qui constitue le maillon le plus faible du projet. Les faiblesses sont de deux ordres : les équipements et le personnel de soutien technique.

• Les équipements commencent à se faire vieux et sont presque obsolètes. Ils devront être remplacés, mais tout dépendra du financement.
• Le concept d'architecture extensible offre la possibilité d'ajouter des capacités supplémentaires relativement rapidement et facilement; l'enjeu n'est pas d'ordre technique mais plutôt d'ordre financier. La croissance physique de l'infrastructure dépend de la réponse du CT à la prochaine demande de financement.

Des plans d'amélioration de l'infrastructure ont été préparés. En attendant, on peut douter à la capacité du système de traiter le large volume de demandes d'informations qui sera généré suite à l'émission de la CBC sur la généalogie en octobre.

Risques

Impact: É
Probabilité: M

Recommandation:

Il est recommandé que BAC prépare un Accord sur le niveau de service (ANS) qui préciserait les objectifs de capacité, de fiabilité et de disponibilité pour les modules AMICAN à la veille d'être mis en production; le FS/PAM constitue une priorité. Ces objectifs devraient ensuite servir à déterminer si l'infrastructure requiert des capacités supplémentaires et des fonctions de redondance.

Suggestions:

Il est suggéré que des investissements adéquats soient consentis en priorité à l'augmentation des capacités de l'infrastructure du projet, advenant l'octroi des fonds par le CT à partir du 1^er avril 2007.

Si ces fonds ne sont pas débloqués le 1^er avril, il est alors suggéré que l'institution réduise l'envergure du projet AMICAN à la hauteur de ce qui peut être financé à même les fonds internes existants. Quoiqu'il arrive, le financement supplémentaire de l'infrastructure demeure une priorité.

---

Activités

Voici les risques associés à l'environnement de l'infrastructure chez BAC :

• Le logiciel VERITY (gestion du contenu web) arrive à la fin de son cycle de vie (et sera remplacé par IDOL 7, un produit de la firme Automony). En conséquence, il n'y a plus de réparation de bogue ni d'entretien par le vendeur. Si BAC se retrouve sans soutien, il lui faudra retirer la fonction de recherche fédérée et retourner à des bases de données individuelles. Il n'y a qu'une seule personne possédant cette expertise à BAC.
• En général, les personnes interviewées estiment que la disponibilité du système, notamment le module FS/PAM, est insatisfaisante. Malgré l'absence d'objectifs précis en matière de disponibilité (il n'y a pas d'ANS à ce sujet), l'orientation donnée par la haute direction implique que les fonctions de recherche sur le web devraient être disponibles 24h/jour, 7j/semaine, sinon la réputation de BAC en souffrirait.
• À l'heure actuelle, il n'y a pas de centre de secours, ni immédiat, ni graduel, en cas d'urgence. Il y avait autrefois une assurance fournie par HP pour le sauvetage de l'infrastructure en cas de désastre. Cette assurance a été annulée par TPSGC il y a quelques années, car le CT avait estimé qu'aucun des systèmes de BAC n'était essentiel à sa mission.
• La Gestion de l'infrastructure informatique (GII) se plaint de recevoir son financement tard durant l'exercice financier; elle doit ensuite mettre les bouchées doubles avec le peu de personnel dont elle dispose pour satisfaire à la demande, tout le monde voulant une installation le plus rapidement possible. Cette situation crée énormément de pression sur le personnel en question et risque d'empêcher une bonne planification de l'installation des équipements.
  • Une forte pression a été exercée sur les employés de la GII pour l'installation rapide de l'infrastructure du DNF, à temps pour la première échéance. Après l'installation, l'échéance a été repoussée. Ceci crée naturellement de l'animosité. On leur a dit qu'il fallait aller très rapidement, puis, que rien de cela ne serait utilisé avant trois mois.
  • Il existe un problème spécifique à la GII; non seulement cette unité manque d'employés, mais ces derniers sont impliqués dans plusieurs nouveaux projets et passent 50 % de leur temps à régler des problèmes dûs à des équipements vieillissants et non fiables.

Conclusions

Parce que l'attention est concentrée sur la livraison d'AMICAN/DNF, les autres systèmes et leur soutien souffrent d'un manque d'investissement.

La répartition des responsabilités et la communication entre le personnel du projet travaillant aux applications et à l'infrastructure ne fonctionnent pas très bien. Les responsabilités de la GII en ce qui concerne la planification des modifications de l'infrastructure et son manque chronique de personnel présentent des risques pour le projet.

À propos du projet DNF, il y a lieu de s'inquiéter du fait que le personnel des unités fonctionnelles ne soit pas porté à inviter la GII aux tables de discussion, car on ne la considère pas comme un acteur à part entière dans le projet, mais plutôt comme un fournisseur de services à l'ensemble des groupes. En conséquence, la GII ne prend connaissance qu'à la dernière minute des besoins en matière d'infrastructure et se plaint de ne pas avoir les budgets nécessaires pour l'entretien de ces équipements. Ceci engendre des retards avant la mise en place de l'infrastructure.

• Le point de vue de la DTI à ce sujet est le suivant :
  1. Il faut impliquer la GII dans l'équipe dès le départ.
  2. Il faut planifier les besoins en matière d'infrastructure lors de la phase de conception du projet.
  3. Voici un cas où il manque une bonne méthode de gestion de projet qui permettrait d'améliorer les choses.

Risques

Impact: M
Probabilité: É

Recommandations:

Il est recommandé que l'ensemble du soutien technologique soit réexaminé, afin d'identifier les risques opérationnels et de les réduire.

• Plus précisément, il faudra examiner les problèmes de la GII en matière de personnel.

Il est recommandé que BAC examine le risque que constitue l'insuffisance de mesures de sauvegarde et de récupération. Plus précisément, BAC devrait préparer des ANS et des plans de récupération couvrant l'ensemble de ses opérations et services essentiels, et s'assurer que la haute direction connaît les délais cibles maximums pour la reprise éventuelle des services.

---

4.2 Transition technologique

Activités

La nouvelle architecture d'AMICAN est fondée sur des serveurs HP à répartition des charges en montée de puissance, Oracle RAC et Linux. Certains des gestionnaires responsables des projets d'applications et le gestionnaire de projet, semblent avoir des inquiétudes quant à la transition vers Oracle RAC et à l'utilisation d'un répertoire électronique pour le CIM, mais ce n'est pas le cas du personnel responsable des infrastructures.

• Le remplacement des serveurs Alpha par ceux de HP ne causera aucun problème; le module de recherche fédérée fonctionne sur un serveur HP depuis quelque temps et le personnel des infrastructures est déjà familier avec ce serveur.
• Certains se demandent si le fait que l'environnement d'assurance de la qualité ne soit pas le même que celui visé pour la production représente un risque. Oracle RAC constitue le seul nouvel aspect de la plateforme de production; le client d'Oracle ne change pas, il n'est que dirigé vers une base de données différente, ce qui sera invisible aux yeux des développeurs.
• Selon le personnel des infrastructures, le changement vers Linux ne constitue qu'un risque mineur, parce que les administrateurs de systèmes sont déjà formés à ce sujet et que ce système est similaire à celui d'UNIX déjà en place.
• Alors que certains employés des projets d'applications s'inquiètent du fait que le répertoire électronique Novell constituera le fondement de l'infrastructure du CIM, le personnel considère que celui-ci est fiable, car il est en usage à BAC depuis 10 ans.

En ce qui concerne les applications et les processus opérationnels, les changements seront faits de façon modulaire. Peu de personnes s'inquiètent des procédures opérationnelles de postproduction; les procédures actuelles relatives à la gestion du changement, des problèmes et des versions prévaudront. Cependant, dans le cas de CoC, le responsable de projet n'est pas certain de la manière dont seront faites la gestion du changement et la gestion des versions lors de la production.

• La mise en application de CoC se fera d'un seul coup dans le nouveau système, mais il est prévu de conserver Trakker pendant quelques mois comme système de secours. S'il s'avérait nécessaire de retourner à Trakker, toutes les données transférées à CoC devront être retransférées à Trakker. Il n'est pas clair comment cela se ferait, ni qui fournirait le soutien requis pour Trakker.
• Il n'existe pas de mécanisme pour examiner d'éventuels changements après la production. La gestion de la configuration (CM) est effectuée par le groupe CM pour les applications seulement. Les membres du groupe gèrent l'assurance de la qualité et le maintien de la production grâce à UNIX-Linux RCS (outil automatisé) pour le contrôle des versions. Le groupe CM accorde l'autorisation des codes d'entrée et de sortie grâce à ce système. Cependant, il n'existe pas de gestion de la configuration de l'infrastructure pour l'instant - on est à la mettre en place actuellement.

C'est TPSGC qui gère présentement le contrat pour le DNF. Il sera aussi responsable de la gestion du système d'infrastructure des TI pour BAC, en vertu d'une entente pour travailler conjointement avec BAC lors de la deuxième phase (projet de gestion partagée du gouvernement canadien). BAC s'attend à pouvoir ainsi réduire son risque grâce à cette collaboration, mais pourrait aussi attendre la troisième phase, si la première n'allait pas très bien. Ce déploiement présente cependant quelques risques.

• L'infrastructure permettant la mise en production des sous-projets DNF en septembre n'est pas installée. Il n'est pas encore clair quelle doit en être la capacité, et donc, quoi acheter. On attend les recommandations et les approbations.
• Le gestionnaire responsable du projet DNF estime que les exigences en matière d'espace sont immenses et très onéreuses (récolte du web, numérisation, audiovisuel numérique). Par exemple, il y a un risque que les récoltes du web soient limitées au budget disponible et ne produisent que des informations ou des collections incomplètes. La DTI a besoin d'une politique générale concernant la planification du stockage de données.

Conclusions

Trois composantes changent en même temps : la technologie, les systèmes et les processus opérationnels. Les changements sont apportés de façon modulaire, du moins pour les applications et les processus opérationnels. Les changements technologiques comprennent trois nouveaux éléments (Oracle RAC, Linux et les serveurs HP), mais seul Oracle RAC est vraiment nouveau, les autres étant en place depuis quelque temps déjà. Cependant, la portée de l'activité, la dépendance technologique des futures opérations de BAC et l'ampleur du changement constituent un risque.

• Le risque associé à la transition est souvent sous-estimé. Jusqu'à maintenant, ce risque a été bien planifié et géré par la Direction de la technologie de l'information. Malgré cela, il faudra accorder encore plus d'attention à la planification en général, notamment en matière d'infrastructure.
• Les procédures de production sont en place, mais peut-être pas assez bien connues par tous les responsables de projet.
• Trakker sera apparemment mis hors service après quelques mois d'opération réussie de CoC. Il n'existe cependant aucun plan de remise en service de Trakker si CoC ne fonctionnait pas bien.
• Il n'existe pas de gestion de la configuration pour l'infrastructure; cela constituera un risque quand les modules seront en production.

Risques

Impact: M
Probabilité: É

Recommandations:

Il est recommandé que BAC se préoccupe des risques de transition de la manière suivante :

• s'assurer que du soutien adéquat soit disponible chez Oracle lors de la transition;
• améliorer les communications entre les employés de GII et ceux de l'administration (AMS), afin de réduire les inquiétudes de ces derniers;
• faire préparer pour Trakker un plan de secours, incluant un programme de soutien des applications et une procédure de mise à jour des données si nécessaire;
• apporter des éclaircissements aux procédures de gestion du changement, des problèmes et des versions qui seront en vigueur lorsque CoC sera mis en production;
• mettre en œuvre une gestion formelle de la configuration au même moment que les nouveaux modules.

---

Activités

Il n'y a pas assez de ressources humaines pour soutenir, en même temps, l'infrastructure et les projets - on manque à la fois d'employés et d'expertise. Dans plusieurs cas, il n'y a qu'une seule personne aux infrastructures qui connaisse bien une technologie en particulier, et cette personne n'a pas de remplaçant.

• Le personnel rattaché aux infrastructures a commencé seulement récemment sa formation sur Oracle RAC, malgré le fait que cette technologie ait été achetée il y a environ un an; il existe donc un risque que le personnel manque d'expérience avec ce système.
• On estime que le personnel des infrastructures ne possède pas assez de compétences en gestion de projet, et ne produise pas les types de plans requis pour démontrer de quelle manière les environnements vont changer et être développés.
• L'entretien des applications sera assuré par des employés permanents de BAC. Même si la quantité de personnel pour cet entretien est adéquate, elle n'est pas idéale; ces personnes doivent travailler avec un très grand nombre d'applications et d'outils. Elles sont formées essentiellement " sur le tas ", lors de leur affectation à travailler sur un de ces modules.
• Le gestionnaire de projet des applications prépare actuellement un plan illustrant la migration des bases de données d'un serveur à l'autre lors d'une mise en application progressive. Il a été proposé, et accepté, qu'Oracle RAC ne soit pas utilisé en production immédiatement, afin de réduire les risques au minimum.

Conclusions

Les responsables et le personnel de la Direction de la technologie de l'information n'estiment pas que la transition technologique représente un grand risque; c'est la disponibilité du personnel pour répondre à la demande croissante de soutien qui pose problème. Si le financement est accordé, BAC pourra jouir de ressources additionnelles et pourra alors mieux planifier tous les éléments du plan de remplacement des équipements, y compris les besoins à long terme. Cependant, même avec de nouveaux investissements, un manque de personnel pour soutenir cette croissance pourrait avoir des conséquences néfastes. Le niveau de personnel pour l'entretien est correct, mais pas idéal.

Il existe un risque de rupture du soutien des systèmes actuels durant la période requise pour mettre en place le nouveau système AMICAN/DNF, ses produits et ses outils. Pouvoir fournir un soutien continu demeure une priorité.

Risques

Impact: M
Probabilité: É

Recommandation:

Il est recommandé que, dans les cas où il n'y a qu'une seule personne à la division des infrastructures qui connaisse un système en particulier, chaque expert ait au moins un remplaçant.

Suggestions :

Il est suggéré, pour de futurs projets, que la DTI clarifie les responsabilités du personnel de la GII dans la planification des changements d'infrastructures, et qu'elle fournisse au besoin de la formation en gestion de projet.

Il est suggéré que BAC assigne, dans le prochain budget de fonctionnement, des ressources suffisantes en personnel d'entretien technique.