Dans un examen de travail du PMI (Project Management Institute, association professionnelle des chefs de projet dans le monde), nous lisons cette question-ci : Quelle phase du projet est typiquement la plus grevée d’incertitudes et la plus risquée ? Est-ce :

1. Le démarrage ?
2. Le développement ?
3. L’exécution ?
4. La conclusion ?

Eh bien, la réponse attendue est : le démarrage. Cette période de l’initiative où les parties prenantes se mettent d’accord sur l’intérêt du projet à venir, cette période qui prendra fin avec leur approbation de la charte du projet.

L’idée est la suivante : bondir sur la planification nous amène à laisser les plus grandes incertitudes non résolues. D’autant que, les témoignages convergent, une fois le projet lancé, l’on perd de vue son objectif.

Une autre question du même questionnaire de travail du PMI:

Quel est la période la plus cruciale pour vérifier les parties prenantes du projet et leurs intentions ?

1. Lorsque la complexité du projet augmente ?
2. Durant la phase de planification ?
3. Durant la phase de démarrage ?
4. Après que le plan de projet a été finalisé ?

Réponse de la communauté des chefs de projet du PMI : même si l’on garde un oeil sur les parties prenantes durant tout le projet, c’est durant la phase de démarrage que scruter les parties prenantes est le plus crucial.

Qu’est-ce à dire, si je suis propulsé dans un projet qui a démarré sans moi ? Eh bien, plutôt que de plonger dans la planification, je ferais mieux de commencer par analyser les parties prenantes.

Michaël, pour ta recherche d'emploi, il y a, dans la droite ligne de l'auteur de référence (en ce qui me concerne), Richard Nelson BOLLES (Cf. son livre What Color Is Your Parachute?) deux plans dont nous venons de parler au téléphone, celui du courriel de prise de contact pour solliciter un entretien et celui du projet professionnel sensu stricto à développer au cours de l'entretien, sous forme d’elevator pitch.

Pour découvrir l'outil elevator pitch dans le nouveau site projet-initiative101.com

Pour le courriel de prise de contact, viser un courriel que tu liras à voix haute (exercice utile) en 2 minutes ou moins :

Bonjour, M/Mme XYZ. 

Je vous contacte de la part de (Untel).

