Last update: 01-04-2021 11:11
21'27"

Logiciel de gestion de projets (PPMProject Portfolio Management)

J'inclus clairement les PPM (Project Portfolio Management) dans la section réservée aux méthodes de travail. Ils couvrent aussi, mais à moindre mesure, les sujets "Canaux de communication" et "Accélération des cycles". Pour un rappel sur ces notions, veuillez vous rendre sur la page Big Picture.

Les PPM visent à adresser plusieurs sujets principaux. Si l'on commence par la vue de haut niveau, celle du portfolio, on dira qu'il s'agit avant tout de pouvoir déterminer quels projets démarrer, et dans quel ordre, en tenant compte de la meilleure allocation possible des ressources de l'organisation. C'est un des sujets de la page "PMO – Project Management Office (See also PSO)". On est donc ici dans les activités de sélection : choisir le ou les bons projets à démarrer.

Ensuite, ces logiciels doivent être capables de gérer, planifier, surveiller, établir les rapports, etc. des programmes [1] et des projets individuels qui y sont rassemblés. De plus, ils intègrent de plus en plus souvent des fonctionnalités de collaboration et de communication.

Depuis quelques années, on assiste à la multiplication d'interfaces web, avec implémentation on-premises ou cloud-based. Cela correspond très claiement à la montée en puissance du paradigme AAA (Anywhere, Anything, Anytime) qui vise à permettre de travailler à n'importe quel sujet, n'importe quand et depuis n'importe où. Cette tendance s'est encore accentuée avec la Covid-19 et le recours massif au télétravail.

Au rang des fonctionnalités essentielles on trouve (sans ordre et sans exhaustivité) :

  • La gestion des demandes (Demand Management)
  • La gestion et la documentation des décisions
  • La gestion du cycle (SDLCSystem Development Lifecycle) selon la gouvernance établie
  • La planification Programe / Projet / Portfolio
  • La gestion du temps
  • La planification, l'assignation et la gestion des ressources
  • La gestion des feuilles de prestation
  • La liaison entre les feuilles de prestations et les factures fournisseurs
  • La liaison entre les factures fournisseurs et les commandes de produits/services liés aux programmes / projets
  • a gestion budgétaire annuelle ainsi que la gestion des coûts planifiés (surtout pour les initiatives étalées sur plusieurs années)
  • La gestion des estimations
  • L'établissement de baselines
  • Le Gating et le formalisation des sign-offs qui permettent de passer d'une phase à une autre
  • La nature même des Business Processes impliqués dans la gestion des projets (ce qui est souvent un couplage à un système externe comme SharePoint par exemple).
  • La gestion des coûts récurrents (RUN)
  • La préparation des exercices budgétaires
  • Le reportage
  • La consolidation Value Chain, dont la roadmap générale
  • La gestion des utilisateurs au départ du système de gestion des identités ( IAMIdentity Access Management) et des rôles.
  • Des possibilités d'export (souvent XML, JSON ou Excel)

Remplacer le PPM (Project Portfolio Management)

Remplacer le PPM est une opération délicate, plus délicate que s'il s'agissait d'en implémenter un from scratch.

RFIRequest For Information/RFPRequest For Proposal

Selon l'organisation, et les Lois/règles auxquelles elle doit se conformer, il s'agira d'établir un RFIRequest For Information/RFPRequest For Proposal, voire à respecter la réglementation des Marchés Publics.

Une demande d'information (RFI) est un processus commercial courant dont le but essentiel est de recueillir des informations écrites sur l'état du marché, présent et futur, des pratiques qui y ont cours ainsi que de s'informer sur les produits/services disponibles. C'est une étape qui permet donc de recueillir les informations qui seront utiles pour les étapes à suivre, une sorte de préparation au processus de RFP. Il est de bon ton d'avoir déjà recueilli les exigences du produit/service qu'on vise à acquérir mais sans ambitionner l'exhaustivité. Personnellement, j'ai souvent participé à des RFI qui donnaient, in fine, de nouvelles idées et, partant, de nouvelles exigences. Généralement, le RFI est préparé de telle façon qu'il permet des comparaisons aisées et objectives.

Une phase de RFI/RFP est souvent précédée d'un pré-requis : le NDANon-disclosure Agreement.

Enfin, on n'oubliera pas non plus la phase d'appréciation de la solidité des entreprises auxquelles on s'adresse. Le Chef de projet en charge de l'implémentation nouvelle ne fera que cocher une croix (Done/Not done) dans la mesure où c'est le plus souvent le département "Legal" ou le département "Procurement" qui se charge de l'analyse souhaitée (en contact étroit avec la partie capable de juger de la solidité financière).

