Focus Projet.
Bienvenue sur Focus Projet,
le podcast du management de projet.
Le management de projet,
qu'est-ce que c'est ?
Ça va être les différentes techniques et outils qui vont nous permettre de mener à bien nos projets.
Planning,
coût,
risque,
gestion d'équipe,
changement,
communication,
définition du besoin.
Au fil des épisodes,
on va voir tout cela ensemble.
Alors que tu sois le directeur de projet de la prochaine Gigafactory ou que tu te retrouves à t'occuper des projets de ton entreprise en plus de ton travail,
abonne-toi.
Ce podcast va simplifier la réussite de tes projets.
Lorsqu'on mène un projet,
on recueille beaucoup d'informations de tout type sur le projet et sa gestion.
Toutes ces données s'accumulent ou se perdent en fonction de l'attention qu'on va leur porter et le soin qu'on va prendre à les traiter.
Au plus les projets vont être conséquents et complexes,
au plus l'accumulation de données va être importante.
Apparaît alors le Data Monster,
une masse d'informations qu'il est nécessaire de maîtriser.
Pour maximiser la performance des projets,
il est important de reprendre la main sur la donnée et arriver à s'en servir efficacement pour piloter le projet.
Pour vous aider dans cette tâche,
je reçois non pas une,
mais trois personnes aujourd'hui.
Alexis Farfaro,
Bastien Ferrier et Julien Laurent.
Bonjour !
Comment ça va ?
Bonjour.
Super.
Très bien,
merci.
Vous pouvez peut-être commencer à vous présenter tous les trois ?
Dans l'ordre dans lequel tu nous as cités,
Tanguy,
je vais me lancer.
Moi,
ça fait 20 ans que je suis chez MIGSO-PCUBED.
C'est un cabinet de conseil spécialisé en PMO,
avec plus de 3000 collaborateurs et une implantation dans 15 pays.
J'ai le plaisir de travailler avec Bastien et Julien à notre plateforme,
Cleverest,
qui dote les PMO d'un véritable outil de pilotage.
Pour cela,
on utilise toutes les nouvelles technologies qui sont à notre disposition aujourd'hui.
Moi,
c'est Bastien Ferrier.
Je suis
CPO, directeur produit pour Cleverest.
Effectivement,
ce qui nous rassemble avec Julien et Alexis,
c'est
MIGS OPQ,
donc
Société de Consulting dans la gestion de projets.
J'ai un gros background dans la gestion de projets et surtout,
j'ai vécu pas mal de problématiques et notamment autour de la donnée projet,
ce qui est le thème de ce podcast,
bien travailler à piloter nos projets grâce à leurs données.
Bonjour à tous,
du coup moi c'est Julien Laurent,
donc pareil ça fait à peu près
15 ans que je travaille dans la gestion de projet.
Donc j'ai une double casquette,
gestion de projet et data,
donc digital.
Et du coup moi j'ai toujours travaillé dans le setup de mission,
donc lié à la gestion de projet et la création d'outils de gestion et de contrôle de projet.
Et actuellement du coup je suis
CTO, donc le directeur technique de Cleverest.
Très bien.
Dans l'introduction,
j'ai repris un terme que j'ai trouvé assez visuel et que j'aime bien,
le data monster.
L'un de vous peut expliquer,
ou plusieurs d'entre vous peuvent expliquer ce que vous entendez par ce terme dans le contexte des projets ?
Oui,
en effet,
le data monster,
c'est le monstre digital.
C'est une bête un peu difforme qui grandit dans toutes les organisations de manière assez organique et bien sûr totalement bien intentionnée au fil du temps.
Mais le data monster,
en fait,
il a pour effet que...
Il comporte un certain nombre de symptômes reconnaissables.
Je vais en citer quelques-uns simplement pour garder les choses simples,
mais je pense que tout le monde va se reconnaître dans ces exemples,
des exemples de saisie ou de ressaisie manuelle d'information dans des systèmes qui sont experts mais en silo,
de la gouvernance de la donnée qui est un peu méconnue ou parfois pas codifiée du tout,
et donc du coup qui ouvre la porte à des voies de contournement acceptées par tous dans Excel ou dans PowerPoint.
ou encore une désorganisation qui en résulte et qui veut dire que la qualité est insuffisante,
la qualité de cette donnée,
et fait perdre énormément de temps aux acteurs du projet.
Donc c'est ça le data monster.
Il n'y a pas à en rougir,
je pense que c'est un phénomène universel,
mais son enjeu est assez fort puisqu'il génère énormément d'inefficacité au niveau des entreprises.
Tu as un peu établi pourquoi la donnée était importante ?
et les impacts qu'elle peut avoir ?
Pourquoi c'est quelque chose qui est critique aujourd'hui dans le management d'un projet d'une manière générale ?
En fait,
la révolution digitale que l'on vit,
la fameuse troisième révolution,
elle est à double tranchant.
Elle peut servir de moteur de croissance et libérer la compétitivité des entreprises,
c'est ce qu'on espère tous,
mais à l'inverse,
elle peut devenir un bloqueur.
Et ça,
on en parle assez peu.
Et ce bloqueur,
il suffoque les projets,
il ralentit et démotive les collaborateurs qui y travaillent.
Et c'est ça les effets du data monster au final.
Et quand on parle de la maîtrise et du pilotage de projets spécifiquement,
ce à quoi nous faisons face,
c'est toujours le même constat.
C'est qu'il y a la moitié,
50%
du temps des professionnels en charge de la maîtrise des projets qui passent dans du traitement de données.
Ça,
c'est colossal,
en fait.
Et on ne parle même pas d'analyse,
on parle de traitement.
Ces acteurs disposent d'une multitude d'outils,
de reporting à destination de la direction,
mais pas vraiment d'outils de pilotage.
Donc ça,
c'est l'un des constats.
Et donc,
du coup,
l'enjeu...
pour la gestion de projet.
Le premier,
c'est cette capacité à sécuriser les objectifs de nos projets et par conséquent,
la compétitivité de nos acteurs économiques.
Donc,
libérer du temps des acteurs projets,
c'est un enjeu de performance économique.
Et le second enjeu,
c'est les bienfaits attendus de l'IA.
Tout le monde en parle,
et surtout quand on veut de l'IA prédictif ou de l'IA prescriptif,
c'est-à-dire celui qui donne des conseils,
ce qu'il faut,
c'est dompter le data monster d'abord.
Et pour le dompter,
il y a aussi quelque chose d'extrêmement important à comprendre,
c'est qu'il ne faut pas punir les humains qui le nourrissaient jusqu'alors en leur demandant de mettre encore plus de leur temps dans la saisie de données bien structurées.
Ce qu'il faut faire,
c'est leur donner de la valeur en échange du travail qu'ils passent à dompter le data monster et on pourra discuter de comment ça doit pouvoir s'opérer.
Et ce qui est paradoxal aussi dans le monde dans lequel on vit et son évolution,
c'est qu'on se rend compte que...
Il y a eu énormément d'évolutions,
notamment sur la donnée personnelle.
Par contre,
quand on regarde les données plutôt à caractère industriel ou du monde professionnel,
on voit aujourd'hui un manque,
et notamment dans le monde de la gestion de projet,
où on est aujourd'hui en capacité de traiter des volumes de données personnelles immenses avec énormément de solutions derrière et d'en exploiter leur richesse.
Ce qui est aujourd'hui moins le cas dans un monde professionnel.
C'est là où,
effectivement,
on vient un peu caractériser ce data monster.
On connaît tous ce problème-là.
On parle plutôt souvent de gouvernance de la donnée pour essayer de faire avancer les choses.
La réalité,
c'est qu'il y a quand même quelque chose de symptomatique qui est qu'on a du mal à comprendre pourquoi cette donnée-là,
on n'arrive pas à bien l'exploiter,
bien l'utiliser dans les organisations.
La caricature du data monster,
ça permet aussi d'exacerber ces problématiques-là dans le monde de l'entreprise.
De manière générale,
on parle beaucoup de données des projets.
Pour peut-être nos auditeurs qui ont peut-être un peu moins l'idée d'où elle vient et de comment,
à quoi ça correspond concrètement,
vous pouvez donner des exemples ou dire à quoi toutes ces données correspondent.
On a principalement des données opérationnelles,
qui proviennent des logiciels ERP ou SRM,
ou aussi bien sûr de nos outils de gestion de projet,
comme Planisware,
Primavera,
Microsoft Project.
On a aussi beaucoup de données qui proviennent de fichiers locaux,
comme les Excel,
les PowerPoints,
ou même des images qui sont réalisées en workshop,
en brainstorming.
On a aussi des données financières,
des données RH,
logistiques.
On a aussi des données liées à la production,
donc dans certains types de produits.
Elles peuvent aussi provenir de certaines parties externes,
de nos fournisseurs,
nos sous-traitants,
nos clients.
Et du coup,
tout cet amas de données,
c'est tout ce qui représente,
tout ce qui est pertinent.
pour nous pour le suivi et le contrôle des projets et donc du coup pour réaliser les synthèses des budgets travailler sur les délais l'avancement de nos projets à identifier les risques et mettre en place la panoplie de capia donc les qui performance indicateurs qui nous permettent de contrôler au mieux la
vie de nos projets pour peut-être un peu synthétisé ça et tout ce qui va être lié au planning au budget
au risque,
peut-être les comptes rendus de réunion aussi,
tous ces éléments-là qui ne sont pas forcément structurés et dans des formats de données intercompatibles.
Ce qui est vrai,
c'est que quand on parle de données projet,
souvent on considère la donnée projet dans les différentes disciplines,
la gestion de projet,
planification,
gestion des risques,
gestion des coûts,
du budget,
etc.
Et on se rend compte qu'il y a beaucoup plus.
de données au sein des projets qui vont être importantes dans la gestion de projet.
Julien en citait pas mal sur d'autres métiers,
si on parle de logistique,
de production,
de RH,
mais au final la donnée RH est importante quand on parle par exemple de planification ou de gestion des coûts.
Et puis tout ce qui est un peu moins structuré,
prise de décision,
gestion des actions,
les comptes rendus de réunion,
etc.
C'est autant de données qui ont une importance au sein du projet.
et qui sont parfois un peu moins regardés,
mais qui vont pour autant aider au pilotage du projet.
Et donc voilà,
ça fait énormément de volume de données,
et c'est au final très complexe de gérer toutes ces données-là pour en ressortir quelque chose d'intéressant au sens du pilotage et de la maîtrise des projets.
On voit que cela peut faire rapidement beaucoup d'informations à traiter.
Comment s'assurer de la fiabilité et de la pertinence des données que l'on va collecter du coup ?
Souvent,
c'est assez simple d'accéder à la donnée,
même si elle n'est pas dans le bon format,
mais le plus compliqué,
c'est de valider que la donnée qu'on récupère est vraiment officielle et on peut l'exploiter pour générer nos analyses.
Je pense que,
avant même de récupérer de la donnée,
il faut arriver à identifier clairement quels sont les propriétaires de chaque set de données et de mettre en place certains mécanismes de contrôle qui nous permettent de s'assurer que...
cette donnée a bien été validée ?
Pour quelle période ?
Surtout en termes de data quality,
est-ce que la donnée qui est récupérée est cohérente ?
Du coup,
c'est s'assurer de la fiabilité de la donnée,
d'une certaine manière,
que ce ne soit pas un bruit de couloir et que ce soit bien une décision qui a été prise officiellement,
et de la pertinence,
parce que ça ne sert à rien d'accumuler trop de données si elles ne sont pas utiles pour l'analyse qu'on veut faire derrière.
C'est bien ça ?
C'est ça.
Il y a aussi un autre niveau que je vois,
c'est lorsque,
par exemple,
on doit venir en réunion de travail,
donc on va sortir des sets de données qui ont été officialisés,
bien sûr,
on va travailler avec,
mais potentiellement,
ce set de données ne peut pas être encore communiqué.
Avant d'exploiter un set de données ou une visualisation,
on doit quand même aussi s'assurer que ce qu'on va afficher ou partager a été validé sur chaque niveau.
C'est-à-dire au niveau de l'équipe projet,
peut-être au niveau des décisionnaires,
etc.
Lorsqu'on communique à nos investisseurs ou à nos fournisseurs,
en haut ou en bas,
il faut s'assurer que tout a été validé avant de partager ces informations.
C'est un peu ce que tu viens d'évoquer.
Quels vont être les risques du coup si on a des données qui ne sont pas de bonne qualité ou qui ne sont pas validées pour la gestion du projet ou pour la communication d'une manière générale ?
La donnée reste importante parce qu'en fait,
derrière une donnée,
c'est une information.
Aujourd'hui,
on parle beaucoup d'intelligence artificielle,
mais la réalité,
c'est que notre objectif,
ça va être de prendre une donnée,
la transformer en information et puis,
le plus possible,
la transformer en connaissances.
Et là,
on commence à rentrer dans les...
logiques de machine learning,
intelligence artificielle,
etc.
Si déjà on reste au niveau de la donnée,
cette donnée va nous permettre d'avoir de l'information pour piloter notre projet.
Et à partir du moment où la donnée est fausse,
on aura beaucoup plus de mal à piloter,
voire clair sur notre projet,
et donc du coup atteindre les objectifs.
La réalité,
c'est qu'un projet existe pour atteindre un résultat,
et si cette donnée est mauvaise,
on aura du mal à piloter,
c'est-à-dire tenir l'objectif de réaliser notre produit dans les temps.
au budget associé,
et donc tout ça,
ça reste ce fameux triptyque sur lequel on essaie d'avoir un projet qui est en succès.
Sur la notion de contrôle de projet,
c'est la donnée qui vient nous aider à y voir clair et donc savoir si on tient notre planning,
si on tient notre budget et surtout comment on vient gérer la performance de notre projet.
Si la donnée est de mauvaise qualité,
potentiellement,
on n'y voit pas clair ou pas les bonnes choses et donc on prend les mauvaises décisions et potentiellement on s'écarte de l'atteinte de l'objectif.
Voilà la donnée aujourd'hui.
C'est quand même quelque chose de crucial.
Et le point de départ avant même d'être capable de mettre en place toute une structure de contrôle de projet,
c'est de s'assurer que cette donnée est bien collectée,
bien structurée,
de qualité,
pour ensuite être capable de l'opérer.
Un conseil peut-être pour faciliter ça ?
On a nous plutôt tendance à essayer de s'appuyer sur des standards,
parce qu'on va aller chercher des sources de données un peu différentes.
En réalité,
quand on parle de gestion de projet,
on parle des mêmes disciplines de projets et donc souvent des mêmes typologies de données.
Si on parle d'un planning,
on va toujours retrouver les mêmes informations,
en tout cas la même structure de données dans les plannings.
Pareil sur des registres de risque,
sur des gestions de coûts,
de budget,
sur une liste de ressources,
etc.
Le contenu en sera différent puisqu'on ne parle pas des mêmes projets,
des mêmes entreprises,
organisations.
Ces sources de données,
il va falloir qu'on arrive à y trouver un standard pour qu'on puisse les exploiter correctement.
Et donc typiquement,
plus on vient travailler sur des projets,
À grande dimension,
plus c'est complexe.
Un projet qui a beaucoup de parties prenantes,
beaucoup de fournisseurs,
doit quand même être capable de consolider un planning global avec potentiellement des sources de données qui vont être différentes.
Comment on fait pour avoir un standard qui nous permet de faire ça assez facilement ?
Donc en mettant un standard en place,
on résout les problèmes de structure de données.
Il y a d'autres obstacles à surmonter ?
La problématique qu'on a,
c'est lorsqu'on joue avec un seul set de données qui correspond à un domaine,
c'est assez facile de réaliser des analyses dessus.
Lorsqu'on commence à travailler avec des multiples sources de données qui correspondent à des domaines différents,
là,
ça va devenir un peu plus compliqué.
Donc lorsqu'on va vouloir lier des actions à des risques,
des risques à des schedules,
des schedules à de la workload,
la workload à des coûts,
etc.,
là,
on commence à rentrer dans de la complexité d'architecture de données.
Et du coup,
au final,
on a besoin d'une clé.
Et cette clé,
souvent,
elle correspond à la structure de nos projets,
ce qu'on appelle WBS,
World Vision Structure,
ou potentiellement ça peut être une autre structure de projet,
comme la CBS ou l'OBS.
Quand on travaille dans des grandes entreprises,
souvent on a des départements qui travaillent pour les coûts,
on a des départements qui travaillent pour les risques,
pour le schedule.
Et en fait,
toutes ces données,
elles ne parlent pas forcément entre eux.
Et du coup,
nous,
notre objectif aussi,
c'est d'arriver à créer cette clé qui sera capable de récupérer toutes ces données dans certains formats.
d'arriver à créer ce standard,
et ce standard doit être capable de faire parler les données entre ces différents domaines de la gestion de projet.
Et ça c'est un point important sur la gouvernance de la donnée du coup,
parce qu'on parle souvent de gouvernance dans ses process,
qui est au-delà de quelles données et comment il va la propager,
mais quels sont les points d'interface.
Donc dans la gouvernance de la donnée,
il y a ces notions-là,
il y a une clé qui permet de faire parler ces données-là,
et si sans,
on n'arrive pas à la garantir et notamment garantir son intégrité,
on risque d'avoir des problématiques sur l'ensemble de la gestion de projet.
Globalement,
chaque discipline,
en tant que silo va bien fonctionner,
l'ensemble aura du mal à fonctionner.
Si je comprends bien,
c'est ce point-là qui va être clé pour arriver à exploiter les données facilement,
à faire en sorte qu'on puisse matcher des données de planning avec des données de ressources,
de coûts et de risques,
d'une certaine manière.
Exactement.
Et c'est vrai que dans la question de projet,
c'est assez théorisé.
Néanmoins,
on le voit souvent dans le monde de l'entreprise,
on a quand même du mal à avoir des standards définis,
quand bien même on fait tous la même chose.
on fait tous des plannings,
tous des budgets,
tous des registres de risques,
on aura du mal à trouver un standard appliqué à peu près partout.
C'est peut-être ce qui nous manque,
mais en tout cas,
avant d'essayer de l'appliquer partout,
on essaie d'avoir une solution qui permet à n'importe qui d'arriver à travailler sur certains standards pour rassembler des données qui sont les mêmes sur des structures différentes.
Du coup,
là,
on est plutôt sur l'exploitation de différents types de données ensemble,
mais je suppose que le problème se pose aussi pour un même type de données avec plusieurs sources potentielles,
comme,
je ne sais pas,
le planning avec différents fournisseurs qui vont avoir des plannings dont la structure ne va pas forcément être cohérente entre eux et simple à exploiter.
Du coup,
vous avez des conseils,
des choses à mettre en place pour cela ?
Oui.
C'est clair.
Typiquement,
si on prend l'exemple d'un client et un fournisseur qui travaillent sur le même projet,
déjà ce qui est certain,
c'est qu'il y a peu de chances qu'ils partagent un code projet.
Et c'est peut-être ce code projet qui est important déjà pour savoir que cette donnée appartient à ce projet-là.
Et ce code projet,
il doit être un identifiant unique qui est reconnaissable au sein du même projet parce que c'est ce qui rassemble ces deux organisations.
Ça,
c'est le premier point de départ.
Et si,
par exemple,
on prend...
Le cas de la planification,
effectivement,
un planning qui vient d'un fournisseur,
un planning qui vient du client,
et ces deux-là doivent travailler ensemble pour y voir clair.
Bien évidemment,
on se retrouve souvent avec des organisations qui vont avoir fait des choix de logiciels différents.
Et donc souvent,
quand on vient chercher cette donnée-là,
on va se retrouver avec deux données de planning qui proviennent de deux logiciels différents et donc avec des structures de données différentes.
Globalement,
le contenu va se ressembler,
ou les informations qu'on va trouver vont...
au final être semblable.
Et c'est là où on a besoin de ce standard,
un format de liste bien conçu,
et surtout de reconnaître quel champ va avec quel champ,
pour avoir une donnée,
planification,
pour ce projet-là,
qui est rassemblée et qui est exploitable pour en faire un planning plus visuel,
une roadmap,
pour en simuler quelque chose,
pour en faire une S-curve pour mesurer la performance du planning,
etc.
Et donc c'est vraiment la clé au final qu'il faut aller chercher.
Et en fait,
ce standard,
il faut l'écrire pour être capable de le réappliquer tout le temps.
C'est ce sur quoi on a beaucoup travaillé.
Quelle est cette clé qu'on vient appliquer dès qu'on a une source de données pour la transformer et être efficace à chaque fois qu'on vient refaire cet exercice-là ?
Et cette clé aussi,
au final,
si une personne fait le travail de son côté,
il faut que cette clé soit partagée à travers l'entreprise pour que tout le monde puisse réutiliser au final cette clé commune et que chacun ne crée pas sa propre clé à chacun de son côté.
Oui,
c'est qu'il faut avoir une structure globale qui permet à tout le monde de fonctionner,
qui soit partagée et appliquée par tout le monde.
On a des principes comme ça,
Tanguy,
qui sont assez forts dans notre projet.
C'est ce sur quoi on travaille et c'est le fruit de 30 ans d'expérience sur le terrain.
Déjà,
le concept d'un data model universel,
un modèle de données universel pour le projet.
Donc ça,
je pense que Bastien et Julien ont bien développé le sujet.
Et après,
effectivement,
c'est...
de permettre aux utilisateurs de gagner du temps parce que les workflows aujourd'hui ne sont pas optimisés de par le data monster,
de par les silos de données,
de par la qualité de la donnée.
Et il y a assez peu d'incentives aujourd'hui à demander aux gens de passer encore plus de temps à avoir de la donnée de qualité.
Donc pour avoir de la donnée de qualité,
aujourd'hui,
il n'y a pas d'autre solution que de redonner de la valeur aux utilisateurs en échange de ce temps passé.
Et de leur montrer aussi qu'il existe des workflows qui leur demandent moins de temps.
Donc la concaténation de différentes sources disparates de planning pour faire une roadmap consolidée
qui s'automatise toute seule.
C'est l'un des cas d'usage,
effectivement,
que l'on développe.
Mais c'est un parmi beaucoup d'autres.
Et c'est très bien de parler d'IA,
mais il n'y a pas forcément besoin d'IA pour faire tout ça très bien.
Et d'ailleurs,
c'est plus éco-responsable de ne pas utiliser de l'IA lorsqu'on peut s'en passer,
juste au passage.
L'IA,
à tout bout de champ,
ça aura les limites que notre planète nous impose.
Il est très important d'utiliser l'IA partout où on doit le faire,
et de le faire bien.
mais aussi il est très important de s'en passer partout où on peut,
et il y a plein de zones où il ne faut pas être feignant,
et absolument avoir le courage de regarder ces workflows,
et d'associer un travail lié à l'outil,
à un travail lié au process également.
Il y a moyen de faire plus simple sans IA,
quoi.
Oui,
oui.
Je veux dire,
on ne fait pas la chasse à l'IA.
On l'utilise et c'est très précieux comme outil de travail.
Mais surtout,
ce n'est pas la solution à tout.
Et pour que l'IA performe bien,
il faut avoir des fondations solides.
Oui,
on est d'accord là-dessus.
Du coup,
on a un peu vu comment structurer les données.
Une fois que celles-ci sont consolidées,
comment les rendre exploitables pour le projet et pour piloter le projet ?
Une fois qu'on a réussi à mettre tout ça ensemble,
les faire communiquer et les rendre cohérentes,
comment les exploiter efficacement ?
Là,
on va rentrer sur le domaine qui est plutôt la visualisation de la donnée,
la business intelligence,
etc.,
qui bien évidemment se base sur la donnée et donc sur une bonne structure de données.
Le premier travail,
c'est de transformer la donnée et la rendre facilement exploitable.
Et donc du coup...
Encore une fois,
il y a des standards.
Typiquement,
il faut faire en sorte d'être toujours sur ce qu'on va appeler plutôt des formats de liste de données plutôt que typiquement des systèmes de tableaux à double entrée qui sont beaucoup plus difficiles à exploiter.
Encore une fois,
il y a des disparités au niveau des disciplines de la gestion de projet parce que si on prend de la donnée planification,
elle va être plutôt bien structurée au sens d'un format de liste.
Si on prend des données,
par exemple,
plutôt gestion de coût ou budget,
on a plutôt tendance à faire des tableaux à double entrée.
C'est beaucoup plus pratique.
Mais par contre...
plus difficile à exploiter quand on vient essayer de comprendre ce qui se cache derrière,
notamment d'y mettre de la visualisation de données ou de la business intelligence.
Donc globalement,
ici,
ça aide d'appliquer aussi cette règle,
comment on transforme tout ça sur des formats de liste à plat.
La transformation,
il faut qu'elle soit efficace,
c'est-à-dire qu'on peut passer du temps à savoir comment la transformer,
mais une fois que c'est fait,
il ne faut pas repasser plus de temps par la suite,
donc il faut la réappliquer très facilement.
Et ensuite,
une fois que ça c'est fait...
On va récupérer une structure par typologie de données qui est propre,
mais surtout,
comme on l'expliquait,
avec des systèmes de clés qui vont permettre que chaque donnée puisse bien se comprendre.
Et donc,
on parlait notamment des structures de projet,
les WBS,
les OBS,
etc.
Ça,
ça nous permet de faire correspondre des données ensemble.
Et puis,
surtout,
tout ce qui va être code projet ou n'importe quel code référence qui va permettre de lier les données.
Ça,
c'est un point important.
C'est toujours difficile d'exploiter une donnée si on ne vient pas garantir les standards de gestion de données et de bases de données.
Donc là on est plutôt dans le monde informatique,
mais c'est au final le cœur de la problématique,
puisque la donnée vient du monde informatique.
Il faut faire attention d'avoir tout le temps des identifiants uniques,
et essayer aussi d'appliquer au maximum ce qu'on appelle la validation des données,
c'est-à-dire quand on est dans des champs de données,
il va y avoir souvent un nettoyage à faire parce qu'on attend certains champs attendus.
Je prends l'exemple de planification.
en planning on va trouver des éléments qui sont de type tâche et de type jalons mais si en réalité dans cette colonne là on va retrouver plein d'informations déstructurées,
jalons qui est écrit de plein de manières différentes tâches pareilles etc etc il y a un gros nettoyage à faire c'est de la validation de données et ça plus on le fait en amont mieux c'est et ensuite ce nettoyage doit être bien fait pour être capable d'exploiter la donnée et là on aura des systèmes de dashboards beaucoup plus propres et donc qui vont faciliter
le pilotage si c'est pas le cas
On risque de passer beaucoup plus de temps à transformer la donnée plutôt qu'à l'analyser,
ce qui n'est pas le but du contrôle de projet et de militer du PMO.
L'idée,
c'est de réduire presque à zéro les tâches de transformation de données pour prendre son temps sur l'analyse de la donnée et le restituer au projet pour aider le projet à être bien piloté.
L'enjeu pour le pilotage,
c'est de pouvoir faire de la corrélation.
de paramètres qui sont distincts dans la manière dont ils sont pilotés et dont les données sont stockées aujourd'hui.
Donc toutes les disciplines de projet qu'on a listées avant,
en fait,
elles sont pilotées indépendamment aujourd'hui.
Et donc les corrélés,
c'est énormément de travail manuel et de risque d'erreur au passage.
Et l'autre enjeu,
c'est d'en reconnaître les interdépendances de façon à pouvoir mieux anticiper les effets des décisions qui sont prises.
Et tout ça,
en fait,
c'est...
Ce sont des choses très tangibles qui sont extrêmement difficiles à faire avec les technos qui sont disponibles la plupart du temps dans nos grands groupes industriels français et internationaux.
Quels vont être les leviers pour transformer ces données disparates en informations utiles pour le pilotage du projet ?
Deux points.
qui pour moi sont extrêmement importants lorsqu'on veut vraiment exploiter les données le mieux qu'on peut.
Notre plateforme,
notre data model doit être capable de nous permettre d'enrichir la donnée source.
C'est-à-dire que souvent,
ce qu'on va récupérer d'un schedule ou d'un fichier Excel qui manage des actions,
etc.,
comprend pas mal de données,
mais nous on a besoin de l'enrichir,
rajouter des commentaires,
rajouter une structure pour pouvoir mieux visualiser la donnée,
etc.
Et au final,
cet enrichissement de données doit être stocké quelque part.
et il doit être réutilisé lorsque la donnée source est mise à jour.
Et ça aussi,
ça nous permet de réaliser des simulations de scénarios.
C'est-à-dire,
demain,
j'ai envie de faire rentrer des nouveaux projets,
j'ai envie de rajouter des ressources qui n'existent pas dans mon environnement RH,
parce que je suis capable de le faire pour pouvoir simuler des projets qui rentrent et savoir si la capacité de mon équipe actuelle pourra répondre à la charge ou je vais devoir embaucher dans quelques mois.
Et en plus de ça,
il y a un autre point aussi qui est très important pour moi,
c'est l'accessibilité,
le partage.
C'est-à-dire que n'importe quel stratége de l'entreprise doit être capable d'accéder à la donnée qui a été officialisée et validée et d'en trouver son compte.
C'est-à-dire que,
par exemple,
on ne va pas forcément voir un décideur ou un CEO qui va aller dans SAP réaliser un extract pour essayer de comprendre ce qui se passe dans ses coûts,
par exemple.
Donc voilà,
c'est comment on rend ce data model accessible à n'importe quelle personne travaillant dans l'entreprise.
Et du coup,
vous avez des méthodes,
des outils pour arriver à faciliter ça,
des technologies particulièrement efficaces pour arriver à exploiter ces données ?
Typiquement,
si on prend Power BI,
Power BI,
c'est un excellent logiciel qui nous permet de faire du BI,
justement,
de prendre des données,
créer des data models et créer de la visualisation.
Mais lorsqu'on doit enrichir la donnée,
ça devient compliqué.
Du coup,
souvent,
qu'est-ce qu'on fait ?
On va créer des fichiers que ça a à côté,
on va rejeter la donnée,
on va réimporter notre Power BI et c'est assez complexe.
Et donc au final,
on se retrouve un peu bloqué dans un monde où il y a plein d'outils qui sont sur-spécialisés sur un domaine,
mais qui ne communiquent pas forcément entre eux et qui ne sont pas capables au final de faire du real-time,
on va dire,
de modification d'informations pour réaliser des scénarios rapidement.
C'est dans ce monde-là qu'on évolue actuellement chez nos clients.
Et c'est pour ça qu'au final,
on a créé Cleverest qui est capable de créer ce data model,
d'enrichir,
de réaliser des analyses.
et de rendre l'accessibilité et le partage de ces analyses plus facile.
C'est ce qu'on appelle les outils d'ETL,
de transformation de données,
Power BI en fait partie et en plus ça fait de la visualisation,
il y en a beaucoup d'autres qui le font.
La particularité c'est que ce n'est pas magique non plus,
il faut quand même un travail aussi pour qu'on puisse bien fonctionner,
ça fait partie d'un métier,
c'est un métier de data analyst notamment.
C'est aujourd'hui nécessaire,
on voit aujourd'hui beaucoup de clients qui vont bloquer cette étape-là,
ou parfois qui vont aller un peu trop vite,
et donc stocker de la donnée qui n'est pas standardisée sur des mêmes typologies de données.
Et donc ça devient compliqué,
c'est-à-dire que j'ai une base de planning gigantesque,
sauf que je vais retrouver tellement de données sur des formats différents qui vont être durs à exploiter pour en sortir quelque chose de cohérent sur plusieurs projets,
à plusieurs années,
etc.
Si on n'est pas data analyst,
ce qui est quand même le cas de la majorité des personnes traitant les données des projets,
on fait comment pour faire cela efficacement ?
On travaille donc sur une plateforme qui s'appelle Claverest.
Et
Claverest, c'est vraiment un outil fait par les PMO et les Project Controllers pour les PMO et les Project Controllers.
L'objectif,
c'est vraiment la maîtrise des projets.
Et ce que l'on constate,
c'est qu'il y a vraiment deux catégories d'environnement.
Il y a les environnements qui sont sous-équipés,
donc soit des petits projets qui passent un peu sous le radar ou alors des projets de transformation qui sont pourtant critiques,
absolument stratégiques,
mais qui ne seront pas équipés par les outils d'entreprise.
Et à l'autre bout du spectre,
on a à peu près la totalité de la population des gros projets qui sont suréquipés par le Data Monster.
Et en fait,
ce que l'on a conçu,
c'est une plateforme qui sache s'adapter aux deux environnements.
C'est-à-dire qu'à la fois,
elle puisse être utilisée de manière autonome et complètement autosuffisante pour servir aux besoins des professionnels de la maîtrise de projet.
Donc,
une plateforme réellement pointue sur de la maîtrise de projet qui s'utilise de manière autoporteuse.
Et...
pour l'autre bout du spectre qui est extrêmement représenté et qui fait perdre énormément de temps aux gens,
une forme de data hub.
Quelque chose qu'il faut s'imaginer comme avec des tentacules qui viennent se connecter à l'ensemble des sources de données et qui puissent permettre de donner un espace de pilotage aux gens,
un espace unique de pilotage aux gens.
Et en fait,
Cleverest,
dans cette configuration-là,
se connecte aux gros outils d'entreprise,
des outils de planification lourdes comme Planisware ou Primavera,
ou MS Project ou autres,
ou des ERP comme SAP,
et se connectent également à des outils de BI,
parce que l'ultra-customisation des BI,
c'est quelque chose qui est déjà bien couvert,
il n'y a plus de besoin non assouvi dans cette niche,
mais également,
ce qui est toujours systématiquement oublié,
c'est la vraie vie.
Il faut des connecteurs avec la vraie vie,
et des connecteurs avec la vraie vie,
c'est à savoir absorber les fichiers Excel que les gens font,
y compris quand les gens font du dessin.
et pas uniquement de la donnée structurée.
Savoir absorber les pléthores de planches PowerPoint qui circulent dans les organisations et qui sont stockées dans des boîtes e-mail ou dans des SharePoint.
Savoir prendre une simple photo d'un tableau blanc pour ne pas avoir besoin de tout retaper.
Quand on parle de dessiner un WBS,
même quand ça ressemble à une mind map,
ou alors prendre une liste de bullet points ou une roadmap qui a été dessinée.
Cleveress,
c'est vraiment un data hub qui permet...
de se connecter au système d'entreprise,
au BI et également à la vraie vie parce que la vraie vie ne fait pas partie de la théorie de la gestion de projet mais elle est éminemment présente dans le quotidien des gens,
ça va de soi.
Vous avez peut-être des exemples concrets où l'analyse de données projet a fait la différence dans les décisions qui ont été prises et dans le management du projet ?
Oui,
je peux vous parler d'une anecdote.
notamment quand j'opérais pour le fournisseur d'un constructeur aéronautique européen,
un des plus gros fournisseurs sur le programme,
et en fait ce fournisseur avait la réputation globalement d'être tout le temps en retard,
et d'ailleurs de causer le retard au final du projet.
J'étais en phase de développement d'engineering,
donc vraiment conception de l'avion.
Et donc typiquement il y avait tout un jeu de gestion des interdépendances,
ce qu'on appelle la gestion des work packages,
et le fournisseur a un work package,
il y a plein d'autres fournisseurs,
et puis il y a le client qui peut faire des choses et qui va l'intégrer.
Et la gestion des interdépendances en phase de conception,
c'est je connecte deux morceaux de fuselage,
il y a une partie d'interface,
et cette partie d'interface il faut la gérer,
parce que si on ne dessine pas correctement,
on ne va pas réussir à assembler les deux.
Et se trouver que le fournisseur en question,
c'est lui qui a le travail le plus compliqué,
parce que...
responsable du centre du fuselage,
et le centre du fuselage,
il y a beaucoup d'interfaces,
puisqu'on vient connecter les ailes,
on a le caisson de voilure,
on a le train d'atterrissage,
et sa responsabilité n'était que sur le fuselage,
le tube,
donc beaucoup d'interdépendance.
Et donc du coup,
il faut bien comprendre que là,
dans une gestion de projet,
si on n'est pas capable de piloter correctement ces interfaces et les parties prenantes,
ça met à mal le projet,
parce que ça ne dépend que de ça.
Et notamment,
j'ai été amené ici à mettre en place tout un système pour eux.
collecter toutes ces interdépendances,
en suivre leur avancement et le pilotage par fournisseur,
par partie prenante.
Et effectivement,
il s'est avéré que la réalité qui était démontrée,
notamment le retard dû à ce fournisseur,
était au final tout autre.
C'était plutôt le client qui mettait en retard.
Pourquoi ?
Notamment par des prises de décision.
Et en fait,
il y a quand même une réalité dans le monde des projets qui est qu'on a parfois certaines impressions qui peuvent être...
parfois fausses sauf que ces impressions vont quand même influencer la compréhension de la donnée et donc si on n'est pas capable de le démontrer notamment par la bonne analyse de la donnée ça peut quand même conduire à un projet
peut être malsain,
voire pas à succès,
parce que vous imaginez bien l'atmosphère au sein du projet quand au final on se tire dessus parce qu'on essaie de savoir qui est en retard sans vraiment savoir pourquoi.
Donc ça,
c'est par exemple une partie importante,
gestion des interfaces,
des interdépendances,
collecte des décisions pour être capable sereinement de piloter le projet,
non pas sur une seule partie,
mais avec la totalité des parties du projet.
Et là,
je parle de gros projets.
de gros programmes,
et donc c'est encore plus important sur ce type de dimension.
Ok,
c'est bien parlant.
Quel conseil vous donneriez au chef de projet qui souhaite mieux exploiter les données pour améliorer son pilotage du projet ?
Je pense qu'un premier qu'il faut appliquer,
au final,
même nous on a tendance à ne pas se l'appliquer,
mais vous connaissez le coordonnier.
Globalement,
on se rend compte qu'on a beaucoup de données.
Et il faut se poser la question,
qu'est-ce qu'on va faire avec cette donnée ?
Et globalement la réponse est assez simple,
c'est-à-dire oublions la problématique de la data déjà,
quels sont nos objectifs ?
Et une fois qu'on a défini nos objectifs,
il faut être capable de les mesurer pour savoir si on va les atteindre.
Et c'est là où quand on cherche à savoir comment mesurer l'objectif,
on a besoin de cette donnée-là.
Ça signifie que la donnée qu'on a à disposition...
pour bien l'exploiter,
il faut l'exploiter vis-à-vis des objectifs qu'on souhaite atteindre et pas juste pour essayer d'exploiter de la donnée sans raison valable.
Par contre,
à l'inverse,
on sait aussi que parfois,
notamment dans le monde de la recherche,
la donnée nous permet de découvrir des choses qu'on n'aurait peut-être pas découvert si on n'avait pas un peu trituré la donnée.
Donc attention,
il faut aussi parfois,
dans le monde de la data analyse et de la data science,
s'amuser sans savoir pour quel but.
Ça ne peut pas être la totalité du temps du pilotage du projet.
Attention,
quand vous avez la donnée,
avant d'aller trop vite dans l'exploitation de la donnée,
déjà,
il faut se poser pour savoir quel objectif on souhaite atteindre et donc quelles données il nous faut pour mettre en place la bonne mesure pour l'atteindre de cet objectif.
Tanguy,
au-delà de l'avis des chefs de projet,
je pense qu'il y a quelque chose qui est important,
c'est un enjeu un peu plus large,
c'est que les chefs de projet,
il fut un temps,
ils s'outillaient.
Et aujourd'hui,
on les outille.
voire même on outille les grandes directions de programme par des sets d'outils qu'ils ne choisissent pas toujours eux-mêmes.
Et donc je pense qu'il y a un re-empowerment à mettre au centre du jeu sur s'assurer que les acteurs-projets choisissent des outils faits pour les projets en toute connaissance de cause,
parce que je pense que les éditeurs de logiciels qui ont pignon sur rue aujourd'hui s'adressent à différents acteurs dans les strates organisationnelles un peu plus haut.
et que du coup,
ça retombe en plus fine au sein des directions de projet.
Ce n'est pas systématiquement le cas,
mais il faut appeler un chat un chat.
Je pense qu'il faut remettre la décision des outils digitaux au centre de la direction des projets.
Oui,
ça,
c'est un bon conseil.
Je pense que beaucoup de gens se retrouveront là-dedans.
On a parlé pas mal des projets,
mais il y a aussi les programmes et les portefeuilles.
Je suppose que tout ce qu'on a dit là est aussi valable pour arriver à faire des consolidations à des niveaux supérieurs ?
C'est clair.
On retrouve des problématiques similaires,
mais on est quand même dans un environnement différent.
Si on parle de portefeuille de projet,
on va regarder une multitude de projets qui vont œuvrer en tant que projet.
On va avoir leur budget,
leur planning,
leur équipe,
des équipes partagées,
peut-être des équipes...
multifonctionnel,
etc.
La différence qu'on va avoir,
c'est qu'on a une vue,
une gestion des interdépendances,
des interfaces un peu différentes.
Et là,
qui va avoir un impact au niveau du projet directement.
Typiquement,
quand on parle d'un portefeuille de projet,
bien souvent,
les projets vont avancer en parallèle et puis vont connaître des interdépendances.
Et il faut comprendre qu'au final,
les décisions qu'on vient prendre au niveau portefeuille vont impacter les projets.
Et parfois,
la décision,
c'est lancer un projet,
arrêter un projet,
et c'est...
important pour la stratégie de l'entreprise.
Donc au final,
ce qui vaut pour un projet,
un programme vaut pour un portefeuille de projet aussi avec la différence qu'un portefeuille de projet c'est plein de projets donc on vient de démultiplier la problématique et donc ce qu'on applique à l'échelle d'un projet si on n'arrive pas à l'appliquer à tous les projets,
on va démultiplier,
même problème pour le portefeuille.
Là où le reporting qu'on fait pour le projet doit exister aussi au niveau portefeuille donc on a vraiment différentes strates.
de contrôle et de reporting.
Je rajouterais aussi un petit truc.
Au final,
lorsqu'on parle de données projet,
ça reste assez simple de gérer les permissions.
Donc,
qui a le droit de regarder,
d'éditer,
etc.
ce genre de données projet ?
Lorsqu'on parle de portefeuille de projet,
si on commence à extraire toutes les données,
modifier tout ça dans des fichiers,
s'injecter dans du Power BI,
partager les informations,
on ne sait pas trop qui va pouvoir accéder à cette donnée.
Et du coup,
aussi l'enjeu...
c'est d'arriver à gérer parfaitement ses permissions et de rendre disponible un portefeuille de projet avec...
X projets dont j'ai accès en écriture ou en lecture.
Mais surtout,
il faut faire très attention à qui a le droit d'analyser ou pas ses portefeuilles.
Donc ça aussi,
il faut le garder en tête et dire que lorsqu'on joue avec ces modèles de données,
il faut intégrer absolument ce système de gestion des permissions.
On a énormément parlé de données,
je suis convaincu que dans certaines entreprises c'est quelque chose qui est omniprésent et très important,
mais de par mon expérience il y a aussi beaucoup de structures où cette culture de la donnée n'est pas du tout présente.
Un conseil pour ceux qui seraient dans cette seconde situation ?
Quand on démarre un projet,
et en fait ça vaut pour l'entreprise,
mais c'est pas simple,
vous savez dans les entreprises il y a toujours une culture d'entreprise qu'on met en place,
qu'on essaie de garantir,
qu'on travaille,
etc.
Et je pense qu'il y a aussi une culture donnée.
Et en fait,
dès qu'on démarre un projet,
c'est une culture qui est importante pour éviter d'avoir une dette sur la collecte de la donnée.
Dès le début,
il faut faire attention à garantir une bonne collecte de données,
une bonne structuration.
Et ça permettra du coup de faciliter la mise en place du pilotage et des moyens de contrôle.
Et on voit bien souvent dans des projets des organisations,
au bout de quelques mois d'activité,
parfois années,
on commence à mettre un pilotage ou être plus mature,
mais en réalité on a perdu du temps sur la collecte de la donnée.
Il ne faut pas collecter à foison,
mais ce qui est collecté,
il faut bien le collecter.
Et ça,
c'est une culture qu'il faut mettre en place au sein du projet,
je dirais même au sein de l'entreprise.
Mais si on n'a pas la main sur l'entreprise,
essayons de le faire au niveau du projet directement.
Donc voilà,
ça c'est important parce que c'est de la dette qui va exister au sein du projet,
au sein de l'entreprise,
mais j'irai encore plus loin si on parle d'intelligence artificielle.
au sein des projets d'intelligence artificielle,
parce que du coup,
c'est autant de données pas collectées qu'on ne va pas pouvoir utiliser pour nourrir l'intelligence artificielle et se créer plus de connaissances.
Donc,
la bataille,
elle démarre dès l'ouverture du projet,
mettons en place cette culture-là,
et on a besoin toujours des bons outils,
puis des bons réflexes pour le faire.
On commence à avoir bien fait le tour de la question.
Une question que j'aurais oubliée ou quelque chose à rajouter ?
Conseil pour les chefs de projet,
choisissez le bon outil.
Il y a quelque chose aussi que je peux rajouter par rapport à ça,
c'est bien sûr,
choisissez le bon outil,
mais surtout prenez du plaisir à utiliser vos outils de gestion de projet,
parce que c'est vos outils,
c'est ce qui vous permet de passer une bonne journée à travers votre analyse,
etc.
Donc si vous utilisez des outils qui ne vous correspondent pas,
que vous n'arrivez pas à réaliser ce que vous êtes censé faire,
c'est que l'outil n'est pas bon.
Moi,
j'essaie de prendre un pas de recul et en fait,
ce qui me préoccupe,
c'est que la gestion de projet attire les meilleurs talents.
Je vis hors de la France,
dans des pays qui,
depuis longtemps,
ont priorisé leur culture financière ou business à une culture d'ingénierie.
Et ça vient avec des effets secondaires sur la robustesse d'une économie,
la capacité de cette économie à continuer à innover et à être compétitive.
Et en France en particulier,
puisque ce podcast est français,
donc je m'adresse à l'audience française,
c'est encore une richesse de notre...
pays et il faut qu'on capitalise dessus et les projets il faut absolument que ça reste un domaine de travail attractif parce que encore une fois notre compétitivité en dépend c'est pas neutre d'avoir des outils qui sont pénibles à utiliser et 50%
de son temps à faire à brasser de la donner parce que c'est décourageant et il faut absolument aussi sur ce point de vue là que le paysage évolue et que la révolution digitale délivre ses promesses
C'est sur ça qu'on travaille.
Je suis très fier de faire partie de cette aventure aux côtés de mes collègues.
On espère que Cleverest aidera les collaborateurs dans les projets de nos fleurons français.
Très bien.
Merci à tous les trois de nous avoir partagé vos conseils et votre vision sur la gestion des données projet et quelques solutions pour mieux les traiter.
Merci Tanguy.
Merci à vous.
Encore merci Alexis,
Bastien et Julien pour cet éclairage sur la gestion de la donnée projet.
J'espère qu'il vous aura donné des idées pour mieux collecter,
traiter et analyser les données de votre projet et que vous pourrez de cette manière reprendre la main sur votre DataMonster.
Vous avez des questions ?
D'autres conseils à partager sur la gestion des données projet ?
Retrouvez-nous sur LinkedIn pour en discuter.
Vous avez pensé à quelqu'un à qui cet épisode pourrait être utile ?
Partagez-lui !
Et pensez à vous abonner à Focus Projet sur votre plateforme préférée pour ne pas manquer les prochains épisodes.
Bonne semaine et à la semaine prochaine !