Assistance GPS pour un déploiement EPM

Cet article fait partie de notre collection « From the Trenches ». Il décrit comment définir une « feuille de route » de déploiement de gestion de projets d’entreprise lorsque vous envisagez d’implémenter EPM. Il décrit les facteurs uniques à prendre en compte lors de la planification de votre itinéraire de déploiement.

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

Assistance G.P.S. dans la feuille de route d’un déploiement EPM

Dans ma dernière colonne, j’ai parlé de l’utilisation d’une approche progressive pour planifier le déploiement de la solution de gestion de projets d’entreprise (EPM) de Microsoft. Aujourd’hui, nous allons nous attaquer à l’élaboration d’une feuille de route de déploiement EPM dans le cadre de votre plan de projet.

Si vous êtes allé à Microsoft Live Maps, vous savez que les itinéraires nécessitent deux choses : une destination et un point d’origine. Lorsque nous appliquons cette analogie à un déploiement EPM, nous devons penser en termes similaires :

  1. Point d’origine défini en termes de technologie, de processus et de personnel

  2. Destination définie en termes métier et hiérarchisée

Nous pouvons également définir des « stations de chemin » ou des arrêts intermédiaires où vous pouvez vous regrouper, prendre des photos, profiter du paysage pendant un certain temps et réapprovisionner vos fournitures pour la prochaine étape du voyage.

Lors de la création d’une feuille de route ou d’une direction, il est assez courant d’avoir deux échelles. Nous gardons la prochaine étape du voyage dans les détails, jusqu’à un itinéraire tour par tour. Toutefois, nous pouvons également conserver une carte de niveau supérieur de l’ensemble du voyage avec moins de détails pour conserver notre jambe actuelle dans le contexte de l’ensemble du voyage. En termes de gestion de projet, nous appelons cela la « planification par vagues propagées ».

« Directions »

Lors de l’élaboration d’une feuille de route de déploiement EPM, nous commençons toujours par la vision ou l’intention de la direction de l’entreprise en termes de ses efforts EPM. Cela nous donne la destination dont nous aurons besoin pour effectuer des itinéraires, comme le ferait Microsoft Live Maps.

Carte montrant la route de Seattle à Montréal.

Si nous demandions simplement : « Que voulez-vous ? », la réponse vient presque invariablement en termes de solution. Personnes sont susceptibles de dire « J’ai besoin d’un rapport qui ressemble à ceci » ou « Notre entreprise a besoin d’une analyse de portefeuille ».

Pour ceux d’entre nous dans le secteur des solutions, nous savons que ces types de notes de conception sont lourds de risques. Nous formons nos consultants pour être à l’écoute des clients qui décrivent leur problème comme une solution. « C’est une solution à un problème, dira-t-on, pas le problème. Définissons le problème.

Nous avons donc tendance à ne pas demander « Que voulez-vous ? » Au lieu de cela, les questions qui peuvent être utiles pendant une vision peuvent inclure :

« Quelle décision d’entreprise êtes-vous désormais incapable de prendre ou ne pouvez-vous prendre qu’avec de grandes difficultés, dont la fabrication serait facilitée par le déploiement d’EPM ? »

Ou :

« Selon vous, quel aspect de l’organisation pourrait être rendu plus efficace par une augmentation du débit ou une diminution des efforts grâce à ce déploiement EPM ? »

Maintenant, à qui devrions-nous poser ces questions ? Pourquoi, les gens qui prennent ces décisions, bien sûr! Si vous avez déjà eu une mini-fourgonnette pleine d’enfants et que vous vous êtes tourné pour leur demander où vous devriez aller comme destination, vous savez que vous obtiendrez 50 réponses.

