Certifications à la mode

quel certification pour un poste PMO ?

PMI serait la meilleure certification, mais il en existe beaucoup.

https://www.leblogdudirigeant.com/les-methode-de-gestion-de-projet/

https://blog-gestion-de-projet.com/pmo-et-chef-de-projet/

https://www.pmi.org/

https://www.piloter.org/projet/

Hello Yxil,

Entre Scrum.org et ScrumAlliance, en dehors de l'expiration quelles sont les différences et que conseilles-tu?

svp quelle formation recommandez vous ? je suis intéressée par chef de projet digital (pour bosser avec une équipe de dev application ou site web ) mais je veux bien apporter de la valeur .le tri est difficile sur google beaucoup de formation et moyen de financement ....

Difficile, pour le coup, de répondre.

Chef de projet, il y a à boire et à manger. Beaucoup de boîtes confondent le métier de chef de projet avec PO, PMO, et même lead dev. Certaines boitent ne comprennent tellement rien à l'IT qu'elles se retrouvent à faire d'un lead dev un mini chef d'équipe. C'est le problème des métiers non réglementés.

Et dans "chef(fe) de projet", il y a des différences notables selon le type de métier. Un CDP commercial n'a rien à voir avec un CDP dans l'IT. Un CDP dans le domaine du dev ne fait pas de choses qui ont tellement un rapport avec un CDP dans le domaine du réseau, etc.

Ce que vous évoquez, CDP d'une équipe de dev (donc appli ou web), c'est plus une formation de Chef de projet SI qui correspond. De plus, CDP, c'est un éventail large, c'est le plus haut dans les boîtes qui fonctionnent en pyramide, ça a une vision de l'ensemble du projet, ce qui n'est pas le cas d'un PO, PMO, etc, donc il faut aussi se demander si c'est véritablement à cette échelle-là que vous voulez bosser.

Les responsabilités et les contraintes ne sont pas les mêmes. Même si le métier de CDP est hautement plus facile intellectuellement que développeur, par exemple, il n'empêche qu'en termes de responsabilité, de stress, de contraintes et parfois de complexité, quand il faut se retrouver à faire des stratégies qui partent dans de la formulation mathématique avec des démonstrations sous format de scénarios, c'est hautement plus difficile et il faut avoir préalablement un petit bagage niveau math spé. Il faut être à l'aise avec le fait de faire des démonstrations à des grands pontes toute la journée, établir des théories, des stratégies, des plans, etc., qui doivent être plus que pertinents et démontrer une valeur réelle, puisque, si vous faites un mauvais choix stratégique, avez mal réfléchi aux conséquences : à quand être en dette technique, la rattraper, comment, à être en complexité accidentelle, à mettre n personnes selon les complexités attendues des features, à les repositionner, à savoir maximiser l'autogestion des devs, puisque c'est eux qui ont réellement l'expertise, pas quelqu'un d'autre, à savoir maximiser leur retour, leur retour d'expériences, leur évolution techniques, etc., etc., etc. Et donc, vous pouvez littéralement couler la boîte avec une mauvaise réflexion...

Un mauvais recrutement, ça coute très cher à une boite, alors je vous laisse imaginer les conséquences d'une mauvaise gestion.

Il faut aussi prendre en compte que notre métier évolue très vite et constamment, ainsi que nos pratiques, il faut être capable de reposer entièrement sa manière de penser la gestion, de mettre son égo de coté, de repartir dans des formations constamment (comme tout les métiers de l'IT), de s'adapter à la personnalité de chacun, etc. Donc il faut plein d'autres qualités que celles fournies par un papier, pour simplement commencer à faire son métier un peu correctement.

Encore une fois, là je parle d'un vrai métier de CDP, pas de ce que font certaines boîtes qui n'y comprennent rien et s'inventent des nomenclatures dans l'organisation, à cause du fait que ce ne soit pas un métier réglementé. Avec un type qui se retrouve marqué CDP sur sa fiche de paie et fait du PO, par exemple.

Dans un grand groupe, le PDG (ou les équivalents que sont les directeurs) donne les clés aux CDP, qui est l'équivalent du fait qu'un général donne les clés à un colonel dans les armées qui va gérer son régiment. Le CDP a la responsabilité de tout ce qui vient avec, le product owner, le lead dev, le dev, le business analyst, le product manager, etc. Bref, tout ce qu'il y a comme élément dans un projet, tant humain que le reste, il en est le Chef... Charge à lui de répartir correctement les autres rôles. Il faut être conscient que si vous faites une faute à ce niveau-là, les conséquences ne sont donc pas les mêmes... Et il faut encore plus être conscient que si vous êtes dans une boite qui ne comprends rien de base à ce qu'est un CDP et en fait un P.O. dans son quotidien et un CDP sur le papier, pour ne prendre que ce format, vous allez être dès le départ dans une mauvaise posture.

Et puis, c'est toujours pareil, un CDP, ça n'a de sens que dans des gros projets, donc est-ce que vous voulez vraiment passer votre vie à être constamment sur des gros projets ? Parce que gros projets ne riment pas avec projet intéressant, loin de là. Si ce n'est pas le cas, il vaut mieux viser une formation de PO, par exemple.

C'est pour ça que j'ai déjà dit à plusieurs reprises sur d'autres thread de ce forum que quand je vois des formations de CDP qui sont moins de bac + 5 (ou RNCP niveau 7), ça me fait doucement rire de voir certains organismes n'ayant aucune honte à proposer de fausses formations, compte tenu de tout ce qu'il y a à apprendre pour être CDP. Impossible de faire ça sur moins d'un bac + 5, soyons sérieux.

Et par-dessus ça, si vous le faites en freelance, où l'on va attendre de vous une expertise totale et où l'on ne sera tolérant avec aucune faute... il faut avoir les pieds bien accrochés, surtout vu le TJM d'un CDP, la boite en veut pour son argent. La moyenne du TJM d'un CDP freelance ça commence à 1k par jour...

De même, si vous êtes dans une boîte full agile, la notion de CDP n'a pas de sens à proprement parler, les responsabilités sont distillées dans l'équipe et donc si c'est le coté "management" qui vous intéresse, vous devez vous attendre à être attaché majoritairement à un certain type de boite.

Si je peux donc me permettre un conseil après ce tour rapide d'horizon, c'est d'abord de bien évaluer et comprendre ce qu'est ce métier.

Vous n'avez manifestement pas lu ce que j'ai écrit, mon cher probe. Ou alors je dois définitivement mal m'exprimer.

Par sur que, les "grands comptes", utilisent pas majoritairement les méthodes citées. il me semble que Google, Microsoft, Amazon, etc n'utilise pas du Safe.

De plus, je parle de gestion de projet, du début à la fin, je fais un état des lieux de ce que c'est et du fait qu'un grand nombre d'entreprises n'y comprennent rien. Je ne parle à aucun moment de dev.

Et je ferai des RACI aux DEV, qui devront bien choisir leur argumentaire en comitologie pour expliquer que leur dur labeur n'est pas aboutit 🥱

Voilà, comme je l'indique, c'est ce que j'appelle avoir un train de retard sur comment faire de la gestion de projet.

PS : je ne dit pas que scrum est une méthode poubelle, je dit que c'est à mettre à la poubelle, merci là encore de comprendre la nuance. Les créateurs de SCRUM eux-même disent de ne plus utiliser scrum. Et pour l'avoir épluché en long, en large et en travail pendant 10 ans non stop, je confirme.