Agence des services frontaliers du Canada
Symbole du gouvernement du Canada

Liens de la barre de menu commune

ARCHIVÉ - Examen du Manifeste électronique

Mission d'examen

Avertissement Cette page a été archivée.

Contenu archivé

L'information dont il est indiqué qu'elle est archivée est fournie à des fins de référence, de recherche ou de tenue de documents. Elle n'est pas assujettie aux normes Web du gouvernement du Canada et elle n'a pas été modifiée ou mise à jour depuis son archivage. Pour obtenir cette information dans un autre format, veuillez communiquer avec nous.

Décembre 2012

Ce document est disponible en format PDF (802 Ko) [aide sur les fichiers PDF]


Table des matières



1.0  INTRODUCTION

Le Manifeste électronique est un grand projet de l'État en cours à l'Agence des services frontaliers du Canada (ASFC). Une fois sa mise en œuvre intégrale terminée, le Manifeste électronique changera le processus d'importation des marchandises commerciales. Les négociants tels que les transporteurs, les transitaires et les importateurs de tous les modes de transport devront transmettre à l'ASFC des données sur le fret, le moyen de transport et l'équipage par voie électronique avant l'arrivée des expéditions à la frontière.

La Division de la vérification interne a effectué un examen du projet du Manifeste électronique, qui comprenait les contrôles exercés sur la portée du projet, les pratiques de gestion du projet, les processus de gestion des coûts et les rapports d'étape sur le projet. L'examen comprenait des entrevues et un examen de la documentation du projet, qui ont eu lieu au cours de la période allant du 1er janvier au 30 août 2012.

2.0   IMPORTANCE DE L'EXAMEN

Cet examen est important, car les grands projets informatiques du gouvernement comme le Manifeste électronique sont fondamentalement complexes, coûteux et risqués, en plus d'être connus pour leurs dépassements de coûts, leurs retards et leur incapacité de livrer ce qui a été planifié. L'examen du Manifeste électronique fournira à la direction de l'ASFC de l'information sur le caractère adéquat de ses pratiques de gestion de projet en général et de ses pratiques propres au projet du Manifeste électronique.

OBJECTIF

L'examen avait pour objectif de déterminer la mesure dans laquelle le Manifeste électronique répondra aux besoins des utilisateurs finals; le caractère adéquat du plan de projet en ce qui concerne la gestion de la portée, du calendrier et des ressources du projet; la gestion des coûts; et l'efficacité des outils et des processus liés aux rapports d'étape.

3.0  ÉNONCÉ DE CONFORMITÉ

L'examen est conforme aux Normes relatives à la vérification interne au sein du gouvernement du Canada, tel que démontré par les résultats du programme d'assurance et d'amélioration de la qualité. Comme l'exige la Politique sur la vérification interne du Conseil du Trésor, la stratégie et les méthodes de vérification adoptées sont conformes aux Normes internationales pour la pratique professionnelle de l'audit interne de l'Institut des vérificateurs internes et aux Normes relatives à la vérification interne au sein du gouvernement du Canada.

L'examen visait à fournir un faible niveau d'assurance, soit le niveau correspondant à un examen.

Retourner au haut de la page

4.0   PRINCIPALES CONSTATATIONS

Des consultations sont menées avec les utilisateurs finals du Manifeste électronique, à l'aide de groupes de travail sur le projet et des comités de gouvernance. Certains ont signifié leur intérêt pour des discussions plus approfondies sur les besoins opérationnels et les décisions prises. Les gestionnaires du projet comprennent l'importance d'une bonne consultation avec les intervenants et considèrent ceci comme un faible risque dans le contexte global du projet.

Le projet du Manifeste électronique a réalisé plusieurs types de tests sur les déploiements précédents. Cependant, à l'ASFC, des normes de mise à l'essai n'ont pas été élaborées pour les plans, et les essais d'acceptation définitifs n'incluent pas les utilisateurs finals. Les résultats des essais n'ont pas été communiqués aux intervenants pour permettre une évaluation plus éclairée du système mis en œuvre. Des essais d'acceptation inefficaces pourraient entraîner des problèmes et des demandes de changement après le lancement du système dans l'environnement de production.

Le compromis entre l'efficacité du projet et la participation des utilisateurs finals présente des risques qui doivent être pris en considération. Par exemple, le lancement initial du regroupement de déploiements 1, prévu pour le 31 mars 2013, pourrait être à risque. Le travail de mise à l'essai estimé au départ a été plus important que le temps disponible. Si cela devient un problème, la direction devra examiner les compromis possibles avant de prendre une décision. Il existe des comités de gouvernance de projet à tous les échelons pour faciliter le processus décisionnel.

En ce qui concerne la planification et la surveillance de projet, la direction ne dispose pas d'un ensemble de données complet sur la gestion de projet pour surveiller les progrès concernant le temps, la portée et les coûts. Chaque gestionnaire a la responsabilité de gérer sa partie du projet et d'en rendre compte mensuellement. On se fie à l'idée que ce processus permettra de cerner les problèmes et les risques et de les régler efficacement en temps opportun.

La gestion de la valeur réalisée (GVR) est un processus qui fournit à la direction de l'information sur le rendement des investissements, ainsi que les points de données nécessaires pour estimer les coûts et les dates probables d'exécution d'un projet. Dans le cadre du plan de gestion des coûts établi par l'Agence pour le Manifeste électronique, il avait été convenu d'utiliser la GVR pour mesurer le rendement. Bien que ce travail ait été entrepris, il a été abandonné en raison de sa complexité et du manque d'outils à l'Agence pour la GVR.

Dans le cas des projets pluriannuels, les prévisions de coûts sont censées être effectuées au moyen d'un modèle d'établissement des coûts conforme à la présentation au Conseil du Trésor. Le Manifeste électronique ne suit pas ce processus. Les gestionnaires de projet négocient leurs besoins budgétaires avec le bureau de projet du Manifeste électronique sans connaître le coût des plans de projet détaillés. Les coûts prévus pour l'exécution du projet du Manifeste électronique se fondent sur la présentation initiale au Conseil du Trésor et les plans de travail élaborés par les gestionnaires de projet.