De même, nous devons nous assurer que les décideurs de l’organisation sont un élément clé de ce processus, sinon nous courons le risque de choisir une direction vers laquelle le « conducteur » n’est pas prêt à se déplacer. Il y a un avantage supplémentaire à intégrer la haute direction dans le processus d’élaboration de la feuille de route EPM à l’heure actuelle. En plus d’être un participant essentiel dans le choix de la direction à suivre pour le déploiement d’EPM, ils sont également en mesure d’avoir une idée de l’ampleur du projet. L’un des défis les plus courants et les plus difficiles à relever pour réussir un déploiement EPM est la prise en charge de la gestion à long terme. Certains cadres supérieurs n’ont pas considéré à quel point cela pourrait changer les pratiques et procédures existantes et à quel point cela pourrait perturber, même temporairement, cette situation. Ils peuvent également ne pas avoir une compréhension de l’effort qu’un projet de changement de culture comme EPM peut être.

Au cours de notre travail avec la haute direction ainsi que la gestion de projet et peut-être le personnel de ligne, nous essayons de relier les décisions d’entreprise ou l’efficacité de l’entreprise avec les processus et la technologie. Existe-t-il un processus qui doit être créé pour répondre à cette exigence ? Qu’est-ce qu’il doit accomplir ? Existe-t-il une fonction système qui existe ou doit être créée pour servir cette décision d’entreprise? Qu’est-ce qu’elle aurait besoin de fournir ?

L’analyse de base des systèmes est essentielle dans cette phase. Nous commençons à partir de la « sortie » de la décision métier et revenons aux éléments de données nécessaires pour prendre ces décisions. Dans certains cas, nous constatons que les données de base ne sont tout simplement pas présentes et que cet élément de la feuille de route est marqué comme « à haut risque ». Après tout, nous devons maintenant inclure la collecte de données dans un nouveau format ou une nouvelle structure pour capturer ces nouveaux éléments de données avant même que nous puissions penser à fournir le meilleur processus métier, ce qui peut être un ordre élevé dans certains cas.

Nous avons une autre chose à faire avant de fermer le processus de destination et c’est de hiérarchiser les différents éléments de la vision finale. Il est très courant de penser au début du processus d’élaboration de la feuille de route que les priorités iront dans un sens, mais vous constaterez qu’au fur et à mesure que vous allez les enregistrer, elles vont très différemment. Il est intéressant de noter qu’au moment où tout le monde s’est mis d’accord sur les cibles incluses dans notre destination, il y a un consensus remarquable sur les priorités principales.

La prochaine chose dont nous avons besoin pour les directions est un point d’origine et nous le gérons par le biais d’un inventaire de l’emplacement actuel de l’organisation par rapport aux objectifs que nous avons choisis.

Carte montrant la route de Seattle à Montréal.

Nous examinons le personnel existant. Sont-ils formés à la gestion de projet pour leurs rôles particuliers ? Avons-nous suffisamment de personnel avec suffisamment d’expérience pour atteindre les objectifs qui ont été fixés? N’oubliez pas que nous devons examiner plusieurs mesures ici, car différentes personnes auront un rôle différent dans le processus de gestion de projet d’entreprise éventuel. Il n’est pas logique de former chaque employé à être un planificateur de projet si, en fait, il ne sera jamais responsable de créer des planifications. Par défaut, nous pensons à quatre rôles : Administrateur, Responsable de projet, Ressource individuelle et Exécutif. Si des feuilles de temps sont impliquées, nous considérons également les superviseurs comme le cinquième rôle. Bien sûr, en fonction de la destination que nous avons définie dans notre processus de conception d’origine, les rôles peuvent être très différents. Cela change profondément le processus d’inventaire des compétences, c’est pourquoi nous commençons toujours par définir la destination avant de penser au point d’origine.

Nous examinons également le processus existant. Existe-t-il un processus de gestion de projet déclaré ou documenté ? Comment est-il maintenu ? Qui en est responsable ? S’il existe déjà un bureau de gestion de projet, une grande partie de cet effort est concentré là-bas. Après tout, il est inutile de créer de nouvelles procédures si des procédures et des processus existants sont déjà efficaces. Nous pouvons inventorier les processus existants qui sont à la fois à l’intérieur du processus de gestion de projet actuel et à l’extérieur, en fonction des objectifs ultimes de l’environnement EPM.

