Chef de projet Questions d'entretien & Réponses

Exemple de réponse

J'ai repris un projet de déploiement CRM qui accusait 3 mois de retard et dépassait le budget de 40 %. Le chef de projet précédent était parti et le moral de l'équipe était au plus bas. Dès ma première semaine, j'ai organisé des entretiens individuels avec chaque membre de l'équipe et les principales parties prenantes pour comprendre les vrais problèmes. J'ai identifié trois causes profondes : le périmètre avait été multiplié par 3 sans ajustement du planning, le prestataire ne tenait pas ses engagements sur les intégrations, et deux membres clés avaient été réaffectés à d'autres projets. J'ai présenté un plan de redressement : renégociation du périmètre avec le sponsor métier, en reportant 30 % des fonctionnalités en phase 2 pour concentrer la phase 1 sur les indispensables. J'ai remonté le problème de performance du prestataire aux achats, qui ont appliqué des pénalités contractuelles et obtenu un développeur senior dédié. J'ai sécurisé un remplacement partiel pour les membres réaffectés. Nous avons livré la phase 1 avec un mois de retard (au lieu de trois), dans le budget révisé, avec un taux de satisfaction des parties prenantes de 92 %. Les fonctionnalités de la phase 2 ont été livrées au trimestre suivant.

Exemple de réponse

Deux ingénieurs seniors de mon équipe avaient un désaccord fondamental sur l'architecture d'une migration de données : l'un défendait une bascule unique (big bang), l'autre une approche progressive. Le désaccord avait pris une tournure personnelle et perturbait les réunions. J'ai rencontré chacun séparément pour comprendre ses préoccupations. Le partisan de la bascule unique craignait de devoir maintenir deux systèmes en parallèle. Le partisan de l'approche progressive craignait des pertes de données lors de la bascule. Les deux préoccupations étaient légitimes. J'ai organisé une revue de conception structurée où chacun présentait son approche avec une analyse des risques. J'ai demandé à l'équipe d'évaluer les deux options selon trois critères : risque de perte de données, complexité opérationnelle et calendrier. Les données montraient que l'approche progressive était moins risquée, mais plus exigeante. J'ai tranché : approche progressive, avec de l'automatisation pour alléger la gestion des systèmes en parallèle (répondant ainsi à la préoccupation du premier ingénieur). J'ai reconnu publiquement la validité des arguments du partisan de la bascule unique et lui ai confié la responsabilité des travaux d'automatisation. La migration s'est déroulée sans aucune perte de données.

Exemple de réponse

À mi-parcours d'une migration de plateforme prévue sur 6 mois, l'équipe conformité a identifié de nouvelles exigences réglementaires représentant 8 semaines de travail supplémentaires. Le sponsor métier attendait toujours la date de livraison initiale. J'ai immédiatement réalisé une analyse d'impact : les nouvelles exigences ajoutaient 320 heures de développement et 80 heures de tests. J'ai présenté trois options au comité de pilotage. Option A : décaler la date de 8 semaines pour absorber le périmètre complet. Option B : recruter 3 prestataires pour tenir la date initiale, avec un coût supplémentaire de $90K. Option C : reporter les fonctionnalités non liées à la conformité pour maintenir la date et le budget, puis les livrer 6 semaines plus tard. J'ai recommandé l'option C, car la conformité n'était pas négociable et plusieurs fonctionnalités reportées n'étaient de toute façon pas nécessaires avant le troisième trimestre. Le comité de pilotage a approuvé. J'ai mis à jour le plan de projet, communiqué le changement à toutes les parties prenantes avec une justification claire, et livré la version axée conformité dans les délais. Les fonctionnalités reportées ont été livrées 5 semaines plus tard. L'essentiel était de présenter des options avec leurs compromis, sans se contenter d'annoncer une mauvaise nouvelle.

Exemple de réponse

J'ai géré un projet de refonte de site web avec des membres d'équipe à New York, Londres et Bangalore, soit trois fuseaux horaires avec seulement 3 heures de chevauchement. J'ai mis en place une structure de communication respectueuse des fuseaux horaires : communication asynchrone en priorité via Slack et Confluence pour tout ce qui ne nécessitait pas d'échange en temps réel, un point quotidien de 15 minutes pendant la plage commune pour les seuls blocages, et des sessions hebdomadaires approfondies avec rotation des créneaux pour qu'aucun membre ne soit toujours contraint de participer tard le soir. J'ai créé une documentation de sprint détaillée permettant à l'équipe de Bangalore de reprendre le travail là où l'équipe de New York l'avait laissé, et inversement. J'ai également investi dans la cohésion d'équipe : événements virtuels mensuels et points vidéo trimestriels avec chaque membre. Le projet a été livré dans les délais avec un score de satisfaction de 4,5/5. Deux membres de l'équipe m'ont dit que c'était le projet distribué le mieux géré qu'ils aient connu.

Exemple de réponse