La Direction générale du contrôle a indiqué qu'elle ne pouvait pas fournir une assurance raisonnable concernant la santé financière du projet, car les coûts et les prévisions du projet ne sont pas établis en fonction des éléments livrables. Elle surveille l'information sur les coûts réels et en discute avec les gestionnaires de projet pour s'assurer qu'elle est conforme à l'information organisationnelle.

Les gestionnaires de projet rendent régulièrement compte de l'état du projet. Il faut clarifier quelle information doit être communiquée, ce qui comprend l'exhaustivité de certains éléments du tableau de bord et le besoin de rendre compte du projet en fonction des éléments livrables plutôt que des phases du projet. La surveillance du tableau de bord pourrait être renforcée afin que tous les problèmes importants des intervenants de l'ASFC soient signalés. Le risque est que la haute direction de l'ASFC ne soit pas informée des problèmes importants qui pourraient avoir des répercussions plus vastes sur les opérations.

Retourner au haut de la page

5.0   SOMMAIRE DES RECOMMANDATIONS

Six recommandations découlent de l'examen :

  • Revoir le processus actuel de consultation avec les utilisateurs finals afin de s'assurer qu'ils l'ont bien compris et que les problèmes sont bien abordés.
  • Élaborer et mettre en œuvre des normes de projet à l'ASFC pour les plans de mise à l'essai et les essais d'acceptation par l'utilisateur (EAU).
  • Déterminer si le cycle de développement des systèmes et les pratiques de gestion de projet qui supportent les techniques souples adoptées pour le projet du Manifeste électronique sont acceptables et applicables à d'autres projets de l'Agence, et mettre à jour les politiques et les lignes directrices sur la gestion de projet en conséquence.
  • Élaborer et mettre en œuvre un processus pour démontrer la réalisation des avantages du Manifeste électronique.
  • Fournir une assurance concernant la santé financière et les coûts restants prévus du projet du Manifeste électronique et les approuver dans le tableau de bord.
  • Demander au comité des directeurs généraux sur les projets d'examiner et de discuter tous les risques et les problèmes, et inclure les risques et problèmes critiques dans le tableau de bord du projet Manifeste électronique.

6.0 RÉPONSE DE LA DIRECTION

La Direction générale des programmes, la Direction générale du contrôle et la Direction générale de l'information, des sciences et de la technologie (DGIST) approuvent l'examen et les constations qui en découlent.

La Direction générale des programmes mettra en œuvre un processus de consultation amélioré avec les utilisateurs finals, fera état des avantages liés au Manifeste électronique et prendra les mesures nécessaires pour s'assurer que le comité des directeurs généraux sur les projets peut passer en revue et discuter de tous les importants risques et problèmes liés au projet.

La DGIST déterminera si le cycle de vie du développement des systèmes et les pratiques de gestion de projet (techniques souples) adoptées pour le projet du Manifeste électronique sont acceptables et applicables à d'autres projets de l'Agence et mettra à jour les politiques et les lignes directrices sur la gestion en conséquence. La DGIST donnera également suite à une proposition de modernisation et de transformation concernant une approche de la mise à l'essai pour répondre aux recommandations.

La Direction générale du contrôle, en collaboration avec la Direction générale des programmes (le bureau de première responsabilité), la DGIST (le bureau consultatif) et le Bureau de gestion de projet de l'organisation (BGPO), mettra en œuvre un processus dans le but de fournir une assurance concernant la santé financière et les coûts restants prévus du projet du Manifeste électronique et les approuver dans le tableau de bord.

Retourner au haut de la page

7.0 CONSTATATIONS

7.1 Portée et besoins des utilisateurs

Objectif de gestion du projet : Respecter la portée du projet et répondre aux besoins des utilisateurs finals.

Le succès d'un projet dépend de l'efficacité avec laquelle le résultat du projet final atteint les objectifs opérationnels initiaux et répond aux besoins des responsables des processus administratifs et des utilisateurs finals. De bonnes pratiques de gestion de projet aident les gestionnaires de projet à respecter la portée du projet et à répondre aux besoins des utilisateurs finals. Ces pratiques comprennent l'approbation de la définition de la portée et des besoins des utilisateurs, l'adoption de mesures de protection appropriées pour gérer les changements apportés à la définition de la portée du projet et aux besoins des utilisateurs, ainsi que des essais d'acceptation par l'utilisateur avant le lancement du système dans l'environnement de production.

Portée du projet :

Avant 2010, les directions générales responsables (Admissibilité, Exécution de la loi et Opérations) approuvaient les besoins opérationnels. Depuis la réorganisation du 1er avril 2010, la Direction des projets principaux de la Direction générale des programmes assume le rôle de bureau de première responsabilité pour le projet du Manifeste électronique. Les bureaux consultatifs, y compris d'autres directions de la Direction générale des programmes et d'autres directions générales, agissent maintenant à titre d'experts en la matière. La réorganisation avait pour but d'accroître les gains d'efficience de la structure de gouvernance et de rationaliser le processus de renvoi aux paliers supérieurs. Par conséquent, les utilisateurs finals internes (directions générales des Opérations et des Programmes – à l'exception de la Direction des projets principaux) ne sont plus tenus d'approuver les besoins opérationnels et n'ont plus le pouvoir d'approuver les questions stratégiques et la définition de la portée. Le compromis entre l'efficacité et la participation des utilisateurs finals présente des risques différents qui doivent être évalués et pris en considération.

