Équilibrage de la matrice : livre blanc

Ce livre blanc fait partie de notre collection « Depuis les tranchées ». Il décrit les défis auxquels sont confrontées les personnes qui implémentent une solution de gestion de projets d’entreprise (EPM) dans une organisation qui utilise un environnement de gestion de projets matricielle.

Pour télécharger la version Word de ce livre blanc, voir Équilibrage de la matrice : livre blanc.

Pour consulter d’autres livres blancs, voir les livres blancs « Depuis les tranchées ».

Équilibrage de la matrice

Dans le milieu de la gestion de projets, nous avons tendance à parler souvent d’environnement de gestion matricielle. La gestion matricielle n’a rien de neuf. Elle est devenue la norme de référence en matière de gestion dans pratiquement toutes les organisations du secteur des hautes technologies.

L’idée de gestion matricielle est issue d’une réflexion sur la gestion menée au début des années 70. J.R. Galbraith a publié en 1971 l’un des premiers ouvrages sur le sujet, traitant de la manière de combiner les responsabilités organisationnelles et fonctionnelles. L’environnement de gestion qui prévalait à l’époque était hiérarchique.

Les organisations étaient d’énormes silos de départements dirigés par de puissants chefs de département. Ce système fonctionne très bien jusqu’à ce qu’il y ait plusieurs projets dont l’accomplissement nécessite l’intervention de plusieurs départements. La notion de matrice « projétisée » est promue par des responsables de projet et des associations telles que le Project Management Institute depuis plus de 30 ans.

Dans une matrice projétisée, nous établissons un deuxième axe pour notre organisation, et confions des responsabilités à la partie de l’organisation qui gère les projets. Le résultat comprend des départements organisationnels d’un côté, et des responsables de projet livrant des projets ou produits de l’autre.

Partage des responsabilités de gestion de projet entre services

Pourquoi évoquer ce sujet en relation avec la gestion de projet d’entreprise ? Parce qu’il s’agit d’un modèle qui est devenu la pierre angulaire de pratiquement chaque déploiement de solution EPM Microsoft. Si vous travaillez sur le déploiement de Project Server, vous pouvez être certain de trouver ce modèle sur votre chemin. Il existe des exceptions au modèle de gestion matricielle, que j’évoquerai ici, mais il suffit de dire qu’il est presque universel si l’on considère les organisations du secteur des technologies.

