EPM : Centralisation ou décentralisation ?

Cet article fait partie de notre collection « From the Trenches ». Il décrit comment les organisations doivent comprendre les problèmes qu’elles tentent de résoudre lorsqu’elles décident d’implémenter un système de gestion de projet. Le déploiement d’un système de gestion de projets centralisé n’est parfois pas la bonne solution.

Pour télécharger la version Word de cet article, consultez EPM-Centralized ou Decentralized ?.

Pour plus d’articles, consultez les livres blancs « From the Trenches ».

EPM - Centralisé ou décentralisé ?

J’ai été un partisan de la gestion de projets d’entreprise depuis que je suis entré dans le secteur de la gestion de projets au début des années 80. Vous penseriez donc que je voterais toujours du côté de la gestion de projet centralisée, mais ce n’est pas toujours le cas. Examinons un instant ce que nous entendons par Gestion de projets d’entreprise.

EPM peut signifier beaucoup de choses différentes pour différentes personnes. J’ai déjà abordé dans d’autres articles de cette colonne comment le focus d’un déploiement EPM peut être la gestion des documents pour une organisation et les planifications intégrées pour la suivante. Toutefois, la gestion de projet d’entreprise a à sa base la notion que les personnes doivent interagir les unes avec les autres dans l’exercice de gestion de projet. Cela signifie que le responsable de projet et/ou l’équipe de gestion de projet ne travaillent pas complètement indépendamment. Mais cela signifie-t-il que la seule façon d’obtenir cette « interaction » est d’avoir un système de planification de projet centralisé ? Pas nécessairement. Pour certaines organisations, le défi de gestion de projet peut être une incapacité à produire des rapports de gestion de projet résumés à l’échelle de l’entreprise en raison de la gestion ad hoc des projets. Dans ce cas, l’EPM peut être obtenue simplement en ayant des normes de projet qui sont partagées entre tout le personnel de gestion de projet. Pour ce faire, il est préférable d’utiliser un pool central de modèles, de supports de formation, de documents et de normes de rapport que tout le monde peut utiliser. Peut-être qu’un simple site SharePoint suffirait.

Pour certaines organisations, le défi de gestion de projet peut être des planifications personnelles inefficaces en raison d’un manque de communication entre les ressources sur ce sur quoi elles travaillent et ce que leur prochain objectif est. Dans ce cas, ePM peut être réalisé en améliorant la communication entre les équipes et les équipes. Les outils peuvent être aussi simples qu’un calendrier partagé, une messagerie instantanée ou un portail partagé où les utilisateurs peuvent lister leurs priorités.

Dans certaines organisations, le défi de la gestion de projet est simplement d’obtenir des progrès sur les projets de développement de programmation. Si c’est le cas, les outils déjà présents dans un produit comme Visual Studio Team Services peuvent suffire. Il est assez courant dans les projets de programmation de constater que de nombreuses tâches peuvent être effectuées dans presque n’importe quel ordre, de sorte que les rigueurs de la planification des chemins critiques peuvent même ne pas être appropriées en fonction du type de développement effectué.

Je me souviens qu’il y a plusieurs années, j’ai travaillé avec le service maintenance d’une compagnie aérienne. Le personnel était autorisé à choisir ses propres horaires au début de chaque mois et si cela n’était pas coordonné (comme c’était souvent le cas), il était possible d’arriver pour gérer un quart de travail uniquement pour découvrir que personne ne travaillait. Leur défi de gestion de projet n’était pas « Quand le travail sera-t-il terminé ? », mais « est-ce que quelqu’un vient travailler ? » Dans ce cas, EPM a été réalisé en implémentant un outil de planification des équipes.

Même lorsque nous concentrons le défi EPM sur les planifications de projet, il n’est pas immédiatement évident que le déploiement d’un système de gestion de projet centralisé est la seule ou la meilleure réponse. Il est utile de demander quelle interaction le personnel de gestion de projet doit avoir les uns avec les autres. S’ils doivent collaborer régulièrement pour résoudre les conflits de ressources, pour voir quelles autres priorités de l’organisation sont à venir ou pour voir comment la progression d’un projet affectera un autre, l’analyse d’un outil comme Project Server est tout à fait logique, mais souvent, je finis par interagir avec des organisations qui ne se sont même pas posées cette question.

Dans certaines organisations, nous trouvons un petit nombre de planificateurs et un grand nombre de ressources. Même dans une organisation de bonne taille, il peut s’agir de la structure en fonction de l’industrie et du type de projets réalisés. Il n’y a pas si longtemps, j’ai rencontré une organisation qui était sûre d’avoir choisi la bonne solution pour son défi EPM. Ils m’ont demandé d’expliquer la solution, mais, comme d’habitude, j’ai demandé qu’ils exposent d’abord leur problème de gestion de projet.

