Je peux me tromper, mais il me semble que les commanditaires d'un projet attendent que leurs collaborateurs soient performants avec leurs nouveaux outils autant que nécessaire pour atteindre rapidement les objectifs business du projet. Pour cela, il faut :

• que les collaborateurs comprennent le besoin de changer,
• qu'ils comprennent ce qui change pour eux personnellement,
• qu'ils acquièrent la compétence sur les nouveaux outils,
• qu'ils résolvent les problèmes au quotidien et
• qu'ils soient remerciés et encouragés par les commanditaires.

Pour aller plus loin, 

• le Modèle ADKAR
• et sur le nouveau site Initiative101 : les facteurs clés de succès des initiatives qui réussissent.

Lu sur le site de l’Usine Nouvelle, article de posté par Christophe BYS le 16 janvier 2015, http://www.usinenouvelle.com/article/la-multiplication-des-chefs-de-projet-est-une-catastrophe-manageriale-majeure-affirme-le-sociologue-francois-dupuy.N307730

En substance, François Dupuy développe l'idée que les organisations suscitent des chefs de projet pour faire de la transversalité là où prospèrent les silos, en vain.

Expérience personnelle : former ces mêmes chefs de projet aux yakafokons du management de projet donne rarement les résultats escomptés. Illustration de l’illusion commune à laquelle j’ai initialement sacrifié : le produit est bon (en l’occurrence le management de projet transversal), la formation est bonne (donnée par les bons experts), alors l’exécution suivra. Or, l’exécution suit rarement, parce que l'environnement des chefs de projet n'est pas prêt à les suivre.

François Dupuy propose d’aborder le sujet par un trio de prémisses : les gens sont intelligents, les gens font selon ce que leur environnement promeut, les gens évitent ce que leur environnement sanctionne. Dès lors, si l’environnement ne promeut pas la coopération et sanctionne les erreurs individuelles, multiplier les chefs de projet revient à uriner dans un stradivarius—ainsi qu'à décourager les violonistes et faire fuir les auditeurs.

Examinons les trois prémisses une à une.

1. Les gens sont intelligents. OK, car s’ils sont stupides, autant adopter directement la dictature : je sais, vous faites. Mais nous savons ce qu’endurent les dictateurs.
2. Les gens font selon ce que leur environnement promeut : si l'antiquaire donne $10 pour chaque papyrus, le berger rapporte plusieurs manuscrits de la Mer Morte car il a déchiré au préalable celui qu'il a trouvé. Cas cité par Rolf Dobelli dans « The Art Of Thinking Clearly ».
3. Les gens évitent ce que leur environnement sanctionne : les préparateurs de l'avion collaborent avec leur coordinateur au sol aussi longtemps que c'est lui/elle qui assigne bons et mauvais points. Dès lors qu'une réorganisation prive le coordinateur au sol de ce levier de sanction, les coordinations se grippent et les vols prennent du retard. Cas Air France cité par François Dupuy dans « Sociologie du Changement ».

Du coup, l’introduction du management de projet invite à se poser la question suivante avec les parties prenantes : Pourquoi adhérer à une pratique qui désigne plus sûrement le coupable ? Un plan de projet clair et suivi ne pointe-t-il pas les responsabilités sans ambigüité ? Les coupables ne sont-ils pas sanctionnés ? Alors, résister à l’application du management de projet apparaît comme une stratégie intelligente : un plan de projet obscur et difficile à suivre est dans l'intérêt des acteurs dépourvus de maîtrise de leur environnement. De plus, le flou - et l’extrême précision, à l’effet identique - ouvrent des perspectives de négociation, d’arrangements. 

Il y aurait donc résistance intelligente à l'implantation du management de projet. Alors, que faire ?

Je puis me tromper, mais je suggère ces quatre points :