À l'heure actuelle, l'unité du secteur commercial de la Direction des programmes avant l'arrivée à la frontière est chargée de la coordination des consultations sur les besoins entre l'équipe de projet et les représentants des utilisateurs finals. L'unité du secteur commercial a recensé les bureaux de première responsabilité appropriés, et elle leur fournit la documentation pertinente pour qu'elle soit commentée. Une fois les commentaires reçus, l'unité du secteur commercial les résume et tente de trouver une solution aux problèmes. Si un problème ne peut pas être réglé, il est renvoyé au comité des directeurs sur les politiques pour qu'il prenne une décision. Un autre moyen d'obtenir une rétroaction consiste à créer une boîte de courriel interne où les utilisateurs peuvent envoyer les problèmes pour que l'équipe des politiques les examine et prenne des mesures en conséquence. Depuis, le processus a évolué et s'est amélioré grâce à la création du comité des gestionnaires sur les politiques en février 2012. Ce comité a été créé pour examiner la nouvelle fonctionnalité du système et discuter des questions stratégiques toutes les deux semaines. Ces séances doivent donner l'occasion de discuter des besoins des utilisateurs et de les valider. Même si des consultations sont menées avec les futurs utilisateurs internes, certains utilisateurs finals ont manifesté un intérêt pour d'autres discussions sur les besoins opérationnels et les commentaires sur les décisions prises. La Direction du projet comprend l'importance d'une bonne consultation avec les intervenants et considère ceci comme un faible risque dans le contexte global du projet.

Retourner au haut de la page

Contrôles exercés sur les changements apportés au projet :

En ce qui concerne les mesures de protection qui s'appliquent à la gestion des changements apportés à la définition de la portée du projet et aux besoins des utilisateurs finals, l'équipe de projet du Manifeste électronique a adopté une approche plus itérative de la gestion du projet. Cette approche s'inspire des concepts de la gestion de projet souple et est reconnue dans l'industrie. Pour obtenir les besoins de façon souple, il faut mener des consultations avec les utilisateurs régulièrement au moyen de diverses méthodes permettant de répondre aux besoins opérationnels acceptables.

Les équipes de projet du Manifeste électronique et les représentants de la technologie de l'information (TI) doivent déterminer quels éléments du projet définissent la portée et les besoins opérationnels liés à chacun des trois regroupements de déploiements restants et serviront de fondement au développement des systèmes. Dans la plupart des cas, les équipes opérationnelles faisant partie du projet du Manifeste électronique produisent les besoins des utilisateurs liés à chaque regroupement de déploiements. Une entente sur les besoins constitue le plan de base pour lequel les systèmes sont développés. Le plan de base des deux premiers regroupements de déploiements a été établi en juillet 2012, ce qui a entraîné le risque que les équipes de la TI aient utilisé des éléments de projet qui n'étaient pas terminés. Un plan de base des besoins est un élément important du contrôle des changements, car toutes les modifications apportées aux besoins après l'établissement du plan de base nécessitent une demande de changement officielle. Sans un plan de base, les besoins des utilisateurs peuvent fluctuer pendant le processus de développement et entraîner des conséquences indésirables comme le remaniement des systèmes développés.

Une autre considération est le besoin de collaborer avec les futurs utilisateurs lors du processus d'obtention des besoins. Comme cela a été mentionné, les trois prochains regroupements de déploiements intègrent l'approche souple plus itérative de la définition des besoins. L'approche actuelle comporte des aspects d'une approche souple avec quelques différences importantes. Le projet du Manifeste électronique n'utilise pas de petits cycles de lancement permettant au produit d'être constamment prêt pour un déploiement. De plus, il n'y a pas de rétroaction continue entre les utilisateurs finals et les équipes de développement. Par conséquent, il peut y avoir d'importants décalages entre la réception des commentaires des intervenants et le moment où les groupes en question valident la fonctionnalité élaborée.

Essais d'acceptation par l'utilisateur :

Habituellement, avant le lancement de modifications de système dans l'environnement de production, l'application est mise à l'essai dans un environnement contrôlé pour en déterminer la fonctionnalité et la convivialité au moyen de scénarios qui simulent la façon dont l'utilisateur final se servira du produit.

Le projet du Manifeste électronique a un plan pour la mise à l'essai et la mise à l'essai a été fait pour des déploiements antécédents. Cependant, à l'ASFC, des directives ou des normes organisationnelles précises propres aux plans de mise à l'essai ou à l'acceptation par l'utilisateur n'ont pas été élaborées.

En ce qui concerne les activités de mise à l'essai des regroupements de déploiements du Manifeste électronique, les domaines à renforcer comprennent une participation accrue des utilisateurs finals et une amélioration de la consignation et de la communication des résultats des essais. Plus particulièrement, les utilisateurs finals n'ont pas participé aux essais d'acceptation, et les tâches n'ont pas été séparées entre les personnes qui ont défini les besoins et celles qui les ont mis à l'essai. Le plan de mise à l'essai n'était pas suffisamment détaillé. Les plans de mise à l'essai doivent comprendre de l'information détaillée sur la portée des essais, le calendrier, les résultats attendus des essais, les critères de lancement et les risques connexes, ainsi que les impondérables. Les résultats des essais examinés n'étaient pas correctement étayés et n'avaient pas été communiqués à tous les intervenants pour permettre une évaluation éclairée du système mis en œuvre par les intervenants internes du projet, comme la Direction générale des opérations, la Direction des programmes frontaliers et la Direction des programmes avant l'arrivée à la frontière.

En mai 2012, un lancement lié au déploiement du passage dans le mode ferroviaire a fait l'objet d'une période réduite de mise à l'essai. La mise en œuvre du système a connu des problèmes, et le règlement de ces problèmes a retardé d'un mois le développement du regroupement de déploiements suivant. Le regroupement de déploiements de mai 2012 a respecté les engagements pris concernant les délais du projet. Il est reconnu que la direction doit établir un équilibre entre les besoins relatifs à la portée, les coûts et le calendrier en plus de gérer les risques connexes.

Retourner au haut de la page

Sommaire