Au moment où ils ont fini de décrire leur environnement sur un tableau blanc, il était évident même pour eux que la solution qu’ils avaient choisie n’allait pas résoudre leur problème.

Dans le cas présent, le problème était un manque d’avancement du projet signalé par un grand nombre de sous-traitants. Le client a déterminé que ce qu’il aurait vraiment besoin de faire serait d’imposer un type de feuille de temps et de facturation à ses sous-traitants. Le directeur de programme a été découragé. « Nous ne serons jamais en mesure d’obtenir cela dans les contrats de sous-traitants », ont-ils dit. Heureusement, un membre du ministère des Finances était présent. « Vous savez, répondit cette personne, une clause qui l’oblige à remplir la feuille de temps de notre choix figure déjà dans le contrat de sous-traitant. » Problème résolu.

L’idée de parcourir le problème avant d’arriver à la solution est une idée dont je parle souvent ici, mais c’est difficile à adopter. La pensée logique dicterait que l’ordre de détermination d’une solution automatisée serait :

1. Identifier le problème

2. Définir la solution

3. Déterminer s’il faut (et, le cas échéant, comment) automatiser la solution

Les démonstrations de solutions automatisées sur des sites web, des vidéos et ailleurs nous font oublier cela. Nous ne cherchons pas de solution, bien sûr, sauf si nous avons un problème, mais les solutions automatisées semblent si convaincantes que nous finissent par le faire :

1. Choisir la solution automatisée

2. Résoudre le problème lors du déploiement de la solution

3. Résolvez ce problème en définissant comment l’outil automatisé peut être appliqué à la solution

4. Essayez de vous 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 quelques années plus tard, quelqu’un de la direction supérieure demande quand le problème initial sera résolu et tout le monde se regarde plutôt surpris. C’était facile à oublier.

Au fil des ans, j’ai recommandé toutes sortes de solutions automatisées possibles. Bien sûr, Project Server a été l’une des options, mais j’ai également recommandé une combinaison de Microsoft Project Pro et 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 même recommandé une fois d’utiliser un grand tableau blanc. Honnête. L’organisation était celle avec laquelle j’avais fait des affaires pendant des années. La personne en question était dans un rôle immobilier et devait renouveler des baux à long terme dans des biens immobiliers. Quand j’ai demandé quel était le problème, il s’agissait clairement d’un problème de planification. La personne avait manqué quelques échéances qui étaient importantes et était certaine qu’un outil de gestion de projet d’entreprise permettrait de résoudre le problème. L’organisation avait déjà demandé que les rapports soient distribués à plusieurs cadres afin que les échéances futures ne soient pas manquées. « Combien d’utilisateurs y aurait-il ? » J’ai demandé. — Juste moi, répondit-il. « Combien de ces projets sont-ils en même temps ? » J’ai demandé « Sept ou huit », répondit-il. « Et combien de ces jalons d’échéance gérez-vous pour chaque projet « C’est très compliqué. Il y a environ une demi-douzaine d’échéances pour chacun d’eux », m’a-t-il dit.

Il était déjà clair pour moi que nous ne devrions pas installer un grand système EPM centralisé pour ce pauvre type.

« Pourquoi ne pas simplement mettre un grand tableau blanc dans votre box et utiliser des marqueurs de couleur pour les différents jalons? » J’ai demandé. « Vous pouvez utiliser le bleu pour la première, le vert pour le second, le rouge pour le dernier, etc. »

Il a pris d’abondantes notes, fasciné par le concept. J’ai quitté l’entreprise sachant que je n’avais vendu aucun service ou produit ce jour-là, mais que j’avais laissé la personne déçue de ne pas pouvoir déployer le système qu’il avait prévu. Sur le chemin du retour, mon téléphone a sonné dans la voiture. C'était lui. « Pourriez-vous expliquer les différentes couleurs du tableau blanc ? » a-t-il demandé.

Déterminer les problèmes que vous essayez de résoudre avant de concevoir la solution et avant de choisir comment l’automatiser ne fait pas qu’économiser de l’argent. Cela permet d’économiser énormément de temps sur des éléments de l’organisation qui n’ont pas eu de problème qui devait être résolu en premier lieu.

Lorsque les problèmes que vous essayez de résoudre peuvent être mieux résolus avec un logiciel de gestion de projet d’entreprise centralisé, rien d’autre ne sera vraiment utile, mais le focus que vous aurez gagné en articulant le problème vous aidera même là. Votre équipe de déploiement peut créer des métriques de réussite qui permettent au projet d’être déclaré comme un succès une fois les problèmes résolus. Centraliser ou décentraliser ? La gestion de projets d’entreprise peut être effectuée avec l’une ou l’autre des deux.

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