Les dérives dans la gestion de projet sont récurrentes. Pourtant, les bonnes pratiques existent, qu’il s’agisse de mieux maîtriser les délais, de ne pas se laisser déborder par les changements, de bien cerner les périmètres ou de créer plus de valeur. Les projets longs et bien planifiés sont censés avoir des avantages : anticipation, mobilisation à temps et programmée des bonnes ressources, absence d’imprévus… Pourtant, plus un projet est long, plus il coûte cher !
Un petit détour au musée de la pensée informatique
Il y a fort longtemps, de 1946 à 1995, nous avions des ministères du « Plan ». En 1966, le général De Gaulle avait lancé le « Plan calcul ». Cette vision à long terme d’un État protecteur, qui se targuait de tout prévoir, trouvait ainsi son prolongement dans le domaine des systèmes d’information. Elle a pris fin avec les trente glorieuses. C’était l’époque des premiers Star Wars, mais déjà la fin du punk, et nous voyions passer ces cabinets de conseils qui avaient des niveaux d’abstraction et des méthodes qui nous étaient étrangers. Nous réalisions alors des schémas directeurs qui prenaient plus de temps qu’un grand projet international de mise en œuvre d’un ERP monolithique, tel que nous le faisons encore aujourd’hui. Le musée de la pensée informatique est ainsi encombré de méthodes que l’on a jetées aux oubliettes. Certains d’entre nous se souviendront avec émotion de Merise, d’autres de Racines, pour les schémas directeurs. Aujourd’hui nous sommes passés à l’agile, au Scrum, à l’Extreme Programming, on réalise des sprints. Désormais, ce sont les rapides qui mangent les lents et non plus les gros qui écrasent les petits. Et si nous prenions un peu de recul ?
Moins c’est long, plus c’est bon ?
Les projets longs et bien planifiés sont censés avoir des avantages : anticipation, mobilisation à temps et programmée des bonnes ressources, absence d’imprévus… Pourtant, plus un projet est long, plus il coûte cher ! En effet, il mobilise des ressources plus longtemps, c’est donc arithmétiquement plus onéreux, mais surtout, plus longue est la durée, plus il y aura de changements. Et ce sont les changements qui coûtent le plus cher.
On observe plusieurs types de changement au cours d’un projet :
- Des changements de périmètre : on modifie des fonctionnalités, des géographies, on inclut ou on exclut une technologie…
- Des changements d’acteurs : ils se produisent aussi bien au niveau de la maîtrise d’œuvre que des donneurs d’ordre.
- Des changements de stratégie : on décide par exemple que le retail est trop cher, ou que l’Inde n’est plus une priorité, ou que la DSI va passer par un tiers…
- Des changements d’organisation : l’entreprise peut se faire racheter, gérer une opération de croissance externe, s’associer à un autre groupe, se consolider ou céder une ou plusieurs entités…
- Des changements de marché : la fréquentation des points de vente est en chute libre, une nouvelle réglementation vient chambouler les plans, une nouvelle technologie prometteuse apparaît, un nouvel entrant capte des parts de marché…
Les pires scénarios de changement concernent ceux qui interviennent au niveau des donneurs d’ordre, lorsqu’un projet sert des intérêts plus personnels que ceux de l’entreprise : la recherche du « next job » et l’employabilité font des ravages… Personne n’en parle vraiment, mais c’est bien là que se situe le risque absolu. Tous les grands échecs de projets sont liés à des changements d’acteurs et, le plus souvent, des changements dus à des considérations personnelles, en général pour des projets dont l’avant-vente s’est concrétisée sur les terrains de golf…
Avec le non-dit du « après moi le déluge », le sponsor suivant doit gérer une situation bancale dont il a hérité et dont il ne se sent pas responsable… uniquement sur la durée de son mandat et en attendant sa promotion. C’est pour cela que certains projets de l’État durent des années. Et chacun sait, si tant est qu’il ait un peu d’expérience, que, sur un projet en retard, si on double les équipes, alors on double le retard. Pour se prémunir de ce risque il faut faire des projets courts, inférieurs à l’année, si possible de six à neuf mois, afin de prendre en compte les périodes de ralentissement dues aux congés et aux budgets.
Un projet court a beaucoup d’avantages :
- Il y a moins de changements à gérer.
- Les équipes sont plus concentrées et attentives.
- Les priorités sont plus claires.
- Il est plus facile d’obtenir un engagement individuel des parties prenantes.
- Le mode « apnée » est envisageable.
En outre, un projet court permet de délivrer de la valeur plus vite.
C’était dans la cible ! Oui, mais laquelle ?
On parle toujours du périmètre d’un projet, mais c’est une double erreur. En réalité, il convient, au minimum, de définir quatre périmètres :
- Le périmètre fonctionnel, celui auquel on pense toujours, celui qui concerne les fonctions que remplira le système.
- Le périmètre géographique, qui précise les lieux physiques où le système sera utilisé, sans oublier les usages en situation de mobilité.
- Le périmètre organisationnel, qui définit les acteurs, les personnes, les services et les entités qui utiliseront le système. Il convient également de ne pas oublier d’intégrer les acteurs externes à l’entreprise, y compris les acteurs internes mais à statut externe, tels que les consultants et les intérimaires.
- Le périmètre technique, qui couvre deux aspects : d’une part, les composants techniques inclus dans le projet (les terminaux portables sont-ils inclus ou pas ? La mise à niveau des réseaux est-elle comprise ?), d’autre part, les terminaux à partir desquels le système sera utilisé.
La définition de ces quatre périmètres permet de lever un nombre incalculable d’ambiguïtés par les débats que cela suscite. Mais ce n’est pas suffisant. Il ne faut pas se contenter de définir ce qui est dans le périmètre, mais également ce qui en est exclu. Ainsi, définir le périmètre en positif et en négatif permet de considérablement réduire la zone d’incertitude. On parvient alors à des descriptions de projets qui sont concises, compréhensibles pour tout le monde, au plus haut niveau et très claires. Par exemple, pour un projet force de vente : le projet comprend la prise de commande des produits vendus, mais pas la prise de commande du matériel marketing ; il sera déployé en France, y compris à Monaco, mais pas dans les DOM-TOM ; il sera utilisé par les commerciaux et la direction de la division, mais pas par le département comptable. De même, le projet pourra être utilisé à partir de terminaux Androïd ou IOS, en complément des PC, mais les terminaux et abonnements ne sont pas intégrés dans le périmètre du projet, pas plus que la mise en place ou à niveau des réseaux Wi-Fi en points de vente.
| La définition des périmètres d’un projet | ||
| Périmètres | In | Out |
| Fonctionnel | ||
| Géographique | ||
| Organisationnel | ||
| Technique | ||
| Source : monCIO | ||
Oui, mais ça a changé !
La gestion des changements doit être rigoureuse et simple. Chaque changement doit être analysé selon les critères suivants :
- Le coût de faire, comparé au coût de ne pas faire.
- Le retour sur investissement.
- L’analyse d’impact (planning, budget, dépendances internes et externes au projet). Cette analyse doit inclure l’impact métier (par exemple : que est le pourcentage des ventes concerné par le changement ? Quel pourcentage en CA peut être impacté ?).
- Les ressources nécessaires.
- L’anticipation de ce qui se passe si le projet n’est pas lancé.
- Quels sont les plans B ?
Lorsque le changement est pris en compte, mais ne sera visible que quelques mois plus tard, comment gérer cette période et réaliser le retrofit (réaménagement) ? Une analyse, rapide mais complète, des demandes de changements permet de prendre des décisions rationnelles.
Piloter par la valeur… pas au rétroviseur !
Bien sûr, dans certains cas, il n’est pas réaliste ou possible de faire un projet court. Mais il faut quand même essayer, notamment en découpant le projet en différentes phases et en s’assurant que chacune peut délivrer de la valeur intrinsèquement.
Exemple :
- La phase de diagnostic dure neuf mois ? Il faut en profiter pour clarifier les rôles et responsabilités, voir si les objectifs sont correctement et clairement assignés, rechercher et spécifier des quick wins. Ainsi, même si le projet doit s’arrêter après le diagnostic, momentanément ou définitivement, les chefs de projets n’auront perdu ni leur temps ni le budget.
- La phase de conception s’avère longue ? Lors de la formalisation des processus cibles, il convient de rechercher comment les mettre malgré tout en œuvre sur la base des systèmes existants.
- La phase de réalisation promet de durer des mois ? Il faut alors privilégier une approche agile et délivrer des fonctionnalités qui seront recettées et mises en œuvre au fil de l’eau.
Ainsi, le chef de projet doit penser en microcycles et constamment être en situation de délivrer de la valeur, même si le projet est arrêté. Il faut penser et travailler en largeur d’abord et bannir l’approche en profondeur, qu’en bons cartésiens nous préférons souvent.
Gestion de projet : travailler la largeur plutôt que la profondeur
Source : Moncio.com
On calcule le plus souvent un ROI (et/ou une durée de payback) avant le démarrage du projet. Tous les bons manuels de gestion de projets expliquent qu’il faut finir les projets par une phase d’évaluation, voire de post-mortem.
Mais à quoi sert la phase d’évaluation post-projet ? À être en ligne avec la méthode, à faire travailler des consultants et des contrôleurs de gestion, à trouver des justifications a posteriori… Si elle est bien faite, cette phase d’évaluation va être au mieux une source de coûts. La finalité d’une entreprise, quoiqu’on en dise, est de délivrer de la valeur aux actionnaires. Toutes les actions de l’entreprise n’ont qu’un seul but : créer de la valeur.
Il en est de même pour les projets SI : ils doivent, directement ou indirectement, créer de la valeur. C’est la première marche de l’alignement entre l’IT et le business que tous les DSI recherchent. C’est donc la création de valeur qui doit dicter nos choix. Par conséquent, il faut piloter par les enjeux, autrement dit savoir ne pas faire forcément dans l’ordre, et réaliser d’abord ce qui délivrera le plus de valeur.
Cette approche présente plusieurs avantages :
- Le projet est crédibilisé par l’exemple.
- Les équipes sont motivées grâce à des résultats visibles et mesurables.
- Un cycle d’autofinancement est initié, tout en préparant une réserve pour gérer l’imprévisible.
Le logiciel s’utilise mais ne s’use pas
La valeur vient de l’usage : le plus beau projet du monde, celui qui peut créer le plus de valeur, n’apportera rien s’il n’est pas utilisé. Et nous savons bien que nos étagères virtuelles sont bourrées de logiciels achetés et non utilisés, de projets utilisés très partiellement et de solutions à usage très restreint, dont le maintien en condition de survie coûte fort cher.
Chaque livraison doit donc s’accompagner d’une mesure de l’usage. Il faut le comptabiliser et responsabiliser les utilisateurs. Le taux d’usage d’une nouvelle solution doit devenir l’indicateur de réussite absolue. Pour cela, on peut comptabiliser des éléments de base : nombre de minutes de connexion, nombre de transactions, nombre d’objets dans les bases de données, mais aussi privilégier des indicateurs plus business : volume financier pris en compte (en valeur absolue et relative), nombre de commandes, nombre de visites… Concrètement, privilégier l’usage signifie, d’une part, livrer en premier ce qui sera utilisé le plus et le plus tôt et, d’autre part, prioriser les demandes des utilisateurs ayant prouvé qu’ils utilisaient effectivement les solutions déjà proposées.
Des modèles et des méthodes
La plupart des projets sont désormais réalisés via la mise en œuvre de solutions « sur étagère » que l’on paramètre, en fonction de l’usage voulu. Partant du principe que l’on met en œuvre un système complet avec sa cinématique, ses fonctions et ses structures de données, on omet désormais totalement de faire des modèles de données (et de traitements), tels que les méthodes Merise ou SADT nous l’enseignaient.
Lors de mes interventions pour mener des audits de projets, très souvent, il faut travailler la modélisation des données (en pratique un MCD Merise) avec un utilisateur, pour comprendre le modèle de données dont il a besoin. Quatre fois sur cinq, le verdict est implacable : l’utilisateur a fondamentalement besoin d’un modèle de données qui n’est pas mis en œuvre dans le système. Dans ce cas, on a souvent pallié cette lacune par des cases à cocher, des reports ou des traitements compliqués, mais sans analyse.
Sans remettre pour autant en cause les ERP et autres progiciels dont on peut être de fervents partisans, on ne devrait pas s’empêcher d’élaborer, a minima, un modèle des données, dès lors que la solution prévue dans le produit ne semble pas convenir immédiatement. On clarifierait ainsi le besoin de l’utilisateur, tout en évitant des usines à gaz dans les systèmes. Si l’abandon des « systèmes à façon » pour les progiciels et l’assemblage de composants est plutôt une bonne approche, l’abandon des méthodes de conception et de certains de leurs outils est, en revanche, très contestable.
De l’intérêt de maîtriser la méthode
Source : Moncio.com
Cet article a été rédigé par Pierre-Albert Carlier, consultant en systèmes d’information, DSI de transition et fondateur de MonCIO (moncio.com),
Seulement les trois-quarts, mais vite !
Au gré des très nombreux projets que j’ai eu à diriger ou à mettre en œuvre, une conviction s’est forgée : il vaut mieux couvrir 75 % des fonctionnalités rapidement (en six à neuf mois) plutôt que viser les 100 % sur une durée plus longue (voir infinie…).
Appliquer ce principe présente plusieurs avantages :
- On bénéficie des avantages d’un projet court : moins de changements, une maîtrise du budget, une meilleure concentration des équipes…
- La solution est livrée plus vite et, de fait, crée de la valeur plus rapidement : le projet est crédible et les phases ultérieures peuvent commencer à s’autofinancer.
- Les besoins de la phase 2 (car il y aura une phase 2…) sont spécifiés en fonction de l’usage de la phase 1. Ainsi, un besoin qui semblait impératif au début aura disparu au profit d’un besoin finalement bien plus utile, né de l’usage de la phase 1.
- On peut servir plus de clients : dès la phase 1 terminée, débute la réalisation d’une série de petites améliorations (ou de projets très courts) visant d’autres utilisateurs. Il n’y a ainsi plus d’utilisateurs « laissés pour compte », ni de foyers non maîtrisés de mécontentement.
- Une phase 2 n’est envisagée qu’à condition que la phase 1 soit utilisée et que les utilisateurs soient en mesure de le démontrer.
Certains grands groupes qui favorisent ainsi l’usage n’hésitent pas à autoriser des dépassements de budget, à la condition que le produit livré sera finalement bien utilisé. Ils considèrent ainsi que la valeur créée par l’usage est plus importante que le décalage du payback. •
Le principe d’enchaînement des projets
Source : Moncio.com
Les principes à retenir
- Plus un projet est long, plus il coûte cher.
- Plus un projet est long, plus il est sujet à des changements et ce sont les changements de personnes, de sponsors en particulier, qui sont les pires.
- Le périmètre doit être définit selon quatre axes (fonctionnel, géographique, organisationnel, technique) et en positif comme en négatif.
- Chaque demande de changement doit être évaluée de façon complète.
- La valeur vient de l’usage. Il faut piloter les projets par les enjeux et les priorités en fonction de l’usage et donc de la création de valeur attendue… et la mesurer.
- Il faut privilégier les demandes des utilisateurs en mesure de démontrer qu’ils utilisent déjà les outils mis à leur disposition et qu’ils les valorisent.
- Spécifier un besoin à l’aide d’un modèle de donnée reste une bonne idée, même quand on utilise un progiciel.
- Il est préférable de livrer vite 75 % des fonctionnalités et de considérer les demandes additionnelles dans un deuxième temps, une fois que le système a été largement utilisé.