Par exemple, nous avons peut-être décidé que la gestion des contrats allait être un élément important de notre nouvel environnement EPM, et que cela n’a jamais fait partie des processus de gestion de projet au sein de cette organisation. Pourtant, si nous regardons un peu plus loin, nous pouvons constater que l’organisation dispose d’un ensemble solide de contrôles pour la gestion des documents et du flux de travail existant qui déplace déjà des documents, peut-être dans SharePoint. Il s’agit d’un processus idéal pour nous d’adopter et, le cas échéant, de l’ajuster pour nous assurer qu’il permettra d’autonomiser cet aspect du nouvel environnement de gestion de projet d’entreprise. Cela a un avantage triple. Tout d’abord, nous n’avons pas besoin de consacrer l’effort à la création d’un nouveau processus. Deuxièmement, nous savons que le personnel a déjà les compétences et les habitudes nécessaires pour utiliser le processus de cette façon, ce qui signifie qu’il n’y a aucun effort de formation ou d’effort pour que le personnel se conforme. Enfin, nous n’avons pas la situation difficile d’essayer de créer un processus distinct qui pourrait être en désaccord avec un processus existant pour la gestion des documents, tels que les contrats.

Nous savons que l’un de nos plus grands défis sera la conformité. Pas de créer le système, mais d’amener tout le monde à l’utiliser et à l’utiliser de manière cohérente. Plus nous pouvons adopter des habitudes, des pratiques et des procédures existantes incorporées dans l’organisation, plus la conformité devient facile.

Enfin, vous avez besoin d’un inventaire de la plateforme technologique. Étant donné que la solution Microsoft EPM repose sur une plateforme de technologie, il est probable qu’une partie de cette technologie soit déjà en place, mais il est également possible que l’organisation devra mettre à niveau une partie de sa plateforme pour que la solution que vous concevez fonctionne. SharePoint et SQL Server sont des éléments évidents du déploiement de Microsoft Office Project Server, mais vous devrez peut-être également vérifier la compatibilité du navigateur (tout le monde utilise-t-il la dernière version d’Internet Explorer ?), l’état de sécurité (le système sera-t-il orienté vers l’extérieur ?), quelle version de SQL Server est déployée (s’agit des services OLAP ou SQL Server Reporting Services déjà utilisé ?). Vous devrez peut-être également envisager d’autres systèmes avec lesquels vous devrez interagir ou intégrer. Comment accéderez-vous à ces systèmes en production ?

La taille du système planifié peut également nécessiter l’analyse du matériel, du réseau et d’autres éléments d’infrastructure pour s’assurer que le système aura la structure dont il aura besoin lorsqu’il arrivera.

Comme avec n’importe quel système d’entreprise, vous souhaiterez planifier une zone de production et une zone intermédiaire afin que les mises à jour et les améliorations puissent être créées dans le labo plutôt que sur le système actif au fil du temps. Vous devrez peut-être également planifier une phase pilote ou de preuve de concept; quelque chose dont je parlerai plus dans ma prochaine colonne.

« Recalcul de l’itinéraire »

Quand l’unité G.P.S. dans ma voiture découvre que j’ai raté un virage, une très belle voix de dame dit « Recalculing route ». Quelques instants plus tard, la ligne à travers ma carte change et j’ai de nouvelles directions. Dans un déploiement EPM, nous devons être prêts pour un détour ou un virage bloqué pour les réparations. Peut-être avons-nous raté cette sortie d’autoroute. Comment traiter le replanification ? Il y a deux choses à se demander quand vous sortez de cours : Tout d’abord, allez-vous toujours au même endroit ? Deuxièmement, comment arriver à partir d’ici ? L’une de mes citations de gestion de projet préférées sur ce sujet vient de Napoléon Bonaparte, qui a dit un jour : « Un plan de bataille dure jusqu’au contact avec l’ennemi ».

Carte montrant l’itinéraire de Seattle à Redmond.

