Reprise du message précédent :
J'ai un projet de solution finale, j'ai besoin d'un gestionnaire

up

Merci

Je vous donnerai des nouvelles sur celui-là  

Up à quoi ?

Bonjour,
 
Après de nombreuses années à pisser du code, j'ai été promotionné chef de projet (je crois, cf la suite), sur un gros projet informatique, avec base de données, client lourd, site web et tout... avec une équipe de développement Offshore, dans le but de remplacer un logiciel vieillissant utilisé dans une des branches du groupe.
 
Vu que le métier de chef de projet, j'y connais rien, ben le projet dérape et j'ai de plus en plus l'impression d'être le capitaine du Titanic partit picoler avec les voyageur alors qu'approche l'iceberg.
 
Donc, on m'a demandé de :

• Faire l'interface entre les utilisateurs et l'équipe de développement.
• De bâcler 'écrire la doc: du cahier des charges au spécifications fonctionnelles détaillées.
• De concevoir la base de données.
• De fliquer vérifier le bon avancement de l'équipe de dév.

J'ai l'impression de rien contrôler, les livrables ne correspondent pas du tout aux attentes du client, et n'arrive pas à la cheville de l'existant. J'ai pas la maitrise de ce dernier (faut dire que celui ci se compose d'un client lourd en Windev (500 000 lignes de codes) d'un mélange de sites en Webdev(350 000 lignes de codes) et en PHP(150 000 lignes de codes) et d'une grosse base MySQL (800 tables, 35 go de données)). Les dev. changent eux mêmes la structure de la bdd et les spécification fonctionnelles, je me contente de leur envoyer des "OK" par Slack. J'ai aucune visibilité sur l'avancement du projet, on a donnée déjà 3 dates de livraisons (choisi en concertation avec les dev.) qui n'ont pas été respectées.  
 
J'ai beau remonter aux donneurs d'ordres que j'ai certaine lacunes en gestion de projets, et que je ne maitrise ni le métier, ni l'existant. Leur seule action jusqu'ici a été de passe l'équipe de dév de 3 à 8 développeurs.
 
Donc:

• La liste des tâches me parait bizarre comme tâche d'un chef de projet , surtout la partie conception de la bdd, et la partie spécification fonctionnelles. Surtout qu'en pratique les dev. ont l'air de bien mieux se débrouiller sans moi...  
• Au secours!
• Suis je bien un chef de projet, finalement?
• Que me conseilleriez vous pour reprendre la main sur le projet?  

Merci!

Mes sincères condoléances.
 
A+,

Si je comprends bien, vous décidez de rédiger la documentation *après* que le projet soit lancé ?!?

Là tout de suite, si j'étais parachuté pompier sur place :

- Recrutement d'un VRAI business analyst, de la même culture / nationalité que le client, et habitué à spécifier à destination des indiens (c'est-à-dire comme s'il s'adresse à des enfants de cinq ans).

- Pondre de la bonne doc, détaillée, et vite.

- Maintenir rigoureusement tes tableaux de bord, plannings, etc. S'en servir pour communiquer fréquemment face à la hiérarchie. Faire les analyses qui leur permettront de faire les arbitrages entre coûts, délais et qualité.

- Livrer des prototypes. Le besoin n'ayant clairement pas été mûri (par manque d'un bon BA) et comme on est déjà dans les choux, autant être agile : livrer des prototypes qui permettent de mieux cerner le besoin, prêtant le flanc à des critiques constructives, qu'il faudra documenter proprement.

