10 conseils d'un Chief Architect expérimenté pour faire avancer la réflexion d'un chef de projet sur son rôle et ses responsabilités.
Je discutais avec un chef de projet informatique d'une banque. Au détour d'un java ("café" en argot américain), il me dit: « Chez nous les projets informatiques sont quasiment tous soumis à la loi du coût minimal, et les projets commencés aujourd'hui, doivent être livrés pour hier ». L'homme, avec un sourire grave et le regard circonstancié, n'avait pourtant pas l'air de plaisanter.
« Quelle méthode Projet, utilisez vous ? »
« On en a pas trop, mais comme on est super forts, on arrive à délivrer pour faire plaisir au métier », dit-il d'un air convaincu et convainquant.
Là, le diagnostique est clair....
En tant que Chief Architect expérimenté, voici les quelques conseils que je lui donnais pour faire avancer sa réflexion sur son rôle et ses responsabilités.
1°) Les métiers demandeurs sont des clients. Ils pensent que leur projet du moment est le projet du siècle, et leur réflexe naturel est d'en dire le minimum pour aller vite, car le temps c'est de l'argent. Parfois même, croyant bien faire, ils lâcheront des mots techniques d'un jargon pas toujours maîtrisé dans un FranGlais que ni Molière ni Shakespeare ne comprennent, soit par habitude, soit par négligence, soit les deux.
2°) Les métiers demandeurs justifieront tout le temps que leur projet est super rentable et que l'on a intérêt à le prendre en compte pour le bien de l'entreprise. Demandons leur de s'engager sur une enveloppe de gains potentiels chiffrés, de gains d'opportunités chiffrés, et du coût à ne pas faire, toujours chiffré, cela fera gagner du temps, et sera utile plus tard, en phase "préparation" pour le calcul du ROI.
3°) Le client est objectivé sur la croissance, dans les cas cités. Il sera félicité pour cela, et espérons que l chef projet aussi. Mais en revanche, même s'il a une idée relativement précise sur les risques de conformité, juridique ou d'obligations réglementaires, qui l'empêche de dormir, il est assez mal préparé à la notion de risques liés au système d'information. Dans les coûts du projet, c'est du devoir du chef de projet les prendre en compte, et de se faire aider de le RSSI. Sinon, cette fois, c'est lui qui fera des insomnies !
4°) Le client est encore moins bien préparé aux problématiques d'architecture et d'urbanisation du SI, qui, projet après projet, peuvent croitre de façon complètement anarchique (ou pas) en fonction du talent de l'architecte en chef. L'entropie d'un SI est un sujet majeur dont l'objectif est de pouvoir assurer dans le temps la disponibilité, l’efficience, la mise en œuvre simple de solutions innovantes. Et plus prosaïquement, d'éviter que le coût marginal d'un dossier ne devienne de plus en plus élevé. En principe, l'anarchie dans le SI doit empêcher tout le monde de dormir, à commencer par le DSI et l'urbaniste, mais également les métiers.
5°) Pour cela, la déclinaison informatique du "projet du siècle" doit être vue à travers une méthode d'architecture, permettant de considérer que tout projet est une transformation potentielle du SI (les projets de maintenance de patrimoine sont à isoler). A ce titre, les impacts doivent être mesurés à long terme par l'équipe Architecture, pourvu que le projet s'inscrive sur un axe stratégique défini et un portefeuille de projets arbitrés. Les transformations grosses mailles devraient alors apparaître dans un ensemble plus vaste que le projet, nommé "Roadmap".
6°) Le projet doit mettre en œuvre des disciplines d’ingénieries (il en existe 5) et de support (il en existe 4). Le rôle de chef de projet entre dans la catégorie des disciplines "Support" (Project Management).
7°) Dans l'entreprise, le chef de projet affirme qu'il délivre à temps. C'est bien ! Il est probablement corvéables à merci. Les besoins arrivent en ordre dispersé, sans véritable alignement avec la stratégie, et la charge ne compte pas la qualité. Cela génère du stress et de la souffrance humaine, pas toujours perceptibles immédiatement pour un manager, lui même en souffrance. Au paroxysme de la flexibilité, nous serions dans une situation où les projets sont aussi nombreux que les besoins, et les mises en production aussi nombreuses que les projets (???).
8°) Le chef de projet doit mettre en place un système de pilotage AGILE. Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients.
Coupler l'approche agile avec du formalisme et de la rigueur :
- En amont sur les aspects métiers et fonctionnels ;
- -En aval sur les aspects applicatifs et techniques.
Cela passe par une refonte globale des habitudes de travail, la formation des équipes autour d'un langage d'entreprise fédérant et formel, comme UML, la mise en œuvre des projets à l'aide d'une méthode agile.
9°) Le chef de projet doit délivrer, mais au juste prix "durable" pour ne pas risquer de mettre le SI en péril, et dans le temps. Les demandeurs du "projet du siècle" ne comprennent pas toujours cela, mais ils n'accepteraient pas non plus que dans le temps, il délivre de moins en moins vite, ou de plus en plus cher. Ainsi il sera, malgré lui, réduit en esclavage du SI qu'il auras négligemment engendré. En fait, les clients s'adressent à un pro, pas à un épicier. Le devis doit prendre en compte tous les coûts permettant d'assurer la pérennité du SI. Le planning du chef de projet devrait classer les activités par discipline pour l'assurer de les couvrir quand c'est nécessaire, et d'avoir des plans d'itérations standards.
Plus facile à dire qu'à faire ! Le chef de projet n'est qu'un maillon, certes important mais un maillon quand même. La solution est un électro-choc managerial, une prise de conscience, une lumière, un espoir "que le changement c'est maintenant". Il devra alors être objectivé sur la qualité du SI, et non plus sur la quantité de livraison dans un temps irréaliste.
10°) Le projet doit être poussé par les exigences : elles seront formalisées par des cas d'utilisation (en UML) et l'ensemble de ces cas formera le squelette de la solution d'architecture.... Bravo et bienvenue dans le monde du processus unifié (UP). Cette méthode objet de gestion de projet est une méthode agile, déclinable à volonté pour les propres besoins du chef de projet.
« Mais au fait, as tu déjà entendu parler de UML ? », lui demandais-je.
« Oui, bien sur, qui ne connait pas de nos jours » (!)