Dans un déploiement EPM, comment appliquer ce même principe ? Tout d’abord, vous avez besoin d’une mesure pour déterminer si vous n’êtes plus sur la voie. Si un membre de l’équipe a un rendez-vous d’urgence chez le dentiste demain et qu’il est absent du bureau pendant quatre heures, devrions-nous alors laisser cet écart changer toutes les tâches en aval, replanifier tout le monde à partir de demain à midi jusqu’à la fin du projet, puis envoyer un e-mail à tout le monde avec leurs nouvelles heures d’affectation?

Absolument pas.

Un écart de quatre heures pour une ressource sur la durée de vie de six mois d’un projet impliquant des dizaines de personnes ne suffit pas pour justifier notre changement de chemin. Ce que nous devons faire pour démarrer n’importe quel type de projet d’entreprise est de définir des seuils de progrès acceptables. Le monde de l’aérospatiale et de la défense trouve un nouveau terme pour cette dernièrement, « Tripwires », qui est très descriptif. Nous pouvons déterminer quels critères nous indiqueraient que notre itinéraire doit être recalculé. Il existe plusieurs métriques ou mesures classiques à prendre en compte. Tout d’abord, si le coût d’achèvement prévu varie de plus de X % par rapport au budget initial, cela peut constituer un examen du plan de projet. Vous pouvez faire la mesure du coût en heures de travail ou en argent. L’un ou l’autre est efficace. Peut-être que si la date de fin prévue varie de plus de X jours par rapport à la date de fin initialement prévue, cela pourrait constituer une révision du plan de projet.

Vous pouvez également décider que l’absence de certains jalons clés de plus d’un certain nombre de jours est un tripwire, ou vous pouvez identifier certains risques en cours de réalisation en tant que tripwire, ou vous pouvez déterminer qu’un changement de certains membres clés de l’équipe de projet, comme le sponsor exécutif, est un tripwire. Il est plus important de définir certains critères que d’obtenir les critères exactement corrects. Rappelez-vous également que vous devrez mesurer ces critères tout au long de la durée de vie du projet. Par conséquent, si vous choisissez 50 ou 100 métriques différentes, vous risquez de passer plus de temps à mesurer le projet qu’à le faire !

Une fois que vous avez déterminé que vous n’êtes pas sur la bonne voie, la meilleure façon de revenir sur les rails consiste à effectuer une révision du plan de projet. Nous vous recommandons d’inclure une représentation à la fois du groupe d’origine de la haute direction qui a aidé à établir notre destination en premier lieu et du groupe au sein de l’équipe de gestion de projet qui a aidé à effectuer l’inventaire initial. Les révisions de plan de projet peuvent s’embourbér dans l’attribution de la responsabilité pour la raison pour laquelle le projet est hors de la voie et pourquoi un certain tripwire a été déclenché. Un tel effort peut être extrêmement contre-productif. Nous vous recommandons de vous concentrer sur les questions suivantes :

  1. Que s'est-il passé ?

  2. Où en sommes-nous arrivés ? Quel est notre point d’origine actuel ?

  3. Sommes-nous toujours engagés dans notre destination d’origine ou y a-t-il une raison convaincante de revoir ce processus ou même de refaire le processus d’étude?

  4. Devons-nous réinitialiser l’un de nos jalons ou phases intermédiaires ?

  5. Devons-nous modifier l’une de nos équipes de projet ?

  6. Devons-nous réinitialiser l’une de nos métriques tripwire ?

Les questions que nous avons trouvées moins productives sont les suivantes :

  • A qui est la faute d’être là ? Qui est responsable ? Qui est responsable ?

  • Comment pouvons-nous « revenir » sur les rails; retour à l’ancien plan ?

La raison la plus courante d’un examen de plan de projet est que les priorités de l’organisation changent. Par exemple, les éléments qui ont été conçus pour être à la phase 3 sont demandés dans la phase 2. Il s’agit généralement du signe d’une dynamique saine au sein de l’organisation et du résultat que des personnes commencent à réfléchir sérieusement aux implications du déploiement du système EPM.

Mauvais temps

