OGGO Réunion de comité

    Chers collègues, la séance est ouverte.

    J'ai quelques points d'ordre administratif avant de commencer. Vous voyez les écrans devant vous. Nous avons essayé de les diviser en deux pour avoir le français et l'anglais ensemble, mais nous n'y sommes pas parvenus. Certains auront donc un écran en français, et d'autres, en anglais. J'espère que nous pourrons nous adapter. Si vous voulez une copie papier des exposés, le greffier peut vous en remettre une, si cela vous aide, mais j'espère que nous pourrons utiliser les écrans tels quels.

    De plus, chers collègues, dans un esprit de pleine divulgation, je tiens à mentionner que même si M. Murphy et moi ne nous sommes jamais rencontrés avant aujourd'hui, nous avons communiqué ensemble au cours des derniers mois. Il m'a été présenté il y a plusieurs mois. Au cours de nos échanges, il m'a parlé des méthodes baptisées « agiles », applicables à la transformation des TI au sein des gouvernements. Naturellement, comme chacun sait, c'est une initiative de grande, très grande envergure.

    Ses propos m'intriguaient. J'ai donc acheminé une partie de l'information qu'il m'avait transmise au gouvernement — aux ministres Brison et Foote — avec un résumé de ce que j'avais trouvé sur les méthodes agiles. Je leur avais mentionné à tous les deux que s'ils souhaitaient communiquer avec M. Murphy et, éventuellement, conclure une entente avec lui pour conseiller le gouvernement dans le dossier de la transformation des TI, c'était libre à eux.

    Je crois savoir, monsieur Murphy, que vous travaillez avec le gouvernement à l'heure actuelle.

    Je voulais simplement que vous soyez tous au courant de mon rôle dans tout cela. J'ai en quelque sorte un intérêt particulier dans la comparution de M. Murphy aujourd'hui.

    C'est une pleine divulgation, n'est-ce pas?

    Des voix: Oh, oh!

    C'est une pleine divulgation.

    Sur ce, monsieur Murphy, je crois savoir que vous avez un exposé de 10 minutes, après quoi je sais que tous mes collègues vous poseront des questions. Nous avons réservé environ une heure et demie pour l'exposé et les questions.

    Sans plus attendre, monsieur Murphy, je vous cède la parole.

    Merci, monsieur le président, et mesdames et messieurs les membres du Comité.

    Je travaille au gouvernement, ou à proximité, et dans le secteur des TI depuis plus de 35 ans. J'ai travaillé environ 10 ans pour IBM, 10 ans pour Cisco, et depuis les 10 dernières années environ, je suis consultant. J'y vais par tranche de 10 ans, en quelque sorte.

    Je ne passerai pas la présentation en détail, mais je vais vous raconter comment j'en suis venu à mes idées et comment nous pouvons transformer le gouvernement fédéral.

    À la fin des années 1990, ou vers l'an 2000, je travaillais pour Cisco, qui réalisait 1 200 projets par trimestre et avait un taux d'échecs de 4 %. Chaque projet ne pouvait dépasser 500 000 $, sinon on le divisait. À Cisco, l'impulsion pour passer aux méthodes agiles, itératives, est venue du PDG. Elle n'est pas partie de la base, mais l'inverse, et c'est pourquoi je suis ici aujourd'hui. Il faut, à mon avis, que l'impulsion vienne des décideurs politiques. Il faut que le personnel politique, les SM, les SMA et les DG comprennent de quoi il s'agit pour bien jouer leur rôle de meneur.

    Toujours est-il que Cisco avait un taux d'échecs de 4 %. Un retard de deux semaines ou un dépassement de budget de 10 % sur un échéancier de 90 jours était considéré comme un échec. Dans l'exemple que je vais vous donner, l'initiative était menée par le DPF. Selon lui, le fait d'accélérer la prise de décisions par la direction serait avantageux pour Cisco. À l'époque, on fermait les livres en quatre semaines, et le DPF, et non pas le DPI, disait que si on pouvait fermer les livres en deux semaines, Cisco aurait un avantage stratégique. Cisco s'est donc attaqué aux initiatives par trimestre de 500 000 $ progressivement, et après un an, l'objectif de deux semaines était atteint. Le DPF a dit alors que si on pouvait les fermer en une semaine, on aurait un avantage stratégique. Ils ont poursuivi leurs efforts et un an et demi ou deux ans plus tard, l'objectif d'une semaine était atteint.

    Aujourd'hui, Cisco ferme ses livres dans 130 pays chaque jour. Quand une occasion se présente sur le marché, ils peuvent la saisir rapidement, et c'est ce qui leur procure un avantage stratégique.

    Vous me direz que cela n'est pas possible au gouvernement, que le gouvernement n'est pas Cisco, et je suis d'accord avec vous que ce ne l'est pas. Toutefois, en 2005 environ, j'étais consultant à Travaux publics, l'ancêtre de Services partagés. Travaux publics n'était pas un monopole. Il devait créer un service, et le service devait avoir une valeur définie, soit un des « thèmes gagnants  » qu'il fallait avoir pour Services partagés.

    J'ai mis sur pied une équipe de cinq personnes ayant les qualités de meneur requises, DG et SMA, et dans l'espace de deux ans, j'ai mis en place un service, un service de réseau haute vitesse, à prix 100 fois plus concurrentiel qu'un service commercial de télécom. J'y suis arrivé au gouvernement et avec les employés du gouvernement. Un peu plus tard, j'ai fait de même avec la téléprésence.

    Je peux donc vous dire que c'est possible. Un grand nombre de petits groupes d'initiatives agiles sont même en cours à l'heure actuelle. Tout ce qu'il leur faut, ce sont des meneurs aux échelons portefeuille et haute direction. « Agile » appelle un changement de mentalité. Ce n'est pas un produit que l'on peut acheter. Ce n'est pas un logiciel. C'est la façon de penser les projets.

    Au lieu d'envisager un projet de 50 millions — une sortie du bilan — j'établirais une politique disant que les projets ne peuvent dépasser tel montant. Je peux avoir une vision à long terme comme Cisco de fermer les livres au quotidien, mais sur un trimestre, je ne peux pas dépasser 500 000 $. Les projets sont trop gros, trop imposants. Au point de départ des projets, qui sont très complexes, l'approche actuelle est de tout comprendre tout de suite. Il faut donc préparer un plan. Partout au gouvernement, on se dit « J'ai besoin d'un plan parce qu'il faut que je prépare un budget et que j'aille en appel d'offres ». Il faut donc trois ans pour créer un plan, un plan qui n'a pas 10 pages, mais 200. Le plan devient une DP, une DP de 200 pages qui donne tous les détails sur la façon de concevoir Phénix.

    C'est impossible, on ne peut pas préparer un plan. Le gouvernement, les TI, la technologie sont trop complexes et évoluent constamment... À Cisco, on disait qu'une année équivaut à sept ans, et c'était en 2000. Le monde évolue beaucoup trop rapidement. Quand on met la touche finale à la définition et aux exigences, deux ans se sont écoulés.

    En fait, le gouvernement prend deux à trois ans pour créer les documents. Ils ne testent ou ne valident aucun détail dans le plan ou les documents avant que le contrat soit attribué. Après seulement, quand on met en oeuvre, on se rend compte, oh mon Dieu, qu'on n'avait pas vu tel petit détail et qu'on ne s'était pas rendu compte que cela avait autant d'importance. Mais c'est important et c'est tout le projet qui est bousillé.

    Un projet de 40 millions de dollars voit, en moyenne, son budget initial multiplié par deux ou trois, de même que son échéancier. Ce n'est pas une moyenne au gouvernement du Canada. C'est une moyenne au sein de l'industrie, partout. Si vous essayez de planifier un projet de grande envergure dans le menu détail dès le départ, son coût sera multiplié par trois. Pour avoir une idée de toutes les initiatives d'envergure qui ont échoué au gouvernement fédéral depuis 2000, consultez les rapports du vérificateur général.

    Je ne veux pas insister sur cela. Tout ce que je veux dire, c'est qu'on peut faire les choses autrement. Les méthodes agiles misent sur de petites équipes de cinq à huit personnes qui travaillent sur une initiative sur une courte période de temps. Ils ne rédigent pas des documents sur la façon dont ils vont s'y prendre. Ils veulent passer à l'action, et tout de suite. S'ils font une petite erreur sur une initiative de 500 000 $, on appelle cela l'apprentissage. Ils ne referont pas la même erreur la prochaine fois, au prochain trimestre.

    C'est beaucoup mieux que trois fois 40 millions de dollars. Trois fois 40 millions de dollars, avec trois ans de retard, c'est beaucoup.

     Dans une initiative agile, on reconnaît d'emblée qu'on ne sait pas tout. Ce qu'on cherche au départ ce sont les inconnus. On sait que la seule façon de valider un projet, en particulier un projet TI ou de technologie, ou un projet complexe, c'est de le mettre en oeuvre. On gère le risque en procédant à petite échelle, avec un échéancier très serré, afin de pouvoir apprendre de nos erreurs et de nous améliorer en cours de route. Il y a tout un volet ici qui touche les RH au sein du gouvernement — accroître les capacités et les compétences à l'interne.

    La machine est en marche. Si vous regardez mon document, j'ai une diapositive sur la FOI 2, une équipe agile, et probablement une des meilleures dans le monde. Elle applique tous les principes.

    À la diapositive suivante, nous avons désigné trois échelons. À l'échelon des projets et des initiatives, le premier, les initiatives agiles sont en cours. À l'échelon des programmes et du portefeuille et à celui de l'organisation, c'est là où se trouve la lacune, à notre avis. Ce qui manque ici, au départ, c'est l'éducation.

    Quelques diapositives plus loin, il y a celle intitulée « Passer à l'action ». Je ne veux pas prendre tout votre temps, mais tout le monde se trouve dans le même bateau. Il n'est pas possible de déléguer ou de se retirer. Il faut que tout le monde s'implique.

    Si je suis ici aujourd'hui, c'est pour vous demander votre engagement, l'engagement des décideurs politiques et des EX partout au sein du gouvernement. C'est un appel concret à l'action. J'ai ciblé votre comité parce que tous les partis sont représentés. L'effort nécessaire ira au-delà des élections. Il faut donc que tous les partis comprennent bien de quoi il s'agit.

    C'est même une question de viabilité politique, car on peut difficilement mettre en oeuvre les programmes fédéraux si on n'est pas capable de mettre en oeuvre ses propres projets ou initiatives. En haut, il y a la prestation des programmes, au sein d'un ministère, et en dessous, il y a tout un lot de composantes. Services partagés en est une, tout comme l'approvisionnement, les RH et les finances. Il faut obtenir des ressources de ces composantes pour la prestation des programmes, et c'est là où se trouve le goulot d'étranglement.

    En fait, l'approche de direction qu'il faut adopter, au gouvernement et partout ailleurs, c'est de ne jamais dicter comment faire les choses. On doit se concentrer sur le « pourquoi ». Pourquoi sommes-nous en affaires? Avec qui? Laissez l'organisation et les équipes le découvrir petit à petit. Quand on se demande comment, on devient beaucoup trop prescriptif, et toute notre pensée, notre façon de voir les choses se perd dans les détails.

    Je vais vous donner l'exemple des directives stratégiques. À mon avis, il ne devrait pas y en avoir. Elles sont trop prescriptives. On a alors toute une organisation qui suit des règles au lieu d'essayer d'améliorer sa valeur. La question qu'il faut se poser est pourquoi sommes-nous en affaires?Nous sommes en affaires pour les citoyens. Que devons-nous faire pour eux? Nous devons améliorer la valeur des services que nous leur offrons.

    Ce que le Conseil du Trésor a entrepris est très bien. L'hon. Scott Brison comprend bien. Il a suivi le cours de deux jours et à la sortie, il était d'avis qu'il fallait tout changer. Je pense qu'il a raison. Nous n'allons pas en faire un gros projet, mais y aller progressivement. Si vous voyez trop gros, ça va échouer.

    J'en ai assez dit. J'aimerais avoir votre engagement et répondre à vos questions.

    Merci beaucoup. Je vous sais gré de votre économie de mots. C' est une entreprise titanesque.

    Nous allons commencer la période de questions par les députés du gouvernement.

    Francis, allez-y.

    Merci, monsieur le président.

    Merci, monsieur Murphy, d’être venu partager certains de vos points de vue avec les membres du Comité.

    Je veux revenir en arrière et je suis curieux de connaître votre opinion. Je me souviens d’un modèle préalable à celui de Services partagés, c’est-à-dire dans le cadre duquel Services partagés existait sans que les ministères doivent obligatoirement faire appel à lui. Ensuite, 2011 est arrivé. Je pense que le 4 août, Services partagés a été officiellement créé par décret. Deux ans plus tard, il était responsable du courriel, des centres de données et des réseaux, et deux ans après, il était chargé des appareils technologiques en milieu de travail; ils ont été abandonnés. On confiait beaucoup de responsabilités à un organisme qui n’avait encore rien accompli. Une bonne partie de ses tâches consistait d’abord à garder le fort et à transférer les t-shirts à d’autres employés.

    Je veux parler de la mesure dans laquelle les ministères étaient préparés. D’autres témoins l’ont mentionné. Certains ministères étaient prêts à mettre en oeuvre la transformation des services de courriel, tandis que d’autres étaient loin de l’être. Dans votre modèle, comment auriez-vous abordé la situation compte tenu de l’état d’avancement des ministères? Services partagés était responsable, je pense, de 43 ministères à l’époque. Nous avons entendu dire par un ancien DPI que son ministère adhérait pleinement au modèle, alors que d’autres ministères n’étaient pas prêts. À quel point était-il réaliste que l’initiative de transformation des services de courriel se concrétise aussi rapidement? Et comme nous l'avons appris du vérificateur général l’an dernier, le budget d’immobilisations a aussi été coupé tôt dans le processus.

    Revenons à SPC et à certains éléments fondamentaux l’entourant. Je ne pense pas que le modèle ait été correct. Cependant, je vais vous donner un exemple. SPC est comme 43 entreprises automobiles, toutes dotées de leur propre département de production, à divers endroits, avec divers employés, qui suivent différents processus. Elles produisent toutes leur propre automobile. C’est une bonne automobile, qui fait la même chose dans tous les cas: elle permet aux gens d’aller du point A au point B. C’est très bien. Ensuite, vous fusionnez les entreprises. Dans le secteur privé, une fusion n’est pas facile. Au gouvernement, elle est vraiment difficile.

    Vous fusionnez donc 43 entreprises automobiles et ensuite vous dites « Nous voulons que vous produisiez un autobus qui sera partagé ». Qui va décrocher le contrat? Quel département de production l’obtiendra?

    Nous avions ce conflit qui a été structuré dans le modèle. Je ne suis pas ici aujourd’hui pour blâmer quelqu’un en particulier au gouvernement. Nous faisons ici face à un problème systémique qui requiert une solution systémique.

    Pour ce qui concerne le courriel, pourquoi avons-nous touché au système? Que pensions-nous en tirer? J’ai participé au processus de mise en place du projet relatif au courriel, et ce n’était pas clair.

    Oui.

    On nous a dit que c’était pour économiser de l’argent, mais nous n’avons pas réalisé d’économies. Ensuite, ils ont tout fait d’un seul coup, et nous essayons depuis de comprendre les détails. Vous pouviez voir où les problèmes allaient se situer. Encore une fois, ils sont devenus bien trop normatifs.

    Nous leur avons redemandé « Pourquoi voulez-vous modifier le système de courriel? Pourquoi voulez-vous le consolider? Ne pouvez-vous pas communiquer aujourd’hui? Qu’est-ce qui justifie ce changement? Est-ce parce que vous voulez que toutes les adresses courriel finissent de la même façon pour qu’il soit plus facile de vous trouver? »

    C’est la partie qui ne se produit pas au gouvernement, la partie du « pourquoi ». Dans les faits, tout le monde se précipite pour répondre à la question « comment », ce qui devient problématique. Au niveau des dirigeants, il est extrêmement important de rester concentré sur la raison et le destinataire. À qui étaient destiné Services partagés?

    Oui, mais nous avons des exemples d’endroits où un modèle différent de services partagés a fonctionné. En Ontario, notamment, ils ont changé le système de courriels très facilement. Ils n’ont éprouvé aucune difficulté majeure. La différence que nous avons apprise, encore une fois, en écoutant le témoignage de David Nicholl, est qu’il passe le plus clair de son temps à penser aux affaires de sa collectivité de DPI. Je ne suis pas convaincu que les dirigeants de Services partagés le fassent régulièrement, c’est-à-dire essayer de comprendre ce que font les membres de leur collectivité de DPI.

    Trouvez-vous qu’il y a une part de vérité dans tout cela?

    Il y a une part de vérité dans tout cela, oui. Je pense qu’on a envoyé des messages contradictoires concernant la structure de SPC lorsqu’on l’a mise en place. Une partie du message était qu’il faut tout normaliser. Si vous êtes tous mes clients, que vous utilisez tous des systèmes différents et que j’ai besoin de normaliser quelque chose, qu’est-ce qui est plus important — que je vous offre le service ou que je le normalise? Le message initial était qu’il fallait normaliser les services. Il faut énoncer clairement les raisons qui justifient cette décision. Pourquoi Services partagés existe-t-il? Son but est-il de normaliser les services? Son but est-il de créer une norme de bon service pour que les ministères puissent offrir les programmes qu’ils souhaitent offrir?

    Il est maintenant clair qu’il y a un engorgement, une contrainte. Je pense qu’on devrait clarifier davantage les raisons qui justifient cette décision.

    J’ai une autre question à poser. Vous avez parlé de commencer à être doué pour concrétiser des petits projets. J’ai beaucoup entendu de commentaires de la collectivité des TI, surtout des PME, qui disent ne plus pouvoir collaborer avec le gouvernement du Canada, car celui-ci a décidé de faire affaire avec des entrepreneurs principaux.

    Une des justifications à l’époque était qu’on voulait économiser sur les acquisitions. Nous n’avons pas à faire affaire avec mille PME, seulement une personne ou cinq entrepreneurs principaux. Les petits contrats hausseront probablement les coûts des acquisitions — on espère que non, mais ce serait plus difficile pour la direction des acquisitions à SPP de faire affaire avec de multiples entrepreneurs.

    Que leur diriez-vous? Si nous convenons tous aujourd’hui que nous adoptons l’approche « agile », mais qu’ils nous reviennent pour nous dire qu’elle fera augmenter les coûts des acquisitions, que leur répondrez-vous?

    Si vous pouviez le faire en une minute environ, je vous en saurais gré.

    On gère mon temps.

    Des députés: Oh, oh!

    Les acquisitions sont une autre contrainte. Le service est engorgé, car je leur demande de gérer une demande de propositions de 200 pages qui prend, en moyenne, un an et demi à créer.

    Nous n’avons pas à faire les demandes de propositions de cette façon. Nous n’avons pas à préciser exactement comment tout fonctionnera. Nous devons dire que Services partagés veut obtenir tel ou tel résultat. C’est ce que je veux. Maintenant, dites-moi comment m’y prendre. Dites-moi comment faire dans la proposition. Je ne vais pas vous dire comment le faire, car je ne peux pas obtenir tous les détails. Dites-moi comment.

    Ensuite, vous savez quoi? Au lieu d’accorder le contrat à un seul entrepreneur, accordons-le à deux ou trois d’entre eux. Vous pouvez le faire; vous êtes intelligent, vous nous avez dit comment nous pouvons y arriver, alors maintenant, mettez votre projet en oeuvre, mais pas pour 350 000 personnes; pour 50 personnes. Et nous avons besoin que vous le fassiez au cours des trois prochains mois. J’ai peut-être trois fournisseurs qui ont été retenus et qui le font.

    J’aime tous les fournisseurs. Je pense qu’ils sont extraordinaires. Cependant, je ne les croirais pas. Ils ne peuvent regarder une demande de propositions normative, soumissionner et savoir ce qui se passera, si bien qu’ils essaient d’en limiter la portée. S’ils ne soumissionnent pas, ils perdent 40 millions de dollars sur 10 ans, donc ils ont besoin de soumissionner. Ensuite, ils se retrouvent dans cette situation. Bien sûr, ils savent qu’aussitôt qu’ils ont soumissionné, ils seront en mode contrôle du changement tout juste après que l’appel d’offres a été lancé. Ils diront que tel ou tel détail n’a pas été précisé. Chaque fois, le gouvernement demande combien cela va coûter. C’est 300 $ ou 3 millions de dollars, parce qu’on ne peut pas tout avoir, n’est-ce pas?

    Je pense que nous allons devoir nous arrêter là.

    C'est une bonne discussion, et M. McCauley voudra peut-être reprendre le sujet. Je vais donner à tout le monde un peu de marge en raison de la matière ici traitée.

    Monsieur McCauley, allez-y, je vous prie.

    Je vous en sais gré.

    Oui, M. Drouin nous a entraînés dans une tangente intéressante. Si nous nous en tenons simplement à Phénix et à Services partagés, nous savons où nous en sommes. Sans montrer quelqu'un du doigt, car nous pourrions passer la journée à se le faire les uns et les autres, maintenant que les deux systèmes se portent mal, pourriez-vous utiliser l'approche « agile » pour vous attaquer aux problèmes que nous avons en ce moment avec Phénix et Services partagés? Faites-nous un genre d'« agile pour les nuls » pour nous expliquer comment vous procéderiez.

    J'ai 50 autres questions, alors vous pourriez peut-être le faire en une trentaine de secondes?

    Je ne suis pas certain que la méthode « agile » puisse régler le cas de Phénix. Il faudrait que j'étudie de plus près la question. Cependant, je dirais qu'il pourrait y avoir encore une vingtaine ou une trentaine de projets importants en attente. La corrélation entre les grands projets et les échecs est de plus de 85 %.

    Plus avec le gouvernement, j'en suis sûr.

    Ce serait bon de revoir tous les grands projets en attente. Cela fait d'ailleurs partie de mes recommandations. Revoyez tout projet important et dites-vous que si vous êtes en train de vous enfoncer, cessez de creuser. C'est la première chose. Cependant, dans le cas de Phénix, la fosse est tellement profonde, maintenant...

    D'accord.

    Qu'en est-il de Services partagés? Je pense que nous sommes dans une fosse aussi profonde.

    Oui.

    Pourriez-vous...?

    Je ne pense pas que la structure actuelle de Services partagés se prête à produire de nouveaux services, car les conflits sont si élevés. Je crois qu’il vous faut créer un autre organisme très petit, un organisme agile, qui ne compterait pas plus de 10 personnes. Avec cinq ou six personnes, j’ai déployé efficacement une entreprise avec un chiffre d’affaires d’un million de dollars par mois, un réseau à haute vitesse. Il a fallu deux ou trois ans, car j’oeuvrais au sein de cet organisme, mais si j’avais une petite équipe, une petite équipe très compétente qui dispose des autorisations au bon niveau pour avancer, nous pourrions faire bouger les choses assez rapidement. Services partagés est en conflit, par contre, car il a des intérêts contradictoires. Il est bien placé pour garder le fort, mais je ne crois pas qu’il le soit pour créer de nouveaux services.

    Pourrions-nous former une équipe agile pour commencer à nous attaquer à certains de ces problèmes, qu'il s'agisse de la transformation des services de courriel ou autres, et nous y attaquer graduellement au fil des ans?

    Oui, il y a un très petit sous-ensemble de services qui retarde tout le reste.

    Revenons-en aux acquisitions. Prenons quelque chose comme la construction navale à 50 ou 60 milliards de dollars, et vous parlez de 500 000 $. La demande de propositions fera 40 000 pages, et nous allons quand même être actionnés pour avoir omis des détails.

    Oui.

    Comment utiliser la méthode « agile » pour régler les questions d'acquisitions? Le rapport de l'ombudsman sur les acquisitions vient d'être publié. Si nous n'avons pas suffisamment de détails, le soumissionnaire qui n'a pas décroché le contrat nous poursuit en justice sous prétexte que nous avons été injustes. Comment pouvons-nous nous servir d'un instrument comme la méthode « agile » pour contourner ce problème ou traiter d'énormes projets comme ceux de construction navale ou d'achat...

    Les projets de construction navale sont un peu plus difficiles, car il faut un certain engagement financier pour construire un navire, mais la plupart des projets technologiques ne requièrent pas d’énormes investissements, surtout de nos jours, avec les services disponibles au mois, à l’heure ou à la minute. Il n’est pas nécessaire de dépenser des millions de dollars pour mener à bien des projets.

    Il faut s’attacher à la valeur. Comment faire pour la créer et que signifie-t-elle? Vous devez retracer vos pas à partir de là. Vous commencez par la valeur et vous vous demandez ensuite à qui elle est destinée. Ensuite, vous déterminez quelles sont vos aptitudes et vos capacités. Pouvons-nous vraiment le faire? Vous devez commencer petit et y aller graduellement. Ce programme ne se développera pas rapidement, mais il créera de la valeur immédiatement. Il ne le fera simplement pas à grande échelle. Il doit être mis à l’échelle, mais il faut d’abord créer les capacités — en matière d'éducation, de compréhension et de leadership.

    Vous avez mentionné que Cisco avait commencé avec des projets de 500 000 $.

    Oui.

    Savez-vous où ils en sont rendus maintenant? Que suggéreriez-vous au gouvernement de faire s'il avait une baguette magique et pouvait déployer la méthode « agile » aujourd'hui? Quelle en serait la valeur pour le gouvernement?

    Oui: de 250 000 à 500 000 $ sur une période de 90 jours, pas plus. Pas plus que cela, car vous ne pouvez pas dépenser beaucoup plus en 90 jours. Que puis-je faire pendant les 90 prochains jours pour rehausser la valeur? Cela ne signifie pas que je vais produire un document sur les exigences, une demande de propositions, un document ou une étude. Nous allons mettre quelque chose en oeuvre en 90 jours. Nous allons le faire avec 10 personnes. Nous allons mettre le système de courriel en place avec 10 personnes et voir s’il fonctionne et cerner les problèmes. Les problèmes surviennent rapidement lorsque vous commencez à mettre en place des projets.

    L’approche normative — et je me suis trouvé dans cette situation — est une équipe de personnes assises dans une pièce qui disent « Je me demande de quoi nous avons vraiment besoin ici. Je ne sais pas, mais nous devons terminer ce document d’ici la fin du mois. D’accord, écrivons quelque chose ». Elles le remplissent d’hypothèses, qui sont d’abord mises au banc d’essai au stade de la mise en oeuvre, ce qui est trop tard, car celle-ci se fait toujours après l'octroi du contrat.

    Par le passé, avez-vous vu d'autres gouvernements — qu'il s'agisse de gouvernements provinciaux ou étrangers ou d'administrations municipales — employer la méthode « agile » ou une version de celle-ci avec succès?

    La plupart des pays dans le monde commencent maintenant... Nombre d'entre eux ont déjà commencé. Le Royaume-Uni le fait depuis quatre ou cinq ans. Même chose pour les États-Unis.

    Pour ce qui concerne les États-Unis ou le Royaume-Uni, où ont-ils commencé? S'agissait-il d'un déploiement à la grandeur du gouvernement ou se sont-ils concentrés sur un ministère? Je me demande simplement comment nous nous y prendrions avec le nôtre.

    Le SCT a fait appel à Olivia Neal du Royaume-Uni, qui a beaucoup travaillé à leur système. Ils ont établi des normes et des statistiques pour la gestion de projet et de portefeuille. C’était bien, et c’est bien qu’on l’ait fait venir, et c’est bien qu’on commence. Cependant, je pense que le point de départ est le leadership de la direction, l’éducation et la compréhension pour pouvoir saisir de quoi il s’agit, car c’est une nouvelle façon d’aborder un problème. Si vous ne comprenez pas comment aborder le problème d’un autre angle, vous vous ingénierez à nouveau à trouver la façon de faire les choses et vous vous attarderez à tous les détails. Ensuite, vous consulterez de multiples documents qui, neuf fois sur 10, sont incorrects et qui sont coûteux lorsque c’est le cas.

    Qui est l'étalon en ce moment? Le Royaume-Uni, les États-Unis ou un autre pays?

    L'étalon mondial en ce moment est Amazon, qui compte 1 000 équipes.

    Désolé, je voulais dire pour un gouvernement.

    Pour un gouvernement, le Royaume-Uni est assez bien. L’Estonie est petite, mais elle est assez exceptionnelle. Ses fonctionnaires ont tout examiné en commençant par les politiques, et leur approche fondée sur les résultats a été très pragmatique. L’Estonie est un bon modèle. Elle sera à la conférence « Forward 50 », FWD50. Un représentant de ce pays fera une présentation.

    Le fait est que c’est vraiment faisable, et c’est une solution systémique qui doit être appliquée. Il faudra du temps. C’est une évolution et non une transformation. Encore une fois, une transformation est l’attitude selon laquelle vous allez entreprendre un grand projet; ne le faites pas. Ce serait ma recommandation.

    Lorsqu'il s'agit du gouvernement, ce sont des projets d'envergure.

    Oui, j'en conviens.

    Devrions-nous tout simplement les scinder en une série de petits projets?

    Oui, scindez-les en des projets de 500 000 $ ou moins.

    D'accord. Merci, monsieur Murphy.

    Je dois vous arrêter là. Encore une fois, j'ai laissé les choses aller, mais je suis convaincu que les questions vont continuer dans le même sens.

    Monsieur Weir, cela dépend de vous.

    Eh bien, c'est peut-être parce que les grands esprits se rencontrent, mais je voulais poursuivre sur la lancée de M. McCauley avec la question suivante: existe-t-il des projets qui portent sur des systèmes interreliés d'une telle envergure ou pour lesquels les économies d'échelle réalisées grâce à la méthode « agile » seraient à ce point avantageuses?

    Je crois que les projets nécessitant d'importants investissements ne seraient pas les mieux appropriés. Ces projets sont risqués. Chaque fois qu'il faut jouer le tout pour le tout, c'est risqué. Je dirais qu'à moins de ne pas avoir le choix, il faut se tenir loin des projets où il faut jouer le tout pour le tout. Pour formuler des conseils qui tiennent la route, il faudrait que je voie les détails du projet, mais vous avez déjà un programme passablement chargé en ce qui concerne l'application de cette méthode.

    Si vous faites un projet que vous avez déjà fait un million de fois et que vous savez qu'il sera exactement pareil à toutes les autres fois, c'est comme pour une recette — vous savez, tel ingrédient à tel moment —, vous incorporez cela et vous obtenez tel résultat. Sauf qu'avec les projets gouvernementaux d'aujourd'hui et la complexité du monde actuel, neuf fois sur dix, il est impossible de procéder de la sorte. Cela ne saurait se faire.

    Vous semblez dire essentiellement que tous les grands projets de TI du gouvernement pourraient être morcelés en de petits projets susceptibles de bien fonctionner avec la méthode « agile ».

    C'est ce que je crois. J'estime que cela devrait être une politique: il ne devrait pas y avoir de projets de grande envergure. Ils devraient être morcelés en étapes trimestrielles. Vous pourriez avoir un objectif à long terme comme Cisco s'était donné de fermer ses livres en une journée, mais vous apercevoir que cela pourrait vous prendre cinq ans.

    Je comprends.

    Mais voilà, si le directeur demande de rendre possible la fermeture des livres en une journée, et que vous disposez d'une année pour le faire, il va y avoir de sérieux problèmes, car l'équipe ne connaît pas ses capacités et ne sais pas de quoi elle est capable. Elle devra essayer tant bien que mal de recueillir des données empiriques, des données dites fondamentales, du genre qu'on ne peut recueillir que d'une mise en oeuvre concrète. Les contrats de ces projets sont truffés d'estimations indicatives, et ils sont très chers.

    Lorsque M. McCauley vous a demandé s'il y aurait lieu d'utiliser la méthode « agile » pour réparer Phénix, vous avez eu certaines réserves. De façon hypothétique, pouvez-vous nous dire à quoi pourrait ressembler la mise en oeuvre d'un système comme Phénix avec la méthode agile, en commençant par le début?

     Bien sûr. Au début, vous démarrez la mise en oeuvre du projet de paye avec 10 personnes dans un seul ministère. Vous tirez des leçons de cela, puis vous étendez le déploiement afin d'inclure 20 nouvelles personnes. Après un certain temps, vous avez les choses bien en main et vous êtes prêts à passer à un autre ministère ou à un autre organisme, disons la GRC. Vous savez que les choses sont un peu différentes là-bas, qu'il y a des règles de sécurité et d'autres aspects particuliers. Vous recommencez donc le processus avec 10 ou 20 personnes, et ainsi de suite.

    Vous pouvez savoir ce qui se passe en écoutant l'équipe. L'équipe dira « nous maîtrisons la situation », ce qui contraste avec l'approche traditionnelle, où l'équipe dirait « nous avons de sérieux problèmes ». Personne ne veut parler, car il y a une date limite à respecter. Les supérieurs ont informé l'équipe qu'elle devait avoir terminé telle chose d'ici telle date.

    L'approche fondée sur le leadership consiste à éliminer les obstacles. Si quelque chose vous bloque la route, venez me voir et je vais faire sauter ces obstacles. L'approche fondée sur le leadership consiste à dégager la voie. Ce n'est pas de dire « voilà comment vous allez procéder, quand vous devez le faire et  combien ça coûtera ». Cette façon de faire plombe le projet avec des barrières et des contraintes artificielles, et l'équipe ne le sait pas encore. Les fonctionnaires savent que l'équipe ne le sait pas, et cela ne fait que générer du stress.

    En général, avec ces projets pangouvernementaux de TI, on aurait tendance à croire qu'il serait logique de procéder un ministère à la fois ou un organisme à la fois. Ce serait une manière logique de scinder le projet en morceaux qui se gèrent mieux.

    De faire les choses de façon graduelle, bien entendu. Encore une fois, je ne vais pas parler du « comment ». Je vais laisser cela à l'équipe.

    D'accord.

    Mon objectif est d'instaurer un système de paye pour le gouvernement fédéral. En tant que directeur, c'est là-dessus que je me focalise. L'équipe entre en scène et elle dit qu'elle va faire un essai avec ces 10 personnes. Je lui dis: « Formidable. Tenez-moi au courant des résultats. » L'équipe me signale que telle ou telle chose pose problème. Je lui réponds: « Je vais éliminer ce problème pour vous. Maintenant, allez faire un autre 90 jours. »

    Les étapes des projets pilotés avec la méthode « agile » durent souvent deux semaines, mais, habituellement, les résultats importants sortent à intervalles de 90 jours. Avec une plage de 90 jours, je ferais la même chose pour le gouvernement que ce qu'a fait Cisco. Je mènerais de multiples projets de front, et tous ces projets se synchroniseraient les uns avec les autres à la fin du trimestre. L'autre chose avec les TI, c'est que, très souvent, les projets sont liés ou assujettis à des produits préalables ou concomitants. Vous commencez à les mettre en oeuvre et vous vous rendez compte qu'il vous faut un serveur de Services partagés. Il faudra donc veiller à ce que le projet du serveur des Services partagés soit placé en priorité, parce qu'il constitue une contrainte pour les autres projets. Une fois débarrassée de cette contrainte, l'équipe peut poursuivre son chemin. Par conséquent, la synchronisation trimestrielle, si je peux l'appeler ainsi, est extrêmement importante.

    Je ne veux pas entrer trop profondément dans les détails. À ce stade-ci, pour ce comité, ce qu'il importe de retenir c'est en quoi consiste le style de leadership et l'approche « agile », ainsi que les principes de cette approche, lesquels sont évoqués dans la présentation en référence à la Deuxième Force opérationnelle interarmées, la FOI 2. La FOI 2 fait partie du ministère de la Défense nationale. L'armée a mis cette équipe sur pied parce que des gens mouraient et parce qu'elle voulait éviter le plus grand nombre de décès possible au sein de ses troupes. La FOI 2 est autonome. On lui donne un plan, mais une fois dans le feu de l'action, tout peut changer; les tirs qu'on attendait du nord pourraient arriver du sud. Sur le terrain, ces militaires doivent être prêts à tout; ils doivent être en mesure de s'adapter et de se donner leur propre plan. Pour ce faire, ils doivent avoir l'autonomie voulue. Voilà ce que doit faire le gouvernement: il doit développer son adaptabilité.

    Un autre élément de grande importance, c'est la question de la cybermenace. Les gens qui exercent ce type de menace sont adaptables. Ils sont agiles et adaptables. Ce sont de petites équipes. Sur le plan de la capacité, ils sont en train de semer le gouvernement et ils évoluent de plus en plus rapidement.

    C'est donc dire que nous sommes en train de prendre du retard, ce qui est inquiétant.

    Très juste. Vous avez parlé de la mise sur pied d'une petite équipe « agile » à l'intérieur de la machine d'État. J'ai un peu de difficulté à imaginer comment cette équipe s'insérerait dans Services partagés ou, de façon plus générale, dans le pouvoir exécutif. Croyez-vous qu'il faudrait demander la création d'une charge de commissaire des TI, soit un agent du Parlement appuyé d'une petite équipe de fonctionnaires?

    Je n'en suis pas certain. Je crois que ce qui est le plus important, c'est que cette vision soit fixée, que le « comment » soit clairement défini et compris, et que la notion fasse consensus. Il faut aussi savoir précisément pour qui nous faisons cela. Le rôle de Services partagés est-il de créer un standard ou de prodiguer des services aux ministères qui offrent des programmes aux Canadiens? Je crois que son rôle est de prodiguer des services. Partant de là, que devons-nous faire pour arriver à ce résultat? Plutôt que de dire « vous ferez ceci et vous ferez cela », nous devrions nous demander ce que nous devons faire pour arriver à ce résultat. Laissons l'équipe revenir et nous expliquer ce dont elle a besoin, puis efforçons-nous de dégager la voie.

    Cela va en sens inverse de ce à quoi nous sommes habitués. C'est ce qui me fait croire que cette mentalité est vraiment au coeur de la méthode « agile ». La méthode transforme notre façon de penser. Ce n'est pas quelque chose que vous allez acheter au magasin. Vous savez, je m'inquiète de la possibilité que la méthode soit éventée et mal interprétée.

    Merci beaucoup.

    Merci beaucoup.

    Monsieur Ayoub, nous vous écoutons.

     Je vous remercie, monsieur le président.

    Monsieur Murphy, j'ai bien écouté votre présentation. J'ai lu l'information concernant vos antécédents, votre expérience professionnelle, et ainsi de suite. J'ai suivi un parcours professionnel en télécommunications, et j'ai travaillé au sein d'une entreprise canadienne bien connue de ce secteur, que je ne nommerai pas. Il existe une panoplie de modèles de gestion de projet ainsi que des normes pour encadrer ces multiples façons de faire, par exemple les certifications ISO-9000 et ISO-8000. De grandes maximes ont cours, comme « arrêtez de creuser quand vous êtes dans un trou ». Je suis bien d'accord sur tout cela.

     Toutefois, la particularité des grands projets, c'est que les vendeurs, concepteurs, intégrateurs et promoteurs de solutions n'offrent que des options englobant la totalité du projet. Rares sont les entreprises, que ce soit Cisco ou IBM, qui sont prêtes à ne vendre qu'une portion de programme ou de projet. On ne veut vendre que des solutions globales, même si les projets nécessitent un financement de 50 millions ou de 1 milliard de dollars. J'en suis convaincu. Là où l'approche diffère, c'est lorsque le modèle de gestion de projet intègre des façons de mener à bien les projets. La gestion de projet est une activité importante, et il n'y a pas de solution miracle.

    Je m'interroge donc sur le modèle de gestion de projet Agile, qui existe depuis les années 1990, d'après ce que j'ai compris. Bien honnêtement, dans ma courte carrière d'à peine une vingtaine d'années dans les télécommunications, je n'ai jamais entendu parler d'Agile. Je suivais peut-être un autre courant de pensée, ou encore nous devions gérer d'autres types de projet. En revanche, nous gérions de petits projets faisant partie de plus gros. D'une certaine façon, il s'agit de gérer les gros projets en les scindant — cela n'est pas nouveau.

    En quoi Agile diffère-t-il des autres modèles, à part le fait d'être guidé par une philosophie particulière de la gestion qui se veut moins axée sur la prise de notes? On comprend que la notion de gestion sans papier n'existe malheureusement pas. Même si, en pratique, la technologie a envahi toutes nos activités, le papier reste encore très présent. Comment pouvons-nous être convaincus de faire confiance à cette méthode? Comment être sûrs qu'il ne s'agit pas d'un processus de gestion par essais et erreurs appliqué à de plus grands projets, surtout compte tenu de la différence qui existe entre les entreprises privées et le secteur gouvernemental? Vous avez abordé brièvement la complexité des projets, mais il existe une très grande différence, selon moi, entre les projets entrepris par diverses entreprises et ceux menés par un gouvernement, particulièrement le gouvernement canadien dont la taille est importante. Pouvez-vous préciser votre pensée? Vous ne voulez pas trop entrer dans les détails, mais pouvez-vous quand même m'expliquer en quoi cette méthode de gestion diffère d'une autre?

    Oui, bien sûr. Il y a beaucoup à dire à cet égard.

    Les grands projets d'intégration sont les plus complexes. Aux termes de l'approche actuelle, ce sont ceux qui présentent le plus de risque. Je conviens que vous pouvez les scinder, mais le problème, c'est la période de latence qu'il y a au début du projet. Au gouvernement, on passe trois ans à faire la liste des exigences et la première validation de ces exigences, de la conception ou de l'architecture du projet n'arrive qu'après l'adjudication du marché. C'est la façon la plus risquée de procéder. Les projets gouvernementaux d'envergure peuvent quand même être mis en oeuvre en composantes plus modestes. IBM ou un gros intégrateur pourrait quand même décrocher un contrat. Ce n'est pas un problème. Sauf que ma démarche d'approvisionnement sera la suivante: au lieu de passer un an à cerner des exigences, je vais me concentrer à définir le résultat que je souhaite, puis je vais inviter les fournisseurs à la table et nous allons nous mettre au travail. Donnez-nous un plan d'ici trois mois, pas d'ici trois ans, un plan où vous expliquerez comment vous allez procéder puis, à la fin de ces trois mois, nous allons commencer la mise en oeuvre.

    Les fournisseurs dépensent des millions de dollars sur les processus d'approvisionnement et ils savent que ce n'est pas la bonne façon de procéder. Demandez leur avis à tous les IBM de ce monde et ils vous diront que cette façon de faire n'est pas la bonne.

    Parlant de grands projets de télécom, j'ai travaillé à la mise en oeuvre d'un service de télécommunication pour Travaux publics. Il a fallu environ six mois pour concevoir le service et le mettre en fonction. Nous sommes allés voir les clients directement pour leur demander ce qu'ils voulaient. Ce qui est vraiment intéressant, c'est qu'ils vous répondent. Si vous leur posez la question directement, ils vont vous dire ce dont ils ont besoin. D'entrée de jeu, ils nous ont demandé d'où nous venions. « Vous ne pouvez pas faire partie du gouvernement, puisque vous me demandez ce que je veux. » Nous leur avons dit: « Non, nous sommes avec Travaux publics. Je suis un entrepreneur, mais ces gens-là ne le sont pas, et nous voulons savoir ce que vous souhaitez comme service. » Ils nous ont dit ce qu'ils voulaient et nous avons travaillé en fonction de cela. Nous sommes arrivés avec notre propre infrastructure et tout le reste, et nous avons mis le service sur pied. C'était bel et bien un service, et pas une technologie. Il s'agissait d'assurer leur connectivité ou quelque chose du genre.

    Alors, même si je n'avais pas à me soucier de 350 000 utilisateurs, c'est un exemple qui montre que c'est faisable. Nous avons commencé par Travaux publics, qui était notre ministère d'attache, et nous avons validé tous nos raisonnements. Nous avions un modèle, et ce modèle était indicatif. Nous avons conçu l'architecture, et cette architecture était indicative. Nous avions des exigences, et ces exigences correspondaient à ce que les clients avaient demandé. Ces exigences étaient indicatives, pas précises, car dans le domaine des technologies, la plupart des clients ne savent pas vraiment ce qu'ils veulent avant de s'en servir. Ensuite, ils disent: « Eh bien, maintenant que je vois ce que c'est, je ne veux pas de ceci ou de cela, mais je veux cette autre chose-là ». Ou « Pouvez-vous placer le bouton ici plutôt que là? » Oui, nous le pouvons. Ce sont des choses par lesquelles il faut passer. L'utilisateur doit apprendre lui aussi. Lorsque vous intégrez l'utilisateur au processus, cet utilisateur devient un client de référence. Il vous aime parce que vous lui demandez son avis et que vous y donnez suite. Alors, il n'en croit pas ses yeux. C'est un tout autre aspect de la dynamique, un aspect important.

    Les grandes sociétés canadiennes de télécom sont en train de converger vers cela. Telus est probablement la plus en avance dans l'intégration de la méthode « agile ». Je suis certain que Bell s'y est mise aussi, et peut-être certaines des plus petites sociétés, mais je ne le sais pas précisément parce que je n'ai pas fait d'étude là-dessus. Je sais que Telus a un vice-président et tout ce qui tourne autour de cela.

    La méthode a pris sa place. Tout le monde l'adopte et s'en sert. Cette méthode est la raison pour laquelle Elon Musk est en train de bousculer l'industrie automobile et l'industrie aérospatiale. Amazon, Uber et Airbnb ne sont pas arrivés là où elles sont par hasard. Ces sociétés sont des sociétés qui sortent de l'ordinaire, et elles sont là depuis longtemps. Blockchain va bousculer le secteur financier.

    Je pense que le gouvernement doit améliorer son adaptabilité, et je crois que cette approche est ce qui lui permettra d'y arriver. Il faut que les gens soient sensibilisés à cela et, bien entendu, la mise en oeuvre devra se faire par petites étapes. C'est la façon d'atténuer les risques. Le gouvernement est une organisation de proximité, alors cette méthode est on ne peut mieux indiquée.

    Merci.

    C'est maintenant au tour de M. Shipley.

    Essayez de vous en tenir à cinq ou six minutes, chers collègues, et nous tâcherons de poser un maximum de questions dans le temps qu'il nous reste.

    Merci.

    Il y a ici une citation qui dit: « Lorsque vous vous retrouvez dans un trou, cessez de creuser. » Nous sommes probablement nombreux à le dire. Or, cela retourne parfois contre nous parce que nous avons parfois du mal à reconnaître, d'abord, que nous nous enfonçons et, ensuite, que nous continuons de creuser.

    J'aimerais en savoir plus sur le processus. Vous vous concentrez seulement sur le « pourquoi ». Comme l'ont mentionné certains de nos collègues, il faut alors beaucoup de confiance...

    Oui.

    ... puisque, maintenant, notre réflexion ne porte plus sur la façon de nous y prendre, sur les échéances, etc. On se contente de me dire pourquoi il faut faire telle ou telle chose; je n'ai qu'à m'atteler à la tâche, et le tout se concrétisera.

    Comment cela se fera-t-il? Je suis peut-être à côté de la plaque, mais Kelly a parlé de l'exemple de la construction navale. Reprenons un grand projet. Cela n'a rien à voir avec la partisanerie. Dans le cadre de notre examen de l'acquisition des avions à réaction, par exemple — et je le mentionne uniquement parce qu'il s'agit d'un projet colossal —, comment scindez-vous cela en petits projets? Dans le secteur privé, on contrôle un peu les modalités, les intervenants, les médias, et tout ce qui s'ensuit. Par contre, au gouvernement, on ne peut pas se contenter d'indiquer les modalités et les motifs, puis de dire qu'on se débrouillera pour le reste, parce que chaque étape met en cause le gouvernement, des facteurs politiques, etc. C'est ce qui arrive.

    Comment gérez-vous cette situation en scindant le tout en petits morceaux avant de vous attaquer à un grand projet? Ce n'est peut-être pas un bon exemple...

    Non, c'est une bonne question.

    ... mais il y a des projets de grande envergure. Nous pouvons procéder ainsi, par exemple, pour la rénovation des édifices du gouvernement. C'est le même principe. Comment nous y prendre?

    C'est une très bonne question. En ce qui concerne l'étape initiale, si vous menez un projet de 500 millions de dollars, alors vous avez besoin d'un grand plan. D'ailleurs, je viens d'en terminer un à SPC, où nous avons instauré un système de prévisions financières qui permet de prévoir le budget par rapport aux dépenses réelles. En l'espace de trois mois, pour une somme de 125 000 $, nous avons créé la version bêta. Si vous deviez déployer le projet à l'échelle du gouvernement, ce serait une tâche énorme. Mais pour 125 000 $, je peux miser cet argent pour apprendre et découvrir les nuances de ce type d'application, ce qui pourrait m'aider à concevoir la prochaine version et celle d'après. Si vous jouez le tout pour le tout, alors oui, vous devez tout savoir, et il faut beaucoup de confiance. En revanche, si vous ne mettez pas tous vos oeufs dans le même panier, si vous commencez par effectuer des mises à l'essai, des tests...

    Dans l'environnement actuel, nous faisons ce travail en mode production, mais nous commençons à une si petite échelle que nous atténuons le risque en conséquence. Selon le mode de pensée habituel, on se dit: « Je dois réaliser tout le projet d'un seul coup, car je dois en établir le budget, attribuer les fonds et faire des achats. » Or, il y a d'autres façons de s'y prendre. Ainsi, en vertu des ententes permanentes, je peux acheter des pièces et des composants, puis construire des choses, les mettre à l'essai et les valider. Je peux le faire en mode production. Je peux parler directement aux utilisateurs et aux citoyens, ce qui fait partie de la notion de gouvernement ouvert, et c'est très positif. Si vous envoyez un chèque d'assurance-chômage à quelqu'un, demandez-lui: « L'avez-vous reçu? Comment cela s'est-il passé? Étiez-vous satisfait du service? Utilisez-vous un nouveau système en ligne du gouvernement? » Il faut parler directement aux citoyens qui l'utilisent et recueillir leurs commentaires.

    L'atténuation des risques se fait en fonction de la taille du projet et du laps de temps. Chaque période est décomposée en de très petites étapes. D'habitude, sur une période de 90 jours, je ferais six ou sept répétitions pour créer seulement une petite composante. Pour la plupart des projets, comme celui que je viens de réaliser pour SPC, la première étape est de déterminer comment ouvrir une session. Vous créez la procédure de connexion au cours des deux premières semaines, puis vous la passez en revue. Vous demandez à l'utilisateur d'en faire l'essai et vous obtenez ses réactions. Quelle est la prochaine étape? Vous procédez donc ainsi, un élément à la fois.

    Dans ce cas, ai-je tort de présumer que cette approche ne peut pas être utilisée pour de grands projets d'acquisition de produits matériels? Par exemple, vous avez dit que les États-Unis, le Royaume-Uni et l'Estonie sont des modèles à suivre. Au Royaume-Uni, le gouvernement vient de faire des travaux majeurs de rénovation de ses édifices.

    Oui.

    Le tout a pris trois fois moins de temps et coûté trois fois moins cher. Quiconque a vu les édifices là-bas sait qu'ils sont énormes.

    Les fonctionnaires britanniques auraient-ils utilisé un protocole « agile » pour faire avancer le projet? Le cas échéant, quelle a été leur première étape? Par où commenceriez-vous, et quelle longueur d'avance prendriez-vous avant la première pelletée de terre ou le début de tout autre travail sur le terrain?

    Je ne peux pas me prononcer sur ce projet en particulier, mais de façon générale, la première pelletée de terre survient pratiquement au début.

    Si je devais entreprendre une transformation à l'échelle du ministère, il y aurait une période de 90 jours pendant laquelle nous planifierions les activités. Par la suite, nous procéderions à la mise en oeuvre, mais il s'agirait de très petits projets qui seraient conçus pour créer de la valeur et qui s'articuleraient autour de l'exécution du programme.

    Je vais vous arrêter ici. Je sais que nous aurons probablement l'occasion d'y revenir.

    Merci beaucoup.

    C'est maintenant au tour de Mme Ratansi.

     Merci beaucoup.

    Je viens du milieu de la consultation. Lorsque nous devions nous occuper de la gestion d'un projet, il y avait tellement de versions. Certaines étaient au goût du jour, mais elles ne duraient pas longtemps. J'espère que l'approche « agile » n'est pas une simple mode passagère.

    Elle ne l'est pas.

    Vous avez travaillé dans les secteurs privé et public, qui se caractérisent chacun par une mentalité totalement différente. Dans le secteur privé, on vous encourage à prendre des risques et on vous récompense ou congédie selon le résultat. Quelqu'un a-t-il été congédié dans la foulée des fiascos de SPC ou de Phénix?

    Je ne crois pas.

    Bon. D'accord. Ce n'est pas grave.

    La raison pour laquelle je vous pose la question, c'est parce que le secteur public n'aime pas prendre des risques.

    J'en conviens.

    Étant peu enclins à prendre des risques, les fonctionnaires sont là à long terme. Leurs maîtres politiques se succèdent, mais les fonctionnaires sont les éléments les plus constants et ils savent comment assurer leur propre gestion. Dans pareil contexte, dans une telle structure hiérarchique, comment une approche « agile » permettrait-elle de répondre aux besoins du gouvernement, d'après vous? Par exemple, dans quel domaine la planification de SPC comportait-elle des lacunes? S'agissait-il de son processus de planification, de sa portée ou de sa qualité? Quand on ne fait pas une planification en bonne et due forme, le processus n'aboutit pas, et tout le monde veut ensuite se sauver. Les sous-ministres changent de poste, ou peu importe. Comment pouvons-nous, en tant que politiciens qui assument la responsabilité de tous les fiascos, atténuer les risques?

    Comme je l'ai mentionné à Francis, la structure de SPC — dans sa forme actuelle et initiale — ne permet pas de créer quelque chose de nouveau; elle n'est pas propice à la création d'un nouveau service partagé. La structure de l'organisation est conflictuelle. Je crois qu'il est très difficile pour les fonctionnaires de procéder ainsi parce qu'ils ont affaire à un si grand nombre de centres opérationnels qui ont leur propre façon de faire les choses. Ils essaient de fusionner le tout, mais c'est là un projet colossal.

    Disons qu'on lance un nouveau projet. Quels conseils donneriez-vous au gouvernement, dans le contexte et la hiérarchie que vous connaissez déjà, pour ce qui est d'utiliser des méthodes comme l'approche « agile » afin d'atténuer les risques?

    Sortez de la hiérarchie.

    Comment? Après tout, c'est ainsi que fonctionne la bureaucratie.

    Encore une fois, à quoi sert une politique? Elle sert à créer une valeur pour les citoyens.

    Je vais vous poser la question d'emblée: la politique actuelle permet-elle la création de valeur ou y fait-elle obstacle? Si j'ai une politique qui précise, dans les moindres détails, comment faire quelque chose, cela devient tout simplement une procédure au sein du gouvernement, ce qui signifie que je dois passer beaucoup de temps à suivre les diverses étapes et à créer un plan d'ensemble, car je suis tenu d'élaborer un plan avant de faire quoi que ce soit.

    Mais la politique est déjà créée. J'ai moi-même participé à des processus de demande de propositions au sein du gouvernement provincial. Si on se retrouvait avec une demande de propositions de 200 pages, c'est parce que les fonctionnaires voulaient éviter tout risque d'échec; pour atténuer ce risque, ils précisaient les diverses étapes à suivre selon une approche très prescriptive. Comment faire pour changer cette mentalité?

    Au Royaume-Uni, les fonctionnaires ont instauré des jalons, ce qui prouve qu'ils ont adopté une approche « agile ». Il ne s'agissait donc pas de dire, à la fin du premier jalon: « Je veux que vous prépariez un gros document. » La directive, après le premier jalon, était plutôt la suivante: « Je veux que vous mettiez cela en oeuvre auprès de 10 personnes; faites-en l'essai et validez les résultats. »

    La méthode de gestion de projets consiste à dire: « Je veux des données empiriques. Je veux éviter une paralysie analytique. Je ne veux pas suivre le processus; je veux créer de la valeur. » De nos jours, les processus gouvernementaux ne créent pas de valeur pour nous.

     Je reviens à SPC, parce qu'il y a des leçons à tirer. Quels conseils auriez-vous donnés sur la portée de SPC à ses débuts?

    La portée pourrait rester la même. Toutefois, je dirais qu'il faut commencer par une toute nouvelle organisation qui n'est pas la fusion de 43 entités existantes. On doit commencer par SPC 2.0, et on n'a pas besoin d'une énorme bureaucratie pour y arriver. Je commencerais par 10 personnes, c'est-à-dire par une FOI 2. On aurait 10 personnes hautement qualifiées. Ces gens ont une mission très précise, et ils réussissent à l'accomplir.

    Quelle serait votre échéance? Vous savez, au gouvernement...

    Là encore, vous posez des questions qui s'inscrivent dans ce que j'appelle l'« approche traditionnelle ». Je dirais qu'il faut mettre sur pied l'équipe, puis faire un suivi tous les 90 jours pour s'enquérir des progrès réalisés par rapport à l'objectif. Au lieu de dire aux membres de l'équipe d'atteindre l'objectif en 90 jours, vous retournez les voir et vous leur demandez ce qu'ils ont fait et quels progrès ils ont accomplis par rapport à leur objectif.

    C'est pourquoi il s'agit d'un cours de deux jours.

    Autrement dit, vous changeriez la mentalité des gens qui sont là depuis 30 ans et qui ont appris que c'est ainsi qu'il faut procéder pour se protéger.

    Oui.

    J'ai déjà eu à m'occuper de fusions et d'acquisitions. Quand on procède à une fusion ou à une acquisition, il faut aussi éliminer beaucoup de postes. Dans le cas de SPC, on a fusionné 43 ministères.

    Oui.

    Cela a-t-il donné lieu à une rationalisation?

    Je ne crois pas qu'il y ait eu des congédiements, mais je ne sais pas exactement ce qui s'est passé. Il y a peut-être eu des changements du côté des retraités, en ce sens qu'on n'a pas réembauché certaines personnes, mais j'ignore ce qu'il en est au juste. La structure de l'organisation n'y est pas propice. Dans le cas d'une fusion, il faudra beaucoup de temps. Pourtant, en six mois, je pourrais créer quelques services essentiels avec l'aide d'une équipe de type FOI 2, ce qui permettrait d'éliminer certains goulots d'étranglement et d'assurer l'exécution des programmes.

    Feriez-vous cela...

    Je suis désolé, mais je dois vous arrêter ici.

    Monsieur McCauley.

    Vous pouvez conclure brièvement; j'aimerais bien entendre la fin.

    Je voulais simplement savoir s'il ferait la même chose pour Phénix parce que c'est le processus de planification qui pose problème.

    Pas cette question.

    Des voix: Ah, ah!

    Vous m'avez laissé faire, alors...

    Non, j'ai plutôt laissé le témoin finir de répondre à cette question. Vous devriez avoir honte d'utiliser mon temps.

    Des voix: Ah, ah!

    Eh bien, Phénix est un immense gouffre, mais SPC... Phénix est un cas difficile parce que les engagements avaient déjà été pris. C'est tout un fouillis. Cependant, SPC est toujours une organisation qui parvient à assurer la continuité des services, mais on ne peut rien créer de nouveau en raison du conflit à l'intérieur de la structure. Par conséquent, dans le cas de SPC, je créerais une équipe d'experts à qui je donnerais un pouvoir de très haut niveau. Je ne parle pas du pouvoir de dire quoi faire, mais plutôt le pouvoir de dégager la voie en vue d'atteindre l'objectif. Ce serait l'objectif de l'équipe; cet objectif lui appartiendrait. L'équipe aurait à atteindre son objectif. Tout le monde doit rendre des comptes. Nous reviendrions tous les 90 jours pour demander comment le tout s'est déroulé. Il y a une solution pour chacun du point de vue des risques. Si nous constatons que l'équipe ne fonctionne pas et que nous devons changer la dynamique pour que cela fonctionne, nous ferons alors un autre suivi après 90 jours pour déterminer si nous faisons des progrès et si nous créons la valeur escomptée. Par la suite, nous examinerons la rapidité avec laquelle nous créons de la valeur. Rendus là, nous pourrons envisager de faire certaines prévisions.

    Je vous remercie d'être allé au bout de votre pensée.

    Je veux revenir aux demandes de propositions. Vous avez parlé de l'idée de donner le résultat aux fournisseurs et vous avez expliqué comment Cisco a des demandes de propositions plus modestes, alors que les nôtres sont de 200 pages rien que pour l'achat d'un crayon. Comment envisageriez les demandes de propositions destinées non pas pour des navires, pour des articles ordinaires? À l'heure actuelle, nous y ajoutons tous les petits détails afin d'éviter des poursuites pour cause d'iniquité. Nous publions notre demande de propositions et nous disons que nous allons choisir le plus bas soumissionnaire. De quoi aurait l'air une approche « agile » dans ce cas-ci?

    Je m'entretiens avec Vincent Robitaille, qui s'occupe de l'approvisionnement et de la modernisation. Je crois qu'il est possible de miser d'emblée sur des mécanismes d'approvisionnement. Il existe des ententes permanentes en vertu desquelles je peux dire: « Écoutez, j'ai seulement besoin de trouver quelques personnes dotées de cette compétence. » Je les réunis alors dans une équipe, et je les laisse travailler pendant 90 jours. Je dispose d'un autre mécanisme pour l'achat de composantes ou de services. Je peux donc y recourir. Le processus d'approvisionnement lui-même est un peu lourd, car il exige beaucoup de documentation.

    Tout à fait, oui.

    Nous travaillons beaucoup à la visualisation des projets. Plutôt que d'avoir un document sur les plans et priorités de 10 pages, nous aurions un document de deux ou trois pages qui regrouperait tout. C'est ce que nous appelons une toile, et cela ressemble plutôt à une carte. Le document comprend les éléments essentiels des plans et des priorités. Si nous faisions des tableaux de présentation pour un ministère donné et que nous en avions environ cinq, nous les regroupions sur une page. Toute personne pouvait consulter l'information et savoir immédiatement quel était l'objectif. On sait ce qu'on fait, pourquoi on le fait et pour qui on le fait. Encore une fois, le « comment » ne devrait pas être inclus dans les plans et les priorités.

    Les grands projets à haute intensité de capital que vous avez mentionnés ne se prêtent pas bien au système agile pour l'approvisionnement. Qu'est-ce qui, au sein du gouvernement serait une valeur limite appropriée, selon vous?

    S'il s'agit d'acheter un bateau, par exemple, c'est probablement plus difficile, mais Elon Musk...

    Si je pose la question, c'est en raison de cette belle histoire sur l'achat de sacs à dos pour l'armée. Il nous a fallu moins de temps pour gagner la Seconde Guerre mondiale qu'il n'en faut pour leur acheter ces sacs.

    Oui. Eh bien, voilà la question importante. Combien cela coûte-t-il et qu'est-ce qu'on en retire?

    Je dois débourser 300 $ pour faire quelque chose et j'en retire 20 $. Concernant l'approvisionnement, j'ai au maximum 25 000 $. Très bien; tout un processus est suivi, qui coûte 100 000 $. Pourquoi nous ne...? Surtout maintenant que l'ALENA va probablement disparaître, nous pourrions avoir un peu plus de marge de manoeuvre.

    Il s'agit de donner des moyens d'action. On en met un peu plus dans les ministères, mais des vérifications et des inspections sont effectuées beaucoup plus souvent. Les inspections ont lieu assurément tous les 90 jours. Nous vous avons donné un peu d'argent. Ensuite, une inspection a eu lieu. Qu'avez-vous fait? Plutôt que de me donner un plan qui pourrait se concrétiser selon vous, je veux que vous mettiez certaines choses en place. Nous verrons ce qui se passera dans 90 jours. Nous atténuons les risques quand c'est petit.

    Mais en quoi la méthode « agile » modifie-t-elle notre processus de demande de propositions? Même pour les petites choses, nous nous retrouvons avec une demande de propositions de 100 pages.

    Non. Je pense qu'on peut faire des demandes de propositions selon une approche plus rigoureuse et moins lourde. Il s'agit de dire quels résultats on essaie d'obtenir, et l'industrie, qui fournira la solution, peut dire comment s'y prendre. Le processus n'a pas à être long. Si je ne dis pas exactement comment tout faire, alors il ne me faudra pas trois mois pour créer la demande de propositions: « Voici le résultat voulu. »

    Il s'agirait très simplement de dire: « Voici le résultat voulu. »

    C'est très simple.

    Il faudrait peut-être que ce soit d'origine canadienne, ou on aurait peut-être besoin...

    Oui. Le plan serait fourni, et nous dirions: « D'accord, nous voulons maintenant le mettre en oeuvre, mais nous ne le ferons pas pour 500 millions de dollars; nous y allons avec 50 000 $. » Et vous savez quoi? Pour les fournisseurs, c'est moins cher que d'embaucher une équipe pendant un an pour la préparation d'une réponse à une demande de propositions, qui coûte 1 million de dollars.

    D'accord.

    Merci.

    Monsieur Peterson.

    Merci, monsieur le président.

    Monsieur Murphy, je vous remercie de votre présence. Votre témoignage est très informatif. J'ai quelques questions à poser au cours des cinq minutes que j'ai à ma disposition.

    D'après ce que vous avez dit dans votre exposé et d'après ce que je comprends de la méthode agile, elle est plus axée sur les gens que sur le processus.

    Oui.

    D'après votre expérience, y a-t-il un type de personnes en particulier qui seraient plus disposées que d'autres à participer dans un lieu de travail agile? Faut-il avoir un ensemble de compétences en particulier? Est-il facile de trouver ces gens lorsqu'on veut changer un milieu de travail?

    La transformation, c'est la transformation des gens. Lorsqu'on commence à changer notre façon de concevoir les projets, c'est ce en quoi consiste la transformation. Il faut être capable de collaborer. Selon la méthode agile, dans le cadre d'une réunion, on ne dit pas à tout le monde comment on fera les choses. Dans une réunion d'équipe, on explique le problème qui se pose et on demande aux gens ce qui pourrait être fait. Les gens proposent alors des idées, parce que si une seule personne... De la formation doit être donnée pour la mise en oeuvre, ce qui existe déjà.

     En ce qui a trait aux personnes, c'est plus haut dans la hiérarchie de Maslow pour ce qui est de la réalisation des objectifs. Je pense ici à une vidéo de David Marquet, qui était un officier de la marine. Il était aux commandes de sous-marins. Il fallait un an à un capitaine de sous-marin pour tout comprendre. Il fallait tout savoir au sujet du sous-marin pour pouvoir le diriger. Il a été transféré à un nouveau sous-marin. Il ne connaissait rien sur celui-là. Tous les membres de l'équipage savaient exactement quoi faire, mais ils attendaient qu'il leur donne ses ordres. Il a dit « Je vais procéder à l'immersion du sous-marin maintenant » et leur a demandé ce qu'ils en pensaient. Ils lui ont répondu qu'ils pensaient que ce n'était pas une bonne idée. Il leur a demandé pourquoi, et ils lui ont répondu. Il a transformé complètement la situation. Vous pouvez voir la vidéo. Elle est excellente.

    Voilà le type de changement dont je parle. Les gens qui participent à des projets pilotés avec la méthode agile accomplissent des choses. C'est un milieu de travail beaucoup plus agréable. Il y a moins de stress. Les gens atteignent des objectifs et sont donc récompensés. J'ai vu trop de gens au gouvernement et dans la bureaucratie diriger la ligue de soccer, parce que c'est là qu'ils éprouvent un sentiment d'accomplissement.

    Oui.

    Faut-il que la méthode agile soit appliquée dans l'ensemble d'un organisme? Je suis sûr que c'était le cas pour Cisco. Est-il possible d'appliquer ce processus à un projet dans un organisme donné? Cela fonctionnerait-il?

    Je réponds oui aux deux questions. Il faut que cela s'applique à l'ensemble d'un organisme et je crois qu'il faut commencer par un projet. C'est qu'on commence et que les choses évoluent. On plante d'abord une graine, mais après on va plus loin, on peut faire comme Cisco. On peut mener différentes initiatives en parallèle. Nous transformerions le concept du bureau de gestion de projet en bureau offrant de la valeur, parce qu'en général, les projets réalisent la portée, mais dans ce cas, avec la méthode agile, nous voulons offrir de la valeur. Nous pouvons voir où nous réalisons la portée dans bon nombre de projets, mais nous n'obtenons pas la valeur.

    Supposons qu'un projet est en cours et qu'une équipe agile le met en oeuvre. Elle s'aperçoit que ce qu'elle fait ne lui permettra pas d'obtenir les résultats qu'elle souhaite. Elle doit changer son approche. Cela peut vouloir dire qu'elle prendra du retard ou qu'il y aura dépassement des coûts.

    Dans une équipe agile, toutes les deux semaines, il y a ce que l'on appelle une rétrospective. À la fin des deux semaines, nous produisons un petit élément de valeur, et les membres de l'équipe se réunissent et se demandent s'ils ont produit la valeur qu'ils pensaient produire. Après avoir répondu à la question, ils se demandent s'ils peuvent faire quelque chose de mieux la prochaine fois pour produire un peu plus de valeur. Ils en discutent et deux autres semaines passent.

    À la fin du trimestre, nous avons une plus grande rétrospective, peut-être à un niveau supérieur, et des questions se posent. Avons-nous produit la valeur et les résultats souhaités? Sinon, pourquoi? Qu'en est-il du budget?

    L'autre chose que je dirais au sujet du budget, c'est qu'il est extrêmement prévisible. Je sais que j'ai une équipe de cinq ou six personnes. Je sais que pour ces trois mois et les trois mois suivants, ce sera sans doute plus ou moins 10 %. C'est très prévisible concernant l'allocation budgétaire.

    D'après la lecture que j'ai pu faire des documents d'information, je crois comprendre que le client participe tout au long du processus dans le cadre de la méthode agile. On fait rapport au client et on obtient son avis à n'importe quelle étape lorsqu'il le faut. Comment les choses fonctionnent-elles au gouvernement, s'il n'y a pas nécessairement de client clairement identifiable?

    Oh, il y a toujours le citoyen. Dans le cas de SPC, il y a un ministère. Concernant le réseau pour Travaux publics, j'ai parlé à tous les gens du réseau du ministère et je leur ai demandé ce qu'ils pensaient de leur service. Ils ont dit qu'il coûtait cher et qu'ils aimeraient en avoir plus pour leur argent. Je leur ai demandé s'il y avait autre chose. Ils ont dit que tout le reste allait. Nous l'avons ensuite fait, et ils ont été ravis.

    Il est donc possible de mettre cela en oeuvre ici.

    C'est possible. L'objectif de l'initiative du gouvernement ouvert, c'est de communiquer directement avec les citoyens par les médias sociaux, par exemple. Il s'agit de pouvoir communiquer, de sorte que les choses fonctionnent.

    D'accord.

    Merci beaucoup.

    Merci beaucoup.

    Monsieur Weir.

    Pour revenir sur ce que vous disiez au sujet du gouvernement ouvert, je crois comprendre que la méthode agile est très itérative. Je peux voir d'un côté en quoi cela rejoint le concept de gouvernement ouvert, mais je me demande si le fait qu'on mette l'accent sur ce type interactions et qu'il y ait moins de documents, cela répond aux exigences en matière de transparence et d'accès à l'information au sein du gouvernement.

    Nous n'éliminons pas complètement la documentation. La situation idéale pour moi, ce serait que l'utilisateur fasse partie de l'équipe durant les réunions d'équipe, parce que toutes les fonctions y seraient représentées. J'ai tout le personnel opérationnel et les concepteurs et toutes les personnes dont j'ai besoin pour créer la solution. Ensuite, nous déterminons si le système que nous avons créé la semaine précédente fonctionne. Ils sont enthousiastes ou ils ne le sont pas. Nous obtenons cette rétroaction et nous continuons.

    Je pense que lorsque c'est possible, pour la méthode agile, il est absolument obligatoire d'avoir des liens étroits avec l'utilisateur ou la personne qui paie le système, la personne qui l'achète ou qui l'utilise. Les gens doivent faire partie de l'équipe et participer, et je pense que le gouvernement peut le faire.

    Bien sûr.

    J'aimerais également vous poser des questions sur la méthode agile dans le contexte des contrats. Concernant Phénix, c'était un contrat avec IBM, et on pourrait dire que le problème n'était pas seulement l'absence de la méthode agile au gouvernement, mais chez IBM. Je me demande tout d'abord si cette méthode est compatible avec la passation des marchés et si le gouvernement devrait chercher à conclure des contrats avec des entreprises qui utilisent déjà la méthode agile.

    Si je suis à la place d'IBM — et j'ai travaillé pour l'entreprise — et qu'il s'agit d'un contrat important sur 10 ans valant de 40 à 50 millions de dollars, nous soumissionnons. Si nous ne le faisons pas, nous sommes perdants pour 10 ans. Ensuite, on examine les choses et on détermine si la soumission est logique.

    Les fournisseurs sont très intelligents. Ils ne peuvent pas voir toutes les exigences. Nous savons que toutes sortes de choses ne peuvent pas se retrouver dans le document sur les exigences. Ils vont donc au siège social et disent: « Voici ce qu'il en est: il s'agit de 40 millions de dollars, mais nous savons que ce sera 150 millions de dollars, alors soit nous soumissionnons, soit nous perdons; or, nous pouvons penser à cela en tant que contrat de 150 millions de dollars plutôt que 50 millions, ce qui nous permettra de soumissionner avec un montant plus bas. »

     Ce n'est pas que les fournisseurs sont malfaisants. C'est seulement que c'est l'environnement qu'on leur offre et auquel ils doivent réagir. Si on leur demande de réagir à un environnement national, ils le feront.

     Je ne suis certainement pas en train de dire qu'IBM est malfaisante...

    Des voix: Ah, ah!

    Non, pas du tout.

    ... mais le projet n'aurait-il peut-être pas dû être divisé...?

    Qu'on me comprenne bien: non, IBM est extrêmement intelligente, mais c'est l'environnement dans lequel elle évolue.

    Oui, mais je me demande si IBM n'aurait pas dû diviser le projet Phénix en plus petits éléments, ce qui est propice à la méthode agile.

    Oh. Non, parce qu'on lui a demandé — bien qu'ils l'ont peut-être fait de leur côté — de répondre à un appel d'offres. Il y a des exigences obligatoires et des éléments souhaitables. Ils veulent le coût le plus bas par point, n'est-ce pas? Ils doivent jouer le jeu de l'approvisionnement. Or, si l'on intègre... si on le fait, on mise tout sur ces propositions. Donc, il ne faut pas tout miser sur cela. Il faut y aller graduellement, et au fur et à mesure, les intervenants de l'approvisionnement peuvent apprendre des choses également.

    À l'heure actuelle, l'industrie, par l'entremise de l'ACTI, communique avec les intervenants de l'approvisionnement pour collaborer afin de déterminer comment ils peuvent mieux faire les choses sur le plan de l'approvisionnement, de sorte que tout le monde y gagne et ait une chance égale.

    Encore une fois, quels résultats veut-on obtenir concernant l'approvisionnement? Le plus bas prix ou la meilleure valeur? Dans bien des cas, on obtient le prix le plus bas, mais pas la meilleure valeur. Il y a une grande différence.

    Entre la passation de marchés, graduellement, comme vous le décrivez, et une équipe agile oeuvrant à l'intérieur de l'administration publique, quel serait le meilleur modèle? Ou bien dépendrait-il des circonstances?

    Vous pouvez jouer sur les deux tableaux, passer des marchés, utiliser les approvisionnement existants et acheter les services d'un fournisseur ou vous fixer tel résultat et, pour l'obtenir, rédiger un projet d'approvisionnement, puis le mettre en oeuvre graduellement. Vous pouvez inviter un fournisseur, mais pendant seulement 90 jours, en l'avertissant qu'il y en aura trois, mais que les 90 premiers jours lui échoient. Si ça ne marche pas avec lui, vous vous adresserez au fournisseur numéro 2. Les fournisseurs pourraient se rebiffer et vous répondre que vous, dans l'administration publique, vous manquez d'efficacité. Cela pourrait se produire, mais je pense que cela permettrait de mieux fonctionner et d'atténuer le risque.

    Les enjeux ne sont pas aussi élevés. Il ne s'agit pas de 50 millions de dollars. S'ils se chiffrent à 100 000 $, peut-être que, à long terme, si je suis fournisseur, je décrocherai le gros lot. Mais je n'obtiendrai que 250 000 $ pour les 90 premiers jours.

    Merci beaucoup.

    Chers collègues, je prévoyais de suspendre les travaux vers midi et demi, pour nous occuper des affaires du Comité. Si ça vous chante encore, nous avons peut-être le temps pour deux interventions de plus, d'une durée de cinq minutes.

    Monsieur Whalen, voulez-vous vous essayer?

    Absolument.

    Il semble que si on essaie de se mettre dans un état d'esprit agile, pour agir avec agilité, il faut procéder avec agilité. Si, par habitude, on passe des marchés de 40 millions de dollars, on ne peut pas, du jour au lendemain, en diminuer la valeur maximale à 1 million. Il faudra de la méthode.

    Pour provoquer agilement de tels changements culturels, quel pourcentage de changement vise-t-on à chaque étape? Envisage-t-on, par exemple, d'écourter les délais de 5 % tous les trimestres pendant les 10 prochains ou de réduire la valeur du contrat de 20 % tous les trimestres? De combien réduit-on chaque fois la croissance des équipes? Combien d'équipes essaie-t-on de monter et quel taux de croissance vise-t-on pour elles afin de provoquer ce genre de changement culturel dans l'administration? À quoi ça ressemble?

    Tous ces éléments ressortent dans les rétrospectives de fin de trimestre. C'est alors qu'on évalue le déroulement des opérations.

    Dans les faits, c'est toujours le même processus de planification que celui que nous avions, sauf que nous faisons un retour d'expérience toutes les deux semaines à l'intérieur du module. À la fin du module, on fait un retour d'expérience trimestriel pour revoir la planification, vérifier la justesse de ses hypothèses.

    À l'intérieur du processus de planification agile, un paramètre permet de mesurer la vitesse de nos réalisations. Combien de services fournissons-nous? Combien de valeur créons-nous? L'équipe s'en fait une idée au fur et à mesure. Elle parviendra à un point de régime stationnaire, où cela deviendra très prévisible. Nous savons qu'elle peut produire tant tous les trimestres, et si tous en sont satisfaits, nous pouvons continuer à ce régime; ou nous voyons s'il y a plus à faire pour augmenter ou réduire la production. Mais ce n'est pas dicté d'en haut; c'est dicté par l'équipe. Ce n'est pas d'en haut qu'on lui demande d'écourter ses délais de deux semaines...

    Dan, est-ce que c'est dicté par l'équipe ou par les données produites par son travail?

    Les deux. Effectivement, vous créez une organisation qui découvre et apprend et qui, en même temps, augmente ses compétences, sa crédibilité et ses capacités internes. Il ne s'agit pas d'embaucher un entrepreneur de l'extérieur à tout faire. Il faut vraiment doter l'administration publique de ces capacités.

    Je suppose que, peut-être, il y a un lien avec notre sujet, mais l'une de mes surprises, relativement à la démarche de Services partagés Canada et à celle de Phénix, c'est qu'elles sont vraiment à fournisseur exclusif. Dans une organisation d'une telle envergure, on voudrait voir un esprit de concurrence contribuer à certaines réussites. Est-ce que l'agilité nous autorise, grâce à ses paramètres, d'approcher ou de créer un type de concurrence culturelle ou une culture de l'excellence ou offre-t-elle des occasions de réelle concurrence, favorisant des soumissions plus fréquentes? Comment fonctionne cette interaction dans les processus agiles?

    Vous pouvez absolument créer un contexte de concurrence, mais je reviendrai encore à ceci: la valeur est-elle votre premier ressort? Cherchez-vous la valeur ou la concurrence? Est-ce que la concurrence entraîne la valeur? Oui. D'accord, augmentons la concurrence.

    Vous pouvez toujours créer et structurer cet environnement. Si je dois évoluer dans un environnement où je recherche la concurrence, parce que cela fait partie de mon mandat, que c'est le monde dans lequel je vis, d'accord, allons-y. Cependant, trop souvent, le résultat découle d'exigences internes par opposition à la valeur que nous voulons piloter pour les citoyens.

    Un citoyen réclame son chèque. Vous répondez qu'il devra attendre, parce que vous devez être concurrentiel. Peut-être bien, mais, sous-jacente à la réalité vers laquelle vous tendez, il y a la création d'une valeur pour le citoyen grâce à l'exécution du programme. Si c'est ce vers quoi vous restez déterminé à parvenir, eh bien tout le reste se relativise dessous. Si vous en perdez la trace, alors la concurrence ou le prix le plus bas devient le plus... C'est alors que commenceront vos ennuis, d'après moi.

    Il vous reste moins d'une minute.

    Les fonctionnaires peuvent-ils suivre ce cours de deux jours comme le ministre Brison? Par exemple, comment est-ce que je fais?

    Par l'entremise de l'ACTI, l'Association canadienne de la technologie de l'information, que vous pouvez contacter. Les renseignements sont accessibles.

    Il importe de comprendre que, pour la transmission des savoirs, il y a beaucoup d'effervescence sur la façon de conduire un essai, de diriger une équipe et d'instaurer une dynamique dans l'équipe, mais, sur le leadership partout dans l'industrie, il y a une grosse lacune qui n'a pas commencé à se résorber. C'est la raison pour laquelle nous voulons la combler par l'entremise de l'ACTI, pour l'industrie, pour tous les types de fournisseurs et non un seul.

    Néanmoins, lancez-vous et vous comprendrez. Si vous suivez le cours, parfait!

    M. Nick Whalen: Merci.

    Finalement, monsieur McCauley.

    Merci encore.

    Vous avez bien résumé la question quand vous avez parlé de la façon, pour nous, de privilégier les exigences internes et non le résultat. Je suis sûr que même si nous nous éloignons du précipice, cela n'a pas d'importance, tant que nous répondons aux critères.

    Exact.

    Je peux m'imaginer à quel point il est difficile de devoir changer complètement d'attitude et de mentalité au gouvernement. Revenons, par exemple, à l'Estonie, aux États-Unis ou à la Grande-Bretagne. Privilégient-ils une démarche ministère par ministère ou est-ce que chaque ministère essaie, à l'interne, de s'attaquer à une petite partie du problème?

    Au Royaume-Uni, le gouvernement, d'après ce que j'ai vu, privilégie l'initiative ou le niveau de projet, et c'est excellent. Tout est bon, parce que nous apprenons.

    Est-ce à la grandeur de l'administration publique?

    Oui. c'est pangouvernemental.

    Que ce soit en matière d'approvisionnement, à la Défense nationale ou petit à petit, dans chaque ministère...

    Oui, c'est animé par l'équivalent, là-bas, de notre Conseil du Trésor. Essentiellement, c'est une démarche axée sur la gestion par projet, assortie de jalons pour le parcours agile des étapes importantes, plutôt que sur l'affirmation « Le recueil de nos exigences est complet. » C'est bien ainsi, mais c'est moins évident d'un point de vue organisationnel.

    Je recommanderais au gouvernement d'essayer un projet organisationnel d'orientation pour amener une organisation à employer ce genre de démarche, comme un conseil du Trésor. Une politique, c'est excellent, mais c'est inféodé au résultat. Elle est censée le donner, et, sous cette politique se trouvent les directives, qui, à mon avis, sont simplement trop prescriptives. Leur rédaction exige beaucoup de temps, de travail et d'intervenants. On peut économiser beaucoup sur le temps d'examen des détails précis des marches à suivre, quand, à la fin, on s'aperçoit que, de toute façon, on ne savait rien. Au moment de la mise en oeuvre, celui de vérité, ça ne marche pas.

    Je me demande à quoi ressemblerait une demande de propositions que nous publierions pour embaucher d'agiles...

    Dans l'administration fédérale états-unienne, on trouve une organisation appelée 18F, son adresse, dans une rue de Washington. Elle a recruté ses membres chez Google. Elle possède des modèles de demandes de propositions et tout ce qui... Elle a peu d'influence. Il y a là de la matière, dont nous pourrions beaucoup profiter. L'important est de s'y mettre, de se salir les mains, de commencer à agir, mais sans mettre tous ses oeufs dans le même panier.

    Quelles grandes sociétés canadiennes privées procèdent de cette manière? Cisco, visiblement.

    Shopify, qui possède 2 500 équipes. J'ai fait appel à ses gens — une histoire phénoménale — et ils font beaucoup de travail. Chez Shopify, vous serez le seul en veston et cravate.

    Des voix: Oh, oh!

    M. Dan Murphy: Et aucun quadragénaire.

    Y a-t-il d'autres institutions, à votre connaissance?

    La banque Scotia a créé un vaste programme. Elle a détaché d'elle-même une partie qui n'est pas soumise à la même gouvernance qu'elle. Elle l'appelle l'Usine numérique. En effet, elle subit une forte concurrence de la part de Tangerine. Je pense qu'elle a fini par acheter Tangerine, dont les services bancaires en ligne lui ont causé beaucoup de frayeur. Tout comme Bitcoin. Bitcoin est une entreprise point-à-point qui fait des opérations sans avoir besoin de banque. À une vitesse extrêmement difficile à imiter. Les banques se dirigent toutes...

    Demain, le vice-président de la banque Scotia vient au centre Shaw pour parler, non pas d'agilité en soi, mais des motifs de la coexistence de deux régimes séparés de gouvernance. Nous l'avons essentiellement prévenu de ne pas nous parler d'agilité, mais de cette coexistence et de ses motifs.

    Je suppose qu'il y avait des règlements.

    Merci beaucoup.

    Monsieur Murphy, au nom de tous les collègues, je vous remercie. Je trouve tous ces renseignements fascinants et extrêmement instructifs. Je vous souhaite la meilleure des chances. Je sais que les gouvernements sont ce qu'ils sont et qu'ils savent ce qu'ils font. Le temps nous dira si notre gouvernement ou d'éventuels gouvernements de l'avenir auront réussi à adopter le genre de culture dont vous parlez. Vous m'avez certainement ouvert les yeux, et ceux de beaucoup d'entre nous, qui doivent peut-être commencer à réfléchir différemment, si nous voulons obtenir les résultats qui, d'après vous, sont à portée de main.

    Encore une fois, merci beaucoup.

    Chers collègues, nous allons suspendre les travaux quelques moments pour ensuite les poursuivre à huis clos.

    [La séance se poursuit à huis clos.]