En ce qui concerne l'objectif de gestion de projet susmentionné, l'Agence s'expose au risque que cette fonctionnalité du système ne réponde pas aux besoins initiaux des utilisateurs finals et que des frais supplémentaires soient engagés pour présenter des demandes de changement visant à répondre aux préoccupations des utilisateurs. De plus, les résultats attendus visant à accroître l'efficacité des employés pourraient ne pas être atteints, et la direction pourrait être dans l'incapacité d'obtenir l'information dont elle a besoin pour gérer efficacement les processus opérationnels.

Le projet comporte différents niveaux de tolérance au risque. Le compromis entre l'efficacité du projet et la participation des utilisateurs finals présente des risques qui doivent être pris en considération par les comités de gouvernance de projet.

RECOMMANDATION 1

Le vice-président de la Direction générale des programmes devrait revoir le processus actuel de consultation avec les utilisateurs finals de façon à s'assurer que le processus est compris, que l'opinion des utilisateurs finals est prise en considération et que tout problème est résolu de façon appropriée.

Réponse de la direction

La Direction générale des programmes approuve la recommandation. L'équipe de projet du Manifeste électronique, en collaboration avec la Direction générale des opérations, améliorera les consultations auprès des intervenants en menant des groupes de discussion avec les utilisateurs finals concernant le passage à l'état final et les systèmes d'évaluation des risques. Elle passera en revue et documentera également le processus actuel concernant les consultations avec les utilisateurs finals et identifiera toute lacune importante dans le processus. D'ici mars 2013, la Direction générale des programmes mettra en œuvre un processus de consultation révisé qui permettra de s'assurer que le processus est compris, que l'opinion des utilisateurs finals est prise en considération et que tout problème identifié par le processus est résolu de façon appropriée.

RECOMMANDATION 2

Le vice-président de la DGIST, en collaboration avec le vice-président de la Direction générale des programmes, devrait élaborer et mettre en œuvre des normes de projet à l'ASFC pour les plans de mise à l'essai et les essais d'acceptation par l'utilisateur (EAU).

Réponse de la direction

La DGIST approuve la recommandation. La DGIST donnera suite à une proposition de modernisation et de transformation concernant une approche de la mise à l'essai pour répondre aux normes propres aux plans de mise à l'essai et aux EAU. D'ici avril 2013, le modèle de mise à l'essai du projet pilote sera mis en œuvre.

Retourner au haut de la page

7.2 Plan de projet

Objectif de gestion du projet : Le plan de projet est suffisamment détaillé pour guider le projet tout au long de son cycle de vie.

L'orientation en matière de gestion de projet à l'ASFC a permis d'établir une approche commune de la gestion de projet. Les plans de projet sont des documents obligatoires qui comprennent la portée, les éléments livrables, les structures de répartition du travail, les rôles et les responsabilités, les estimations de coûts, les jalons, les liens de dépendance clés et le chemin critique du projet. Un plan de projet efficace établit un plan de base et permet à la direction de suivre les progrès touchant la portée, le temps et les coûts. L'orientation établie par le bureau de gestion de projet de l'organisation se fonde dans une large mesure sur les principes traditionnels de la gestion de projet.

L'approche du Manifeste électronique à l'égard des calendriers de projet comporte des concepts souples visant à réaliser des gains d'efficience. L'orientation de l'Agence ne prévoit pas de méthodes de rechange comme la gestion de projet souple, laquelle est reconnue en tant que méthode valide. En résumé, voici ce que comprend l'approche du projet du Manifeste électronique :

  • Une définition de la portée qui vise à réaliser des gains d'efficience. En décembre 2010, le groupe de travail sur le déploiement stratégique du Manifeste électronique a été créé pour établir une séquence de déploiement de haut niveau pour le reste des éléments livrables du Manifeste électronique. La définition de la portée a été modifiée pour permettre le lancement des éléments livrables en parallèle et réaliser des gains d'efficience à l'égard du calendrier.
  • Une approche « case temps » a été adoptée pour la planification de projet selon laquelle les échéances (dates de fin) liées à la mise en œuvre de systèmes sont fixes. Les dates inscrites au calendrier pour les tâches peuvent fluctuer afin que les échéances soient respectées. Chaque équipe de projet a la responsabilité de respecter ses échéances.
  • Le calendrier principal indique la durée et les heures prévues de chaque tâche. Un nombre élevé de plans détaillés se greffent au calendrier principal du projet. Les plans de projet détaillés contiennent les éléments livrables convenus dans le document de définition de la portée.
  • Il reste trois regroupements de déploiements du Manifeste électronique, dont les dates de lancement sont les suivantes : regroupement 1, mars 2013; regroupement 2, juillet 2014; regroupement 3, décembre 2014.

En ce qui concerne la planification de projet, une structure de répartition du travail aide à définir et à organiser avec précision la portée du projet en répartissant les éléments livrables du projet en blocs de tâches entre divers paliers des plans de projet. Un examen des plans de projet a permis de constater les points suivants :

  • Les éléments livrables du projet sont indiqués dans des plans de projet détaillés.
  • Une durée estimative a été attribuée aux activités, mais aucune précision n'est donnée quant à l'affectation des ressources, l'effort estimé ou les coûts standards.
  • En ce qui concerne les plans de projet détaillés, la règle 8/80, selon laquelle aucun bloc de tâches ne doit être inférieur à huit heures ou supérieur à 80 heures, n'a pas été utilisée. Cette règle permet aux gestionnaires de projet de gérer la taille et la portée des plus petites portions de travail et d'appliquer des règles uniformes à l'ensemble des structures de répartition du travail.

La méthode du chemin critique est utilisée pour prévoir la durée du projet grâce à l'analyse de la séquence des activités qui présente le moins de souplesse sur le plan de l'ordonnancement. Pour le Manifeste électronique, la méthode du chemin critique traditionnelle n'a pas été utilisée. Le projet du Manifeste électronique ne prévoit aucune marge de manœuvre pour la mise en œuvre des regroupements de déploiements.

