Mode projet à un mode Produit : comment accompagner la transition?

Dans les transformations d’entreprises d’un mode projet à un mode Produit, plus on remonte la chaîne de décision et les interactions entre les métiers et l’IT, plus le niveau de complexité devient difficile à gérer. Comment transformer les instances de gouvernance validant le lancement des projets ainsi que toute la partie amont de la conception, à savoir l’émergence des projets, leur cadrage et leur estimation, avant la maturation et le raffinement par les équipes IT de réalisation. Nous souhaitons partager avec vous une expérience vécue à partir d’un cas client. Nous pensons que cette expérience fait écho à de nombreuses problématiques rencontrées dans des entreprises similaires.

Transformer la gouvernance et la conception 

Nous avons commencé notre mission à un moment où l’entreprise avait déjà entamé sa transformation. Les équipes de réalisation étaient organisées en agile et se coordonnaient entre elles à travers des trains (modèle SAFe). Les rôles agiles et produit étaient en place, aussi bien au niveau des équipes (PO, Scrum Master, développeurs) que des trains (Product Manager, RTE, architectes). Un troisième étage transverse avait été créé, une Large Solution, également sur le modèle SAFe, avec les rôles préconisés par le modèle et des rôles transverses, dont l’objectif était de coordonner les trains sur la réalisation des projets transverses. 

Cependant, toute la partie amont de conception, d’expression des besoins, d’estimation budgétaire et, particulièrement, la gouvernance et le pilotage étaient restés en mode projet, cycle en V et gouvernance de programme. 

Mode projet à un mode Produit : à la croisée de 2 mondes

Nous avions deux mondes avec des modes de fonctionnement différents, auxquels s’ajoutaient deux échelles de temps différentes : les équipes agiles étaient organisées en sprints et en engagements trimestriels (PI), tandis que les métiers n’avaient pas de contrainte temporelle fixe. Chaque direction métier avait son propre rythme, qui ne s’inscrivait pas dans les cycles de développement. 

Tous les acteurs situés à l’entrelacs des deux mondes étaient dans des postures et situations potentiellement conflictuelles. Parallèlement, les équipes agiles de réalisation ne comprenaient pas ou plus les orientations, le sens des évolutions demandées. Les équipes se sentaient purement exécutantes. Elles ne comprenaient pas leur lien avec la stratégie. 

Partant de ce constat, comment transformer la partie amont et la faire basculer davantage d’un mode projet à un mode Produit ? Pour ce défi, aucun cadre de travail ne décrit par le menu les actions à mettre en œuvre. Nous nous sommes davantage basés sur l’application des principes et valeurs lean, agile et design, afin de trouver des solutions pragmatiques et applicables. 

Voici les axes sur lesquels nous avons décidé de nous concentrer : 

• L’amélioration du flux 
  
• La clarification des rôles dans la conception et un cadrage centré utilisateurs 
  
• Le désilotage des acteurs en les orientant davantage vers la chaîne de valeur utilisateurs plutôt que vers leurs directions 

L’amélioration du flux 

Les deux mondes ayant des fonctionnements différents, la jonction entre leurs deux flux de travail était évidemment marquée par de nombreuses ruptures : 

• D’un côté, des équipes agiles en sprints et engagements trimestriels. Elles avaient une cadence établie, des jalons de préparation et de planification, mais qui recevaient de nouveaux besoins sans processus établi et, d’un autre côté, des métiers non acculturés aux pratiques en place sans point d’entrée identifié. 
  
• De l’autre, des équipes métiers sur leur propre échelle de temps, habituées à avoir des équipes projet dédiées et une approche en cycle en V, où chaque projet définissait son tempo. 

La première action que nous avons initiée est un point d’entrée unique pour tous les besoins pouvant impacter une ou plusieurs équipes agiles de la Large Solution au travers d’une cérémonie de présentation dédiée. Les différents métiers demandeurs étaient systématiquement réorientés vers cette cérémonie. Dans un second temps, nous avons établi les processus de cette cérémonie avec un livrable commun permettant de pouvoir décrire le besoin, la valeur attendue et la temporalité souhaitée (démarrage des développements et livraison souhaités). 

Une fois le flux des nouveaux besoins maîtrisé, nous avons pu travailler sur la formalisation et le suivi d’une roadmap globale. Ainsi que sur la définition et la visualisation des étapes nécessaires à la vie du besoin : 

• Le cadrage (ou l’analyse) 
  
• La priorisation pour entrée en maturation 
  
• La maturation (ou le refinement) 
  
• La priorisation pour planification de réalisation 
  
