Colorier les contours du projet (avec Maik Stettner d’EA Games)

Lisez la transcription :

Nous faisons un essai de transcription de nos balados à l’aide d’un programme informatique. Merci de nous excuser pour les éventuelles fautes, car le robot n’est pas toujours exact à 100%.

Ben Aston

Bienvenue sur le balado DPM, où nous allons au-delà de la théorie pour vous donner des conseils PM d’experts pour gérer de meilleurs projets numériques. Merci d’être à l’écoute, je suis Ben Aston, fondateur du Digital Project Manager. Soyons honnêtes : êtes-vous prêt à livrer vos projets dans le budget ? Et à l’heure ? Êtes-vous prêt à livrer le périmètre promis également ? Vous ne savez pas ? Alors, comment le savoir et comment faire ? C’est justement le sujet du balado aujourd’hui : les contrôles de projet.

Ils sont en réalité comme les lignes que l’on trace autour de nos projets pour nous aider à connaître les limites du projet. Où nous devons colorier à l’intérieur. Et pour savoir quand nous colorions en dehors de ces lignes dans notre projet.

Cet épisode est sponsorisé par Resource Guru, l’outil de planification des ressources utilisé par des équipes de sociétés telles qu’Apple, Ogilvy, Deloitte et Publicis. Les auditeurs de DPM bénéficient de 20% de réduction à vie avec le code promo DPM2018.

En savoir plus sur Resource Guru

Aujourd’hui, je discute avec Maik Stettner. Et Maik vient d’être nommé directeur du développement pour EA Games, auparavant chez FCV, où il dirigeait l’équipe. C’est aussi l’un de nos experts DMP à la Digital Project Manager School. Et, quand on gère une équipe de PM, l’un des sujets qui passionne, ce sont les contrôles de projet. Maik a beaucoup d’expérience là-dedans. Vous voulez que votre équipe respecte le budget. Vous voulez qu’elle atteigne les échéances, les jalons, sinon tout peut se défaire et vous devez intervenir. Alors aujourd’hui, on va parler de la manière dont on peut mieux gérer nos projets et des contrôles qu’on peut mettre en place. D’abord, pour savoir si nous sommes sur la bonne voie. Ensuite, pour avoir des leviers d’action quand on commence à sortir des rails.

J’espère que cela vous tente. Maik, bonjour et bienvenue dans l’émission.

Maik Stettner :

Salut, Ben. Merci de m’avoir invité.

Ben Aston :

Content de te revoir. Maik, parle-nous un peu de… Tu es justement en train de changer de rôle, passant de FCV où tu dirigeais une équipe de PM, à directeur du développement chez EA Games. Tu sais déjà ce que ça implique ?

Maik Stettner :

Je vais très vite le découvrir. L’accent est toujours mis sur la gestion de projet. Bien sûr, le passage de l’agence au jeu vidéo avec Electronic Arts, ce n’est pas totalement nouveau pour moi car j’ai déjà travaillé dans différentes industries durant ma carrière. Je suis impatient de m’y plonger à nouveau. C’est assez complexe d’un point de vue gestion de projet. Donc stimulant, dynamique, et il est probable que je doive aussi appliquer tout ce qui concerne les contrôles de projet.

Ben Aston :

Intéressant ! Et, alors que tu changes de rôle et découvres d’autres outils et façons de travailler, as-tu découvert ou utilisé récemment un outil ou une approche que tu voudrais vraiment amener dans ce nouveau poste ?

Maik Stettner :

J’ai l’impression que dans chaque poste occupé, j’ai toujours appris de nouveaux aspects et de nouvelles manières d’aborder les problèmes. Car, surtout dans le logiciel ou la gestion de projet numérique, on rencontre souvent des problèmes similaires mais il existe des solutions alternatives. Cela peut passer par des outils de suivi d’incidents, qui s’améliorent avec le temps, ou encore par des outils d’analytique permettant de prendre des décisions à l’improviste. Je n’ai pas vraiment de nom précis, si ce n’est les suspects habituels. Ce qui m’intéresse surtout, c’est de constater que beaucoup de problèmes sont similaires, qu’il s’agisse de créer une appli, un logiciel de bureau, un site web ou un jeu ; les défis sont comparables. Et donc les démarches pour les résoudre aussi.

Ben Aston :