- Grâce aux prototypes, passer sur des cycles de développement courts (de l'ordre de la semaine) de manière à avancer par petits pas rapides.

- Recourir à un prestataire extérieur (qui connaisse le business) pour la conception du modèle de données, et de la base.

Bon courage, et bonne chance.

 
 
Mince, je voulais dire drap. ça commence bien.  

En même temps en fait: Pour accélérer la livraison, il a été décidé que le développement commencerait au plus tôt, c'est à dire tout de suite...  
 
 
Je pense que c'est ce qu'il manque, le métier n'étant pas du tout trivial...  
 
Ce que j'essaye de faire, je passe mes journée à écrire. Je vais bientôt atteindre ma 400eme page de spécification fonctionnelle détaillée...
 
 
Ça, c'est la partie "gestion de projet" ou je suis largué:
 

• Tableaux de bord: j'en ai pas vraiment, juste une liste de tâche à faire.
• Planning: pour l'instant, il n'y en a aucun. Si j'écoute les indiens, toutes les tâches serait fini en une journée, et le produit livré la semaine prochaine.  

 
 
Ça, c'est fait, le problème, c'est que les utilisateurs ont commencé une grève des tests. Parce qu'il s'attendait sûrement a quelque chose de plus aboutit...
 
D'ailleurs, mon principal interlocuteur du cote des utilisateurs a posé sa dem. il y a 15 jours...
 
edit: err de tab...

 
D'aprés ce que je lis il ya des crispation des deux cotés ( MOE et MOA)
Tu dépends de quel service ? SI ?
D'aprés la description de ton rôle, tu es AMOA puisque tu dois faire l'interface entre le métier et les devs.
L'urgence est selon moi de crever l'abcès et de ré-impliquer tout le monde dans le projet.
Donc mettre en place une réunion de suivi hebdo si ce n'est pas déja fait, lever un peu la tête de tes specs et faire que tout le monde se reparle.
Ensuite repartir sur de bonnes bases en faisant bien valider tes specs par le client et le dev.
Dans ce type de relations tendus le mieux reste la méthode agile avec des sprint de quelques semaines et une forte implication du client. Vous utilisez quelle méthode ?

J'avais créé le topic en lien dans le 1er post du topic, alors je reviens sur celui-ci qui a réussi à atteindre la deuxième page.

Je suis en train de me former à Prince2 grâce au bouquin précité. D'ailleurs l'auteur est celui qui m'a formé à ITIL, et j'espère retomber sur lui pour me former à Prince2, c'est un excellent pédagogue.

Je compte passer les certifications cette année.

J'ai environ 8 années cumulées en gestion de projet, mais j'ai débuté sur le terrain, sans méthodologie, et j'en ai chié.

Les échanges tendus de la première page illustrent bien l'incompréhension qu'il peut y avoir sur la fonction même de chef de  projet (et de son utilité), car beaucoup de projets sont souvent gérés par des personnes incompétentes et/ou sans méthodologie, et qui pensent faire de la gestion de projet alors qu'elles ne font qu'un semblant de coordination. Cela donne une mauvaise image des chefs de projet, alors même que ceux-ci se révèlent rapidement très précieux s'ils apportent du sérieux et de la méthodologie.

Avec le recul, même quand j'étais à l'arrache, je me suis aperçu que j'adoptais des réflexes ou des façons de faire que j'assimilerais désormais à de la gestion de projet en cycle en V ou en mode agile, selon les cas.

Dans les projets que j'ai menés, j'ai fait un peu d'orga, un peu d'infra, et beaucoup d'intégration applicative.

J'espère relancer un peu le topic.

Le problème c'est que les beaux théoriciens de projet et des méthodes, les formateurs quoi, sont souvent des gens qui ne connaissent du projet que les reporting et les séances de coordinations et de planifications, sans avoir réellement mis les pieds dans le concret.

Faut avoir fait les 2 pour savoir réellement de quoi on parle. Le perdu dans son planning, une fois que ça dérape sur le terrain, ou que des actions rapides doivent être menées, est trop souvent largué.

Suis chef de projet depuis 15 ans dans l'industriel et je peux dire plusieurs choses qui vont faire mal aux certifiés:
- La gestion du planning sur MS project avec des lignes et des lignes de tâches est une entreprise bouffe temps qui ne sert qu'à rassurer le client et la direction, mais n'est jamais suivie et n'est de toutes manières pas réalistes (j'ai piloté des planning de 4500 tâches et plus...)
- Le chantier ne se passe jamais comme planifié et prévu dans le détail, le but étant finalement de rentre une réalisation conforme aux attentes et fonctionnelle, il faut savoir bien jongler avec les informations reçues, les personnes et l'organisation pour combler les vides et corriger les erreurs.
- Les séances ne sont constructives qu'en petit comité, avec des objectifs précis. Le reste, c'est de la perte de temps. Trop de clients et de directeurs organisent des réunions parce que c'est le job d'y être et qu'ils ont l'impression de suivre et de manager leur boîte. Le ou les CP convoqués y sont à la place de faire des choses constructives.
- Enormément des pseudos outils que les méthodologies prônent ne servent qu'à bouffer du temps que l'on a plus pour le concret.