• La réalisation (ou le développement, test, mise en production/service) 

Ces étapes nous ont permis de pouvoir établir nos processus au niveau de la Large Solution afin de pouvoir lier la demande avec l’exécution et la capacité à faire des équipes. Nous avons également pu ainsi acculturer et intégrer nos métiers dans notre mode de fonctionnement et notamment la préparation et la participation aux PI Planning. 

Conception : clarifier les rôles et mettre en oeuvre un cadrage centré utilisateurs

Très liée à l’absence de processus d’avancement du besoin clair et partagé, la seconde problématique concernait la répartition des rôles et responsabilités dans la conception et la gestion du besoin. 

Clarifier les rôles, décrire les fonctions

L’entreprise avait détaillé des rôles de Product Managers au niveau des collectifs de réalisation (trains) et des Product Owners au niveau des équipes. Leurs rôles et responsabilités avaient été décrits par l’entreprise dans des fiches de poste. Cependant, les autres rôles d’une organisation produit étaient balbutiants. Les parties prenantes principales de chaque produit n’étaient pas clairement désignées. Il n’y avait pas de Business Owners, à savoir des représentants d’entité Business, d’une gamme commerciale ou d’une compétence métier spécifique, dont le rôle pourrait être de travailler en étroite relation avec les Product Managers. 

À l’inverse, pour chaque expression de besoin majeur, un chef de projet était nommé, qui n’était ni un expert de la demande, ni du parcours utilisateurs, mais plutôt un chargé d’administration et de rédaction des livrables de jalons projets. Chaque demande d’évolution passait ainsi par une comitologie et des livrables particulièrement longs et chronophages. Surtout, les chefs de projets métiers allaient et venaient, et ne développaient pas une expertise autour des problématiques clients qu’ils pouvaient rencontrer durant leur projet. 

Des individus avaient pourtant un rôle émergent pérenne auprès des équipes chargées du produit, parfois appelé “Product Manager métier”, ou encore “Chef de projet permanent”, ou “Expert métier à temps plein”. La difficulté de l’entreprise à donner un qualificatif décrivant objectivement leur fonction était symptomatique d’une transition du mode projet vers le mode produit qui n’avait pas encore été intégrée jusqu’au référentiel des fonctions RH. 

Notre priorité a ici été de décrire les fonctions et activités d’un Business Owner intégré aux trains, la répartition de ce rôle par rapport aux Product Managers. Leur participation aux bonnes instances de cadrage des besoins, de priorisation et d’élaboration des roadmaps a permis d’incarner cette collaboration. 

Le chantier le plus long terme a été de décrire les activités et responsabilités de ces rôles, leur classification en termes de grille salariale, en collaboration avec les RH et l’organisation hiérarchique, afin de faire évoluer le référentiel de fiches de poste dans l’entreprise. Les RH et les managers ont ainsi pu mieux identifier les personnes occupant déjà en partie ces fonctions et de mener l’étude d’impact de leur évolution de poste, voire de direction. Ces travaux sont les plus longs et les plus profonds en termes d’implication et de transformation. Ils touchent au cœur même des métiers et de l’organisation de l’entreprise. 

 Mode projet à un mode produit : inscrire le Design

Les UX et UI étaient les autres rôles mal reconnus dans l’organisation. La problématique était ici différente. Leurs rôles et activités étaient bien décrits au niveau RH. Les personnes étaient déjà présentes, exerçaient et maîtrisaient les compétences requises. Ils étaient cependant mal intégrés dans le processus de vie du besoin. Intervenant en général en bout de chaîne au moment de la conception des écrans, ils ne participaient pas à la définition des parcours utilisateurs généraux. 

Notre accompagnement du mode projet au mode produit a mis l’accent sur leur intervention dès le début de la chaîne d’expression et de cadrage des besoins. L’évolution de leur rôle est aussi allée vers une plus forte spécialisation et distinction entre les rôles d’UX – davantage sur les parcours et expériences transverses (cross-applicatives) clients -, et les UI – davantage sur des parcours au sein d’une application et le détail des écrans. Une meilleure (re)connaissance de la valeur ajoutée des UX en début de cadrage des projets a permis de mieux dimensionner les ressources. Cela a inscrit le Design dans des interventions à l’échelle, directement au sein des équipes mixtes IT et métier. 

Cette clarification des rôles a permis de mieux faire travailler les différents acteurs, particulièrement dans la phase cruciale de la conception et du cadrage. 