Si vous travaillez sur un déploiement de solution EPM Microsoft, les organisations que vous rencontrez sont dans l’un des états suivants :

  1. Il n’existe pas de matrice.

    L’organisation est entièrement basée sur un silo. Chaque chef de département gère son département comme s’il s’agissait d’une filiale de l’organisation. Les budgets sont récapitulés vers le haut via les départements de façon hiérarchique (imaginez un organigramme). Le lancement d’un projet s’effectue à l’intérieur de chaque département, même quand des ressources d’autres départements peuvent être requises pour l’accomplissement du projet. Si le projet ne peut pas être réalisé avec les ressources du département qui le gère, des ressources externes sont négociées sous la forme de demandes entre départements.

    Cela ne se présente pas trop mal tant que vous n’essayez pas de gérer un tel projet. Si presque chaque projet nécessite des ressources de plusieurs départements, il devient impossible de comprendre les priorités entre les groupes. Rien n’incite un chef de département à abandonner le contrôle de la priorité de ses propres ressources. Il apparaît illogique de renoncer à un tel pouvoir. Dès lors, tout projet qui ne peut pas être accompli au sein d’un seul département en pâtit.

    En outre, les cadres situés un échelon au-dessus des chefs de département se plaignent invariablement de ne pas pouvoir obtenir de planification de la capacité des ressources. C’est tout à fait compréhensible. Il n’existe aucune structure entre les départements pour agréger les informations nécessaires pour une planification de la capacité des ressources, ni rien qui puisse inciter chaque chef de département à soumettre ses projets à la hiérarchisation centralisée qui serait nécessaire pour une telle analyse.

    Il est presque certain dans ce cas que nous ne trouverons pas un mais plusieurs bureaux de projet, un par département, qui coopèrent très peu entre eux.

    Le déploiement de la Solution EPM Microsoft dans ce type de scénario nécessite une réflexion sur la façon d’ajuster l’organisation au même moment. Nous recevons souvent les appels de sociétés de ce type, qui nous demandent l’impossible. En quelques semaines, nous devrions former des centaines, voire des milliers d’utilisateurs, et faire en sorte que Project Server soit installé et en production. Parce que l’entreprise a acheté un système de gestion de projet d’entreprise centralisé, son attente est que l’organisation s’adapte immédiatement et opère comme un environnement matriciel centralisé. C’est une fantaisie onéreuse. Nous devons inévitablement expliquer à l’encadrement supérieur comment l’organisation va devoir changer. Cela n’est généralement pas reçu comme une bonne nouvelle, car l’encadrement espérait que l’achat du logiciel constituerait un engagement suffisant pour amener tout le monde à changer.

    Nous abordons de tels projets en travaillant sur des plans de bureau et de procédures de gestion de projet centralisés. Project Server est introduit lentement en partant du centre. Il n’est pas rare que de tels projets nécessitent entre 12 et 24 mois avant que l’organisation entière soit finalement impliquée. Nous venons de redémarrer un projet de ce genre après deux ans et demi de retard pendant lesquels l’entreprise a elle-même travaillé à la création d’un bureau de gestion de projet.

  2. Il existe une matrice équilibrée

    Quand cela se produit, c’est formidable. Mais c’est malheureusement très rare. Maintenir une matrice équilibrée requiert un ajustement et un soin constants. Toutefois, quand nous trouvons une matrice équilibrée, nous savons qu’il y a également de fortes chances pour que nous trouvions un ensemble très évolué de procédures, des rôles définis et un processus bien compris de toutes les personnes concernées. Le déploiement de la solution EPM Microsoft dans ce type d’organisation est le meilleur scénario possible.

  3. Il existe une matrice mais elle n’est pas équilibrée

    C’est de loin le scénario auquel nous sommes le plus souvent confrontés, et c’est parfaitement compréhensible. Le modèle matriciel est porteur de conflits intrinsèques. Ainsi, nous découvrons souvent que la matrice penche soit en faveur du département avec un bureau de gestion de projet faible, soit en faveur de ce dernier avec des chefs de département faibles. Ou bien (et c’est bien plus problématique), nous découvrons que la matrice penche en faveur de certains départements au détriment d’autres, et de certains responsables de projet plutôt que d’autres, de sorte qu’il est difficile de trouver le centre de gravité au sein de l’organisation.

    Le déploiement de la solution EPM Microsoft dans ces environnements nécessite un travail d’inventaire et de découverte. Où les processus établis ont-ils réussi ? Où les processus ont-ils échoué ? Qu’est-ce qui fonctionne au niveau de la gestion de projet centralisée, que nous pourrions exploiter pour déployer Project Server, et qu’est-ce qui ne fonctionne pas ?

    Dans ces types de déploiements, nous devons choisir très soigneusement les éléments de la solution EPM que nous comptons déployer en premier lieu, et où les déployer. Dans ce type de scénario, le déploiement selon l’approche progressive est essentiel, car une approche en mode Big Bang est presque certainement vouée à l’échec.

Le problème de la matrice

Qui n’a jamais rien connu d’autre que des organisations structurées de façon matricielle, ne s’est probablement jamais demandé si cette structure est bonne ou mauvaise ou quelles sont les forces et les faiblesses de ce type de gestion. Il existe un problème fondamental lié à l’organisation matricielle, que bon nombre d’utilisateurs ne soulèvent même pas : elle est conflictuelle à dessein. La structure définit deux forces opposées : les chefs de département et les responsables de projet. Bien sûr, nous ne dirions jamais cela à haute voix, mais un simple examen de la structure est révélateur.

L’objectif du chef de département est de veiller aux effectifs de son département. Il veut s’assurer que ses employés sont productifs, qualifiés et satisfaits. Si nous laissions les rênes de l’organisation aux mains des chefs de département, nous nous retrouverions avec des employés ravis, bien formés, pas trop surchargés et bien rémunérés, mais qui seraient peu productifs.

L’objectif du responsable de projet est de veiller à la livraison du projet. Il veut s’assurer que son projet sera accompli le plus rapidement et économiquement possible, dans le respect des critères d’étendue et de qualité définis au début du projet. Si nous laissions les rênes de l’organisation aux mains des responsables de projet, nous nous retrouverions avec des projets rapidement achevés, mais un taux désastreux de renouvellement du personnel, car des employés seraient sacrifiés sur l’autel du rendement.

