Les entreprises ne manquent généralement ni de roadmaps, ni de comités, ni de présentations PowerPoint.
Elles manquent plus souvent d’un système permettant de relier durablement la stratégie, la gouvernance et l’exécution.
C’est particulièrement visible lors de la mise en place d’un PMO, d’une nouvelle gouvernance ou d’un Target Operating Model (TOM).
L’organisation cible est définie.
Les responsabilités sont documentées.
Les instances de décision sont créées.
Les programmes de transformation sont lancés.
Puis vient la réalité opérationnelle.
Les projets sont suivis dans plusieurs outils. Les décisions sont consignées dans des comptes rendus. Les risques remontent parfois tardivement. Les ressources sont difficiles à consolider. Et les équipes produisent de nouveaux reportings pour alimenter chaque comité.
Le problème n’est alors plus de définir le modèle.
Le problème est de le faire fonctionner.
Du Target Operating Model à l’Operating Model
Un Target Operating Model permet de répondre à des questions structurantes :
- Comment voulons-nous fonctionner demain ?
- Quels processus devons-nous transformer ?
- Qui décide de quoi ?
- Quelles responsabilités confier aux différentes équipes ?
- Quels rôles créer ou faire évoluer ?
- Quels indicateurs mesurer ?
- Quelle gouvernance mettre en place ?
Mais décrire une organisation cible ne garantit pas son fonctionnement.
Une matrice RACI dans une présentation ne garantit pas que les responsabilités seront réellement exercées.
Une roadmap ne garantit pas la disponibilité des ressources.
Un COPIL mensuel ne garantit pas l’exécution des décisions.
Et posséder une liste de projets ne signifie pas disposer d’un véritable portefeuille piloté.“
Le passage du Target Operating Model au véritable Operating Model nécessite donc une couche de pilotage.
C’est notamment le rôle du PMO.
Du Project Management Office au Portfolio Management Office
Le PMO est encore parfois assimilé à une fonction de consolidation :
- collecter les statuts ;
- mettre les slides à jour ;
- consolider les plannings ;
- préparer le prochain comité.
Cette approche présente rapidement une limite : le PMO produit du reporting mais ne facilite pas suffisamment la décision.
Un PMO mature doit pouvoir répondre presque immédiatement à des questions beaucoup plus importantes :
- Quels projets contribuent réellement à notre stratégie ?
- Quels programmes sont en risque ?
- Quelles décisions doivent être prises ?
- Où sont nos problèmes de capacité ?
- Quelles dépendances menacent notre roadmap ?
- Quels projets devons-nous accélérer, décaler ou arrêter ?
On passe alors progressivement du Project Management Office à une logique de Portfolio Management Office.
L’enjeu n’est plus uniquement de savoir si chacun des projets est correctement géré.
Il faut savoir si l’ensemble du portefeuille est le bon portefeuille.
Et c’est là que l’outil change de rôle
Monday est fréquemment perçu comme un outil de gestion de tâches.
Mais utilisé à l’échelle d’une organisation, il peut devenir la couche opérationnelle d’un système beaucoup plus large.
La logique peut être représentée ainsi :
STRATÉGIE
↓
TARGET OPERATING MODEL
↓
GOUVERNANCE
↓
PORTFOLIO / PMO
↓
PROGRAMMES
↓
PROJETS
↓
ACTIONS
↓
KPI & DÉCISIONS
Monday permet notamment de consolider plusieurs projets dans une vue portefeuille, de gérer des dépendances entre projets, de suivre la capacité et les ressources et de construire des dashboards transverses.
Mais la puissance de l’outil ne constitue pas le point de départ.
L’erreur : commencer par paramétrer Monday
Lorsqu’une entreprise déploie un nouvel outil, la tentation est forte de commencer par construire des boards.
Nous préférons faire exactement l’inverse.
La première question doit être :
Qu’avons-nous besoin de piloter ?
Puis :
Qui doit voir quoi ?
Et enfin :
Quelles décisions cette information doit-elle permettre de prendre ?
Ce n’est qu’après avoir répondu à ces questions que l’on devrait configurer l’outil.
1. Définir les niveaux de gouvernance
On peut par exemple distinguer quatre niveaux.
Niveau stratégique
CODIR / COMEX
Vision attendue :
- priorités stratégiques ;
- objectifs ;
- portefeuille ;
- investissements ;
- bénéfices ;
- grands risques ;
- arbitrages.
Niveau portefeuille
PMO / Transformation Office
Vision attendue :
- programmes ;
- projets ;
- priorisation ;
- ressources ;
- capacité ;
- budgets ;
- dépendances ;
- risques ;
- décisions.
Niveau programme
Program Managers
Vision attendue :
- jalons ;
- livrables ;
- budget ;
- ressources ;
- risques ;
- dépendances ;
- actions.
Niveau projet
Project Managers et équipes
Vision attendue :
- planning ;
- tâches ;
- responsables ;
- deadlines ;
- livrables ;
- actions quotidiennes.
Le point important est que ces quatre niveaux ne doivent pas produire quatre systèmes d’information différents.
L’information doit pouvoir remonter de l’exécution jusqu’au management sans être reconstruite manuellement à chaque niveau.
2. Transformer plusieurs projets en portefeuille
Prenons l’exemple d’un programme de transformation de l’expérience client.
Il peut regrouper :
- Projet 1 — CRM
- Projet 2 — Parcours digitaux
- Projet 3 — Data et connaissance client
- Projet 4 — Marketing automation
- Projet 5 — Service client
- Projet 6 — Change et formation
Chaque équipe dispose de dizaines ou centaines de tâches.
Mais le CODIR n’a pas besoin de voir tout cela.
Il pourrait simplement disposer d’une vue indiquant :
- 6 projets actifs
- 2 projets en risque
- 1 arbitrage budgétaire attendu
- 3 dépendances critiques
- 85 % des jalons respectés
- Capacité Data : 110 %
- Prochain jalon stratégique : 30 septembre
C’est là que se situe la valeur du Portfolio Management.
Il transforme des centaines d’informations opérationnelles en quelques informations permettant de décider.
3. Faire de la gouvernance un processus
Une gouvernance est encore souvent assimilée à un calendrier de réunions :
COPROJ.
COPIL.
CODIR.
COMEX.
Pourtant, ajouter des réunions ne crée pas nécessairement de gouvernance.
La gouvernance doit être conçue comme une boucle continue :
Donnée → Analyse → Décision → Action → Suivi → Nouvelle donnée
Avant un COPIL, les informations devraient être à jour automatiquement.
Les risques dépassant un certain niveau devraient remonter.
Les décisions à prendre devraient être identifiées.
Pendant le comité, la décision devrait être enregistrée.
Après le comité, cette décision devrait générer une action, un responsable et une échéance.
Puis son exécution devrait être suivie.
L’outil permet ainsi de passer d’une gouvernance fondée sur des comptes rendus à une gouvernance fondée sur des décisions et des actions.
4. Relier les risques aux décisions
La couleur rouge d’un projet n’a aucune valeur si elle ne produit aucune conséquence.
Un modèle de gouvernance mature doit définir ce qui déclenche une escalade.
Par exemple :
Budget > +10 %
→ remontée PMO.
Jalon stratégique > 15 jours de retard
→ arbitrage programme.
Ressource critique > 110 % de capacité
→ décision Portfolio.
Risque critique
→ remontée COPIL.
Le dashboard ne devient alors plus uniquement un outil de visualisation.
Il devient une partie du système de gouvernance.
5. Intégrer réellement la capacité
C’est souvent l’un des angles morts des roadmaps.
Sur PowerPoint, quatre projets peuvent parfaitement commencer au mois d’octobre.
Dans la réalité, ils ont parfois tous besoin des mêmes deux architectes, des mêmes experts Data ou du même responsable métier.
Le portefeuille doit donc rapprocher :
demande projets ↔ capacité disponible
et permettre d’arbitrer.
La question n’est plus :
« Peut-on réaliser ce projet ? »
mais :
« Parmi tous les projets que nous pourrions réaliser, lesquels devons-nous réellement lancer maintenant ? »
Cette nuance est fondamentale.
6. Et cela ne concerne pas uniquement l’IT
Prenons une direction marketing.
Son portefeuille peut comprendre :
- campagnes d’acquisition ;
- CRM ;
- contenus ;
- social media ;
- événements ;
- nouveaux sites ;
- lancements produits ;
- opérations commerciales ;
- projets Data ;
- campagnes média.
Ces actions sont souvent gérées dans plusieurs plannings.
Le Portfolio Management permet au contraire de rattacher chaque initiative à :
un objectif
→ une cible
→ un budget
→ un responsable
→ des ressources
→ un calendrier
→ des KPI
Une direction marketing peut alors répondre beaucoup plus facilement à une question pourtant simple :
Que faisons-nous réellement cette année pour atteindre chacun de nos objectifs ?
Et surtout :
Avons-nous mis nos budgets et nos ressources sur les bonnes priorités ?
7. Le TOM peut lui-même être piloté
L’intérêt va encore plus loin dans le cadre d’une transformation d’organisation.
Un Target Operating Model définit généralement plusieurs dimensions :
- Organisation
- Processus
- Gouvernance
- Compétences
- Technologies
- Data
- KPI
Chacune peut être traduite en chantiers de transformation.
Par exemple :
TOM cible
↓
8 capacités à transformer
↓
15 chantiers
↓
35 projets
↓
120 jalons
↓
400 actions
Le TOM cesse alors d’être uniquement une représentation de l’organisation cible.
Il devient une trajectoire mesurable de transformation vers cette cible.
La logique que nous privilégions
L’ordre est essentiel.
1 — Stratégie
Que voulons-nous atteindre ?
2 — Target Operating Model
Comment devons-nous fonctionner pour y parvenir ?
3 — Gouvernance
Qui décide ? Qui arbitre ? Selon quelles règles ?
4 — Portfolio / PMO
Quelles initiatives devons-nous piloter et prioriser ?
5 — Monday
Comment industrialiser et rendre visible ce modèle ?
6 — Exécution
Comment permettre aux équipes d’agir sans produire parallèlement un système lourd de reporting ?
L’outil intervient donc en cinquième position et non en première.
C’est probablement l’un des principaux facteurs de réussite.
Les cinq conditions d’un modèle efficace
Un langage commun
Projet, programme, risque, jalon, bénéfice ou décision doivent avoir la même signification pour tous.
Une donnée saisie une seule fois
Le reporting ne doit pas devenir une activité parallèle au projet.
Une information adaptée à chaque rôle
Un membre du COMEX, un PMO et un chef de projet n’ont pas besoin de la même granularité.
Des règles d’escalade
Un problème détecté doit provoquer une action ou une décision.
Une gouvernance de l’outil lui-même
Templates, droits, référentiels, automatisations et règles d’utilisation doivent être maîtrisés.
Sans cela, un outil extrêmement flexible peut finir par reproduire exactement le désordre qu’il devait supprimer.
Passer du PowerPoint au pilotage
Le véritable enjeu n’est finalement pas de déployer Monday.
Il consiste à construire un système dans lequel :
- la stratégie fixe les priorités ;
- le TOM définit le fonctionnement cible ;
- la gouvernance organise la décision ;
- le PMO pilote le portefeuille ;
- Monday industrialise le modèle ;
- les équipes alimentent naturellement le pilotage en exécutant leur travail.
Chez L’AGENT X, nous abordons donc ces projets en partant du modèle de fonctionnement :
cadrage du TOM → définition de la gouvernance → conception du PMO et des KPI → modélisation des workflows → configuration et déploiement de la plateforme.
Parce qu’un outil ne remplacera jamais une bonne gouvernance.
Mais une bonne gouvernance mérite un outil qui lui permette réellement de fonctionner.
Vous souhaitez structurer votre pilotage avec Monday ?
Nous pouvons vous accompagner dans la définition de votre modèle de gouvernance, la structuration de votre portefeuille de projets et la mise en place d’un dispositif de pilotage adapté à vos enjeux.