Avant de partir sur une longue route, vous vérifiez probablement le canal météo (ou weather.msn.com) pour vous assurer qu’aucun mauvais temps n’affectera votre voyage. Les risques font partie de la vie. N’oubliez pas que s’il n’y avait aucun risque, il n’y aura pas besoin de gestionnaires de projet ! La planification des risques les plus criants n’est pas un processus compliqué. Commencez par le début du processus de conception, et lorsque vous examinez chacun des éléments de la destination que vous concevez, demandez au groupe quels obstacles pour atteindre cette destination ils peuvent penser. Dans certains cas, les risques seront importants. Il n’est pas rare qu’une organisation désire un résultat particulier, mais seulement pour constater que les données brutes requises pour fournir ce résultat n’ont jamais été collectées et qu’il peut y avoir une résistance considérable à la collecte de ces données.

Page MSN montrant les prévisions météorologiques pour Montréal.

Dans un exemple, nous avons trouvé une organisation qui souhaitait planifier la capacité des ressources. Cela exigerait une comptabilité complète de toute la disponibilité des ressources de tout le personnel du projet et une comptabilité complète de toutes les charges de travail possibles qui pourraient être appliquées à ce personnel. Lorsque nous avons demandé si ces deux options étaient disponibles, on nous a dit que, bien sûr, elles étaient disponibles, mais seulement pour les deux cinquièmes de l’organisation. Quand nous avons ensuite découvert que les trois cinquièmes de l’organisation pour laquelle les données n’étaient pas disponibles n’étaient même pas représentés à la réunion de prévision, nous avons dit : « Supposons. Les problèmes que vous rencontrez avec la planification de la capacité des ressources se trouvent dans ces trois divisions. Naturellement, ils l’étaient, et nous avons dû identifier l’inscription des responsables de division de ces divisions comme une phase distincte du projet et un risque très élevé.

Au fur et à mesure que vous travaillez avec la gestion de projet et le personnel de ligne dans le processus d’inventaire, demandez au cours des entrevues les risques que ces employés pourraient être en mesure d’identifier.

Une fois les risques identifiés, il est important de les organiser. Si vous ne l’avez pas fait auparavant, les informations les plus basiques seront les plus précieuses. Incluez ce qui suit :

  1. Brève description du risque

  2. La zone ou la phase du projet qu’il peut affecter

  3. Gravité du risque si les critères sont atteints

Enfin, l’une des choses les plus importantes que vous pouvez faire est d’ajouter des détails sur l’atténuation des risques. Le simple fait de penser à un risque est un facteur atténuant énorme, mais alors que le déploiement EPM en est à ses balbutiements, il peut être précieux d’entrer des notes sur la façon dont vous pourriez gérer un risque particulier pendant le projet. Il est courant que les décisions soient prises à la hâte dans un contexte émotionnel lorsque les risques sont pris en compte. Avoir des notes qui ont été pensées alors que les têtes plus froides ont prévalu peut être utile.

Conduisons la voiture que nous construisons

Voici un conseil sur l’élaboration de votre feuille de route qui peut rapporter d’énormes dividendes : Utilisez Project Server et la solution Microsoft EPM pour vous aider à créer et à gérer votre plan de feuille de route. Cela semble évident peut-être, mais il est assez rare pour les organisations de le faire que nous le mentionnons ici.

Site SharePoint affichant une liste de livrables de projet.

Un responsable supérieur m’a dit un jour que son équipe de projet lui avait demandé s’il pensait que l’utilisation de la solution Microsoft EPM pour déployer la solution Microsoft EPM n’était pas exagérée. « Si nous construisions des avions à réaction pour gagner notre vie, nous ne les transporterions pas au travail », ont-ils dit. — Tu plaisantes ? » répondit-il. « Si je pouvais voler un avion à réaction pour travailler, je le ferais tous les jours! »

En fait, l’utilisation de la solution Microsoft EPM pour l’équipe de déploiement EPM est une excellente idée.