Trop souvent, quand on me parle de formateurs, je n'ai en face de moi que des théoriciens qui ne se sont jamais confrontés à la réalité.

Ce genre de topic est donc surtout amusant, parce que finalement, il y a trop de type de CP pour que cela soit généralisable.

 
Salut lefredo1978,
 
On peut ne pas être d'accord, mais je relève quand même que tu te contredis. Je prends seulement un exemple : tu dis qu'il n'est pas possible de généraliser, mais tu généralises toi-même en disant que seules les séances en petit comité sont constructives. Ça prouve bien que tu as toi-même réussi à dégager une méthodologie dans l'environnement dans lequel tu te trouvais.
 
Et si on prend l'exemple de Prince2, puisque c'est la méthodologie que j'étudie en ce moment, ce qui me plaît c'est justement qu'elle est le résultat de la mise en communs des meilleures pratiques de plusieurs professionnels qui ont l'expérience du réel. Tu peux faire une recherche sur le Chaos Report du Standish Group, et peut-être que ça t'amènera à avoir une vision moins stéréotypée de qui imagine ces méthodes.
Et le bouquin que je lis à ce sujet a été rédigé par quelqu'un qui a une grosse expérience de gestion de projet dans le domaine industriel.
 
Je ne vais pas m'attacher à déconstruire point par point ce que tu dis, mais il y a d'autres contradictions, et surtout l'expérience que tu décris semble (j'ai peut-être tort) être celle d'un chef de projet en interne qui n'a que peu de compte à rendre, ou en tout cas pas de façon contractuelle.
Mais comment ferais-tu si tu étais prestataire de service et que ton client voulait te confier la gestion d'un projet ? Tu sais par exemple que dans un contrat il peut y avoir des pénalités si des engagements ne sont pas respectés.
 