Je fais... (mon parcours professionnel, d'où je viens--avec un verbe d'action (je fais aboutir les projets de mes clients depuis 199.) plutôt qu'un titre (je suis chef de projet) qui ne parle pas à tous de la même façon).

Je souhaite faire... (mon projet professionnel, idem un verbe d'action (je souhaite aider mes collègues à réussir leur projets au moindre coût en s'appuyant sur leur environnement et sur la décomposition structurée du travail) plutôt qu'un titre (je souhaite devenir consultant) qui ne plaît pas à tout le monde).

A cette étape de mon projet professionnel, je recueille le retour / feedback de professionnels pour le confronter au réel et l'affiner. 

(Untel) m'a recommandé de m'adresser à vous. Auriez-vous 20 minutes à m'accorder prochainement, afin que je vous expose mon projet et que vous disiez ce que vous en pensez ? Je précise que je ne sollicite ni stage ni emploi ni mission d'aucune sorte, juste votre feedback personnel.

Formule de politesse / Signature

Voici le brouillons des courriels que j'ai envoyés par saut de puces jusqu'à la personne qui avait le pouvoir et le désir de m'embaucher, pour information :

Mme R.,

Je vous contacte de la part de D. T.. Lucie, mon épouse, est invitée à travailler un an à la clinique M. dans le service de D. S. et nous l'accompagnons tous, nos trois enfants et moi-même. Nous prévoyons de nous rendre sur place en éclaireurs Lucie et moi dans la semaine du 14 juin.

Pour ma part, je fais aboutir des projets informatiques depuis 19 ans et ai reçu la certification Project Manager Professional en 2000, délivrée par le Project Management Institute basé en Pennsylvanie. Je travaillais alors chez IBM France. De plus, je forme des étudiants au référentiel PMI et j'aide des professionnels à réussir dans leur rôle de chef de projet, notamment ceux dont ce n'est pas la compétence première.

Durant cette année à Rochester, MN, je souhaite contribuer utilement à un ou plusieurs projets comme chef de projet, dans la planification, l'exécution ou la surveillance et le contrôle de ce(s) projet(s).

Je serais heureux de connaître votre avis sur la faisabilité de mon souhait et sur mon approche.

Puis-je vous demander vingt minutes de votre temps prochainement, au téléphone, à une heure de votre choix compte tenu du décalage horaire de 7 heures ?

En vous remerciant par avance, etc.

Voir aussi cet autre exemple de courriel pour solliciter un entretien-réseau dans le nouveau site projet-initiative101.com

Nota Bene : à tout contact généré par cette approche, tu dois répondre par un courriel de remerciement dans les 24 heures.

Comment faire pour que les gens de l'Informatique, de l'outil, livrent des applications utilisables ? Ergonomiques, certes, et aussi utilisables dans la vraie vie.

Comment faire pour que les gens des métiers utilisent les applications ?

Sabine, analyste métier dans une équipe d'informaticiens : C'est simple, ce que veut le promoteur du projet informatique, ce sont des équivalents-temps-plein en moins. 

S'il en est ainsi, je comprends que l'application ne soit pas utilisée par les utilisateurs dont elle menace l'emploi. La démarche menace l'emploi. De quel emploi s'agit-il, de qui ?

David, consultant en management de projet : Souvent, les commanditaires des projets ignorent combien coûte le projet et combien il est sensé rapporter ; alors, pourquoi le lancent-ils ?

Je risque une réponse : parce qu'en échange d'un os à ronger, l'Informatique produira des économies en équivalents-temps-plein. Même si c'est difficile à quantifier, ça vaut le coup d'essayer.

Du coup, à qui vendre le management du changement ? Quelle incertitude pertinente pour quel acteur le management du changement maîtrise-t-il ? Commencer par étudier les incertitudes des acteurs en présence.

Côté Métier, 

• l'opérateur ? 
• le super-utilisateur ?
• le superviseur ?
• le responsable business ?
• le Directeur des Opérations ?

La mission, parce que la mission donne l'impulsion vers le long terme et soulève des problèmes à moyen terme et occupe à manager la nouveauté à court terme.

Côté Informatique,

• le développeur ?
• le manager ?
• le chef de projet ?
• le chef de service ?
• le Directeur Informatique (CIO) ?

Mon épouse prend la responsabilité d'un service au sein d'un centre de recherche médicale. Elle rencontre des gens, elle ouvre des armoires et découvre... un sentiment de découragement. Trop de choses à faire, trop de dysfonctionnements, l'équation paraît sans solution.

Ce matin, au petit-déjeuner, nous cherchons à comprendre la situation, à évaluer l'impact du changement sur le moral de l'acteur engagé. Il y a bien un point où le moral atteint son point bas. Patienter dans la tourmente, rester toutes antennes dehors et faire confiance en la situation et en soi-même, c'est plus facile avec quelqu'un à qui en parler.

Cette conversation me fait me rendre compte de ceci : faire équipe avec un coach, pratiquer la supervision, ça devrait faire partie du job de responsable d'équipe. J'ai vécu cela dès mes missions chez IBM Learning Services en ingénierie de formation et, à l'époque, je pensais que c'était du "nice-to-have". En fait, j'avais bien de la chance. L'essentiel m'a été donné lorsque j'en ai eu besoin.

David GRAEBER, auteur entre autres de "Dette : 5000 ans d'histoire" constate "l’hypertrophie du temps de travail qui veut que nous travaillons beaucoup pour des boulots dont une grande partie ne sert à rien d’autre qu’à occuper les gens". Je rapproche ça du constat de mes collègues informaticiens : entre 50 et 75% des applications informatiques que nous livrons sont inutilisées.

Qu'est-ce à dire ? En développant ces applications informatiques, en accomplissant ces projets, nous sommes-nous consacrés à des choses sans autre utilité que celle de nous occuper sainement ?

Si oui, alors poser la question de l'utilité d'une initiative avant d'en faire un projet est un problème. Comme est un problème de mesurer la différence qu'a faite une application informatique quelques mois après sa livraison. En effet, si nous renonçons à faire un projet parce qu'il est inutile, si nous montrons que 50% à 75% de nos livraisons sont inutiles, qu'adviendra-t-il de notre emploi ?

L'approche projet - ADKAR® promeut cette question initiale et cette revue post-démarrage. Et donc menace, d'une certaine façon, notre emploi. C'est ainsi que je m'explique la bonne foi de mon collègue informaticien dans une banque : jamais nous ne mesurons la différence qu'a faite un de nos projets.

En soi, les raisons sociales (le maintien de l'emploi) me paraissent légitimes. En même temps, le coût écologique de cette suractivité à haute technologie me semble démentiel.

Tout un système est à l'oeuvre. Il favorise les technologies les plus coûteuses et se pare d'écologie à la marge. Exemple : la HD, Haute Définition. Des mégapixels de clichés envoyés par des réseaux énormes sur ces serveurs colossaux dans des datacenters pharaoniques - mais refroidis de la plus écologique des façons. Tous les acteurs s'entendent et se renforcent les uns les autres. Les capacités croissent. Et l'utilité ?

Pour aider les gens à interroger leur modèle, il me semble qu'il faut aborder la question de l'emploi. Par exemple, qu'est-ce qui garantit que j'aurai un emploi si je quitte le bateau de la HD ? Ou celui du développement d'applications inutiles ?  Ou celui de l'accumulation d'informations superflues ? 

Est-ce la même situation pour la recherche de la Qualité ? Amis de Toyota, vous assortissez votre recherche Qualité par la promesse qu'il y aura toujours de problèmes, de toute façon, et donc aucun chômage pour ceux que passionne leur résolution.

Alors, que dire à ceux qui s'inquiètent et avouent : "nous voulons bien nous centrer sur l'utile au nom de l'écologie mais quid si nos emplois disparaissent ?"

Là, je sèche. Une idée ?