Tout le processus de RFI/RFP/Marché Public se conclut avec l'établissement d'un contrat piloté par le département "Legal". C'est une bonne idée d'inclure le Chef de projet dans les discussions afin que les clauses impliquant des éléments techniques puissent être examinées avec toute la connaissance requise.

Choisir un pilote

Quelle que soit la stratégie définie, Big Bang ou Remplacement progressif, voire une stratégie hybride, (voir plus bas), il est conseillé d'implémenter un nouveau système PPM en sélectionnant avec minutie 1 ou 2 pilotes.

Le choix du ou des pilotes se fera en respectant la trilogie suivante : low-risk, low-cost, low-distraction. Cela s'explique aisément : il est inutile de faire subir à l'ensemble de l'organisation des risques non-maîtrisés, il faut choisir un projet dont l'échec ne comporte pas un coût prohibitif (il faut accepter l'idée de ce que le projet pilote lui-même soit mis à mal), et il ne faut pas que ce projet détourne l'organisation de sa mission première.

Au-delà, il n'est pas futile de faire diriger le pilote par un chef de projet expérimenté, voire carrément sous la direction du PMO.

On pensera aussi à impliquer les Stakeholders qui sont concernés par les critères de succès, lesquels sont évoqués dès la phase du RFI/RFP/Marché Public.

Enfin, je conseille vivement de considérer le pilote comme un POC qui permet, si le succès n'est pas au rendez-vous, de se dégager sans indemnité de rupture. Bien évidemment, il s'agit-là d'un aspect qui sera géré par le département "Procurement" flanqué du département "Legal".

Big Bang ou Remplacement Progressif ?

Les deux stratégies sont possibles, Big Bang ou remplacement progressif : il y a des pour et des contre pour chacune. Le changement aura intérêt à être fait à la charnière des exercices (charnière annuelle établie par l'organisation), par exemple au démarrage d'une nouvelle année budgétaire. Il existe aussi une troisième voie : une implémentation hybride.

Méthode Pour Contre
Big Bang
  • Pas de période de chevauchement pendant laquelle il semble difficile de savoir dans quel système, nouveau ou ancien, sont maintenus les projets.
  • Pas de coût important d'export et import des données, en particulier l'évitement de l'adaptation des données de l'ancien système vers le nouveau : on passe du jour au lendemain de l'ancien système vers le nouveau [2] .
  • Reporting cohérent, pour tous les projets/programmes/portfolios.
  • Le décomissionnement de l'ancien système est réalisé peu de temps après l'entrée en vigueur du nouveau (souvent, l'année qui suit).
  • Difficulté de gérer les projets étalés sur plusieurs années.
  • À moins de se livrer à un exercice d'export/import, exercice souvent coûteux, on ne dispose pas d'historique des données, ce qui peut s'avérer difficile pour les projets étalés sur plus d'une année ou pour le "PMO – Project Management Office (See also PSO)"
Remplacement progressif
  • On s'affranchit partiellement de la nécessité d'effectuer la transition entre ancien et nouveau système aux charnières annuelles.
  • La période de formation au niveau système est étendue dans le temps et se fait sans à-pic. Les collègues qui sont déjà passés au nouveau système peuvent fournir des explications éclairées.
  • PMO a le temps de s'adapter.
  • Difficulté de générer des rapports consolidés et difficulté de tirer des situations Portfolio ou Value Chain car extraction nécessaire de plusieurs systèmes.
  • Coût non négligeable de portage des données (export/import).
Hybride
  • Les périodes charnières sont respectées automatiquement.
  • La période de formation au niveau système est étendue dans le temps et se fait sans à-pic. Les collègues qui sont déjà passés au nouveau système peuvent fournir des explications éclairées.
  • PMO a le temps de s'adapter.
  • L'IT vit avec un double système pendant un certain nombre d'années même après implémentation du nouveau système, ce qui peut engendrer des coûts de licences supplémentaires.
  • Les rapports consolidés sont plus difficiles car impliquant des données de systèmes différents

En fonction de votre organisation, je vous conseille de compléter la table ci-avant pour pouvoir en tenir compte lorsque le choix de la stratégie devra être effectué.

Personnellement, je suis en faveur d'une stratégie hybride : tous les projets démarrés avant la date de mise à disposition du nouveau système sont maintenus dans l'ancien système, même s'ils doivent l'être encore plusieurs années. Par contre, tous les projets démarrés après l'entrée en vigueur du nouveau système sont introduits dans le nouveau système. Lorsqu'il n'existe plus de projet/programme/portfolio à maintenir dans l'ancien système, celui-ci est décommissionné. Au demeurant, si les projets ne subissent pas trop de retard, cette stratégie permet de prévoir la période de décommissionnement assez facilement. Le choix de cette stratégie, puisqu'elle peut impliquer une période de chevauchement, peut avoir un coût non-négligeable sur le coût des licences. Dès lors, je conseille de prendre ce point en compte lors des tractations commerciales.

Lorsqu'il n'existe plus de projet/programme/portfolio à maintenir dans l'ancien système, celui-ci est décommissionné.

Juger de l'effort, juger de l'impact

Il est essentiel, pour juger de l'effort que le remplacement de PPM exigera, d'avoir une idée à la grosse louche du nombre de projets et du nombre de chefs de projets qui peuvent être impactés. Prenons la seule mesure du nombre de chefs de projet pour estimer, par exemple, l'effort de formation !

Vous serez bien inspiré de "compter" le nombre de projets impactés, de "compter" le nombre de chefs de projet impactés, d'"évaluer" le nombre de rapports ou outils spécifiques qui ont été développés au cours des années antérieures : le remplacement du PPM c'est aussi une période où tout un pan du Shadow IT se révèle ! Les gens ont créé des solutions qui leur sont spécifiques, souvent non documentées mais qui font le boulot ! Ces solutions ne marchent plus du jour au lendemain et les plaintes affluent, ici pour une procédure Excel qui ne fonctionne plus, là pour un import qui se comporte de manière inattendue, etc. Dans une implémentation précédente pour un gros intervenant dans le secteur financier, j'ai noté jusqu'à 11 outils ajoutés en moyenne par département concerné ce qui faisait quand même 57 outils au total. La prise en compte de ces outils dans votre effort de migration sera récompensé au centuple !

Et, last but not least, il s'agit de mener cet effort d'évaluation en bonne entente avec PMO !

Export / Import des données

Une partie importante du budget de migration d'un PPM à un autre concerne l'export des données, leur traitement, et ré-import dans le nouveau système. Disposer de passerelles d'export avec à la clef des formats standards est un atout non négligeable. L'export de données sous format XML est quasiment un question sine qua non. Bien entendu, cela n'aura que peu d'utilité si vous ne disposez pas d'un utilitaire d'import dans le nouveau système%!%

Cela devra faire partie de l'expression des besoins.

J'ai remarqué deux zones principales de friction en la matière : (1) la gestion/génération d'IDs uniques (en particulier sur des "objets" de modèles de données incompatibles), (2) l'utilisation de zones peu ou mal structurées (des dates incorrectement formatées, des zones email qui servent à d'autres fins, des adresses incohérentes, etc.)

Il vous appartiendra de choisir entre des traitements spécifiques ou s'en remettre à l'examen strict des formats (par exemple, si la zone ne contient pas un email, tant pis, elle est perdue). Que votre petite veilleuse soit bien allumée : tous ces traitements spécifiques coûtent des fortunes ! Petite combine … pour une migration personnelle, j'ai opté pour la mise en dépôt de toutes les zones non-comprises dans une zone fourre- tout que j'ai appelée junk et dont le contenu était formaté en XML avec le nom du champ que je n'étais pas parvenu à traduire d'ancien système à nouveau système : à ma charge, par la suite, d'effectuer le nettoyage nécessaire.

Rapports

Vous serez surpris de voir combien de rapports personnels existent dans le système que vous vous apprêtez à quitter. Il n'est pas rare d'avoir 3 rapports personnels par chef de projet, des rapports qui se ressemblent beaucoup mais sont toujours légèrement différents.

S'obliger à faire l'effort de porter ces rapports de l'ancien système vers le nouveau allonge souvent l'effort de migration d'1 à 2 mois ce qui, bien évidemment, a une influence sur le coût total de votre projet, au-delà d'être du travail qui doit être évalué au coup par coup, ce qui n'est évidemment pas possible (ou très difficile) au début du projet. La seule évocation du sujet mène à l'élaboration de clauses contractuelles difficiles pour toutes les parties.

J'ai trouvé utiles 2 méthodes de travail pour adresser le sujet :

  1. Organiser une session commune avec les chefs de projet et PMO pour limiter drastiquement le nombre de rapports à porter vers le nouveau système. C'est une façon d'attaquer le problème efficace mais qui peut aussi s'avérer difficile dans l'organisation des meetings.
  2. Faire en sorte que la formation (voir plus bas) dispensée aux chefs de projet leur montre clairement comment faire un nouveau rapport et leur assigner l'exercice d'en réaliser au moins un.

Business Intelligence

L'IT tourne aujourd'hui autour de la notion d'Intelligence Artificielle qui, comme chacun le sait, fait grand usage des données passées pour prédire l'avenir. L'application de la formule de Bayes est souveraine à cet endroit-là.

Le pont qu'il m'apparaît utile de dresser ici c'est de considérer le nouveau PPM comme étant producteur de données qui vont intéresser l'ensemble de l'organisation. C'est un véritable constat général. Si vous ne le prévoyez pas au début, soyez absolument sûrs de voir le sujet s'innviter très rapidement … hros projet.

Je vous renvoie alors vers la page de BIBusiness Intelligence mais aussi à la manière de choix de consommation des données : la méthode APIApplication Programming Interface est celle qui a le vent en poupe.

Critères de succès

Ce site est en construction. Il évolue tous les jours. Voici une de ces pages qui est au menu du travail à mener!

En néerlandais on dit Meten is weten , ce qui se traduit par Mesurer, c'est savoir.

Les critères objectifs se subdivisent en deux groupes :

  1. Les critères de succès de l'implémentation du nouveau système
  2. Les critères de succès opérationnels

Les critères d'implémentation auront été décrits sous forme de grille permettant un scoring simple et efficace. Ils se trouvent dûment exposés dans les documents qui constitiuent le RFI/RFP/Marché public.

Les critères opérationnels se mesurent auprès des groupes suivants :

  • Le Top Management qui devra se prononcer sur la qualité des informations extraites du système PPM. Il s'agit essentiellement de savoir si le nouveau système satisfait à la question "quels projets démarrer et dans quel ordre" : les informations sont-elles pertinentes, facilement compréhensibles et permettent-elles de meilleures décisions ? Je donne de plus amples explications concernant ce sujet sur la page "PMO – Project Management Office (See also PSO)".
  • Le PMO qui doit s'assurer que le nouveau système est bien utilisé par les chefs de projet, qu'il soit aussi simple, voir plus simple, mais également aussi complet, voire davantage, que l'ancien système et … qu'il lui permette de livrer des informations pertinentes au Top Management.
  • Les auditeurs qui doivent pouvoir s'assurer que le nouveau système remplit toutes les fonctions nécessaires afin de ne pas mettre en péril les activités de l'organisation (pensez aux exigences FDA données en exemple).
  • Les chefs de projet qui doivent pouvoir satisfaire aux exigences de la bonne gestion de projets mais également de leur PMO. Pour un chef de projet, c'est avant tout une question de facilité d'usage et de temps à consacrer régulièrement à l'outil.
  • Les collaborateurs qui sont souvent suscités afin de remplir leurs feuilles de prestations : c'est une affaire de temps à y consacrer … pas plus de 5 à 10 minutes par semaine.
  • Les parties prenantes dont les systèmes peuvent être liés au nouveau PPM comme, par exemple, la comptabilité, la gestion des contrats, les achats, …

Backoff ― Rollback

blahblah et ne pas oublier le PMO!!!

Training / Formation

Avec la mise à disposition d'un nouveau PPM, il est important de prévoir la phase d'apprentissage/training, non seulement dans votre planning mais également dans votre budget.

Train the Trainer

Au sein des organisations importantes, il existe souvent un support interne qui intervient à différentes occasions pour débloquer des situations compromises ou lorsqu'il s'agit de réaliser des rapports génériques servant, non à un projet particulier, mais plutôt à l'ensemble de l'organisation.

Le plus souvent, ce sont ces gens-là qui distillent aussi les formations à ceux qui ont besoin d'une mise à niveau.

Ma recommandation est d'inclure ces personnes dans une formation spéciale qu'on appelera Train-the-Trainer. C'est de l'argent bien investi, croyez-le bien.

Au-delà, ne négligez pas leur importance dans l'établissement des exigences : leur métier les met au contact par faisceau convergent de beaucoup des souhaits exprimés par les utilisateurs.

Décommissionnement

Un projet de remplacement de PPM ne se fait pas sans tenir compte du décommissionnement de l'ancien système, non seulement pour des questions philosophiques telles que la dette technique mais également parce que le décommissionnement est une bonne source d'économies, économies que le Management voudra voir effectives le plus rapidement possible.

Stockage / Archivage / Historique

En matière de stockage, il y a lieu de considérer l'espace nécessaire à la rétention des données, à leur redondance et à leur backup.

Ces dernières années, une véritable tendance s'est dégagée en faveur d'un stockage dans le Cloud. C'est évidemment une solution mais elle ne saurait aller de soi par simple volonté de suivre la tendance actuelle. Aller dans le Cloud, cela ne s'improvise pas ! C'est une décision à passer au crible de la confidentialité des données et à leur caractère privé.

Si ce n'est pour la seule utilité des données du passé, il s'agira peut-être de respecter des obligations légales ou imposées par des consortiums industriels, voire par des organes supérieurs auxquels il faut se conformer. Ainsi, en pharmacie par exemple, la FDA (Food & Drug Administration) considère que toute la partie software fait intégralement partie du processus industriel et exige que la documentation du projet soit archivée pendant 20 ans[3] , la documentation et tous les moyens de la lire, ce qui inclut évidemment le logiciel dans lequel cette documentation a été formalisée, le PPM utilisé donc, ainsi que tous ces pré-requis ou dépendances (base de données, système d'exploitation, …)

Etant donné ces implications, on comprend que l'archivage des données sera couvert par la gouvernance en place dans l'organisation et que le sujet général du PPM fait partie des prérogatives des auditeurs.

Les aspects GDPR (General Data Protection Regulation) ne peuvent pas non plus être ignorés, ce qui est d'ailleurs le cas de toute donnée, archivée ou non. Il est donc bienvenu d'inclure le DPO (Data Protection Officer) dans les aspects génériques du PPM.

La mise en place du PPM est un projet en soi

Besoins / Exigences

Vous avez besoin de rassembler les exigences de toutes les parties prenantes ce qui me fait dire qu'il est nécessaire d'en faire la liste. C'est une des premières actions à mener. Au travers de ce billet on en dresse une bonne figure : le PMO, le Top Management, les chefs de projet, l'Enterprise Architect, le bureau de support PMO, le PSO, les personnes qui devront utiliser le système, etc.

Ensuite il s'agit de collecter leurs besoins et de les classer en grandes catégories : les fonctionnalités, les contraintes techniques, les besoins non fonctionnels, etc.

Cette liste est à constituer le plus tôt possible car elle vous accompagnera dès le début du projet pour grandir avec lui, notamment au travers de la phase de RFI si vous décidez d'en passer par là.

Pour chaque besoin collecté, il est nécessaire de se poser la question de savoir comment il pourra être testé. Si un besoin – ou sa formulation, dirais-je – n'est pas complet, ou n'est pas stable, ou ne peut être testé, il faudra le challenger, voire le rejeter au final.

Une fois la liste établie, attachez-vous à lui adjoindre une grille d'évaluation. C'est indispensable pour les marchés publics; c'est une bonne idée, ou même une bonne pratique, pour un simple RFP.

N'oubliez pas de couvrir la question "méthodologie" de projets : si vous avez l'intention de couvrir les méthodes Waterfall, Prince2 par exemple, il faut que la solution le permette. Le même raisonnement s'applique si on couvre les méthodes Agiles.

Enfin, gardez un oeil sur la problématique "AAA". Pouvoir disposer d'un accès sécurisé au PPM depuis un accès distant devient vite une exigence actuelle.

Les plans de coûts et les exercices budgétaires

Ce site est en construction. Il évolue tous les jours. Voici une de ces pages qui est au menu du travail à mener!

Les exercices pluri-annuels

Ce site est en construction. Il évolue tous les jours. Voici une de ces pages qui est au menu du travail à mener!

Les estimations et les bases de référence (baselines)

Ce site est en construction. Il évolue tous les jours. Voici une de ces pages qui est au menu du travail à mener!

Infrastructure

Maintenant que je suis lancé dans les questions de stockage, autant parcourir rapidement la question de l'infrastructure.

Aucun doute : votre PPM ne passera pas la barre de l'acceptation générale s'il ne s'inscrit dans l'architecture entreprise !

Vous avez besoin de serveurs, vous avez besoin de transport, vous avez besoin de load balancing et de failover, vous avez besoin … de vous faire accompagner par un Enterprise Architect !

Notes de bas de page

[1] … Ensembles de projets liés logiquement les uns aux autres

[2] … Il s'agit rarement d'un évitement total

[3] … Source: 21CFR11