La décision du responsable produit : un facteur déterminant dans les projets technologiques gouvernementaux

Dans les projets technologiques menés au sein des services gouvernementaux et d'urgence, j'ai constaté que certains ont rapidement généré une valeur exceptionnelle, tandis que d'autres s'éternisent, engendrant de nombreuses opportunités manquées et un retour sur investissement plombé par une mauvaise gestion des ressources. La différence tient rarement à la complexité technique ou aux contraintes budgétaires. Un constat s'impose cependant : le Product Owner a un impact considérable sur la valeur ajoutée et le respect des délais.

Consacrer du temps et des efforts au choix de la bonne personne – lorsque l'on investit potentiellement des millions de dollars – est à la fois un investissement judicieux et une étape cruciale de la planification de votre projet. Voici ce qui compte réellement lors du choix du Product Owner de votre projet – et cela pourrait vous surprendre.

#1. La bonne attitude (Principale)

Ce que je considérais auparavant comme important : Une compréhension approfondie du rôle de Product Owner, une expérience personnelle en tant qu'utilisateur, une connaissance des méthodologies et des cadres agiles.

Ce qui compte réellement : Un enthousiasme débordant et une détermination sans faille à mener à bien les projets.

Les meilleurs Product Owners avec lesquels j'ai travaillé n'étaient pas forcément les plus attachés aux processus, et la plupart n'avaient jamais occupé ce poste auparavant. Certains n'avaient même jamais entendu parler de la méthode Agile. C'étaient ceux qui considéraient les résultats du projet comme leur mission personnelle et qui travaillaient comme de véritables membres de l'équipe de développement, quelle que soit la structure du projet. Ils se souciaient sincèrement de résoudre les problèmes des utilisateurs et ne se contentaient pas de travailler dans le cadre d'un tableau Jira ; ils cherchaient constamment à créer de la valeur et à obtenir des résultats.

Ce qu'il faut rechercher : Une personne qui parle de l'impact potentiel du projet avec un enthousiasme sincère, qui pose des questions pertinentes et qui propose de nouvelles idées et des pistes de réflexion en dehors des réunions planifiées.

Ce qu'il faut éviter : Une personne qui considère cela comme une simple responsabilité supplémentaire venant s'ajouter à sa charge de travail actuelle, et une liste de tâches à accomplir.

#2 : Disponibilité dédiée (du Product Owner et des experts concernés)

La réalité : Votre Product Owner doit être pleinement disponible pour le projet, sans avoir à le surcharger entre ses autres priorités. Outre son temps personnel, il coordonne également l’accès à l’ensemble des ressources nécessaires au projet.

Votre Product Owner devient le lien essentiel entre :

• Les équipes de développement et les utilisateurs finaux qui comprennent les véritables problèmes

• Les parties prenantes qui ont une vision et les personnes capables de la concrétiser

• Les responsables des données et les data scientists capables d’en extraire des informations pertinentes

• Les décideurs et les utilisateurs que le projet est censé servir

La réalité de la coordination : Pour les projets d’envergure, cette fonction de coordination peut facilement représenter une part importante du rôle d’une personne. Si le Product Owner n'est pas réellement disponible, ou si les experts métiers dont il a besoin (analystes militaires, linguistes, spécialistes du comportement des tirs, commandants opérationnels) sont constamment indisponibles, vous risquez de vous retrouver face à une série de retards, de blocages et de priorités mal définies pour votre équipe de développement.

Profil recherché : Une personne capable de consacrer du temps au projet et de maintenir sa dynamique malgré des priorités concurrentes. Elle doit gérer proactivement les attentes des parties prenantes, coordonner les calendriers sans devenir un goulot d'étranglement et mobiliser les décideurs clés et les experts métiers au moment opportun.

