Je discutais avant hier avec un chef de projet informatique
d'une banque, lors d'un petit déjeuner technologique. Celui-ci, au détour d'un
java (ça veut dire "café" en argot américain), 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", lui demandais-je interrogatif ?
"Ben.... on en a pas trop, mais comme on est super fort on arrive à délivrer pour faire plaisir au métier"
dit-il d'un air convaincu et convainquant.
Bon alors là le diagnostique est clair....
En tant que chief Architect, expérimenté, voici en une demi heure, 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 tes clients. Ils pensent que leur projet du moment est le projet du siècle, et leur réflexe naturel et de t'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 te justifieront tout le temps que leur projet est super rentable et que tu as intérêts à le prendre en compte pour le bien de l'entreprise. Demande leur donc 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 te fera gagner du temps, et te sera utile plus tard, en phase " préparation" pour le calcul du ROI.
3°) Le client est objectivé sur la croissance, dans les quelques cas que tu m'as cités. Il sera félicité pour cela, et espérons que toi 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 ton devoir de les prendre en compte, et de te faire aider de ton RSSI. Sinon, cette fois, c'est toi qui feras des insomnies.
4°) Ton 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 solution innovante, plus prosaïquement, éviter que le coût marginal d'un dossier ne deviennent 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, et les métiers.
5°) Pour cela ton projet (La déclinaison informatique du projet du siècle) doit être vu à travers une méthode d'architecture, te 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 ton 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 ton projet, nommé "Roadmap".
6°) Ton projet doit mettre en œuvre des disciplines d’ingénieries (Il en existe 5) et des disciplines de support (il en existe 4). Ton rôle de chef de projet entre dans la catégorie des disciplines "Support" (Project Management)
7°) Dans ton entreprise, tu me dit que tu délivres à temps; C'est bien !! Vous êtes probablement corvéables à merci. Les besoins arrivent en ordre dispersés sans véritable alignement avec la stratégie, et la charges ne compte pas la qualité. Cela génère du stress, et de la souffrance humaine, pas toujours perceptible immédiatement, pour un manager, lui même en souffrance. Au paroxysme de la flexibilité on serait dans une situation ou les projets sont aussi nombreux que les besoins, et les mises en production aussi nombreuses que les projets.
uhmm comment dire ???
8°) Tu dois 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”
Couple ton 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°) Tu dois délivrer mais au juste prix "durable" pour ne pas risquer de mettre en péril et dans le temps, le SI. Tes demandeurs de projets du siècle ne comprennent pas toujours cela, mais ils n'accepteraient pas non plus que dans le temps, tu délivres de moins en moins vite, ou de plus en plus cher. Tu seras alors malgré toi réduit en esclavage du SI que tu auras négligemment engendré. En fait, dis toi, que tes 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. Ton planning devrait classer les activités par disciplines pour t'assurer de les couvrir quand c'est nécessaire, et d'avoir des plans d'itérations standards.
Plus facile à dire qu'à faire. Tu n'es qu'un maillon, certes important mais un maillon quand même. La solution est un électro choc managériale, une prise de conscience, une lumière, un espoir "que le changement c'est maintenant" :-). Tu devras alors être objectivé sur la qualité du SI, et plus sur la quantité de livraison dans un temps irréaliste. Des demain regardes tes objectifs.
10°) Ton 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 ta solution d'architecture..... Bravo et bienvenu dans le monde du processus unifié (UP). Cette méthode objet de gestion de projet est une méthode agile, déclinable à volonté pour tes propres besoins.
Je te raconterai une suite possible dans un prochain déjeuner techno .... :-)
... Mais au fait, as tu déjà entendu parler de UML ?
"Oui bien sur, qui ne connait pas de nos
jours ???"L'homme, avec un sourire grave et le regard circonstancié, n'avait pourtant pas l'air de plaisanter.
"Quelle méthode Projet, utilisez vous", lui demandais-je interrogatif ?
"Ben.... on en a pas trop, mais comme on est super fort on arrive à délivrer pour faire plaisir au métier"
dit-il d'un air convaincu et convainquant.
Bon alors là le diagnostique est clair....
En tant que chief Architect, expérimenté, voici en une demi heure, 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 tes clients. Ils pensent que leur projet du moment est le projet du siècle, et leur réflexe naturel et de t'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 te justifieront tout le temps que leur projet est super rentable et que tu as intérêts à le prendre en compte pour le bien de l'entreprise. Demande leur donc 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 te fera gagner du temps, et te sera utile plus tard, en phase " préparation" pour le calcul du ROI.
3°) Le client est objectivé sur la croissance, dans les quelques cas que tu m'as cités. Il sera félicité pour cela, et espérons que toi 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 ton devoir de les prendre en compte, et de te faire aider de ton RSSI. Sinon, cette fois, c'est toi qui feras des insomnies.
4°) Ton 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 solution innovante, plus prosaïquement, éviter que le coût marginal d'un dossier ne deviennent 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, et les métiers.
5°) Pour cela ton projet (La déclinaison informatique du projet du siècle) doit être vu à travers une méthode d'architecture, te 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 ton 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 ton projet, nommé "Roadmap".
6°) Ton projet doit mettre en œuvre des disciplines d’ingénieries (Il en existe 5) et des disciplines de support (il en existe 4). Ton rôle de chef de projet entre dans la catégorie des disciplines "Support" (Project Management)
7°) Dans ton entreprise, tu me dit que tu délivres à temps; C'est bien !! Vous êtes probablement corvéables à merci. Les besoins arrivent en ordre dispersés sans véritable alignement avec la stratégie, et la charges ne compte pas la qualité. Cela génère du stress, et de la souffrance humaine, pas toujours perceptible immédiatement, pour un manager, lui même en souffrance. Au paroxysme de la flexibilité on serait dans une situation ou les projets sont aussi nombreux que les besoins, et les mises en production aussi nombreuses que les projets.
uhmm comment dire ???
8°) Tu dois 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”
Couple ton 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°) Tu dois délivrer mais au juste prix "durable" pour ne pas risquer de mettre en péril et dans le temps, le SI. Tes demandeurs de projets du siècle ne comprennent pas toujours cela, mais ils n'accepteraient pas non plus que dans le temps, tu délivres de moins en moins vite, ou de plus en plus cher. Tu seras alors malgré toi réduit en esclavage du SI que tu auras négligemment engendré. En fait, dis toi, que tes 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. Ton planning devrait classer les activités par disciplines pour t'assurer de les couvrir quand c'est nécessaire, et d'avoir des plans d'itérations standards.
Plus facile à dire qu'à faire. Tu n'es qu'un maillon, certes important mais un maillon quand même. La solution est un électro choc managériale, une prise de conscience, une lumière, un espoir "que le changement c'est maintenant" :-). Tu devras alors être objectivé sur la qualité du SI, et plus sur la quantité de livraison dans un temps irréaliste. Des demain regardes tes objectifs.
10°) Ton 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 ta solution d'architecture..... Bravo et bienvenu dans le monde du processus unifié (UP). Cette méthode objet de gestion de projet est une méthode agile, déclinable à volonté pour tes propres besoins.
Je te raconterai une suite possible dans un prochain déjeuner techno .... :-)
... Mais au fait, as tu déjà entendu parler de UML ?
En sa qualité de responsable d'Architecture IT, Emmanuel PESENTI est amené régulièrement à animer des présentations sur la méthode projet UP qu'il met en place au service du référentiel d'architecture du SI, sur les objectifs à venir, et la façon d'y arriver.
Cette méthode est unique et s'appuie sur ses 10 dernières années d'expérience, de pilotage par les modèles et expliquant comment les artéfacts d’ingénierie des projets se capitalisent dans un référentiel d'architecture, structuré en UML.