Les délais initiaux établis pour le lancement du regroupement de déploiements 1 pourraient être à risque. L'effort estimé au départ pour effectuer la mise à l'essai a été plus grand que le temps disponible pour respecter l'échéance de mars 2013. Si des problèmes potentiels se présentent, les comités de gouvernance des projets devront prêter leur concours afin de faciliter la prise de décisions.

Retourner au haut de la page

Sommaire

En ce qui concerne le plan de projet actuel du Manifeste électronique, la direction ne dispose pas d'un ensemble de données complet sur la gestion de projet et, par conséquent, sa capacité de surveiller les progrès concernant le temps, la portée et les coûts s'en trouve limitée. Chaque gestionnaire a la responsabilité de gérer sa partie du projet du Manifeste électronique, y compris les ressources, la portée et le calendrier, et est tenu d'en rendre compte régulièrement. Une fois par mois, les résultats des gestionnaires sont regroupés à l'intérieur du tableau de bord du projet du Manifeste électronique. On se fie beaucoup à l'idée que ces processus de gestion permettent de cerner les problèmes et les risques et de les régler efficacement en temps opportun.

RECOMMANDATION 3

Le vice-président de la DGIST devrait déterminer si les pratiques de cycle de développement des systèmes et la gestion de projet qui supporte les techniques souples (adoptées pour le projet du Manifeste électronique), sont acceptables et applicables à d'autres projets de l'Agence et mettre à jour les politiques et les lignes directrices sur la gestion de projet en conséquence.

Réponse de la direction

La Direction générale de l'information, des sciences et de la technologie (DGIST) approuve la recommandation. La DGIST déterminera si le cycle de vie du développement des systèmes et les pratiques de gestion de projet (techniques souples) adoptées pour le projet du Manifeste électronique sont acceptables et applicables à d'autres projets de l'Agence et mettra à jour les politiques et les lignes directrices sur la gestion en conséquence. La date d'achèvement prévue est avril 2013.

Retourner au haut de la page

7.3 Gestion des coûts

Objectif de gestion du projet : Les coûts sont surveillés, et les différences sont relevées et corrigées en temps opportun. Le rendement sera mesuré et validé.

Selon la Politique sur la gestion des projets du Conseil du Trésor, les projets sont censés optimiser les ressources et produire des résultats en tenant compte des limites de coûts. L'Agence s'attend aussi à ce que les projets optimisent les ressources. L'ASFC a présenté un plan de gestion des coûts dans le cadre de l'approbation définitive de projet, qui indiquait que la GVR serait la technique utilisée pour s'assurer que les coûts sont gérés efficacement et que le rendement est mesuré et validé.

La GVR est un processus qui fournit aux gestionnaires de projet et aux intervenants de l'information sur le rendement des investissements, ainsi que les points de données nécessaires à l'estimation de coûts et de dates d'exécution statistiquement probables. La mise en œuvre d'un processus de GVR est un paramètre reconnu en matière de bonne gestion de projet. La GVR permet de s'assurer que les coûts, le calendrier et les aspects techniques de l'investissement sont intégrés. De plus, la GVR :

  • Établit un lien entre les budgets échelonnés et des tâches précises;
  • Indique les progrès des travaux;
  • Rattache de manière appropriée les coûts, le calendrier et les réalisations techniques à la portée;
  • Est valide, rapide et vérifiable;
  • Permet une estimation statistique des coûts d'achèvement;
  • Fournit aux gestionnaires de l'information résumée de façon pratique;
  • Facilite la gestion des risques;
  • Fournit de l'information sur la réalisation des avantages.

Actuellement, des techniques de GVR ne sont pas utilisées pour le Manifeste électronique. Les gestionnaires de projet ont indiqué qu'il était difficile de respecter les exigences de la GVR avec les outils dont ils disposent.

Actuellement, l'équipe de projet du Manifeste électronique fait le suivi des coûts réels au moyen des systèmes administratifs d'entreprise (SAE). Toutefois, différents groupes rendent compte de leurs coûts de différentes façons. Par exemple, les employés de la DGIST utilisent des ordres internes pour déclarer leur temps. D'autres groupes n'utilisent pas d'ordres internes pour leurs feuilles de temps. Ils appliquent plutôt une allocation salariale au projet en fonction des coûts réels ou estimatifs. Le code d'ordre interne n'est pas un champ obligatoire des SAE, ce qui entraîne le risque que les coûts ne soient pas répartis par projet de manière exacte.

À l'heure actuelle, il est difficile de relier le coût total du projet aux regroupements de déploiements et éléments livrables actuels et futurs du projet. Plusieurs systèmes sont utilisés pour appuyer le processus de gestion des coûts, tels que le Système intégré de mesure et d'évaluation de l'observation (COMPASS) et les SAE, mais ne sont pas intégrés aux plans de projet du Manifeste électronique.

Dans le cas des projets pluriannuels, les prévisions de coûts sont censées être effectuées au moyen d'un modèle d'établissement des coûts conforme à la présentation au Conseil du Trésor. Le Manifeste électronique ne suit pas ce processus. Les gestionnaires de projet négocient leurs besoins budgétaires avec le bureau de projet du Manifeste électronique sans connaître le coût des plans de projet détaillés. Les coûts prévus pour l'exécution du projet du Manifeste électronique se fondent sur la présentation initiale au Conseil du Trésor et les plans de travail élaborés par les gestionnaires de projet.

Selon l'orientation en matière de projets de l'ASFC, la Direction générale du contrôle et le BGPO jouent un rôle important en ce qui concerne la gestion des coûts. Le BGPO doit surveiller le projet, maintenir l'orientation en matière de gestion de projets, analyser les rapports du tableau de bord pour assurer l'exactitude des comptes rendus sur les paramètres clés du projet, en plus de valider l'information du tableau de bord et d'en faire une analyse critique. La Direction générale du contrôle doit fournir et compléter les données financières du projet et assurer la qualité de ces données. Elle ne peut pas fournir une assurance concernant la santé financière du projet, car les coûts et les prévisions du projet ne sont pas établis en fonction des éléments livrables. La Direction générale du contrôle examine et surveille l'information sur les coûts et en discute avec les gestionnaires de projet pour s'assurer que les données financières sont conformes aux SAE et à COMPASS.