Le principe de l’organisation matricielle est que l’instauration d’un conflit entre ces deux forces produira pour l’organisation un équilibre heureux entre la productivité et la satisfaction des employés. Toutefois, l’hypothèse de base est que les chefs de département et les responsables de projet soient en définitive également puissants. Le problème, bien entendu, est que les gens ne sont pas égaux. Il y aura toujours un responsable de projet plus expérimenté que d’autres, ou un chef de département plus compétent que ses pairs.

Ce manque d’égalité déséquilibre d’emblée la matrice. Le simple fait de réaliser qu’une organisation matricielle équilibrée constitue une exception suffit souvent pour que les bureaux de gestion de projet et les organisateurs réfléchissent à la manière de maintenir l’ordre, et ce peut être une bonne chose.

Obtenir un équilibre parfait n’est pas aussi important que s’assurer que l’organisation s’efforce d’identifier ce qui entrave certains projets ou personnes. Les outils pour faire fonctionner un environnement matriciel sont toujours les mêmes : processus et communication. Un responsable d’implémentation expérimenté est capable d’identifier des processus et procédures qui déterminent ce qui est important pour l’organisation.

Abandonner la matrice ?

L’organisation matricielle ne fait pas l’unanimité. Ces dernières années, plusieurs chefs d’entreprise ont exprimé l’idée que l’organisation matricielle n’était peut-être pas la panacée. Ils préconisent la division du personnel en équipes de projet dédiées, et l’organisation des projets de façon à pouvoir les confier entièrement à un chef de département. Pour plus d’informations à ce sujet, vous pouvez lire cet article de Rob Enderle, qui expose le raisonnement d’une personne estimant que le modèle matriciel devrait être abandonné.

Dans de nombreuses organisations que j’ai récemment visitées, j’ai observé des modèles matriciels asymétriques. Chaque situation m’amène à formuler des recommandations spécifiques quant à la manière de déployer Project Server et la solution EPM Microsoft. À défaut de bureau de gestion de projet centralisé, ma première recommandation est d’en créer un. Certaines organisations m’ont approché en déclarant qu’elles voulaient utiliser Project Server uniquement pour réduire les frais de licence, mais n’avaient aucune intention de collaborer. Cela n’a pas beaucoup de sens. L’idée même d’un système de projet d’entreprise centralisé est de regrouper des données à des fins d’analyse et d’affichage, afin de pouvoir gérer plusieurs projets ensemble. Si vous n’avez aucune intention de procéder de la sorte, conservez les licences de bureau individuelles.

Dans certaines organisations, le modèle matriciel a été supplanté par un retour au mode silo. Ce genre de chose peut se produire suite à un grand changement d’organisation, ou en réponse à un stimulus externe tel qu’un grand bouleversement économique. Soumis à la pression, certains dirigeants luttent pour la survie par tous les moyens possibles. J’ai vu récemment plusieurs grandes organisations où des chefs de département décrivaient le bureau de gestion de projet et leur propre personnel comme des ressources redondantes, et usaient de leur influence pour que le contrôle soit rendu aux chefs de département.

Le résultat de telles modifications peut avoir un effet diamétralement opposé à l’effet escompté. Il est vrai que les coûts baissent pendant une brève période, mais la perte d’efficacité des personnes précisément chargées de veiller à l’efficacité au travers de projets plus courts et moins chers, entraîne souvent un retour de manivelle à court terme. Mais dans certains grandes organisations, plusieurs mois ou même années peuvent s’écouler avant que ces effets se manifestent. Entre-temps, la matrice s’effondre et Project Server peut être paralysé.

Une organisation plus progressiste pourrait mettre en avant le bureau de gestion de projet, en marquant un respect nouveau pour ses capacités, voire en lui conférant un niveau inédit d’autorité face à une économie de plus en plus complexe.

Restauration (ou établissement) de l’équilibre

Pour les personnes qui travaillent ou sont sur le point de travailler sur des déploiements EPM, voici quelques nouveaux éléments de réflexion concernant les environnements de gestion matricielle que vous rencontrez :

Tout d’abord, recherchez les processus et définitions de rôles pour chaque axe de la matrice. Lors des entretiens, cherchez à épingler les processus qui rendent l’organisation plus productive au lieu de plus bureaucratique. Lorsque vous examinez les rôles, soyez attentif au problème classique de « responsabilité sans autorité » si souvent évoqué dans le milieu de la gestion de projets.