Je choisis en fonction de trois facteurs : la stabilité des exigences, la flexibilité des parties prenantes et l'expérience de l'équipe. Le Waterfall convient quand les exigences sont clairement définies et peu susceptibles d'évoluer (projets de conformité réglementaire, construction, matériel), quand le client a besoin d'un prix et d'un calendrier fixes dès le départ, ou quand le projet comporte des dépendances strictes devant suivre une séquence. L'Agile convient quand les exigences vont évoluer au fil des retours utilisateurs (développement produit, transformation numérique), quand livrer de la valeur de façon incrémentale prime sur l'attente d'une solution complète, et quand l'équipe est habituée au travail itératif. En pratique, la plupart des projets bénéficient d'une approche hybride : exécution Agile dans un cadre de gouvernance Waterfall. Je définis le périmètre global et les jalons en amont (pour l'alignement budgétaire et parties prenantes), mais j'exécute en sprints avec la flexibilité d'ajuster les priorités dans le périmètre. L'erreur à éviter : utiliser l'Agile comme prétexte pour ne pas planifier, ou le Waterfall comme prétexte pour refuser toute adaptation.

Exemple de réponse

J'utilise une combinaison de techniques selon la phase du projet. En phase amont (ordre de grandeur) : l'estimation par analogie, en comparant à des projets similaires passés ajustés selon la complexité. Cela donne une fourchette, pas un chiffre précis. 'Sur la base du projet CRM de l'an dernier, ce projet représente 4 à 6 mois.' En phase de planification : l'estimation ascendante. Je décompose le travail en tâches, l'équipe estime chaque tâche (j'utilise le Planning Poker pour la pondération relative), puis j'intègre les dépendances et les marges. J'applique la règle du 1,5x : quelle que soit l'estimation de l'équipe, je multiplie par 1,5 pour tenir compte des inconnues, de la complexité d'intégration et des changements de contexte. Pour chaque tâche, je demande trois estimations : optimiste, probable et pessimiste. La formule PERT, (O + 4M + P) / 6, donne une moyenne pondérée. Je présente toujours des estimations sous forme de fourchettes, jamais de chiffres uniques. Et je réestime à chaque jalon important à mesure que nous en apprenons davantage sur le projet. L'estimation la plus dangereuse est celle qui n'est jamais révisée.

Exemple de réponse

Je tiens un registre des risques actif, révisé chaque semaine. Pour chaque risque, je consigne : description, probabilité (1 à 5), impact (1 à 5), score de risque (probabilité x impact), responsable, stratégie d'atténuation et indicateurs déclencheurs. Je classe les risques en quatre catégories : techniques (nouvelle technologie, complexité d'intégration), ressources (dépendance à une personne clé, lacunes de compétences), externes (retards prestataires, évolutions réglementaires) et calendrier (chaînes de dépendances, incertitudes d'estimation). Pour les 5 premiers risques par score, je développe des plans d'atténuation spécifiques. Quelques exemples : pour une dépendance à une personne clé, je m'assure du partage de connaissances et de la documentation. Pour un risque prestataire, je maintiens une relation avec un prestataire de secours. Pour un risque calendaire sur le chemin critique, j'ajoute des marges et identifie les tâches qui peuvent être parallélisées. Je distingue l'atténuation des risques (réduire la probabilité ou l'impact avant qu'ils se réalisent) de la planification de contingence (que faire si le risque se matérialise). Chaque responsable de risque fait un point hebdomadaire. Les risques qui se matérialisent deviennent des incidents et sont suivis dans le journal des incidents, avec un responsable et un calendrier de résolution.

Exemple de réponse

Je suis quatre catégories d'indicateurs. Calendrier : tendance de vélocité des sprints (l'équipe accélère-t-elle, est-elle stable ou ralentit-elle ?), taux d'atteinte des jalons et indice de performance calendaire (valeur acquise / valeur planifiée). Budget : dépenses réelles vs planifiées, rythme de consommation et estimation à terminaison. Qualité : densité des défauts, taux de réussite des tests et pourcentage de retravail (quelle part du travail est retournée). Équipe : satisfaction (sondages mensuels), heures supplémentaires (des heures supplémentaires prolongées sont un signal d'alerte) et risque d'attrition. Je présente ces indicateurs sur un tableau de bord d'une page avec un code couleur rouge/orange/vert pour chaque catégorie. L'indicateur le plus important n'est pas un chiffre isolé : c'est la tendance. Une vélocité stable à 30 points de story est correcte. Une vélocité qui était à 40 au sprint précédent et qui est maintenant à 30 est un signal d'alerte qui mérite investigation. Je suis aussi un indicateur honnête, difficile à manipuler : les dates de livraison réelles vs prévues pour les jalons déjà atteints. Si nous livrons systématiquement en retard, notre processus d'estimation doit être revu.

Exemple de réponse

