EPM : Centralisation ou décentralisation ?

Cet article fait partie de notre collection « From the Premier pays ». 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, voir EPM centralisé ou décentralisé ?

Pour plus d’articles, consultez les livres blancs « À partir des sables».

EPM : centralisé ou décentralisé ?

J’aime la gestion Enterprise Project depuis que je suis entrée dans le secteur de la gestion de projets au début des années 1980. Vous pensez alors que je vote 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 voulons dire par Enterprise Project gestion.

EPM peut avoir un grand nombre d’éléments différents pour différentes personnes. J’ai déjà abordé dans d’autres articles de cette colonne comment un déploiement EPM peut se concentrer sur la gestion des documents pour une organisation et les planifications intégrées pour la suivante. Enterprise Project gestion de projet a toutefois pour base la notion selon laquelle les utilisateurs doivent interagir les uns 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 fonctionnent pas de manière totalement indépendante. Mais cela signifie-t-il que la seule façon d’obtenir cette « interaction » consiste à 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écapitulatifs à l’échelle de l’entreprise en raison de la gestion ponctuelle de tous les projets. Dans ce cas, EPM peut être obtenu simplement en ayant des normes de projet partagées entre tous les membres du 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. Un site SharePoint simple suffirait peut-être.

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

Dans certaines organisations, le défi de gestion de projet consiste simplement à faire avancer les projets de développement de programmation. Si tel est le cas, les outils déjà présents dans un produit comme Visual Studio Team Services suffisent. Il est assez courant dans les projets de programmation de trouver que de nombreuses tâches peuvent être effectuées dans presque n’importe quel ordre, de sorte que les exigences de la planification des chemins critiques peuvent ne pas être appropriées en fonction du type de développement effectué.

Je me rappelle qu’il y a un certain nombre d’années, j’ai travaillé avec le service maintenance d’une compagnie aérienne. Le personnel était autorisé à choisir ses propres plannings 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 travail d’équipe uniquement pour savoir que personne ne travaillait. Leur défi en matière de gestion de projet n’était pas « Quand le travail sera-t-il terminé ? » c’était « est-ce que tout le monde vient travailler ? » Dans ce cas, EPM a été obtenu en implémentant un outil de planification des déplacements.

Même lorsque nous concentrons le défi EPM sur les planifications de projets, 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 intéressant de se demander quelle interaction le personnel de gestion de projet doit avoir entre eux. 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 affecte un autre projet, l’examen d’un outil tel que Project Server est parfaitement logique, mais je finis souvent par interagir avec des organisations qui n’ont même pas encore posé cette question d’elles-mêmes.

Dans certaines organisations, nous trouvons un petit nombre de planningeurs et un grand nombre de ressources. Même dans une organisation de bonne taille, il peut s’agit de la structure en fonction du secteur d’activité 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 solution adaptée à son défi EPM. Ils m’ont demandé d’articuler la solution, mais, comme d’habitude, j’ai demandé qu’ils d’abord articulent 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 ne résoudrait pas leur problème.

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

L’idée de passer en travers du problème avant d’arriver à la solution est celle dont je parle souvent ici, mais c’est difficile à adopter. La 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, si c’est le cas, comment) automatiser la solution

Les démonstrations automatisées de solutions sur des sites web, des vidéos et ailleurs nous font oublier cela. Bien entendu, nous ne sommes pas à la recherche d’une solution, sauf si nous avons un type de problème, mais les solutions automatisées semblent si attrayantes que nous finirons par faire ceci :

  1. Choisir la solution automatisée

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

  3. Résoudre ce problème en définissant la façon dont l’outil automatisé peut être appliqué à la solution

  4. Essayez de vous souvenir du 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, qu’une personne de la direction supérieure demande à quel moment le problème d’origine sera résolu et tout le monde se regardera plutôt surpris. Il était facile d’oublier.

Au fil des ans, j’ai recommandé tous les types de solutions automatisées possibles. Oh, Project Server a été l’une des options, bien sûr, mais j’ai également recommandé une combinaison de Microsoft Project Pro et SharePoint Server. J’ai recommandé d’utiliser une combinaison de Excel et 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. Intègre. L’organisation était celle avec qui j’ai fait des affaires pendant des années. La personne en question était dans un rôle immobilier et a dû renouveler des baux à long terme dans l’immobilier. Lorsque j’ai demandé la cause du problème, il s’agissait clairement d’un problème de planification. La personne a manqué quelques échéances importantes et s’est assuré qu’un outil de gestion de projet d’entreprise corrigera 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 y a-t-il d’utilisateurs ? » J’ai demandé. « Moi uniquement », répondit-il. « Combien de ces projets sont-ils à la fois ? » 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 existe environ une demi-dizaine d’échéances pour chacune d’elles », m’a-t-il dit.

Il était déjà évident pour moi que nous ne devons pas installer un système EPM centralisé de grande taille pour ce collègue médiocre.

« Pourquoi ne pas simplement placer un grand tableau blanc dans votre cube et utiliser des marqueurs de couleur pour les différents jalons ? » J’ai demandé. « Vous pouvez utiliser le bleu pour le premier, le vert pour le deuxième, le rouge pour le dernier, etc. »

Il a pris des notes copieuses, en s’intéressant au concept. J’ai quitté l’entreprise en sachant que je n’ai vendu aucun service ou produit ce jour-là, mais que j’ai laissé la personne sachant qu’elle ne pouvait pas déployer le système qu’elle envisageait. Sur le chemin d’accueil, mon téléphone a sonné dans la voiture. C'était lui. « Pourriez-vous expliquer les différentes couleurs du tableau blanc ? » il a demandé.

Déterminer les problèmes que vous essayez de résoudre avant de concevoir la solution et avant de choisir comment l’automatiser n’économise pas simplement de l’argent. Cela peut faire gagner beaucoup de temps à travailler sur des éléments de l’organisation qui n’avaient pas de problème à résoudre 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 fera réellement, mais le focus que vous aurez obtenu en articulant le problème vous aidera même là. Votre équipe de déploiement peut créer des mesures de réussite qui permettent de déclarer le projet comme une réussite lorsque les problèmes ont été résolus. Centraliser ou décentraliséer ? Enterprise Project gestion des données peut être obtenue avec l’une ou l’autre.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de Hms, hms Software basé au Canada, un microsoft certified Partner. Il dispose d’un degré d’économie de Mc Galerie University et plus de 30 ans d’expérience dans l’automatisation des systèmes de contrôle de projet. Il est membre de longue date de l’Project Management Institute (PMI) et a contribué à la recherche des chapitres Du groupe d’utilisateurs du Microsoft Project (MPUG) de Contrôle d’ensemble. Les publications pour lesquelles Chris a écrit incluent Classement, Heavy Construction News, Computing Canada magazine et PMI’s PMNetwork, et il est régulièrement habitué à Project Times. Il enseigne la gestion avancée Project à l’Université Mc University et parle souvent dans les fonctions d’association de gestion de projet en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système de gestion du temps orienté projet TimeControl et est un partenaire Microsoft Project solution depuis 1995.

Chris Vandersluis peut être contacté par courrier électronique à l’adresse : chris.vandersluis@hms.ca

Si vous souhaitez lire d’autres articles relatifs à EPM par Chris Vandersluis, consultez le site d’aide EPM de HMS ( https://www.epmguidance.com/?page_id=39) .