Oui, ce qui m’a frappé en commençant des missions de consultant c’est que, même si l’on pense savoir comment les choses doivent fonctionner, par exemple pour la gestion des ressources, on peut utiliser Resource Guru ou d’autres outils comme Harvest avec Forecast. On se dit qu’on maîtrise la conduite du navire, et tout à coup, on commence à utiliser un outil dans la façon dont l’agence le fait, et on réalise que c’est complètement différent. Le même outil peut être utilisé de tellement de façons différentes, ce qui rend la chose complexe, parfois.

Mais ce que tu dis sur l’importance des données, des analyses, c’est essentiel. Et ça fait le lien avec l’article que tu as écrit sur les contrôles de projet. Quand on dirige une équipe de chefs de projet ou qu’on travaille avec eux, il ne faut pas se fier à son intuition ou au ressenti. Il faut des données, n’est-ce pas ?

Maik Stettner :

Absolument. Surtout dans mes fonctions de manager de PM, je n’ai pas toujours accès au même niveau de détail que le PM dédié. Je me fie donc beaucoup aux données : suivre l’état du budget, analyser le burn rate, etc. Cela me permet de prendre des décisions en collaboration avec, par exemple, le chef de projet ou l’équipe associée.

Ben Aston :

Donc, cela constitue nos contrôles de projet, en somme. Pour la gestion de programme, pour la gestion d’une équipe de PM, ce sont les données que l’on regarde. Ce sont les artefacts produits par nos PM. Peux-tu définir ce que sont les contrôles de projet ? À quoi cela correspond concrètement ?

Maik Stettner :

Le terme peut paraître impressionnant. Pour moi, les contrôles de projet désignent tous les outils nécessaires pour accéder à la bonne information et prendre des décisions éclairées. Cela concerne tous les indicateurs qui aident à décider sur les coûts, le temps, le périmètre, etc. Ils sont directement liés aux interactions client ou aux décisions dynamiques en projet. L’équipe est-elle assez grande ? Ai-je besoin de recruter ? Sommes-nous dans les délais ? Dans le budget ? C’est vraiment un cadre à haut niveau pour manager le projet et prendre de bonnes décisions.

Ben Aston :

Et quels sont pour toi les documents clés à produire ? Car il y a beaucoup de documentation possible. Si l’on s’en tient à l’essentiel, lesquels sont les plus utiles selon toi – pour toi-même en tant que PM ou pour un directeur de programme qui manage plusieurs équipes ?

Maik Stettner :

Le plus standard et que je recommande à tous, c’est la création d’un vrai rapport d’avancement. C’est un relevé du projet qui réunit tous les indicateurs pertinents : coûts totaux, budget restant, burn rate, ce qui a été réalisé ces derniers mois, les actions clés, risques, obstacles et décisions. En général, dans tous les projets où j’ai travaillé, nous produisions des rapports d’avancement chaque semaine. Et ils étaient toujours partagés au client, afin qu’il dispose d’une vision claire et puisse décider. C’est un outil essentiel pour le PM aussi…

C’est presque du self-contrôle : en début de semaine, dresser un rapport, vérifier comment vont les chiffres, où en est le budget, le calendrier. À haut niveau, on rassemble tout cela. On le valide avec le client, par exemple lors de réunions régulières, qui n’ont souvent pas besoin de durer plus d’une demi-heure. Mais servent de points de contrôle et aident à établir une vraie relation de confiance. Ça peut être à distance ou en présentiel – le face à face, c’est toujours mieux – pour renforcer ce lien et aborder les opportunités, problèmes ou obstacles lors de ces réunions régulières.

Ben Aston :

Donc, tu produis la documentation puis tu organises ces points réguliers avec le client. On fait nos rapports d’avancement. Mais quoi d’autre partages-tu ? Car c’est une chose de contrôler le projet en interne, mais transmettre ces données au client, c’en est une autre. Outre les rapports d’avancement, quels sont les outils fondamentaux pour toi, pour contrôler et gérer avec le client ?

Maik Stettner :

Un outil essentiel pour garder le contrôle global du projet, c’est… cela peut être aussi une demande de changement, ou le processus lié avec les formulaires associés. Donc, chaque fois que le périmètre évolue, s’il faut prévoir des efforts supplémentaires, ou si l’équipe doit pivoter pour répondre à des changements de planning, il faut documenter. Souvent, le terme « demande de changement » effraie et on hésite à l’employer de peur d’alerter le client. Mais c’est en fait normal.