Si vous partez de rien, vous pouvez toujours trouver des processus dans la structure hiérarchique, dont l’adoption vous serait très bénéfique. Si vous parvenez à trouver une procédure ou un processus existant au sein d’un département, que toutes l’entreprise pourrait adopter, la reconnaissance de sa source vous apporte instantanément deux avantages : Tout d’abord, vous disposez d’un processus dans un département, qui ne nécessite aucun déploiement. Il a déjà été adopté. Ensuite, vous pouvez vous gagner un précieux allié dans vos efforts de création du deuxième axe de la matrice, en ce que le chef de département concerné pourra constater que vous n’avez nulle intention de balayer tout ce que les départements ont déjà accompli.

Si vous créez des processus touchant plusieurs départements, comme ce sera le cas, songez à impliquer les personnes qui pourraient se sentir désavouées. Par exemple, j’ai récemment aidé une organisation qui devait créer un processus de planification de la capacité des ressources opérant entre plusieurs départements. Inutile de dire que cette idée ne réjouissait guère les chefs de département, qui pressentaient qu’ils perdraient dans une certaine mesure le contrôle de la gestion de leur propre personnel. J’ai recommandé de créer comité directeur de portefeuille (incluant ces chefs de département) qui fixerait les priorités des projets. Les chefs de département n’auraient pas le sentiment d’être dépouillés d’une partie de leur autorité. Au lieu de cela, ils feraient partie de la nouvelle structure ayant l’autorité de prendre les décisions relatives aux questions touchant plusieurs départements. Cette façon de procéder a permis d’éviter un problème délicat de tout déploiement EPM en incluant les personnes qui s’y seraient autrement opposées.

Enfin, dans le cadre de votre déploiement et de la mise en place des procédures centralisées, songez à procéder avec « légèreté » en travaillant par couches pour éviter toute intervention excessive. Par exemple, nous travaillons sur un projet dans lequel la matrice est très puissante sur le plan organisationnel. Le bureau de gestion de projet en est aux balbutiements, et une opposition trop marquée à la structure organisationnelle n’est pas recommandée. Pour le début de la gestion des ressources, nous avons recommandé de ne pas descendre jusqu’au niveau individuel. Au lieu de cela, l’organisation déploiera la gestion des ressources en tant que processus centralisé, avec un très petit nombre d’utilisateurs connectés au bureau de gestion de projet, soit directement, soit en tant que délégués des départements. Les ressources seront toutes définies comme génériques, et l’objectif ne sera pas d’aller jusqu’au niveau de tâche individuelle pour chaque employé. Au lieu de cela, le bureau de gestion de projet commencera à planifier la capacité des ressources en identifiant d’éventuels problèmes de cumul dans les périodes à venir, puis en soumettant les problèmes aux chefs de département chargés de les gérer. Nous espérons qu’avec le temps, les chefs de département eux-mêmes finiront par demander un élargissement du déploiement EPM afin de faciliter leur propre travail de gestion des conflits de ressources.

Conclusion

Que vous déployiez une solution EPM en tant que consultant pour d’autres personnes, ou votre propre solution EPM au sein de votre propre organisation, vous pouvez être pratiquement certain d’avoir à affronter les défis de l’organisation matricielle. La difficulté de maintenir en équilibre votre matrice est l’un des principaux obstacles à la réussite d’un déploiement d’environnement EPM et de systèmes tels que la solution EPM Microsoft.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de HMS Software. Basée à Montréal (Canada), l’entreprise est un partenaire Microsoft Certified Partner. Diplômé en sciences économiques de l’université McGill, Chris a plus de 30 ans d’expérience dans l’automatisation des systèmes de gestion de projets. Il est membre du Project Management Institute (PMI) depuis de nombreuses années et a participé à la création des chapitres du Microsoft Project Users Group (MPUG) pour Montréal, Toronto et Québec. Il a publié des articles dans Fortune, Heavy Construction News, Computing Canada et PMNetwork. Il tient également une chronique régulière pour Project Times. Il enseigne la gestion de projets avancée à l’université McGill et intervient souvent lors d’événements organisés par des associations de gestion de projets en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système d’horloge pour les projets TimeControl et est un partenaire Microsoft Project Solution Partner depuis 1995.

Vous pouvez contacter Chris Vandersluis à cette adresse : chris.vandersluis@hms.ca.

Pour consulter d’autres articles en lien avec la gestion des projets d’entreprise rédigés par Chris Vandersluis, rendez-vous sur le site EPM Guidance de HMS Software (http://www.epmguidance.com/?page_id=39).

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×