Retourner au haut de la page

Sommaire

En ce qui concerne l'objectif de gestion du projet, l'Agence s'expose au risque que ses gestionnaires ne soient pas mis au courant en temps opportun des dépassements de coûts possibles du projet du Manifeste électronique. Les coûts réels sont surveillés, et le taux de combustion du Manifeste électronique est relié au budget original du projet.

La direction reconnaît ces défis liés à l'intégration des coûts et des prévisions par élément livrable et les rattache aux avantages du projet. La GVR est une façon d'y parvenir, mais il faut avoir la capacité, les outils et la discipline nécessaires pour la mettre en œuvre.

RECOMMANDATION 4

Le vice-président de la Direction générale des programmes devrait élaborer et mettre en œuvre un processus pour démontrer la réalisation des avantages du Manifeste électronique.

Réponse de la direction

La Direction générale des programmes approuve la recommandation. L'équipe de projet du Manifeste électronique rédigera l'ébauche d'un rapport démontrant les avantages qu'a apportés le projet du Manifeste électronique d'ici janvier 2013. L'équipe présentera ensuite le rapport au Comité directeur des vice-présidents sur les projets pour approbation d'ici mars 2013.

RECOMMANDATION 5

Le vice-président de la Direction générale du contrôle devrait fournir une assurance concernant la santé financière et les coûts restants prévus du projet du Manifeste électronique et les approuver dans le tableau de bord. Une discussion avec la Direction générale des programmes sur le besoin en données financières est requise pour fournir l'assurance nécessaire.

Réponse de la direction

La Direction générale du contrôle approuve la recommandation.

Depuis l'examen du Manifeste électronique, la Direction générale du contrôle a collaboré avec les principaux intervenants, soit le bureau de première responsabilité, le bureau consultatif et le Bureau de gestion des projets de l'organisation (BGPO), pour établir les éléments nécessaires en vue d'assurer la qualité et la santé financière du projet. 

On a établi et approuvé une structure des ordres internes (répartis par composantes et regroupement des déploiements). Des frais et des délais seront associés à chaque composante et regroupement des déploiements, afin de mieux surveiller la santé financière et d'établir des rapports, à compter du 1er avril 2013. Cette mesure permettra à l'Agence d'atteindre le principe de gestion de la valeur réalisée (GVR).  

Le dirigeant principal des finances de la Direction générale approuvera les tableaux de bord mensuels et/ou fournira des commentaires, au besoin, afin de confirmer qu'il y a bien eu une assurance de la santé financière, y compris les prévisions des coûts.

Retourner au haut de la page

7.4 Rapports d'étape sur le projet

Objectif de gestion du projet : Les outils et les processus servant à la production des rapports d'étape sont utilisés de manière appropriée.

Les gestionnaires du projet du Manifeste électronique doivent rendre compte de l'état du projet à la haute direction de l'ASFC et à la Direction du dirigeant principal de l'information du Conseil du Trésor tous les mois. Pour ce faire, un tableau de bord conçu pour rendre compte des paramètres de base du projet, soit les coûts, le calendrier, la portée, les risques et les problèmes, est utilisé. Les besoins en données sont précisés pour chaque paramètre dans le guide des tableaux de bord de la direction pour les projets de surveillance du Conseil du Trésor. Par exemple, pour rendre compte du calendrier du projet, les gestionnaires de projet précisent la date d'achèvement approuvée, la date d'achèvement prévue et l'écart par élément livrable. Selon le guide du Conseil du Trésor, l'indicateur d'écart est calculé au moyen de la différence entre la date d'achèvement révisée (approuvée) et la date d'achèvement prévue.

L'état de chaque paramètre est codé par couleur au moyen d'un indicateur vert, jaune ou rouge. Le vert indique un écart de moins de 10 %, le jaune un écart qui varie entre 10 et 20 %, tandis que le rouge indique un écart de plus de 20 %. Le processus de production de rapports sur le projet est mené à bien par le bureau de soutien et de suivi du projet du Manifeste électronique, qui recueille de l'information provenant de divers systèmes et documents et valide celle-ci avec le comité des directeurs de projet avant de l'intégrer au tableau de bord. Comme cela a été mentionné précédemment, les activités permettant d'assurer la qualité des données financières doivent être effectuées par la Direction générale du contrôle. Le BGPO examine les rapports et procède à une analyse critique de leur exactitude et de leur exhaustivité. Le tableau de bord final est approuvé par le directeur général des Projets principaux.

L'orientation concernant les rôles et les responsabilités est suffisamment définie, et les principaux intervenants comprennent leurs rôles et leurs responsabilités liés aux approbations et aux examens de la qualité.