Une demande de changement n’implique pas forcément d’impact négatif, parfois c’est juste pour tracer. Pas de conséquences budgétaires parfois, pas d’impact sur le calendrier. Mais c’est toujours bon de documenter et de familiariser le client à ce processus car, si un jour une décision a un impact sur le budget, il faut alors vraiment documenter et tout faire valider.

Ben Aston :

Un autre document clé que tu évoques, donc un autre contrôle de projet, c’est le registre RAID. Un aspect important du pilotage du projet. Mais si tu devais n’utiliser qu’un seul outil documentaire, lequel choisirais-tu ?

Maik Stettner :

La chose la plus essentielle, c’est un bon rapport d’avancement. Un RAID log va plus dans le détail et, selon la complexité du projet, tu n’en as pas forcément besoin. Mais le rapport d’avancement doit capter ces éléments. S’il y a des risques, obstacles, etc., prévois-les dans le rapport, pour que tout le monde garde cela en tête. Ensuite, tenir régulièrement des réunions client, partager les KPI et indicateurs clés, passer en revue les progrès. Pour moi, c’est l’indicateur principal.

Ben Aston :

C’est donc une question d’équilibre finalement : quelle dose de contrôle s’autodonner ? Documenter les exigences ou les contrôles, cela renvoie au débat agile, jusqu’à quel point s’attacher à la documentation sans se brider ? Comment ne pas passer tout son temps à surveiller le budget, mettre les rapports d’avancement à jour, organiser des réunions ? Où fixer le curseur ?

Maik Stettner :

Pour moi, lorsque j’aborde un nouveau projet, je commence de façon assez « égoïste », dans le sens où je crée un rapport d’état ou autre, très simple à produire. Je peux l’extraire via des outils déjà en place (Resource Guru, feuille de temps, etc.). Cela me permet d’obtenir les indicateurs de base. Cela peut suffire pour démarrer. Certains clients demanderont plus de détails, mais pour garder une vision interne et communiquer au client, c’est une excellente base. Cela ne prend pas beaucoup de temps à produire régulièrement.

On ne veut surtout pas alourdir la charge car sinon, on finit par arrêter de le faire, ça passe à la trappe si le projet devient tendu ou monopolise toute l’attention, et la partie reporting passe au second plan.

Ben Aston :

C’est pertinent : il faut contrôler le projet, mais la régularité compte davantage que le volume de rapport. Tu peux créer une documentation de rêve en début de projet, mais si extraire les données prend des heures à chaque fois, tu finiras par ne plus le faire, et tu perdras en contrôle.

Maik Stettner :

Exactement. Et il faut garder en tête que cela va dans les deux sens. Le PM a besoin de savoir où il en est pour décider, le client veut savoir, mais l’équipe aussi a le droit d’être informée. Une des décisions du PM c’est comment partager les contraintes de budget, planning, etc. avec l’équipe. Je n’ai jamais fait un review sec de rapport à mon équipe, j’expose les contraintes différemment. Mais il faut garder aussi assez de données pour que toute l’équipe sache où elle va.

Ben Aston :

Très bon point. Ce n’est pas que pour les clients, c’est aussi pour les équipes. C’est pour qu’elles saisissent les contraintes, qu’elles sachent si un projet est « chaud », qu’il faut serrer les rangs et chercher plus d’efficacité. Disposer des données, ce n’est pas juste pour embêter, c’est pour éclairer l’équipe : « Regardez les chiffres, le rapport montre que ça chauffe : trop de temps sur l’UX ou le design – il ne restera plus de budget pour la QA si on ne boucle pas vite .»

Dans ton article, tu détaillais le processus d’initiation du contrôle de projet, puis comment tu les appliques. Tu mentionnais évaluer, planifier, réagir, connecter. Peux-tu nous expliquer cette approche ?

Maik Stettner :