Je commencerais par avoir une conversation franche avec la personne qui part, sur son calendrier et sa disponibilité pour faciliter le transfert de connaissances. Même 2 semaines de passation structurée ont de la valeur. J'évaluerais immédiatement l'impact : quels travaux dépendent des connaissances uniques de cette personne ? Sur quelles tâches travaille-t-elle actuellement ? Où sont les points de défaillance uniques ? Ensuite, j'agirais sur trois fronts. Capitalisation des connaissances : sessions intensives de documentation et enregistrements de ses travaux. Une documentation imparfaite vaut mieux que pas de documentation du tout. Redistribution de la charge : réaffecter ses tâches selon la capacité et les compétences des autres membres. Soyons réalistes : l'équipe ralentira temporairement. Communication : informer les parties prenantes de l'impact sur le calendrier et des mesures prises. Je préfère annoncer une mauvaise nouvelle tôt avec un plan plutôt que les surprendre par un retard en livraison. Pour le remplacement : lancer immédiatement le processus de recrutement, mais planifier la continuité du projet sans attendre le remplaçant. Aucun projet ne devrait être tributaire d'une seule personne : si c'est le cas, c'est un risque que j'aurais dû anticiper et atténuer plus tôt.

Exemple de réponse

Je commencerais par rendre les conflits visibles. Souvent, les parties prenantes ignorent qu'elles sont en conflit, car chacune a communiqué ses priorités au chef de projet séparément. J'organiserais une session d'alignement avec toutes les parties prenantes clés, en présentant : la liste complète des exigences, les ressources et le calendrier disponibles, et le fait que tout ne peut pas être livré en même temps. J'utiliserais un exercice de classement forcé : chaque partie prenante dispose de 100 points à répartir sur les fonctionnalités. Cela rend les arbitrages concrets. Lorsque les classements divergent significativement, je facilite une discussion : quel est le cas métier pour chaque priorité ? Quel est le coût du retard ? Souvent, le simple fait d'entendre les raisons de l'autre résout le conflit. Si ce n'est pas le cas, j'escaladerais au sponsor du projet pour une décision d'arbitrage, en m'appuyant sur les données de l'exercice et sur ma recommandation. Après l'alignement, je documenterais les priorités convenues et les diffuserais largement. Quand les priorités changent inévitablement, je recommencerais le processus plutôt que de trancher seul.

Exemple de réponse

J'agirais vite : les dépassements budgétaires s'aggravent avec le temps. D'abord, une analyse des causes racines : pourquoi sommes-nous en dépassement ? Causes fréquentes : extension de périmètre (du travail ajouté sans ajustement budgétaire), erreurs d'estimation (tâches plus longues que prévu), évolution des coûts de ressources, ou facteurs externes (hausses de prix prestataires, exigences réglementaires). Ensuite, je présenterais la situation et les options au sponsor du projet. Option A : augmenter le budget de 25 % pour livrer le périmètre complet, en justifiant la hausse par des éléments précis sur ce qui a changé. Option B : réduire le périmètre pour tenir le budget initial, en précisant les fonctionnalités reportées et leur impact métier. Option C : étaler dans le temps (si le dépassement est lié aux coûts de surcharge, diluer le travail dans la durée peut revenir moins cher). Option D : optimiser l'exécution : peut-on réduire les coûts par l'automatisation, la renégociation des tarifs prestataires ou des ressources différentes ? Je présenterais ma recommandation avec les données à l'appui. Quelle que soit la décision, j'instaurerais des contrôles budgétaires plus stricts : revues hebdomadaires au lieu de mensuelles, points de validation pour toute nouvelle exigence et actualisation des estimations pour le travail restant. L'essentiel : une surprise budgétaire ne devrait jamais en être une. Communiquer tôt.

Exemple de réponse

J'investiguerais avant de prescrire. D'abord, j'analyserais les données : sur quels types de travaux ratons-nous nos objectifs ? Est-ce systématiquement sous-estimé, ou des interruptions détournent-elles les membres de l'équipe du travail du sprint ? Y a-t-il des blocages de dépendances où une équipe en bloque une autre ? Ensuite, j'aborderais le sujet en rétrospective avec l'équipe : les objectifs de sprint leur semblent-ils réalistes ? Voient-ils des problèmes systémiques que je ne vois pas ? Les causes racines fréquentes que je rechercherais : surengagement (l'équipe planifie à 100 % de sa capacité alors que la réalité est à 70 % en raison des réunions, du support et des interruptions), mauvaise estimation (les stories sont systématiquement 2 à 3 fois plus grandes que prévu), exigences floues (les stories entrent dans le sprint et passent 2 jours en clarification) et changements de contexte (membres tiraillés par des incidents ou d'autres projets). Mes correctifs dépendent du diagnostic : intégrer une marge de capacité de 30 %, améliorer l'affinage des stories pour détecter les ambiguïtés avant le sprint planning, négocier du temps de concentration protégé avec la direction, ou découper les stories en éléments plus petits, plus faciles à estimer et à terminer.