À éviter : Si vous devez opter pour des rôles partagés, je privilégierais un Product Owner qui partage son temps à parts égales entre le projet et un rôle utilisateur, plutôt qu'un Product Owner réparti à parts égales entre deux projets différents. L'exception concerne les projets étroitement liés (par exemple, deux systèmes faisant partie d'un flux de travail critique) : dans ce cas, ce type de chevauchement peut s'avérer extrêmement précieux.

#3 : Influence et crédibilité organisationnelles (Le superpouvoir caché)

La réalité : Le succès ou l’échec de votre produit dépendra de son adoption par les utilisateurs de différents services et niveaux hiérarchiques.

Votre product owner doit :

• Bénéficier d’une crédibilité transversale (et pas seulement au sein de son service)

• Faciliter l’accès à l’expertise, aux données ou aux approbations nécessaires

• Comprendre le processus décisionnel réel (au-delà de l’organigramme)

Les projets les plus réussis auxquels j’ai participé avaient des product owners capables d’obtenir rapidement l’accès à des experts métiers très sollicités via Slack, de planifier des réunions et de garantir la présence des bonnes personnes, ou encore de distinguer les approbations réellement nécessaires des formalités bureaucratiques.

L’effet de réseau : Grâce à un réseau solide, des mois de questions-réponses fastidieuses peuvent se résumer à une seule conversation. À l’inverse, des demandes simples peuvent se transformer en processus d’approbation interminables.

Le défi du contrôle exécutif : Voici un scénario courant : un haut responsable finançant le projet arrive lors du sprint final avec une idée géniale pour une fonctionnalité qu’il juge précieuse. Le problème ? Les utilisateurs (ceux pour qui le projet a été financé) ont déjà établi que cette fonctionnalité est certes tape-à-l’œil, mais inutile. Votre responsable produit doit avoir la crédibilité et la fermeté nécessaires pour défendre les priorités des utilisateurs dans ces moments-là. Il possède le contexte, les données concrètes et connaît les cas d’utilisation réels. Il doit être capable de défendre les utilisateurs avec respect mais fermeté lorsque c’est important. Il ne sera évidemment pas seul, mais sa contribution sera essentielle lors de ces discussions cruciales.

#4 : Motivation et identité liées à la mission (Leur engagement détermine leur impact)

Les personnes ayant la bonne attitude n’ont pas choisi leur carrière par hasard. Elles ont généralement acquis une expertise pointue dans au moins un domaine critique : systèmes SIG, lutte contre le terrorisme, affaires militaires, planification opérationnelle ou protocoles d’intervention d’urgence.

La raison pour laquelle il est important de s'intéresser au domaine dans lequel ils ont choisi de construire leur carrière, c'est que cette expertise métier reflète leur motivation par la mission. Ils sont profondément investis dans leur travail car ils y ont consacré des années pour le maîtriser. Ils s'efforceront de mener à bien leurs missions car il ne s'agit pas simplement d'un projet : c'est le prolongement de leur identité professionnelle et de leur passion. Une fois rentrés chez eux, ils réfléchissent à cette mission et à la manière dont ils peuvent contribuer au mieux à l'atteinte des objectifs.

Cette expertise métier et cette motivation personnelle surpassent souvent les formations formelles de product owner ou de développement produit. Ils comprennent les véritables problèmes car ils les ont vécus. Ils bénéficient d'une crédibilité immédiate auprès des utilisateurs finaux car ils ont été à leur place, et ces mêmes utilisateurs savent probablement déjà comment ils ont exercé leurs fonctions, car ils y excellaient.

Voici l'idée clé : le développement produit doit être une étape significative de leur parcours professionnel, et non leur finalité. Les meilleurs product owners perçoivent ce rôle comme un moyen d'amplifier leur expertise et d'accroître l'impact organisationnel au-delà de leur domaine traditionnel.

Renforcer l'investissement

La plupart des organisations abordent la sélection du Product Owner en se basant sur la disponibilité des candidats. Or, dans les secteurs public, de la défense et des services d'urgence, notamment lorsqu'un investissement important en argent, en temps et en ressources est consacré à un projet technologique majeur, cette approche superficielle compromet l'ensemble de l'investissement.

Si votre organisation investit des centaines de milliers, voire des millions de dollars, dans une initiative technologique majeure, le rôle de Product Owner mérite une sélection et un accompagnement rigoureux.

L'approche stratégique : Identifiez vos meilleurs candidats et rendez le rôle de Product Owner attractif. Montrez-leur comment la conduite d'une initiative technologique réussie leur permettra de :

• Accroître leur influence au sein de l'organisation

• Développer de nouvelles compétences en technologies et en gestion du changement

• Créer un impact concret qu'ils pourront mettre en avant dans leur évolution de carrière

• Tisser des relations précieuses à tous les niveaux et dans tous les services

En présentant le rôle de Product Owner comme une opportunité de développement professionnel plutôt que comme une simple mission, vous attirerez des candidats plus qualifiés et obtiendrez de meilleurs résultats.

Bénéfice pour l'organisation : Investir dans un excellent Product Owner ne se contente pas d'améliorer votre projet actuel ; cela développe également les compétences internes pour les initiatives technologiques futures et améliore la culture technique au sein de toute l'organisation.

Conclusion

Vos choix technologiques sont importants. Votre approche de développement est importante. Votre budget et votre calendrier sont importants.

Mais rien de tout cela ne permet d'optimiser la valeur sans la bonne personne pour orchestrer le lien entre ce que vous développez et les utilisateurs finaux.

Lorsque vous réalisez des investissements technologiques importants, accordez à la décision concernant le Product Owner l'importance stratégique qu'elle mérite. Le retour sur investissement d'un choix judicieux se déploie à chaque décision ultérieure de votre projet.

Quelle a été votre expérience avec le rôle de Product Owner dans les projets technologiques ? Quels facteurs avez-vous jugés les plus prédictifs de succès ?