EPM : centralisation ou décentralisation ? : livre blanc

Ce livre blanc fait partie de notre collection « Depuis les tranchées ». Il décrit la façon dont les entreprises doivent comprendre les problèmes qu’elles tentent de résoudre lorsqu’elles décident d’implémenter un système de gestion de projets. Parfois, le déploiement d’un système centralisé de gestion de projets n’est pas la meilleure réponse.

Pour télécharger la version Word de ce livre blanc, voir EPM : centralisation ou décentralisation ? : livre blanc.

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

EPM : centralisation ou décentralisation ?

Je suis devenu adepte de la gestion de projet d’entreprise (EPM) dès l’instant où j’ai commencé à travailler dans le secteur de la gestion de projets au début des années 80. Vous pourriez penser que je prône systématiquement la gestion centralisée de projet, mais ce n’est pas toujours le cas. Consacrons quelques instants à expliquer ce que nous entendons par EPM.

Le concept d’EPM recouvre différentes choses selon les personnes. J’ai déjà évoqué, dans d’autres articles de cette rubrique comment un déploiement EPM peut se focaliser sur la gestion des documents dans une organisation, et sur l’intégration des échéanciers dans une autre. Toutefois, au cœur de l’EPM, figure la notion que les personnes doivent interagir dans le cadre de l’exercice de gestion de projet. Cela signifie que le responsable de projet et/ou l’équipe de gestion de projet ne travaillent pas de façon totalement indépendante. Mais cela signifie-t-il que le seul moyen d’obtenir cette « interaction » consiste à centraliser le système de planification de projet ? Pas nécessairement. Pour certaines organisations, la difficulté de gestion de projet peut résider dans une incapacité à générer des rapports de gestion de projet récapitulatifs, à l’échelle de l’entreprise, parce que tous les projets font l’objet d’une gestion ad hoc. Dans ce cas, L’EPM peut consister simplement en l’instauration de normes de projet partagées entre tous les membres du personnel de gestion de projet. La meilleure façon d’y parvenir est de mettre en place un pool central de modèles, de supports de formation, de documents et de normes de rapport que tout le monde peut utiliser. Un simple site SharePoint pourrait peut-être suffire.

Pour certaines organisations, la difficulté de gestion de projet peut résider dans l’inefficacité des échéanciers personnels, résultant d’un manque de communication entre les ressources concernant ce sur quoi elles travaillent et ce sur quoi elles se concentreront ensuite. Dans ce cas, une EPM peut être obtenue en améliorant la communication au sein des équipes et entre elles. Les outils peuvent être aussi simples qu’un calendrier partagé, une messagerie instantanée ou un portail partagé sur lequel les utilisateurs peuvent indiquer leurs priorités.

Dans certaines organisations, la difficulté de gestion de projet est simplement de progresser au niveau des projets de développement par programmation. Si c’est le cas, les outils déjà présent dans un produit comme Visual Studio Team Services peuvent suffire. Dans les projets de programmation, il est très fréquent que l’on découvre que de nombreuses tâches peuvent être accomplies pratiquement dans n’importe quel ordre, de sorte que les contraintes de planification de chemin critique peuvent même ne pas être appropriées en fonction du type de développement en cours.

Je me rappelle avoir collaboré, il y a quelques années, avec le département de maintenance d’une compagnie aérienne. Les membres du personnel étaient autorisés à choisir leur propre échéancier au début de chaque mois et, à défaut de coordination (comme c’était souvent le cas), il était possible d’en arriver à gérer une équipe dont aucun membre ne travaillait. Leur difficulté de gestion de projet n’était pas de savoir quand le travail serait accompli, mais si quelqu’un allait venir travailler. Dans ce cas, l’EPM a été assurée en implémentant un outil de planification des équipes.

Même si nous nous concentrons sur la difficulté d’EPM en relation avec les échéanciers de projet, il n’est pas immédiatement évident que le déploiement d’un système centralisé de gestion de projet est la seule ou la meilleure réponse. Il est judicieux de s’interroger sur l’interaction nécessaire entre les membres du personnel de gestion de projet. Si ces personnes doivent collaborer régulièrement pour résoudre des conflits de ressources, afin d’anticiper d’autres priorités d’organisation à venir ou l’incidence de la progression d’un projet sur un autre, envisager un outil tel que Project Server a du sens. Par contre, je finis souvent par interagir avec des organisations qui n’ont même pas soulevé cette question.

Certaines organisations comptent un nombre restreint de planificateurs et un grand nombre de ressources. Même dans une organisation de bonne taille, cette structure peut dépendre du secteur d’activité et du type des projets en cours d’accomplissement. Il y a peu, j’ai rencontré une organisation qui était convaincue d’avoir choisi la solution appropriée pour résoudre son problème EPM. Ils m’ont demandé d’exposer la solution mais, comme d’habitude, je leur ai demandé de m’exposer d’abord leur problème de gestion de projet.

Après qu’ils eurent décrit leur environnement sur un tableau blanc, il était évident pour tous, y compris eux, que la solution choisie n’allait pas résoudre leur problème.