1. Clarifier avec les commanditaires ce qu'ils veulent voir changer dans leur environnement. Des projets imprévisibles, des pénalités de retard, des collaborateurs burn-out, une image désastreuse ? Puis examiner avec eux quel management de projet est propre à répondre à ces attentes. Enfin, inviter les commanditaires à communiquer leur vision avec force et clarté aux manageurs, aux experts et aux chefs de projet.
2. Passer de la formation "Yakafokon du management de projet" à la facilitation d’un groupe managers + experts + chefs de projet, donner aux chefs de projet en formation les moyens de se susciter un commanditaire/sponsor dans l'objectif d'initier un management de projet juste nécessaire. Cette approche part du terrain vers les décisionnaires (bottom-up).
3. Former les stagiaires au management d’une initiative, c’est à dire d’une idée encore à préciser qui génèrera un projet (ou pas) mais qui transformera l’environnement de façon durable et efficace pour un mieux produire et un mieux-être au travail.
4. Accompagner chacun selon le Modèle ADKAR®.
   .

En tous cas, c’est dans cet esprit que j’anime les sessions de management de projet qui me sont confiées.

Vous êtes un/une pro du management de projet, mais voilà, cette fois-ci, rien ne se passe comme vous voudriez.

Le "Manuel à l'usage des chefs de projet qui ont des parties prenantes difficiles" est le complément indispensable à une méthodologie projet.

Avec ce manuel, vous allez anticiper ce qui vous attend dans le projet, faire d’un groupe une équipe efficace et plaisante, résoudre les problèmes qui vous sont soumis, communiquer efficacement au moindre coût, réussir vos négociations du moment, participer aux décisions plutôt que les subir, apprendre de vos erreurs comme de vos succès,

Consolidez votre expérience, produisez ensemble avec méthode avec les parties-prenantes qui vous entourent, réussissez plus facilement et plus vite et prenez-y plaisir.

« C’est léger, humoristique, bien écrit. Cela m’a rappelé bien des choses quand j’étais en société de services. » Bénédicte Courbon, consultante.

« Votre opuscule introduit bien au monde du projet, il dédramatise la pratique du management de projet. » Yann Le Guevel, Directeur Opérations Europe PMGS.

« Je viens de lire la moitié de cet opuscule sacrément original et plaisant. Quel style et quelles bonnes questions ! » Serge Masserot, DRH.

« J’ai trouvé la lecture de cet ouvrage très intéressante et surtout pertinente. Il y a là un véritable partage d’une expérience de chef de projet avec un angle d’attaque inhabituel. Avec mon expérience des projets, (...) je me suis même parfois dit : Oui, c’est exactement ça ! » Véronique Sagot, Chef de Projet. 

Pascal Le Deley's Books and Publications Spotlight

Pascal LE DELEY, PMP®, fait aboutir initiatives et projets de 6 à 6000 jours.hommes. Il forme au management de projet des responsables d'initiatives et des collègues manageurs de projets. Il fait partie de la communauté des praticiens en management du changement certifiés par Prosci.

http://www.lulu.com

Je travaille avec des collègues chefs de projet d'un acteur français de l'énergie, et la conversation roule sur le travail à plusieurs entités en parallèle :

La première itération d'ingénierie se passe bien, les acteurs travaillent dans le bon ordre, en séquence.

Et puis, les modifications de tous bords bombardent les résultats de l'étude. Alors, les experts, comme des pompiers, réparent et colmatent en ordre dispersé sans coopérer les uns avec les autres, alors que les modifications des uns affectent les autres.

Notre conversation se poursuit : quels sont les problèmes sous-jacents ?

Pb #1 : trop de détail dans la première itération. Détail exigé par les prestataires pour participer au chiffrage, lesquels déclarent : "nous, on ne chiffrera pas si le cahier des charges n'est pas détaillé".

En quoi est-ce que ça pourrait aider d'exiger d'être exact (la bonne valeur est quelque part dans un intervalle de confiance), sinon précis (au risque d'être inexact) ? Et quels inconvénients pourraient naître de cette approche ?

Pb #2 : la gestion de la configuration est inefficace : assez tôt dans le projet, plus personne ne sait en quoi la configuration sur laquelle il travaille est compatible avec celles sur lesquelles travaillent les autres.

En quoi est-ce que ça pourrait aider de s'assurer que les acteurs travaillant en séquence oeuvrent sur la même version de référence - même si d'autres versions circulent ? Et quels inconvénients pourraient naître de cette approche ?