Comment gérerais-tu le fait que ton planning dérive complètement et de ne pas être payé (ou d'avoir beaucoup de pénalités de retard) parce que tu as mal anticipé certaines choses ?
Penses-tu que tous les chefs de projet sont mauvais ?
Ne penses-tu pas qu'il est plus simple si tout le monde au début d'un projet parle le même langage ?
 
4500 tâches ça te semble beaucoup j'imagine, mais comment ferais-tu si tu en avais 10 ou 100 fois plus et que les enjeux financiers étaient 10 ou 100 fois plus importants mais sans avoir 10 ou 100 fois plus de temps ? Penses-tu qu'on te confierait le projet ou toi-même penses-tu que tu gérerais de la même manière ?

On ne peut pas généraliser le type de CP. Il y en a beaucoup et le terme reste vague. Les obligations et les compétences aussi. Implanter une petite pompe, 20m de piping est un peu d'isolation ou construire une raffinerie, ce n'est pas le même métier et cela ne se gère pas de la même manière.
 
Alors oui, je généralise sur les séances car c'est du vécu, de toutes tailles de projets auxquels j'ai participé. L'idéal c'est entre 5 et 8 personnes. Après il y a ceux qui n'ont rien à faire là et qui perdent leur temps, ceux qui font chier pour des détails parce qu'il faut montrer qu'ils font quelque chose et qu'ils ont des idées, et ceux qui reviennent sans arrêt sur des trucs déjà discutés et décidés. Perte de temps pour tous le monde.
 
Pour répondre à tes questions:
Je n'ai jamais été chef de projet qu'en prestataire de service justement. Je n'ai jamais eu cela à faire en interne. Après, j'avoue que cela restaient des projets de tailles modestes, disons jusqu'à 10 millions d'euros.  
J'ai géré des projets pour la chimie, la pharma, l'agroalimentaires, etc... Expérience large, avec des clients très différents, qui ont des manières de travailler très différentes également.
 
Je ne connais pas le Prince2, ni qui l'a écrit d'ailleurs. Je ne vais donc pas épiloguer sur cette méthode, qui en est une parmi d'autres, l'efficacité dépendant de toutes manières de celui qui l'applique et non de celui qui l'a crée.
 
Pour tes autres questions:
Les pénalités font partie d'une partie du job. Elles sont rarement uniquement dues au prestataire de service et sont donc négociable. Un chef de projet digne de ce nom ne laisse pas dériver sans réagir et sans en avertir son client. Il a a sa charge de trouver les solutions pour livrer dans les meilleures conditions. D'ailleurs, le client n'a pas intérêt non plus à trop écraser le prestataire de service, son but premier est d'avoir un ouvrage rendu conforme à ses attentes, pas de récupérer le max de fric sur le dos de l'ingé. Mais si réelle grosses dérives il y a , le CP sera viré car pas compétant. Sinon, c'est qu'elles ne sont pas dues à sa négligence, donc elles ne déboucheront pas forcément sur des pénalités. Pénalités qui de toutes manières sont limitées dans un contrat.
 
Non, tous les chefs de projet ne sont pas mauvais, je ne vois pas ce qui pourrais te faire penser cela dans mon poste.
 
Oui, c'est plus simple si tout le monde parle le même langage, mais ce n'est jamais totalement le cas. Il est bien rare que le client ait un cahier des charges bien rédigés qui ne laisse pas place à l'interprétation.  
C'est pour ça que les séances avec le client de démarrage et de préparation sont importantes et ne doivent jamais être négligées, comme il est important de toujours bien référencé les décisions prises et les informations données.
 
Pour ta dernière question, les 4500 tâches c'était pour un projet à 150 millions de CHF et je n'en étais pas le CP. Mais là, on revient à ce que je disais, ce n'est plus le même métier. Le CP, ou dans ce cas le directeur de projet, ne fait QUE gérer, du reporting et de la politique auprès du client. Il a le temps de s'occuper de faire de joli tableau et document, il est payé pour ça (j'exagère un peu).  
Si tu rajoutes 10x ou 100x cela, cela n'entre plus dans mes compétences de gestion. Et ce n'est plus le métier dont je parle. Il est illusoire de prétendre que l'on peut gérer un projet de la taille dont tu parles simplement en ayant suivi une formation et lu un bouquin. Cela qui dit cela est un charlatan.  
Il n'y a d'ailleurs pas tant de "chef de projet" qui ont l'occasion de gérer des projets de plusieurs centaines de millions d'euro dans leur carrière.

 
Tout ne mérite pas d'être géré en mode projet, mais même l'installation d'une petite pompe peut être modélisée selon une méthodologie projet. Je ne pense pas que ça soit là l'objet de la discussion.
 

Certes, mais dans ce cas, d'un point de vue purement méthodologique :
- ça veut dire que le chef de projet convie aux réunions des personnes qui ne devraient pas être là,
- ou bien que les instances qui décident n'ont pas pris suffisamment part aux projets pour trancher,
- ou bien que le(s) document(s) qui font foi pour cadrer et valider les différentes étapes du projet n'ont pas été mis à jour et/ou communiqués
- ou bien tout a été respecté mais les personnes qui prennent par à la réunion ne suivent pas la méthodologie
 
Et enfin, plus simplement, il peut y avoir des facteurs autres, comme un souci de management. Et là où je te rejoins, c'est que l'expérience a beaucoup plus de valeur que la certification. La certification permet surtout de faciliter la communication entre différents intervenants qui partage le même référentiel méthodologique.
 

On est entièrement d'accord. La méthodologie n'est qu'un outil en soi, c'est comme un diplôme, ça ne remplace pas l'expérience. Ma "thèse" c'est que si plus de personnes étaient formées au(x) même(s) référentiel(s), cela générerait moins souvent les situations que tu décris ici.
 

Certes, c'est le jeu commercial, mais là ça sort de la gestion de projet.
 

Je te questionnais par rapport à ton post précédent où tu dis que ça ne se passe jamais comme prévu. J'ai envie de dire "oui, évidemment". C'est là où un bon chef de projet fera en sorte que ces écarts soient réduits et que les risques de dérives soient le mieux maîtrisés possibles.
Et le but n'est pas de dire qu'une certification va permettre de gérer tout ça sans heurt, mais plutôt de faire prendre conscience au chef de projet et à tous les acteurs qui partagent le même référentiel qu'il existe cette notion d'écart ou de risque. Il m'est arrivé de voir des projets démarrer promis à l'échec simplement parce qu'ils n'avaient pas envisager certains facteurs de risques pourtant évidents.
 
 

Nous sommes là aussi d'accord, mais tu admets que de parler le même langage aide. Et je ne parle même pas du langage du métier, mais du langage lié à la gestion du projet lui-même.
 

Je trouve que ça n'est pas vraiment exagérer que de dire ça, c'est un métier à part entière. Un chef de projet, selon la taille du projet, peut avoir plusieurs rôles, mais il y a quand même bien un moment où il faut que quelqu'un reporte à celui qui finance le projet et/ou à ceux qui vont bénéficier les produits du projet. Et même si on n'a pas besoin de certification pour ça, tu comprends bien que s'il y a des choses communément admises, il est aussi possible d'aller plus loin dans la méthode et que c'est plutôt bénéfique pour tous.
 

Je ne pense pas que quiconque ici prétende cela.

Je drapalise.

 
Ca peut effectivement, être géré en mode "projet". Mais suivant le niveau de difficulté, cela ne veut plus dire grand chose. Ce que je voulais dire, c'est que tu ne vas pas pouvoir appliquer les mêmes théories de gestion et de mangement quand tu gères un projet seul ou que tu dois diriger une équipe de plusieurs dizaines de personnes. Formellement, le titre est le même : chef de projet, mais concrètement, ce sont deux métiers qui n'ont plus grand-chose en commun.
 

 
M'ouais, le même référentiel, j'y crois pas trop. Les termes techniques types sont les mêmes quelle que soit la méthode. C'est la manière d'aborder le problème qui va changer un peu, mais même pas tant que ça. En fait, la certification, est surtout un moyen marketing de dire aux clients qu'ils peuvent avoir confiance, car tu as été "certifié". Par qui? Pour quoi? ça c'est un peu plus flou. Mais n'étant moi-même pas certifié, mais ayant dû collaborer avec des chef de projet PTP ou autre certification, je n'ai pas eu l'impression qu'ils en savaient plus que moi, ou qu'ils le faisaient mieux.
Quant aux personnes présentes aux réunions... tu oublies le facteur politique, présent dans les projets conséquents, où il ne faut surtout pas qu'il soit dit que la personne engagée dans un des domaines du projet n'ait pas donné son avis sur l'un ou l'autre des sujets, même s'il n'est pas pertinent.
 

 
Pas convaincu, car finalement, la gestion de projet c'est surtout une question de bon sens et de logique. Et on constate vite que cela n'est pas un référentiel universel. Le problème est souvent entre le prestataire et le client, quand ce dernier participe au projet de manière relativement active. Parce qu'alors, les intérêts ne sont pas les mêmes. Le prestataire va chercher absolument à rendre un ouvrage conforme aux attentes du client, dans les temps et au prix souhaité. En espérant ne pas perdre d'argent.
Le client, lui, va vouloir le truc le mieux possible, c'est clair. Mais ses représentant, vont le vouloir tout en se faisant bien voir afin de garder leur place, ou d'être promu. Cela distord un peu les relations et les aspirations, ce qui fait qu'il y a divergence sur la durée. Cela n'a pas forcément de grands impacts, mais dans certains cas cela peut devenir problèmatique. Avoir suivi la même méthodologie ne changera malheureusement pas cela.
 

 
Oui est non. Le chef de projet a toujours envie que commercialement, cela fonctionne aussi. Il n'y a plus tellement d'entreprise qui paie sans discuter si cela n'était pas prévu au départ. Cette gestion est donc indispensable, même si elle est souvent perçue comme peu intéressante par le CP.
 

 
A démontrer... là, comme ça, je ne suis pas sûr de voir de quoi tu veux parler.
 
 

 
C'est un métier à part entière, qui n'est plus vraiment le CP avec les pieds dans le terrain. C'est souvent nécessaire, effectivement, mais cela reste de la politique à mon avis.
 

 
Non, mais il fallait le préciser tout de même

En fait, l'élément qui rentre en ligne de compte dans tes remarques est la dimension managériale, ou les aspects de communication. En effet, tout le monde n'a pas des qualités innées de manager ni des talents d'orateur. Néanmoins, la méthodologie, si une méthodologie est suivie, peut être la même.  L'intérêt de ces méthodologies sont qu'elles sont adaptables et "scalables" même si je n'aime pas trop ce mot.

Expérience, communication, management... OK. Evidemment ça se passe mieux quand on maîtrise ces autres aspects.
Cela dit, l'intérêt d'une méthodologie est aussi de parler le même langage et d'être d'accord sur le processus à suivre, ce qui limite le risque politique. Tout dépend évidemment, et encore une fois, de la taille du projet et des enjeux, mais si on  parle de méthodologie, le but est de pouvoir abstraire, généraliser, prendre du recul.

Expérience, communication, management... Oui, oui, et re-oui, mais ce ne sont que des outils complémentaires, ça ne remplace pas la méthodologie.
Par exemple, il est classique de se mettre d'accord avant le projet (ou à son début) sur la manière dont il va se dérouler : fréquence des réunions, lotissement, membres de l'équipe projet (comité pilotage, ou équipe opérationnellement pour la réalisation), documents à échanger/valider.
Ce sont toutes ces choses qui sont en effet du bon sens et de la logique qu'on retrouve dans une méthodologie. Et je suis prêt à parier que tu appliques un nombre important de ces conseils/bonnes pratiques pour gérer tes projets, sans savoir que des personnes ont cherché aussi à généraliser ces pratiques en créant une méthodologie.
Avec l'expérience, ou lorsqu'on est doté de bon sens, tout ceci semble évident mais comprends aussi à l'inverse qu'il y a des personnes qui n'ont pas la moindre idée de comment gérer un projet et que d'être formé à une méthodologie ne peut être qu'une bonne entrée en matière, surtout quand cette méthodologie est basée sur un nombre important de retours d'expérience.

Et réciproquement, il n'y a plus tellement d'entreprises qui réalisent des choses si elles n'étaient pas prévues au départ (il y a ceux qui ne veulent pas payer si ce n'est pas fait, et ceux qui ne veulent pas faire si ce n'est pas payé). Certains chefs de projet gèrent les contrats, d'autres non.
Dans la méthodologie que j'apprends, je n'en suis pas encore à la gestion budgétaire, je ne sais pas ce qui est dit à ce sujet. Dans mon boulot, au quotidien, je dois faire de la gestion budgétaire, et j'ai en effet intérêt à ce que commercialement ça soit un succès. Et c'est en effet une grande différence entre la théorie et la pratique, mais cela ne remet pas en cause qu'on peut travailler sur de bonnes bases, communes. D'ailleurs, en kick off ce mercredi, comme c'est l'usage chez mon employeur, j'exposerai notre méthodologie (interne à mon employeur mais relativement généraliste car pleine de bon sens) de projet à notre client pour qu'on soit d'accord sur la manière dont celui-ci se déroulera.

Je ne vois pas ce que tu veux ce que je démontre parce que je parle de faits, il n'y a pas vraiment d'arguments. Est-ce que nous sommes d'accord sur le fait qu'il faut gérer les risques qui peuvent mettent en péril le projet (ou son résultat) ?

Il y a différents niveaux de gestion de projets en effet. L'intérêt d'une méthodologie basée sur les bonnes pratiques et les retours d'expérience (je continue à parler de Prince2), c'est aussi le fait que la méthodologie elle-même encourage celui qui va l'appliquer à l'adapter à son contexte. Il est donc  possible d'élaguer si tu estimes que certaines parties ne sont pas nécessaires. Mais si les projets sont si courts et si insignifiants qu'ils ne nécessitent peu ou pas de communication, peu ou pas de suivi, on en revient à ton exemple de changement de pompe, il n'est peut-être pas nécessaire d'entrer dans des considérations méthodologiques.

Je crois qu'on est assez d'accord.
Je ne suis pas certifié, donc je ne sais pas exactement ce que l'on demande, mais je peux affirmer que je suis effectivement la majorité des éléments mis en avant dans ces méthodologies.
Simplement parce que j'ai du recul et de l'expérience et que si le bureau d'étude ne pose pas une méthodologie, effectivement discutée avec le client au départ d'un projet de taille correcte, c'est le client qui le fait.
J'ai bossé pour de grosses multi, il est clair qu'ils ont des manières de travailler standardisées qui correspondent aux méthodologies de gestion les plus communes.
Maintenant je bosse pour une relative grosse boite d'ingénierie et la méthode interne suit aussi ces "règles".
Je n'essaie pas de dire que ces formations ne sont pas intéressantes, je pense que leur nécessité quand on bosse dans une grosse société d'ingé, ou pour de gros clients, est surtout marketing, car les procédures internes font que l'on va suivre l'une ou l'autre de ces méthodologies de toutes manières, car elles correspondent aux bonnes pratiques et sont appliquées grâce aux procédures internes.
L'ingé indépendant et seul, ou le nouveau CP dans une équipe réduite peut y trouver son compte, car il n'aura pas une structure et les retours d'expériences d'autres CP plus expérimentés pour le soutenir et lui donner une méthode.

Je critiquais un peu plus les "formateurs" qui ne sont pas assez souvent des gens de terrains avec une réelle expérience, ou des gens qui transposent leur expérience d'un domaine vers un autre, alors que cela ne fonctionne pas forcément.
Un CP en informatique ou réseau ne pourra pas forcément me former alors que je suis principalement actif dans la chimie.
C'est en ce sens que je dis que c'est surtout marketing. Je pourrais me faire certifier, à un bon niveau en plus vu la taille des projets gérés, mais cela ne m'apportera pas grand chose, sinon un titre à mettre sur la carte de visite qui rassurera peut être le client. Mais en cela, le nom du groupe pour lequel je bosse est déjà une garantie pour beaucoup de clients.

Oui.
 

Plutôt d'accord, l'expérience compte (enfin il me semble) toujours plus que les certifications. Mais à choisir entre deux juniors, je suppose qu'une certification peut faire la différence.
Dans certains cas, il est tout de même important de parler le même langage, pas forcément d'avoir une certification, mais au moins des notions. Même si on peut transposer certains rôles ou certaines phases/séquences entre deux méthodologies, il y a quand même des approches différentes. Lorsque tu parles de l'industrie (lourde), je pense qu'ils seront un peu plus hermétiques à la gestion "agile" de leurs projets, alors que c'est courant dans le domaine informatique.
 

Pourtant si, et c'est bien là son intérêt : la méthodologie a une hauteur de vue qui ne a fait pas dépendre d'un secteur d'activité ou d'un métier particulier.
Cela dit, comme tu l'expliques, tu n'as pas l'air d'en avoir besoin, je parle de manière générale.