Dans ce cas, le problème consistait en un manque de progression du projet signalé par un grand nombre de sous-traitants. Le client a déterminé que la solution consistait à imposer à ses sous-traitants un moment et un type de facturation de feuille de temps. Le directeur du programme était découragé. « Jamais nous ne pourrons imposer cela dans les contrats de sous-traitance », disait-il. Heureusement, un membre du service financier est intervenu : « Vous savez, il existe déjà dans le contrat de sous-traitance une clause imposant le remplissage d’une feuille de temps de notre choix. » Problème résolu.

J’ai souvent évoqué ici la nécessité d’étudier le problème avant de proposer la solution, mais il est difficile d’ancrer cette idée dans les esprits. Une réflexion logique nous amènerait à considérer que l’ordre de détermination d’une solution automatisée serait le suivant :

  1. identification du problème ;

  2. définition de la solution ;

  3. détermination de l’opportunité d’automatiser la solution (et, le cas échéant, de la façon de procéder).

Les démonstrations de solutions automatisées sur des sites web, des vidéos et ailleurs nous font oublier cela. Nous ne recherchons évidemment pas de solution tant que nous ne rencontrons pas de problème, mais les solutions automatisées semblent si attrayantes que nous finissons par adopter la procédure suivante :

  1. choix de la solution automatisée ;

  2. création du problème en déployant la solution ;

  3. résolution du problème en définissant comment l’outil automatisé peut être appliqué à la solution ;

  4. tentative de se rappeler quel était le problème d’origine.

Le nouveau problème devient le déploiement de la solution pendant un certain temps, puis des semaines, des mois, voire des années, jusqu’à ce qu’une personne de l’encadrement supérieur demande quand le problème d’origine sera résolu et que tout le monde se regarde avec surprise. Il était facile d’oublier le problème.

Au fil des années, j’ai recommandé toutes sortes de solutions automatisées possibles. Project Server a bien sût été l’une des options, mais j’ai également recommandé une combinaison de Microsoft Project Pro et de SharePoint Server. J’ai recommandé d’utiliser une combinaison d’Excel et d’Outlook. J’ai recommandé d’utiliser des feuilles de temps tierces avec Project.

J’ai une fois recommandé d’utiliser un grand tableau blanc. Honnête. Il s’agissait d’une organisation avec laquelle j’avais longuement collaboré. Mon interlocuteur s’occupait d’immobilier et devait renouveler des baux à long terme. Lorsque j’ai demandé quel était le problème, il est apparu clairement qu’il était lié à la planification. La personne avait manqué quelques échéances importantes, et était convaincue qu’un outil de gestion de projet d’entreprise résoudrait le problème. L’organisation avait déjà demandé que des rapports soient distribués à plusieurs cadres, afin de ne pas manquer d’échéances futures. « Combien d’utilisateurs y aurait-il ? », ai-je demandé. « Moi seul », a-t-il répondu. « Combien de ces projets y a-t-il en même temps ? », ai-je demandé. « Sept ou huit », a-t-il répondu. « Et combien de ces jalons d’échéance gérez-vous pour chaque projet ? » « C’est très compliqué, car il y a environ une demi-douzaine d’échéances pour chacun. »

Il m’apparaissait déjà évident que nous ne devrions pas installer un grand système EPM centralisé pour ce client infortuné.

« Pourquoi ne pas simplement placer un grand tableau blanc dans votre bureau et utiliser des marques de couleur pour les différentes échéances ? », ai-je demandé. « Vous pourriez utiliser du bleu pour la première, du vert pour la deuxième, du rouge pour la dernière, etc. ».

Il a pris de nombreuses notes, fascinée par le concept. J’ai quitté l’entreprise, conscient de n’avoir rien vendu ce jour-là, et d’avoir laissé cette personne déçue de ne pas pouvoir déployer le système qu’elle avait envisagé. Tandis que je rentrais chez moi en voiture, mon téléphone a sonné. C’était lui. « Pourriez-vous expliquer les différentes couleurs pour le tableau blanc ? », m’a-t-il demandé.

Comprendre les problèmes que vous tentez de résoudre avant de concevoir la solution et de choisir la manière de l’automatiser ne permet pas seulement d’économiser de l’argent. Cela permet également d’épargner une quantité considérable de temps à travailler sur des éléments de l’organisation qui ne présentent pas de problème nécessitant une résolution prioritaire.

Lorsque les problèmes que vous tentez de résoudre peuvent être résolus de façon optimale avec un logiciel de gestion de projet d’entreprise centralisé, rien d’autre ne peut réellement s’y substituer, mais la compréhension que vous aurez acquise en exposant le problème sera utile même dans ce cas. Votre équipe de déploiement pourra créer des indicateurs de réussite grâce auxquels le projet pourra être considéré comme un succès une fois les problèmes résolus. Centralisation ou décentralisation ? Il est possible de déployer une solution EPM des deux façons.

À 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.

×