Le Blog du DSI

Risques liés à l'implantation du management par projet

Je suis tombé aujourd’hui sur une question particulièrement intéressante postée dans un forum et que je vous livre à l’identique ainsi que la réponse que j’ai faite sur ce forum dans la foulée.

...
Quels sont les risques (ou freins ou difficultés) qui peuvent compromettre l'implantation du management par projet dans un organisme ?

Par exemple :
il y a risque que la Direction ne soit pas totalement impliquée dans la démarche.
il y a risque le personnel ne soit pas formé au management et à la gestion de projet.
il y a risque que l'organisme n'est pas la maturité nécessaire en projet.
il y a risque que l'effort de l'implantation ne soit pas constant.
il y a risque que les bons comportements ne soient pas compris et admis.
etc.
...

Sans prétendre avoir une vue exhaustive des problèmes que l’on peut rencontrer dans une démarche d’implantation d’une gestion par projets, voici quelques-uns des écueils que j’ai pu identifier.

Le premier est la volonté d’aller trop vite. Comme dans tout changement, il faut respecter quelques étapes pour fédérer les équipes autour du projet. Le premier temps est celui du diagnostique. Tant qu’un relatif consensus n’est pas atteint, il reste trop de place pour des réactions du type : « Pourquoi changer ? On n’est pas si mauvais. ». Le second temps est celui de l’information. Il permet de faire découvrir aux équipes ce qu’est le management par projet, comment il fonctionne et de montrer en quoi il peut répondre au diagnostique. Ce n’est qu’ensuite que peuvent venir le temps de la préparation, de la formation et du déploiement. Là encore, il faut y aller progressivement. Il faut commencer quelques pilotes, avec des objectifs raisonnables, en commençant par quelques processus de base et en complétant au fur et à mesure. Et quand tout est en place, il faut continuer les efforts pour arriver au temps de l’institutionnalisation, le temps où l’on ne se rappelle plus comment on faisait avant. Le temps ne respecte pas ce qui ce fait sans lui. Si on brûle des étapes, l’implantation du management par projet risque de retomber comme un soufflé, avec beaucoup de désorganisation au passage.

Le second risque est une maladie que j’appelle la « méthodologite aigüe ». Elle conduit tout droit à la déresponsabilisation et à la grève de l’intelligence. Elle se déclenche de façon insidieuse à l’occasion des premiers projets. Les équipes, en pleine phase d’apprentissage des nouvelles méthodes, se laissent conduire par les processus plutôt que de conduire les processus du projet. Ce faisant, elles laissent au vestiaire une part de leur capacité de jugement sur l’utilité des tâches qu’elles accomplissent. Le symptôme absolu de la maladie est lorsque quelqu’un accomplit une tâche « parce que c’est dans la méthode ». La formation et le coaching des projets doivent intégrer la lutte contre cette maladie. Les méthodes sont nécessaires mais doivent rester un moyen, non une fin.

Le troisième risque survient lorsque l’on va au bout de la logique du management par projet et que l’on dédie les ressources humaines au projet en les détachant de leur structure dans l’organisation. J’ai souvent pu observer dans cette situation que des personnes dont la participation au projet paraissait aller de soi et qui pourtant refusaient d’y participer. En fait, ces personnes avaient simplement peur de quitter leur position dans l’organigramme. Le problème est qu’elles n’avaient aucune confiance dans la capacité ou la volonté de l’entreprise de les réintégrer à l’issue du projet à une place qui leur donne satisfaction. Ce risque, à lui seul, peut faire échouer la mise en place d’un management par projet. Pour y parer, il faut mettre en place des règles claires et des engagements précis sur ce sujet et aborder la question de façon franche avec les personnes concernées. Même ainsi, si l’entreprise ne bénéficie pas d’un capital de confiance suffisant aux yeux de ses employés, cette résistance peut poser des problèmes.

Le quatrième risque est la montée du stress. Le management par projet rend l’activité des personnes très mesurable. La planification des tâches met un coup de projecteur sur l’activité et sur la productivité individuelle. La production systématique de livrables rend également les résultats de ces activités très visibles en quantité et en qualité. Pour beaucoup de personnes, c’est une situation anxiogène, génératrice de mauvais stress. Pour éviter, ou du moins limiter la montée de ce stress, la direction et le management se doit d’adopter une certaine retenue dans l’utilisation des nouveaux indicateurs pour l’évaluation des collaborateurs et dans son niveau d’exigences. Il faut absolument démontrer que les indicateurs servent avant tout à mesurer et éventuellement à remettre en cause les processus et non les individus. Ceci ne peut en aucun cas être un discours, auquel personne ne croirait, il faut que la pratique en fasse rapidement la démonstration.

Ce sont selon moi les risques majeurs qui mettent en péril le déploiement d’un management par projets ou d’une gestion de projet. Après, il faut rentrer dans les détails de chacun des processus du PMBoK ou du moins de ceux que l’on aura décidé d’implanter. Selon la maturité de l’entreprise et le niveau de ses collaborateurs, les risques de dysfonctionnement pendant la période d’apprentissage existent plus ou moins. Il faut donc les évaluer au cas par cas et évaluer dans quelle mesure ils pourraient mettre en péril l’atteinte des résultats visés.

Je pense être loin d’avoir épuisé le sujet. Aussi, tous vos commentaires ou retours d’expériences seront les bienvenus. Je ne serais pas étonné que ce thème vive plusieurs années sans jamais trouver une conclusion définitive.