L’installation de Project Server et des autres éléments de la solution Microsoft EPM n’est pas un énorme défi technique, et avec le minimum absolu de configuration, vous pouvez être opérationnel avec une petite équipe de déploiement en tant qu’utilisateurs en quelques jours. Il s’agit d’un excellent moyen pour les utilisateurs qui deviendront vos champions de déploiement de se familiariser avec l’utilisation et les avantages du système avant qu’il n’arrive aux bureaux de la majeure partie du personnel.

Ce déploiement ne doit pas être votre environnement de production. Vous allez presque certainement configurer cela et le personnaliser pour répondre à la vision de la destination d’origine. Vous ne travaillerez presque certainement pas sur des éléments tels que la planification de plusieurs projets, la planification de la capacité des ressources ou l’optimisation du portefeuille dans votre itération de déploiement EPM de Project Server, mais vous serez en mesure de fournir un système qui peut offrir d’excellents avantages. Nous vous recommandons ce qui suit :

  1. Effectuez une planification d’ondes propagées en tant que projet publié.

    Un calendrier de vagues propagées met en évidence la phase actuelle en détail et les phases futures en tant que résumé. Cela permet aux membres de l’équipe de savoir sur quoi ils doivent travailler maintenant, tout en leur permettant de voir le projet dans un contexte plus large.

  2. Gérer le document de vision dans l’espace de travail du projet.

    L’espace de travail du projet est un site SharePoint lié au projet qui inclut par défaut une zone pour les problèmes, les risques et les documents. Pourquoi ne pas placer tous vos documents de projet ici pour le projet de déploiement EPM et instituer le contrôle de version de SharePoint afin que vous puissiez toujours revenir à la version d’origine ?

  3. Placez vos approbations de jalon et vos « portes » dans les livrables de l’espace de travail de projet.

    Il s’agit d’une liste de tâches simple que vous pouvez lier à des tâches dans Project Server. Il donne une vue très haut de gamme du projet et est un outil facile à utiliser pour la gestion des seuils afin de déterminer quand vous allez « hors cours ».

  4. Placez la gestion des modifications dans l’espace de travail de projet en tant que problèmes.

    La gestion du changement est l’un des grands défis des projets technologiques. À mesure que de nouvelles suggestions de modifications au projet surviennent, faites-les entrer dans la zone Problème en tant que changement potentiel à gérer. En ajoutant quelques champs à cette zone, vous pouvez obtenir une liste d’éléments prioritaires et les personnes responsables de ces éléments à tout moment.

  5. Placez les risques du projet dans l’espace de travail du projet.

    Outre les documents et les problèmes, la zone à risque de l’espace de travail est l’endroit idéal pour ajouter vos risques et vos plans d’atténuation. En fait, l’écran par défaut contient tous les champs prêts à être utilisés.

Y sommes-nous ?

« Presque. Nous y serons bientôt. »

Un déploiement EPM peut amener une organisation à tellement d’endroits différents qu’il n’existe aucun moyen de simplement publier la planification par défaut pour tout le monde. Mais quelques minutes de recherche sur Internet peuvent vous fournir un grand nombre d’exemples possibles pour différentes parties du projet. Si je résume l’exercice de feuille de route ci-dessus, vous êtes susceptible de vous retrouver avec un projet qui comporte quelques phases évidentes :

  1. Exercice de feuille de route

  2. Envisioning (choisir la destination)

  3. Inventaire des processus existants (identifier le point d’origine)

  4. Inventaire du personnel existant (identifier le point d’origine)

  5. Inventaire de la technologie (identifier le point d’origine)

  6. Déploiement de la solution EPM pour l’équipe EPM

  7. Étape 1

  8. Design

  9. Configuration, personnalisation, documentation

  10. Pilote

  11. Formation

  12. Déploiement

  13. Examen de la phase 1 et ajustement de la phase 2 au besoin

  14. Étape 2

  15. Étape 3

  16. Étape 4

  17. Résumé du projet

L’application d’un exercice de feuille de route à votre déploiement EPM peut changer l’expérience de chaos à gérable très rapidement. N’oubliez pas de choisir d’abord votre destination, de déterminer votre point d’origine et de tracer le chemin entre eux.

Heureux de voyager!

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