Oui, bien sûr. Comme PM, il faut toujours savoir où l’on en est pour prendre des décisions. D’abord, il faut évaluer : savoir où en est le projet, dans le plan du projet, si l’on est en voie d’atteindre l’objectif. Il ne s’agit pas que des KPI, mais de s’impliquer vraiment, de questionner, de comprendre chaque membre de l’équipe. Savoir un peu de tout de chaque discipline (UX, design, dev, QA) pour savoir où l’on peut faire des compromis. On ne peut le découvrir qu’en s’investissant vraiment, à un niveau granulaire, en échangeant avec les gens.

Puis, la deuxième étape c’est la planification. Très souvent, il faut coordonner des changements, ajuster le périmètre, le calendrier, etc. On planifie la suite avec l’équipe grâce à la connaissance acquise. En tant que PM, on a le côté client et l’interne, il faut combiner tout ça pour avancer.

Ensuite, il faut réagir. Mettre en œuvre les changements décidés. Cela implique de prévenir le client, de modifier le process si besoin, d’actualiser la documentation, les outils de suivi type Jira, mettre à jour les plannings, etc.

Enfin, la dernière étape, c’est connecter. En tant que PM, vous êtes le liant de l’équipe. Il faut que tout le monde dispose de la même vision d’ensemble. Diffusez l’information auprès de l’équipe, du client. Puis accompagner et orchestrer ces changements pour garantir la livraison.

Ben Aston :

Ce que j’entends, c’est qu’il y a deux volets : en gestion de projet, la donnée est primordiale – elle nous permet d’évaluer où en est le projet et de prioriser, d’ajuster les ressources pour livrer ; mais le contrôle de projet, ce n’est pas que des chiffres, c’est aussi créer la discussion, impliquer l’équipe, avoir une posture plus agile, s’adapter au fil de l’eau, ne pas rester bloqué sur un chiffre dans un rapport. J’aime que tu parles d’en faire un dialogue.

Pour ceux qui n’ont jamais pensé à produire de véritables rapports d’avancement, tu as détaillé ce processus. Mais pour toi, quel est le premier pas pour maîtriser ses projets ? Même sans rapport d’état ou outils de contrôle, quel conseil donnerais-tu à un PM pour prendre le contrôle ?

Maik Stettner :

Pour moi, il faut d’abord avoir une vision claire de ce qu’il faut faire pour livrer. Cela commence parfois par des aspects très logistiques. Mais identifier les attentes du client, les impératifs : y a-t-il une date limite pour une campagne, une présentation à la direction ? Ensuite, en interne, il faut savoir de quelle équipe on a besoin et comment cela va fonctionner, au moins de façon macro. Avec l’expérience, on apprend à deviner les grandes étapes à prévoir dans le process.

Le rapport d’avancement aide surtout à ne pas oublier ces jalons réguliers. C’est ça, la clé : c’est un mix entre KPI, soft skills et garder une vision panoramique du projet pour toujours savoir où l’on en est, même dans la complexité. Et trouver l’outil qui nous aide le plus.

Ben Aston :

J’aime ce que tu dis : la donnée sans point de comparaison ne vaut rien. Il faut toujours un plan à opposer aux rapports d’avancement. Et chez les PM d’autres agences, souvent il manque la feuille de temps, ce suivi de combien de temps on passe sur une tâche. Même si c’est le truc le plus pénible, c’est indispensable pour comparer temps passé et plan, et donc reprendre la main sur le projet. Super conseil. Merci Maik, ravi de t’avoir eu avec nous !

Maik Stettner :

Merci Ben.

Ben Aston :

Et comme l’un de nos experts DPM, Maik animera notre prochain cours qui commence en septembre : Maîtriser la gestion de projet digital. Il s’agit d’un programme intensif de sept semaines en gestion de projet digital. Vous y apprendrez à mener des projets numériques complexes efficacement. Le cours comprend des vidéos, des exercices, des discussions de groupe, et des sessions de coaching en option. Rendez-vous sur thedpmschool.com pour vous inscrire. Il reste quelques places, mais le cours commence le 10 septembre. Si vous souhaitez contribuer à cette discussion sur les contrôles de projet, sur la manière de mieux piloter nos projets et sur les types de documents utilisés, rendez-vous dans la section ressources de thedigitalprojectmanager.com pour rejoindre notre équipe Slack, où vous trouverez des conversations passionnantes sur ces sujets. Commentez l’article, discutez sur Slack et trouvons ensemble comment mieux maîtriser nos projets !

À la prochaine, et merci pour votre écoute.