De la maîtrise d’œuvre et de la maîtrise d’ouvrage.

Cela faisait pas mal de temps que je ne m’étais plus posé de questions au sujet du modèle français d’organisation des projets autour d’une maîtrise d’œuvre et d’une maîtrise d’ouvrage.

Pour rappel, ce modèle d’organisation, emprunté au secteur du bâtiment, fait partie de l’exception culturelle française. Tous ceux qui, comme moi, ont utilisé ces termes pour présenter leur parcours professionnel dans leur CV ont dû s’en rendre compte au moment de la traduction en anglais. La traduction est impossible, le concept n’existe même pas. Il faut donc rédiger autrement la version anglaise. (Note: Pour ceux qui souhaitent aller plus loin dans cette problématique de traduction vers l'anglais, je recommande de suivre le lien suivant qui est, et de loin, ce que j'ai rencontré de mieux sur ce sujet: http://anglais-pratique.fr/rubriques/gestion-projets/92-maitre-ouvrage-oeuvre).

Deux épisodes récents m’ont amené à réfléchir à nouveau sur ce sujet.

Le premier d’entre eux était un article dans un forum. Celui-ci relatait les difficultés rencontrées par un projet. L’équipe de maîtrise d’ouvrage avait réalisé des spécifications détaillées à l’aide d’un AGL et il avait fallu énormément de temps aux développeurs pour prendre en main ces spécifications et arriver à travailler en bonne intelligence avec la maîtrise d’ouvrage.

Le second épisode est la lecture d’un article sur un site anglo-saxon qui est une pépite en matière de gestion de projet : « The Project Management Hut ». Cet article est intitulé « The Yin and Yang Of Project Management and Business Analysis ». Dans cet article, l’auteur présente deux rôles complémentaires, souvent attribués à une même personne : le chef de projet et l’analyste métier. Il reconnait le bien fondé de cette approche pour de petits projets mais regrette la confusion ainsi créée. Selon lui, il s’agit de métiers distincts même s’ils demandent de nombreuses compétences communes. Il plaide donc pour la séparation de ces rôles. L’analyste métier réalise alors un certain nombre de tâches et produit un certain nombre de livrables qui doivent faire partie du plan de projet géré par le chef de projet. A ce titre, l’analyste métier répond au chef de projet et lui rend compte de son activité. Tout ceci est parfaitement en ligne avec les meilleures pratiques anglo-saxonnes.

Ces deux épisodes m’ont rappelé plusieurs éléments fondamentaux pour que notre système français fonctionne bien.

Tout d’abord, pour que le modèle fonctionne, les responsabilités doivent être clairement identifiées et attribuées à chacune des équipes. La maîtrise d’ouvrage est en charge des besoins et des exigences du métier vis-à-vis du produit. Elle est centrée sur l’atteinte des résultats qui ont été définis et sur l’utilisation du produit. La maîtrise d’œuvre est centrée sur le produit. Elle en fait les spécifications, la conception et la réalisation. Elle s’assure également d’en assurer la qualité.

Ensuite, les tâches de maîtrise d’ouvrage peuvent-elles être dissociées des activités du projet ? Bien sur que non ! Une gestion de projet efficace doit donc prendre en considération l’ensemble des tâches. Sur ce point, je suis parfaitement en phase avec nos amis anglo-saxons. Non seulement les tâches de maîtrise d’ouvrage et de maîtrise d’œuvre se doivent d’être intégrées dans un unique plan de projet, mais je prétends en plus qu’elles ne sont pas séquentielles mais concourantes. Elles se déroulent en même temps et s’influencent mutuellement.

Le problème est que trop souvent, chaque équipe souhaite gérer son propre prisme du projet et à sa manière. C’est ainsi que l’on voit surgir des notions bizarres de chef de projet utilisateur et de chef de projet de maîtrise d’œuvre. Un projet, deux chefs, cherchez l’erreur ! On peut comprendre un intégrateur qui nomme un chef de projet pour gérer ses équipes et ses engagements sur le projet de son client. Mais qu’elle est la valeur de ce plan de projet pour le client ? Et si j’ai plus d’un intégrateur ? Décidément, le chef de projet doit embrasser l’ensemble de l’équipe projet, maîtrise d’ouvrage et maîtrise d’œuvre confondue. Le chef de projet n’est donc pas le maître d’œuvre.

Les notions de maîtrise d’œuvre et de maîtrise d’ouvrage ont le mérite de permettre l’attribution de rôles précis réclamant des compétences distinctes. Il est seulement regrettable que, parfois, on veuille les mettre dans une relation client-fournisseur là où une relation de collaboration est tellement plus efficace.

Au vu de ces quelques réflexions, y a-t-il encore un problème pour un analyste métier de rendre compte de ses activités sur un projet au … chef de projet ? Peut-on également s’étonner qu’un dossier de spécifications détaillées, réalisé par la maîtrise d’ouvrage, pose d’énormes problèmes de prise en charge par les développeurs. Un simple cahier des charges, précisant les besoins et les attentes aurait été plus simple à produire et aurait probablement abouti à une solution plus simple, moins couteuse et peut-être même livrée dans les temps.

Finalement, vu comme cela, notre exception française n’est en rien incompatible avec les meilleures pratiques qui sont bien souvent, n’en déplaise à certains, anglo-saxonnes. Il s’agit juste d’une contribution additionnelle : The French Touch.