En ce qui concerne le Manifeste électronique, il existe quelques différences par rapport à l'orientation du Secrétariat du Conseil du Trésor pour les rapports sur le calendrier du projet. Dans la partie des rapports d'étape sur le calendrier, il faut rendre compte des écarts pour les jalons ou les éléments livrables clés en fonction de la date d'achèvement approuvée et de la date d'achèvement prévue. En ce qui concerne le Manifeste électronique, le BGPO a formulé des préoccupations concernant la définition d'un jalon ou d'un élément livrable. Actuellement, les gestionnaires de projet utilisent les phases du projet (p. ex. la construction et la mise à l'essai) comme définition pour les jalons et les éléments livrables. Le BGPO demande que le tableau de bord reflète les éléments livrables clés en fonction des regroupements de déploiements restants. Cette façon de faire permettrait de surveiller plus efficacement les progrès et les retards possibles.

De plus, le calcul de l'écart (retard selon le Conseil du Trésor et le guide du BGPO) a dérogé à la politique. À l'heure actuelle, les gestionnaires de projet utilisent un calendrier de projet qui comprend tout le temps d'élaboration du Manifeste électronique (2007 à 2014). Le calendrier actuel du projet a fait l'objet d'un plan de base et a été approuvé en janvier 2012 en fonction d'une mise en œuvre finale du projet d'ici décembre 2014. Par conséquent, le calcul du retard doit se fonder sur la durée révisée du plan de base du projet.

Au cours de l'examen, divers intervenants ont soulevé des problèmes qui semblent suffisamment importants pour être signalés dans le tableau de bord du projet.

  • Un règlement clé qui devait entrer en vigueur avant novembre 2012 pour que les transporteurs routiers soient tenus de transmettre de l'information par voie électronique n'a pas été adopté. Par conséquent, les avantages prévus sont retardés.
  • En lien avec le premier point, le nombre de transporteurs routiers qui adoptent l'échange de données informatisé augmente lentement. En octobre 2012, 3 339 des 15 000 transporteurs actifs étaient inscrits, ce qui correspond à un taux de 22 %, mais représente seulement 77 % du volume total des échanges. Des transporteurs non inscrits, 5 651 transporteurs comptaient en moyenne moins d'une mainlevée par mois, dont 1 381 qui comptaient une seule mainlevée pour l'année. Lorsque la transmission d'informations deviendra obligatoire, cela pourrait créer une demande de la part des transporteurs que l'Agence ne sera pas en mesure de traiter en temps opportun.

En ce qui concerne les risques liés au projet, ces derniers sont indiqués dans le tableau de bord et sont assortis de stratégies d'atténuation. Après examen, il n'est pas sûr que certaines des stratégies d'atténuation atteignent le résultat escompté en réponse au risque. Par exemple, un risque relevé est la capacité des ressources de la DGIST de s'occuper du Manifeste électronique en plus d'autres projets de l'Agence comme le plan d'action Par-delà la frontière et la Gestion des cotisations et des recettes de l'ASFC. La stratégie d'atténuation partait du principe que le Manifeste électronique sert de fondement à un grand nombre d'initiatives et que l'Agence s'engagerait à poursuivre la mise en œuvre du Manifeste électronique et à obtenir les ressources nécessaires. L'équipe de l'examen a entendu dire que ce risque est en train de se manifester. Par conséquent, cette situation doit être notée comme problème à régler et gérée en conséquence.

Retourner au haut de la page

Sommaire

En ce qui concerne cet objectif de gestion du projet, les gestionnaires de projet rendent régulièrement compte de l'état du projet, et les outils et les tableaux de bord sont utilisés. Il faut clarifier quelle information doit être communiquée dans le tableau de bord et l'exhaustivité de certains éléments du tableau de bord, plus particulièrement la section sur les risques et les problèmes. La surveillance des rapports du tableau de bord pourrait aussi être améliorée afin que toute l'information importante provenant des intervenants de l'ASFC soit signalée. Le risque est que la haute direction de l'ASFC ne soit pas informée des problèmes importants qui pourraient avoir des répercussions plus vastes sur les opérations.

RECOMMANDATION 6

Le vice-président de la Direction générale des programmes devrait demander au comité des directeurs généraux sur les projets d'examiner tous les risques et les problèmes et inclure les risques et les problèmes critiques dans le tableau de bord du projet Manifeste électronique.

Réponse de la direction

La Direction générale des programmes approuve la recommandation. À partir de janvier 2013, les registres détaillés sur les risques et les problèmes seront un point permanent de l'ordre du jour du comité des directeurs généraux sur les projets, où ils seront passés en revue et feront l'objet de discussions. Les points importants seront inclus au tableau de bord du projet.



Retourner au haut de la page

ANNEXE A – À PROPOS DE L'EXAMEN

OBJECTIFS ET PORTÉE DE L'EXAMEN

L'examen avait pour objectif de déterminer la mesure dans laquelle le Manifeste électronique répondra aux besoins des utilisateurs finals, le caractère adéquat du plan de projet en ce qui concerne la gestion de la portée, du calendrier et des ressources du projet, la gestion des coûts, ainsi que l'efficacité des outils et des processus liés aux rapports d'étape.

La portée de l'examen comprenait tous les aspects du projet du Manifeste électronique sans exception. La mission consistait en un examen et non en une vérification, et des essais détaillés n'ont pas été entrepris. Le niveau du travail que nous avons accompli correspond à un examen, ce qui fournit un faible niveau d'assurance.

ÉVALUATION DES RISQUES

Un certain nombre de secteurs de risque ont été définis au cours de la phase de planification de l'examen :

  • Portée : En l'absence de contrôles adéquats pour la gestion de la portée, le projet risque de ne pas répondre aux besoins opérationnels et aux besoins des utilisateurs, ce qui pourrait entraîner le rejet des fonctions mises en œuvre. De plus, il existe le risque que des essais insuffisants se traduisent par des systèmes insatisfaisants pour les utilisateurs fonctionnels.
  • Gestion de projet : En l'absence de pratiques de gestion de projet raisonnables, il risque d'y avoir des différences par rapport à la portée, au calendrier et aux coûts. De plus, en l'absence de pratiques de gestion de projet uniformes, les projets interdépendants risquent de manquer d'uniformité.
  • Gestion des coûts : En l'absence de contrôles suffisants pour les coûts, il existe le risque d'un manque de contrôle des coûts de projet, ce qui pourrait entraîner de mauvais investissements dans la TI.
  • Rapports sur le projet : En l'absence de contrôles satisfaisants pour les rapports sur le projet, les rapports risquent de ne pas rendre compte des progrès efficacement, ce qui peut se traduire par des problèmes, des obstacles ou des risques non détectés. Il existe aussi le risque que les attentes des clients et les besoins opérationnels soient perdus de vue.
Retourner au haut de la page

APPROCHE ET MÉTHODE

Deux cadres ont été utilisés pour l'examen, qui se fondait principalement sur des entrevues et des analyses de documents :

  • Control Objectives for Information and related Technology (COBIT), version 4.1;
  • Project Management Body of Knowledge (PMBOK).

Les COBIT définissent les processus de TI qui devraient exister pour que la TI appuie les opérations de façon efficace. Les COBIT et les publications connexes définissent les objectifs, les techniques et les pratiques de contrôle couramment requis pour chaque processus.

Le guide PMBOK définit le processus relatif aux pratiques exemplaires pour la gestion de projet, ainsi que les connaissances et les techniques requises pour que les processus soient efficaces. Ce guide peut être adapté à n'importe quelle industrie, y compris la TI.

CRITÈRES D'EXAMEN UTILISÉS POUR LA PHASE DE LA MISSION (par secteur d'intérêt)

