Équilibrage de la matrice
Cet article fait partie de notre collection « From the Trenches ». Il décrit les défis auxquels est confronté une personne qui implémente la gestion de projets d’entreprise (EPM) dans une organisation qui utilise un environnement de gestion de projet matricielle.
Pour télécharger la version Word de cet article, consultez Équilibrage de la matrice : livre blanc.
Pour plus d’articles, consultez les livres blancs « From the Trenches ».
Équilibrage de la matrice
Dans les cercles de gestion de projet, nous avons tendance à parler souvent d’un environnement de gestion matricielle. La gestion des matrices n’est pas nouvelle. Il est devenu la norme de facto pour la gestion dans pratiquement toutes les organisations de haute technologie.
L’idée de gestion matricielle est née de la pensée managée au début des années 70. J.R. Galbraith nous livre l’un des premiers ouvrages publiés sur le sujet en 1971, qui explique comment combiner les responsabilités organisationnelles et fonctionnelles. L’environnement de gestion dominant à l’époque était hiérarchique.
Les organisations étaient d’énormes silos de services dirigés par de forts chefs de service. Cela fonctionne très bien jusqu’à ce qu’il y ait plus d’un projet qui doit s’étendre à plusieurs départements pour être terminé. Depuis plus de 30 ans, la notion de matrice « projectisée » est promue par des gestionnaires de projets et des associations comme le Project Management Institute.
Dans une matrice projectisée, nous établissons un deuxième axe pour notre organisation et nous donnons une certaine responsabilité à la partie de l’organisation qui gère les projets. Le résultat a des services organisationnels d’un côté de l’affichage et des responsables de projet qui fournissent des projets ou des produits de l’autre.
Pourquoi en parler tout en parlant de gestion de projets d’entreprise ? Ce modèle est devenu la pierre angulaire de pratiquement tous les déploiements de solution Microsoft EPM. Si vous travaillez maintenant sur le déploiement de Project Server, vous êtes sûr de rencontrer ce modèle lors de vos déplacements. Il existe des exceptions au modèle de gestion de matrice que je vais aborder avant de terminer ici, mais il suffit de dire qu’il est proche de l’universel si nous examinons les organisations technologiques.
Si vous travaillez maintenant sur un déploiement de solution Microsoft EPM, vous trouverez une organisation dans l’un des états suivants :
Il n’y a pas de matrice
L’organisation est entièrement basée sur le silo. Chaque chef de service gère son propre service comme s’il s’agissait d’une filiale de l’organisation plus grande. Les budgets sont récapitulés à travers les départements de manière hiérarchique (pensez à un organigramme). Lorsqu’un projet est lancé, il est effectué au sein de chaque service, même lorsque d’autres services peuvent avoir besoin de ressources pour terminer le projet. Si le projet ne peut pas être terminé avec les ressources du service qui le gère, les ressources externes sont négociées en tant que demandes inter-services.
Cela ne semble pas trop mauvais tant que vous n’essayez pas de gérer un tel projet. Si presque tous les projets nécessitent des ressources interdépartements, il est impossible de déterminer les priorités entre les groupes. Il n’y a aucun motif pour un chef de service de renoncer à la priorité de ses propres ressources. Il est contre-intuitif de renoncer à une telle puissance, de sorte que tout projet qui ne peut pas être réalisé au sein d’un seul service en souffre.
De plus, lorsque nous parlons à des cadres supérieurs d’un niveau supérieur à celui des chefs de service, la lamentation universelle est qu’ils ne peuvent pas obtenir de planification de la capacité de ressources. C’est tout à fait logique. Il n’existe aucune structure inter-services pour agréger l’information dont nous aurions besoin pour la planification de la capacité des ressources ni aucune incitation pour chaque chef de département à soumettre à la hiérarchisation centralisée qui serait nécessaire pour une telle analyse.
Dans cette situation, il est tout à fait probable que nous trouverons non pas un, mais plusieurs bureaux de projet, un par service qui coopère très peu entre eux.
Le déploiement de la solution Microsoft EPM dans ce type de scénario nécessite une réflexion sur la façon d’ajuster l’organisation en même temps. Souvent, nous recevons des appels de ce genre d’entreprises nous demandant de faire l’impossible. Entraîner des centaines, voire des milliers d’utilisateurs, installer Project Server et être en production dans quelques semaines. Comme l’entreprise a acheté un système de gestion de projet d’entreprise centralisé, l’organisation doit immédiatement s’aligner et fonctionner comme un environnement matricielle centralisé. C’est un fantasme cher. Inévitablement, nous devons discuter avec la haute direction de la façon dont l’organisation devra être modifiée. Ce n’est généralement pas une bonne nouvelle pour la direction qui espérait que l’achat du logiciel suffirait d’un engagement pour que tout le monde change.
Nous commençons ces projets en travaillant sur des plans pour un bureau de gestion de projet centralisé et des procédures de gestion de projet centralisées. Project Server est introduit lentement à partir du milieu. Il n’est pas rare que de tels projets prennent de 12 à 24 mois avant que l’ensemble de l’organisation soit finalement impliqué. Nous venons de relancer un tel projet après un délai de 2 ans et de deux ans pendant qu’ils travaillaient eux-mêmes pour créer un PMO.
Il existe une matrice équilibrée
C’est génial quand cela se produit, mais c’est malheureusement assez inhabituel. Le maintien d’une matrice équilibrée nécessite un ajustement et un soin constants. Toutefois, lorsque nous trouvons une matrice équilibrée, nous sommes également susceptibles de trouver un ensemble très évolué de procédures, de rôles définis et d’un processus bien compris par toutes les personnes impliquées. Le déploiement de la solution Microsoft EPM dans ce type d’organisation est le meilleur scénario.
Il existe une matrice, mais elle est déséquilibré
C’est de loin le scénario le plus courant que nous rencontrons et il est parfaitement logique. Le modèle de matrice comporte certains conflits inhérents, de sorte que nous trouvons souvent la matrice soit pondérée vers le service avec un PMO faible, soit pondérée vers le PMO avec des chefs de service faibles. Ou (et c’est de loin le plus difficile) nous trouvons la matrice pondérée envers certains départements, mais pas d’autres et certains gestionnaires de projet, mais pas d’autres, de sorte que le centre de gravité de l’organisation est difficile à trouver.
Le déploiement de la solution Microsoft EPM dans ces environnements implique d’effectuer un travail d’inventaire et de découverte. Où ont été établis les processus qui réussissent ? Où les processus ont-ils échoué ? Qu’est-ce qui fonctionne au niveau de la gestion de projet centralisée que nous pouvons exploiter pour déployer Project Server et ce qui ne l’est pas ?
Dans ces types de déploiements, nous devons être très prudents pour choisir les éléments de la solution EPM que nous voulons déployer en premier et sur qui les déployer. Le déploiement dans une approche par phases dans ce type de scénario est essentiel, car une approche big-bang n’est presque jamais réussie ici.
Le défi de la matrice
Pour ceux qui ont grandi ne connaissant que les organisations structurées de matrice, vous ne penserez peut-être même pas à vous demander s’il s’agit d’une bonne structure ou mauvaise ou de penser à ce qui est fort ou faible dans ce type de gestion. Il existe un défi fondamental avec l’organisation matricielle que beaucoup ne mettent même pas en doute : il s’agit d’un conflit par conception. La structure met en place deux forces opposées : les chefs de service et les responsables de projet. Nous ne dirions jamais cela à haute voix, bien sûr, mais le simple fait de regarder la structure rend cela évident.
L’objectif du chef de service est de faire attention aux membres du personnel du service. Ils veulent s’assurer que leurs employés sont productifs, qualifiés et satisfaits. Si nous devions laisser l’organisation aux chefs de service, nous serions ravis d’employés bien formés, pas trop surmenés et bien rémunérés, mais qui n’ont pas produit beaucoup.
L’objectif du responsable de projet est de veiller à la réalisation du projet. Ils veulent s’assurer que leur projet est réalisé aussi rapidement et à moindre coût que possible tout en conservant l’étendue et la qualité qui ont été définies au début du projet. Si nous devions laisser l’organisation aux gestionnaires de projet, nous serions avec des projets réalisés rapidement, mais un énorme roulement de personnel car nous avons brûlé des employés au nom de l’achèvement du projet.
L’idée de l’organisation matricielle est que la mise en place d’un conflit entre ces deux forces permettra d’équilibrer heureusement l’organisation entre la productivité et la satisfaction des employés. Le principe, cependant, est que les chefs de service et les gestionnaires de projet sont en fin de compte tous à peu près aussi puissants les uns que les autres. Le défi, bien sûr, est que les gens ne sont pas égaux. Il y aura toujours un chef de projet plus expérimenté qu’un autre; un chef de service qui est plus qualifié que le suivant.
Ce manque d’égalité met la matrice hors d’équilibre le premier jour. Il suffit souvent de réaliser que l’exception est une organisation matricielle équilibrée pour que les PMO et les organisateurs réfléchissent à la façon de maintenir l’ordre, ce qui peut être une bonne chose.
Il n’est pas aussi important d’obtenir un équilibre parfait que de s’assurer qu’il y a un effort pour identifier où les projets et les personnes de l’organisation sont bloqués. Les outils permettant de faire fonctionner un environnement de matrice sont toujours les mêmes : processus et communication. Un implémenteur qualifié peut identifier les processus et les procédures qui établissent ce qui est important pour l’organisation.
Abandonner la matrice ?
Tout le monde n’est pas fan de l’organisation Matrix. Au cours des dernières années, un certain nombre de dirigeants d’entreprise ont exprimé l’idée que la pensée de l’organisation matrice n’est peut-être pas le meilleur plan. « Divisez le personnel en équipes de projet dédiées », disent-ils « et vous serez plus heureux pour cela », ou « Organiser les projets pour travailler au sein de chaque service et les donner aux chefs de service ». Pour plus d’informations à ce sujet, consultez cet article de Rob Enderle pour voir quelqu’un qui pense que le modèle Matrix doit être mis hors service.
Dans un certain nombre d’organisations que j’ai visitées récemment, j’ai vu des modèles de matrice qui ont été biaisés dans une direction ou une autre et chaque situation m’amène à faire des recommandations un peu différentes dans la façon de déployer Project Server et la solution Microsoft EPM. S’il n’y a pas de PMO centralisé du tout, cela devient ma première recommandation. Certaines organisations m’ont contacté en disant qu’elles veulent utiliser Project Server uniquement pour réduire les coûts de licence, mais qu’elles n’ont pas l’intention de travailler ensemble. Ça n’a pas beaucoup de sens. L’idée d’un système de projet d’entreprise centralisé consiste à rassembler les données à des fins d’analyse et d’affichage afin de permettre la gestion des projets ensemble. Si vous n’avez pas l’intention de le faire, utilisez des licences de bureau individuelles.
Dans certaines organisations, le modèle Matrix a été déplacé par un retour à la pensée en silo. Ce genre de chose peut se produire lorsqu’il y a un changement organisationnel important ou une stimulation externe, par exemple, un changement important dans l’économie. Lorsqu’ils sont sous pression, certains gestionnaires se battront pour la survie par tous les moyens possibles. J’ai vu récemment plusieurs grandes organisations où les chefs de département ont qualifié avec succès le PMO et leur personnel de « ressources de projet redondantes » et ont fait pression pour que les chefs de département reviennent au contrôle.
Le résultat de ces modifications peut avoir l’effet exactement inverse de ce qui était prévu. Certes, les coûts baissent pendant une courte période, mais la perte d’efficacité des personnes dont le travail était de générer de l’efficacité grâce à des projets plus courts et moins chers entraîne souvent un rebond un certain temps plus tard. Pourtant, avec les grandes organisations, il peut s’agir de mois, voire d’un an ou deux, avant que ces effets ne se réalisent. En attendant, la matrice s’effondre et la puissance de Project Server peut être inhibée.
Dans l’organisation plus progressiste, l’accent pourrait être mis sur le PMO avec un nouveau respect pour ses capacités et, peut-être, un nouveau niveau d’autorité face à une économie difficile.
Restauration (ou établissement) de l’équilibre
Pour ceux qui travaillent sur ou sur le point de travailler sur des déploiements EPM, voici quelques points à prendre en compte en ce qui concerne l’environnement de gestion de matrice que vous rencontrez :
Tout d’abord, recherchez les processus et les définitions des rôles pour chaque axe de la matrice. Tout en effectuant des entrevues, recherchez où les processus rendent l’organisation plus productive plutôt que plus bureaucratique. Lorsque vous examinez les rôles, faites attention au défi classique de la « responsabilité sans autorité » dont on parle si souvent dans les cercles de gestion de projet.
Si vous partez de zéro, vous pouvez toujours trouver des processus dans la structure hiérarchique qui peuvent être adoptés, et ceux-ci peuvent très bien vous être utile. Si vous trouvez un processus ou une procédure existant au sein d’un service qui pourrait être adopté par l’ensemble de l’entreprise, l’accusé de réception de la source du processus vous permet d’obtenir deux choses instantanément : Tout d’abord, vous avez un processus dans un service qui n’a pas besoin d’être déployé. Il a déjà été adopté. Deuxièmement, vous pouvez vous retrouver avec un grand allié dans vos efforts pour créer le deuxième axe de la matrice où le chef de service impliqué peut voir des preuves que vous n’avez pas l’intention de jeter tout ce qui a déjà été fait par les services.
Si vous créez des processus qui se répartissent entre les services et que vous devrez le faire, pensez à impliquer les personnes qui pourraient se sentir privées de leurs droits. Par exemple, j’ai récemment aidé une organisation qui a dû créer un processus de planification de la capacité des ressources entre les services. Inutile de dire que les chefs de département n’étaient pas ravis de cette idée, car ils pensaient qu’ils perdraient un certain contrôle sur la gestion de leur propre personnel. J’ai recommandé la création d’un comité directeur de portefeuille (comprenant parmi ses membres les chefs de département) qui établirait les priorités du projet. Les chefs de service n’ont pas l’impression qu’on leur a enlevé l’autorité; au lieu de cela, ils seraient inclus dans la nouvelle structure d’autorité pour prendre des décisions entre les services. Cette façon de procéder a détourné un aspect autrement difficile d’un déploiement EPM en incluant les personnes qui s’y opposeraient autrement.
Enfin, envisagez d’aller « légèrement » sur votre déploiement et d’établir les procédures centralisées sans intervention excessive en travaillant en couches. Par exemple, nous travaillons sur un projet où la matrice est très forte sur le plan organisationnel. Le PMO n’en est qu’à ses balbutiements et il n’est pas idéal de s’opposer à la structure organisationnelle. Nous vous recommandons de ne pas travailler jusqu’au niveau individuel pour démarrer la gestion des ressources. Au lieu de cela, l’organisation déploiera la gestion des ressources sous la forme d’un processus centralisé avec un très petit nombre d’utilisateurs attachés directement ou en tant qu’émissaires des ministères au PMO. Les ressources seront toutes définies comme génériques et l’objectif n’est pas de passer au niveau de tâche individuel pour que chaque employé commence. Au lieu de cela, le PMO commencera à planifier la capacité des ressources en identifiant les défis agrégés en matière de ressources dans les périodes à venir, puis en cliquant sur les chefs de service pour les gérer. Nous nous attendons à ce qu’au fil du temps, les chefs de service eux-mêmes demandent d’élargir le déploiement ePM afin de faciliter le travail qu’ils ont à gérer eux-mêmes les conflits de ressources.
Conclusion
Que vous déployiez la gestion de projets d’entreprise en tant que consultant pour d’autres personnes ou que vous déployiez votre propre EPM au sein de votre propre organisation, vous êtes presque certain de devoir faire face aux défis de l’organisation matricielle. Maintenir l’équilibre de votre matrice est l’un des principaux défis des systèmes EPM et EPM comme la solution Microsoft EPM pour les rendre efficaces.
À propos de l’auteur
Chris Vandersluis est le président et fondateur de HMS Software, basé à Montréal, au Canada, un partenaire certifié Microsoft. Il a un diplôme en économie de l’Université McGill et plus de 30 ans d’expérience dans l’automatisation des systèmes de contrôle de projet. Il est un membre de longue date du Project Management Institute (PMI) et a participé à la création des sections de Montréal, Toronto et Québec du Microsoft Project Users Group (MPUG). Les publications pour lesquelles Chris a écrit incluent Fortune, Heavy Construction News, le magazine Computing Canada et PMNetwork de PMI, et il est un chroniqueur régulier pour Project Times. Il enseigne la gestion avancée de projets à l’Université McGill et intervient souvent à des fonctions d’association de gestion de projets dans Amérique du Nord et partout dans le monde. HMS Software est l’éditeur du système de gestion du temps timecontrol orienté projet et est partenaire de solution Microsoft Project depuis 1995.
Chris Vandersluis peut être contacté par e-mail à l’adresse : chris.vandersluis@hms.ca
Si vous souhaitez lire d’autres articles relatifs à L’EPM de Chris Vandersluis, consultez le site d’aide sur l’EPM de HMS (https://www.epmguidance.com/?page_id=39).