Parfois, des projets déraillent simplement parce que nous nous lançons trop rapidement. Ben Aston discute avec Maik Stettner de la manière dont nous pouvons utiliser un document d’initialisation de projet, ou un brief projet, pour que tout le monde soit aligné dès le début afin de rendre les lancements de projet plus efficaces.
Ce podcast fait partie d’un article publié sur The Digital Project Manager.
Vous pouvez lire l’article ici.
Lisez la transcription :
Nous testons la retranscription automatique de nos balados à l’aide d’un programme logiciel. Merci de nous excuser pour les éventuelles fautes de frappe, car la reconnaissance vocale n'est pas exacte à 100 %.
Ben Aston :
Merci de nous écouter. Je m’appelle Ben Aston et voici le balado du Digital Project Manager. Ce balado vous est présenté par Clarizen, le leader des logiciels de gestion de projet et de portefeuille d’entreprise. Rendez-vous sur clarizen.com pour en savoir plus.
S’il y a une chose certaine avec un projet, c’est qu’il ne suivra jamais exactement le plan prévu. Mais pourquoi les projets dérapent-ils ? Parfois, c’est simplement parce que nous nous lançons trop vite et, voyant l’échéance approcher, nous commençons dans la panique ; et lorsque les choses tournent mal, on se demande pourquoi.
Souvent, nous avons toutes les infos du projet, la stratégie, les détails, les exigences et les indicateurs de succès dans notre tête, et nous faisons l’erreur de croire que tout le monde sait tout cela aussi. Mais en réalité, si ce n’est pas écrit, il y a de grandes chances que notre équipe soit dans le flou.
Aujourd’hui, nous allons donc parler d’un outil qui permet de synchroniser tout le monde dès le démarrage du projet. C’est le document d’initialisation de projet, ou plus couramment dans notre secteur, le cahier des charges. Nous allons donc vous donner aujourd’hui les clés pour créer un PID et l’utiliser afin de rendre vos projets plus efficaces.
Aujourd’hui, je suis accompagné de Maik Stettner, un ami et collègue. Maik fait partie de nos experts DPM au Digital Project Manager. Bienvenue, Maik.
Maik Stettner :
Bonjour. Comment ça va ?
Ben Aston :
Oui, bien. C’est super de t’avoir avec nous. Maik, parlons d’abord un peu de toi et racontons à tous ton parcours, car nous travaillons ensemble depuis maintenant, cinq ans c’est bien ça ?
Maik Stettner :
Oui, quatre à cinq ans environ.
Ben Aston :
Oui. Je me souviens que lorsque j’ai embauché Maik, je me suis demandé : « Est-ce qu’il va pouvoir s’en sortir ? » Tu n’as pas le parcours traditionnel d’agence, alors raconte-nous ton histoire. Comment es-tu devenu chef de projet dans une agence digitale ?
Maik Stettner :
Oui, alors globalement, j’ai une dizaine d’années d’expérience dans divers domaines. J’ai commencé dans le jeu vidéo et l’édition, à gérer des sorties de jeux en Europe et Amérique du Nord, puis je suis allé vers d’autres secteurs comme les bases de données médicales, mais en gros toujours autour du développement logiciel et de la gestion de projet, avec des équipes variées, etc. Durant ma carrière, j’ai acquis de l’expérience en agence avec le développement d’applications et un peu de développement web aussi. Quand on a parlé de bosser ensemble, j’ai vraiment basculé à fond dans le web et l’agence.
Ben Aston :
Oui.
Maik Stettner :
Et oui, je travaille dans ma société actuelle, FCV, depuis environ quatre ans, où je dirige maintenant l’équipe de gestion de projet pour l’agence. Je suis responsable de la livraison globale des projets et de la satisfaction des clients.
Ben Aston :
Super. Pour ceux qui nous écoutent et qui se disent… peut-être qu’ils sont dans une situation similaire… et on l’entend souvent de la part de ceux qui disent : « Je suis chef de projet, j’ai géré du logiciel, mais j’envisage maintenant de passer en agence et d’être Digital Project Manager ». Pour toi, comment as-tu vécu cette transition du monde logiciel vers l’agence digitale ? Quelles différences as-tu vues dans la gestion des gens ou des projets ? J’aimerais comprendre ce contraste et ce que ceux qui souhaitent faire ce parcours devraient préparer.
Maik Stettner :
D’abord, il y a beaucoup de points communs. Les situations rencontrées ailleurs, dans le développement logiciel, dans la gestion de projet, on les retrouve aussi en agence. Les équipes sont variées, les projets peuvent déraper pour plein de raisons, et on peut utiliser les mêmes techniques pour corriger le tir.
La principale différence pour moi, au début, c’est d’avoir dû intégrer ce mode de travail : être très focus sur le temps et les ressources, sur des incréments courts d’activité plutôt que de grosses livraisons. Les clients, surtout dans le domaine où je travaille, veulent davantage de transparence et de contrôle sur de petites unités de travail. Ça impose de la rigueur dans le reporting et requiert plus d’effort pour expliquer précisément au client ce que tu fais, pour instaurer la confiance. Cela demande plus d’ajustement que lorsqu’on travaille sur un produit à lancer en interne.
Mais au fond, bosser sur une base de données, un jeu ou un site web, tu te heurtes à des problèmes assez similaires transférables d’un secteur à l’autre. Et si tu appliques les bonnes pratiques de communication et de gestion de projet, il y a de fortes chances que tu réussisses, quoi que tu construises.
Ben Aston :
Parlons alors : tu gères aussi des équipes. En tant que responsable d’équipe de gestion de projet, tu es confronté à la gestion de portefeuilles de projets — des projets aux exigences parfois conflictuelles en termes de ressources humaines. Quels sont les défis typiques que tu rencontres dans ce rôle-là ?
Maik Stettner :
Mon rôle est plus global, en fait. Je veille à ce que tout tourne. L’un de mes axes principaux : le staffing, m’assurer qu’on a les bonnes personnes au bon endroit, pour la bonne durée.
Ben Aston :
Oui.
Maik Stettner :
Souvent, il faut composer quand un projet se rallonge alors qu’un autre démarre ; trouver les ajustements nécessaires, rassurer le client, rester disponible… Le risque, dans un poste plus généraliste, c’est d’être celui qu’on appelle quand il y a un souci. Et c’est dommage, car il faut aussi rester impliqué dans les projets pour développer la confiance, sans négliger la structuration interne (ressources, opérations, collaboration inter-agences…).
Chez nous, par exemple, il est important que Toronto et Victoria travaillent bien ensemble. C’est ma priorité aujourd’hui. Mais je garde toujours quelques clients en gestion, ça reste ma passion, et je ne compte pas lâcher ça.
Ben Aston :
Vu la problématique de gestion des ressources, comment fais-tu pour trancher quand deux chefs de projet ont un deadline le même jour, avec les mêmes besoins de ressources ? Quel est ton processus ? Ton approche pour la gestion de portefeuille ? Cela parle à beaucoup de PM !
Maik Stettner :
D’abord, je regarde la priorité des projets. Y a-t-il une vraie deadline ? Une promesse au client ? La contractualisation est aussi un critère ; si le projet doit être livré dans 3 jours, difficile de prélever des ressources…
En général, j’attends aussi de mon équipe qu’elle défende ses besoins en ressources lors des points de staffing. Ça peut créer des frictions, mais chacun doit défendre ce qui lui est nécessaire, pour qu’au final le manager trouve la bonne balance entre tous.
Ben Aston :
Peut-être est-ce un problème canadien de staffing !
Maik Stettner :
Standoff canadien garanti !
Ben Aston :
Parlons outils maintenant. As-tu découvert dernièrement un outil de gestion de ressources ou de projet devenu indispensable ?
Maik Stettner :
Nous utilisons une suite classique de gestion du temps. MS Project, souvent trop complexe pour les clients… On expérimente avec plusieurs solutions cloud, dont la version Office 365 de Project. Nous cherchons encore l’outil idéal, car notre process reste en partie manuel ; l’outil parfait n’existe pas encore selon moi. J’aimerais construire ou adapter un outil à nos besoins.
Ben Aston :
Pour toi, que manque-t-il dans les outils actuels ?
Maik Stettner :
Principalement, un outil qui relie simplement la gestion du temps, la saisie des heures, la planification des ressources et le financier. Par exemple, heures x taux de facturation. Mais il y a de nombreuses subtilités qui perturbent la remontée des chiffres et génèrent du travail manuel inutile. Je n’ai jamais trouvé de solution parfaite.
Ben Aston :
Changeons de sujet : sur ton article sur le document d’initialisation, tu expliques que souvent les projets échouent car on ne les lance pas correctement. Quelles sont tes recommandations concrètes pour améliorer cet aspect, et comment sits le PID dans le processus ?
Maik Stettner :
Supposons qu’un nouveau client vienne de signer. Il s’agit d’avancer vers des actions concrètes. Habituellement, on rédige une déclaration de travail (SOW), mais au début tout reste très haut niveau. Le PID et les réunions de lancement servent alors à vérifier s’il y a d’autres enjeux à intégrer.
Une fois le SOW pré-rédigé, l’équipe agence lance un kick-off interne, puis on organise un kick-off externe, pour présenter l’équipe, le processus, le périmètre défini. Le document d’initialisation vient ensuite : il permet d’aller plus loin, même si le projet reste flou, et apporte un contexte business pour que les paramètres de base soient clairs à tous.
Ben Aston :
Qu’inclure côté contexte : comment ne pas perdre l’équipe avec trop (ou trop peu) d’infos ? Quels éléments sont vraiment essentiels ?
Maik Stettner :
Tout est question de : pourquoi le client fait-il ce projet ? Quels problèmes veut-il résoudre, quels sont les objectifs business ? Et la question clé : comment définit-on le succès, même à ce stade préliminaire ? Il faut que l’équipe comprenne où elle va et pourquoi, même si tout n’est pas détaillé.
Cela sert aussi de trace écrite initiale pour s’aligner avec le client sur les objectifs majeurs.
Ben Aston :
C’est très utile, car un bon contexte oriente la solution, surtout pour quelque chose de nouveau. Les objectifs business, ce à quoi ressemble la réussite… c’est clé. Ensuite, côté « paramètres », quels sont les cadres à fixer ? En quoi est-ce utile de restreindre le champ ?
Maik Stettner :
Il ne s’agit pas de brider les experts. Mais il faut un cadre : budget, planning, jalons… L’équipe doit savoir quelles sont les contraintes, que c’est ce qui a été promis au client pour tel budget. Si quelqu’un pense avoir besoin de plus, il faut en discuter collectivement. Le but, c’est de permettre à l’équipe de réussir, tout en anticipant les hausses de budget ou risques détectés d’emblée.
L’essentiel est que l’équipe se sente prête à livrer, aussi motivée que le client.
Ben Aston :
Parlons aussi du plan de travail prévisionnel que tu proposes de joindre au PID. Quand tout n’est pas encore figé, comment arrives-tu à créer un plan, ton ébauche, pour guider l’équipe dès le début ?
Maik Stettner :
Pour être honnête, c’est surtout une estimation à ce stade. On s’appuie sur la SOW ou un devis existant, mais beaucoup de variables restent inconnues (réactivité du client, nombre d’itérations, etc.). Mais rien que d’avoir un plan, même imparfait, aide à préparer le staffing et la stabilité de l’équipe. Cela permet aussi d’identifier vite les points clés et d’encadrer le dialogue.
Même une esquisse est préférable au vide, car elle suscite la discussion et permet d’affiner peu à peu le déroulement réel.
Ben Aston :
Donner ce canevas, même imparfait, enclenche la dynamique de projet bien plus sûrement qu’une feuille blanche et des personnes hésitantes. Avoir un plan, même faux, est mieux que de ne pas en avoir du tout.
Le document d’initialisation (ou le brief) peut-il prendre d’autres formes ? Comment évolue-t-il durant le cycle de vie du projet ?
Maik Stettner :
Le guide proposé est un exemple de ce qu’on peut y inclure. Il y a un minimum, mais on peut faire autrement : par exemple, intégrer la partie risques ailleurs, ou des matrices de responsabilités (RACI), ou des rapports d’avancement, etc.
Peu importe la forme : l’essentiel est que tout le monde l’ait validé (écrit, partagé, évolutif). L’objectif, c’est que ce qui est livré soit clair, reconnu, et partagé selon ce cadre.
Ben Aston :
Bonne nouvelle ! Si après avoir écouté tu te demandes par où commencer, Maik a créé un excellent modèle de PID à télécharger. Merci Maik pour ta participation aujourd’hui, c’était super.
Maik Stettner :
Merci à toi de m’avoir accueilli.
Ben Aston :
Avec plaisir. Si ce que dit Maik t’intéresse, sache qu’il interviendra dans notre prochaine formation, « Maîtriser la gestion de projet digital », qui commence en septembre. Tu cherches une formation PM ? C’est un programme en 7 semaines, avec vidéos interactives, devoirs hebdomadaires, discussions de groupe et coaching en option. Rendez-vous sur digitalprojectmanagerschool.com avant que le cours n’affiche complet.
Pour rejoindre la discussion sur le document d’initialisation ou le brief, rendez-vous dans la section ressources du site ou rejoignez-nous sur Slack pour partager vos remarques, ou commentez l’article. Merci d’avoir écouté et à bientôt.