1. Portée et besoins des utilisateurs
Critères

Le projet respectera sa portée et répondra aux besoins des utilisateurs finals.

Sous-critères

Portée du projet : La portée du projet est définie et officiellement approuvée par les responsables du programme et du projet.

Contrôle des changements apportés au projet : Le plan de projet reflète les changements approuvés apportés à la portée; un plan de base est établi; le plan de projet est mis à jour pour refléter les demandes de changement approuvées.

Essais d'acceptation par l'utilisateur : Le système répond aux besoins des utilisateurs fonctionnels finals grâce à des essais d'acceptation par l'utilisateur réussis.

2. Plan de projet
Critères

Le plan de projet est suffisamment détaillé pour guider le projet tout au long de son cycle de vie.

Sous-critères

Plan de projet intégré : La portée, les éléments livrables, les ressources requises et les responsabilités, les structures de répartition du travail, les estimations des ressources requises, les jalons, les liens de dépendance clés et le chemin critique sont étayés dans le plan de projet intégré.

3. Gestion des coûts
Critères

Les coûts sont surveillés, alors que les différences sont relevées et corrigées en temps opportun.

Sous-critères

Gestion des coûts : Un processus de gestion des coûts a été mis en œuvre pour comparer les coûts actuels avec les budgets. Les coûts font l'objet d'une surveillance et de rapports, et les différences sont relevées et évaluées en temps opportun.

4. Rapports d'étape sur le projet
Critères

Les outils et les processus servant à la production de rapports sont utilisés de manière appropriée.

Sous-critères

Les rôles et les responsabilités liés aux rapports d'étape sont clairs et bien compris.

Rapports sur le projet : Les rapports d'étape sur le projet respectent les normes organisationnelles pertinentes.



Retourner au haut de la page

ANNEXE B – GLOSSAIRE

Essais d'acceptation par l'utilisateur :
Application de mesures du rendement et de la capacité aux éléments livrables du projet permettant de s'assurer que ceux-ci respectent les spécifications et les besoins et sont à la satisfaction du client.
Gestion de projet souple :
Processus hautement itératif et progressif dans le cadre duquel les développeurs et les intervenants du projet collaborent activement pour comprendre le domaine, déterminer ce qui doit être créé et établir les priorités de la fonctionnalité. Les méthodes souples sont utilisées lorsque les conditions suivantes sont réunies : la valeur du projet est évidente; le client participe activement à toutes les étapes du projet; le client, les concepteurs et les développeurs se trouvent au même endroit; un développement progressif axé sur les caractéristiques est possible; la documentation visuelle (cartes au mur c. documentation officielle) est acceptable.
Plan de base :
Plan original (d'un projet, d'un bloc de tâches, d'une activité), plus tout changement approuvé. Peut être utilisé avec une variante (par exemple, plan de base des coûts, plan de base du calendrier, plan de base de la mesure du rendement).
Mesure du plan de base :
Ensemble d'estimations approuvées pour la portée, les coûts et le calendrier qui sert de fondement à la gestion du changement lors de l'exécution du projet. Le plan de base d'un projet est établi à la fin de la phase de planification.
Regroupement de déploiements 1 :
Fonctionnalité permettant aux transitaires de tous les modes de transport de transmettre des données détaillées avant l'arrivée (p. ex. papier creux) qui devrait être prête en mars 2013.
Regroupement de déploiements 2 :
Fonctionnalité pour le passage dans le secteur commercial et l'évaluation des risques qui devrait être prête en juillet 2014. Ce regroupement de déploiements comprendra la fonctionnalité permettant aux importateurs de transmettre des données commerciales préalables.
Regroupement de déploiements 3 :
Améliorations apportées à l'évaluation des risques et au passage prévues pour décembre 2014 qui comprendront des améliorations de la fonctionnalité du passage dans le secteur commercial et de l'évaluation des risques, ainsi qu'une nouvelle fonctionnalité pour l'évaluation des risques liés à l'équipage dans tous les modes.
Jalon :
1. Activité qui n'a pas de durée et qui ne nécessite pas de ressources. Elle sert à mesurer les progrès d'un projet ou d'un programme et marque l'achèvement ou le début d'un élément livrable important ou d'un autre paramètre important comme les frais engagés, les heures travaillées et les paiements effectués;
2. Point de repère dans un projet, un programme ou un ensemble d'activités, qui représente une obligation de rendre compte ou l'achèvement d'une partie importante d'un ensemble d'activités.
Gestion de la portée du projet :
Processus nécessaires pour s'assurer que le projet comprend tous les travaux requis, et seulement les travaux requis, pour sa réalisation. La gestion de la portée du projet vise principalement à définir et à contrôler ce qui est inclus dans le projet et ce qui ne l'est pas.


Retourner au haut de la page

ANNEXE C – SIGLES

GCRA — Gestion des cotisations et des recettes de l'ASFC

SAE — Systèmes administratifs d'entreprise

ASFC — Agence des services frontaliers du Canada

COBIT — Control Objectives for Information and Related Technology

COMPASS — Système intégré de mesure et d'évaluation de l'observation

BGPO — Bureau de gestion de projet de l'organisation

GVR — Gestion de la valeur réalisée

DGIST — Direction générale de l'information, des sciences et de la technologie

TI — Technologie de l'information

PMBOK — Project Management Body of Knowledge

EAU — Essais d'acceptation par l'utilisateur