Pour chaque nouveau sujet entrant dans l’entonnoir de présentation des besoins, un trinôme de cadrage, composé de PM ou PO, d’UX et d’architectes, était nommé. Ce trinôme travaillait de façon étroite avec le ou les Business Owners et autres représentants des utilisateurs, afin de proposer un découpage des grands projets par la valeur, et selon l’évolution des parcours utilisateurs. 

Cette collaboration et ce temps supplémentaire passé entre acteurs en conception amont a permis de réellement découper des MVP et des lots en stratégie incrémentale centrée sur les utilisateurs. La visualisation des parcours utilisateurs et des évolutions possibles permettait un meilleur alignement entre les différentes parties prenantes, et diminuait d’autant la documentation purement administrative d’avancement de jalons projets. Enfin, des grands projets découpés en plus petits lots étaient plus aisément priorisables les uns par rapport aux autres. 

Désiloter les portefeuilles afin de connecter la stratégie et l’exécution 

En plus de pouvoir identifier les acteurs majeurs, clarifier leurs rôles et améliorer le flux du travail, il nous a semblé que cela n’aurait de réelle valeur qu’en donnant du sens : que chacun trouve sa place dans cet écosystème et puisse lier la stratégie à l’exécution. 

Notre troisième challenge était de faire évoluer les instances stratégiques de validation budgétaire, les portefeuilles. Nous avions des responsables de portefeuille qui chacun avaient des ambitions et des priorités mais qui travaillaient en silos. Afin de casser ces silos, nous avons amélioré une instance déjà existante, qui réunissait les différents portefeuilles afin d’y partager et revoir la roadmap globale et discuter des priorités. 

Cette instance a été calée sur les jalons des équipes agiles (trimestre de réalisation, ou PI) et non plus sur les prévisions budgétaires. Nos objectifs étaient de : 

• Donner la légitimité et l’empowerment à cette instance, pour la rendre ultime arbitre par rapport à la galaxie de comitologie de suivi de programmes. 
  
• Apporter de la transparence entre tous les acteurs, en rendant visible l’ensemble des demandes émanant des différents portefeuilles et des programmes majeurs à chaque trimestre. Avec le temps, nous avons aussi détaillé pour chacune leur niveau de maturité dans le cadrage, le découpage et la maturation du besoin. Enfin, l’ensemble des besoins estimés et cadrés étaient mis face à la capacité à faire des équipes pour priorisation. 
  
• Échanger objectivement avec les responsables de portefeuilles et des directions de programmes afin d’établir les priorités, à chaque trimestre, et les contraintes de calendrier. Pour arriver à cela, nous avons conservé l’affichage de deux calendriers : le calendrier annuel traditionnel et le calendrier des PI afin de pouvoir lier les ambitions avec les jalons des équipes de réalisation. 
  

En complément, nous avons proposé de mettre en place un top 10 des priorités par trimestre. Ce top 10 a permis de clarifier la vision en liant les initiatives majeures avec la stratégie de l’entreprise et ainsi aider les équipes agiles à comprendre quelle initiative doit démarrer avant une autre. 

Enfin, nous avons travaillé à revoir et clarifier l’instance de gouvernance en y intégrant nos Business Owners et les leads de chaque train. Cette instance est devenue la référence et nous a permis de supprimer ou diminuer les autres comités en silos. Chaque acteur connaissait son rôle et nous avions une instance dédiée pour discuter et prendre des décisions liées à la gouvernance. 

Du mode projet au mode produit : ambitions et résultats

Ces différentes actions ont été étalées dans le temps et nous ont permis d’agir sur la transformation globale. Quand nous faisons le bilan des succès après 18 mois d’accompagnement, nous pouvons noter que nos actions ont permis d’éclaircir la vision, en liant la stratégie à l’exécution, de limiter les travaux en cours (WIP) grâce au Top 10, de mieux prioriser et de se concentrer sur les initiatives avec le plus de valeur. 

Plutôt que de nous concentrer sur la méthode ou un framework et être dogmatique, nous avons souhaité nous concentrer sur les principes que nous souhaitions véhiculer, de donner du sens et un rythme commun à tous les acteurs. 

Nous avons particulièrement gardé en tête dans toutes nos actions l’idée de pouvoir mettre en place une pensée systémique, d’améliorer le flux de façon continue en nous concentrant sur la valeur pour l’entreprise et pour les utilisateurs, d’améliorer et donner de la visibilité et de la compréhension sur la cadence et de pouvoir se synchroniser au bon moment et avec les bonnes personnes. 

L’entreprise continue sa transformation et garde le cap en ayant pérennisé les actions mises en place. 

Christelle Boulan, Camille Placier, Consultants Inspearit