Une Euro-vision pour Rapid Application Development Abstract Vu des pays Anglo-saxons, il n y a aucun doute que les méthodologies de Rapid Application Development ont réalisé les objectifs qu elles s étaient assignées: que ce soit DSDM ou bien RUP, leur succès, tant sur le plan de la croissance que des réalisations, est indiscutable. Il est en revanche frappant de constater que l application de Rapid Application Development rencontre rarement un succès dans les projets d envergure internationale. A l heure de l intégration Européenne, il est impératif de se pencher sur les causes des ces échecs, et apporter les solutions appropriées. Cette présentation est le fruit de diverses expériences de RAD appliquée a des projets Européens. Après un court rappel sur les différences inhérentes que nos cultures ont générées pour le management de projets, nous allons les relier aux spécificités du management de projets RAD, pour essayer d expliquer les limitations de principes édictés dans un contexte Anglo-saxon et appliqués dans un contexte Européen. Nous proposerons alors, dans une seconde partie, des adaptations de ces principes, pour un succès transculturel. A l issue de cette session, chacun de nous aura compris que comment interpréter ces méthodologies a un niveau international, pour conserver tous leurs bénéfices, en surmontant les obstacles que sont les différences culturelles et organisationnelles, différents langages et la distance géographique. Mots Clefs DSDM, RUP, RAD, Union Européenne, Management Transculturel Auteur Mr Fabrice Gouttebroze Senior Consultant Gresham Bell Ltd The Counting House 53 Tooley Street LONDON SE1 2QN Royaume Uni Tel. (44) (0) 207 645 3800 Ligne directe : (44) (0) 207 645 3831 Portable : (44) (0) 7714268081
Une Euro-vision pour Rapid Application Development Introduction La plupart des project managers ont acquis une expérience professionnelle basée sur des concepts, des approches et des méthodes qui sont propres à leur pays, qu il soit leur pays d adoption ou pays natal. Dans le cadre de l intégration européenne, nombre d entre nous avons déjà ou allons bientôt être confrontés au problème du management de projets et d équipes à travers plusieurs pays. Pour tirer tous les bénéfices de ces opportunités, il est important de comprendre que le management de projet et les schémas organisationnels sont fortement influencés par notre culture et nos processus de pensées. Les méthodes RAD Rapid Application Development, sont plus particulièrement concernées. Venues des pays anglo-saxons où elles ont rencontré un succès remarquable, elles ont en revanche des difficultés à s imposer dans les pays d Europe continentale, et conséquemment pour les projets d envergure pan-européenne. Cette présentation va se concentrer sur les 2 méthodes formelles de RAD, que sont RUP (Rational Unified Process), et DSDM (Dynamic Systems Development Method). L objectif de cette présentation est, dans une première partie, d analyser la nature et le pourquoi de ces difficultés, puis, dans une deuxième partie, de proposer des solutions qui sont le fruit de diverses expériences de projets RAD dans un cadre européen. Différentes cultures, différentes approches Qu est ce que le management de projet? On trouve, dans la littérature, différentes définitions pour le management de projet. D après le Collins, il s agit du «processus de planification, organisation, et gestion des taches et des ressources pour achever un objectif défini, dans des contraintes de temps, ressources et coût.» Il semble donc que le management de projet soit une science relativement simple. Quelques semaines de training devraient être suffisantes pour acquérir toutes les connaissances nécessaires a la gestion de projet. Cela fera t-il de nous un bon project manager? Peut être cela fera t-il de nous un bon administrateur, mais cela paraît clairement insuffisant pour faire de nous un bon project manager. Par ailleurs, dans des projets d une certaine envergure, ces tâches sont prises en charge par un project office, ce qui permet au project manager de se concentrer sur le management du projet a proprement parler. On s accorde également a définir le management de
projet comme une tache qui est séparée du travail technique. Mais alors, si le project manager ne prend en charge ni le travail d administration, ni le travail technique de l équipe, qu est ce que le management de projets? Mon point de vue sur la question est que le management de projets consiste essentiellement a faire travailler ensemble une communauté dysfonctionnelle de personnes, dans le but de livrer suivant un plan, un ou plusieurs produits ayant une justification commerciale. Une communauté incluant l équipe de développement, les clients, le marketing, toute personne ayant un intérêt et une contribution à faire pour le projet. Des équipes dysfonctionnelles différentes raisons La plupart des équipes sont à l origine dysfonctionnelles. On va trouver une infinité de raisons justifiant ces dysfonctionnements, telles que les conflits de personnalités, des plans de carrières divergeant, des opinions syndicales, un style de management ou des différences culturelles. Ce sont autant de challenges auquel le project manager va devoir faire face. Ce qui différencie le project manager du project administrator, c est la faculté d identifier ces handicaps, et de les transformer en atouts. Le but de cette présentation consiste à se pencher sur un handicap qui va devenir prépondérant pour les project managers de ma génération et de la vôtre : Comment implémenter des projets d envergure pan-européenne selon des méthodes de project management qui ont été inventées dans les pays anglo-saxons. Plus spécifiquement, comment gérer ces projets dans le cadre de Rapid Application Development. Différences culturelles Hofstede nous offre probablement l une des meilleures définitions de la culture : «La programmation collective d un peuple dans un environnement (qui) s est cristallisée dans les institutions que ce peuple a mises en place : les structures familiales, les formes de gouvernements, l organisation du travail.» [1] La démocratie est-elle un système approprie? J imagine que la plupart d entre nous approuveraient, mais qu en serait-il si je devais parler dans d autres régions du monde? Notre définition de ce qui est un système de gouvernement approprié est donc largement influencé par notre culture. De même, notre vision des organisations, et de qui est important dans ces organisations, en terme de communication et de processus de décision, est largement dépendant de notre culture.
Comment fonctionnent nos organisations? Selon Napoléon, les Anglais étaient une nation de boutiquiers. Ce qu il voulait être péjoratif, peut en fait être interprété de façon beaucoup plus positive. Il y a en effet, chez les Anglo-Saxons, un sentiment profond que le marché ne doit être le sujet d aucune régulation. Le libre échange, le laisser faire favorise les initiatives individuelles, qui, par leur développement deviennent sources de richesses. La bureaucratie est haïe, et vue comme un obstacle au progrès. Cet état d esprit est reflété dans les organisations anglo-saxonnes, ou l on retrouve les caractéristiques suivantes : Les projets démarrent d un simple mandat, décrivant la vision pour le projet, en quelques lignes Une réelle organisation ne se met en place que pour le management de projets ou programmes Une collaboration active des acteurs commerciaux est vue comme indispensable a la réussite d un projet L autorité de position est affaiblie; des consultants sans autorité de position sont souvent des personnes clefs La hiérarchie et le management traditionnel ne constituent pas de barrières a l initiative Les organisations ne sont pas fixées dans le temps Le project managers sont utilisés à tous niveaux de l organisation Peu de symboles hiérarchiques : bureaux ouverts, ou se côtoient les employés seniors et juniors Par opposition, sur le continent européen, la structure précède l implémentation. En France, la tradition Colbertiste force la normalisation, l initiative contrôlée par une autorité centrale. Il y a un puissant corps de fonctionnaires qui supportent l évolution et l implémentation de l initiative privée. L environnement de gestion est déjà là, dans la société et dans l entreprise, pour prendre en charge et développer les projets. Les caractéristiques suivantes se retrouvent dans ces organisations : L autorité de position et la hiérarchie est importante : peu d initiatives peuvent être prises sans l aval du supérieur hiérarchique Les structures de l organisation sont rigides, et sont également liées à des règles profondément culturelles (cadres, personnel de maîtrise etc.) Les objectifs sont à long terme, et la pensée stratégique est privilégiée par rapport au pragmatisme au quotidien
L organisation va agir comme une machinerie découpant les projets en unité de travail. Ces unités vont être distribuées à des chefs d équipes, ou chef de projets. Le concept Anglo-Saxon de project manager ne trouve pas de vrai équivalent dans les organisations Françaises ou Allemandes. Le management de projet encadre la structure mais n en fait pas partie Les processus sont définis est respectés à travers l ensemble de l organisation. Tout employé évolue dans un environnement parfaitement défini, qui facilite son travail quotidien Les organisations anglo-saxonnes font confiance en un environnement dérégulé pour stimuler les initiatives, quitte à fournir un effort d organisation lorsque le projet prend forme - d où la nécessité de méthodes de gestion telles que Prince 2 ou le PMBok. Les organisations continentales sont plus stratégiques, et sont supportées par un environnement régulé orienté sur le développement des initiatives. Des différences dans nos processus de pensée Le métier que nous exerçons est l aboutissement d une route tortueuse, dont les guides ont été la vocation, le statut et la nécessité de gagner notre vie. Le statut que confèrent certaines professions est une notion qui a guidé notre choix très tôt dans notre vie. Il en est de même pour la vocation, mais les vocations enfantines ont été perverties par l influence de notre environnement, qu il s agisse de notre famille, de nos professeurs, ou de nos amis. Des l age de 7 ans, nous avons déjà le sens du statut liée à une profession. Le salaire ou le revenu que nous pouvons espérer gagner par sa profession est un paramètre qui influe notre choix beaucoup plus tard dans notre parcours. Il faut en général pratiquer pour savoir ce que l on va réellement gagner. Il y a donc une longue gestation de vocation mêlée de désir de statut, et cette longue gestation modélise l approche que l on va adopter pour résoudre les problèmes auxquels on est confronté quotidiennement dans son activité professionnelle. En réalité, nous ne privilégions pas l approche la plus efficace par rapport à un problème, mais l approche que l on nous a appris être la plus efficace, et que nous ne remettons jamais en question puisqu elle reçoit l aval de nos collègues et supérieurs. Il en résulte que les décideurs français vont toujours avoir une tendance naturelle a privilégier une approche scientifique des problèmes, hérité du modèle du bac scientifique, des prépas et des grandes écoles. Les décideurs des milieux anglo-saxons viennent d horizons plus divers, mais les métiers prestigieux outre-manche ou outre-atlantique sont liés au droit, la finance et l économie. Le management préférera par conséquent une solution qui sert uniquement les intérêts économiques et commerciaux, au risque de délivrer une mauvaise solution technique.
Implications pour les méthodes RAD Ces différences fondamentales dans l approche des problèmes, et les modèles d organisation crée des difficultés inattendues pour les méthodes RAD. D un concept britannique et nord américain, les méthodes RAD ont pour but essentiel de faciliter le processus de pensée anglo-saxon, faisant que certains de leur principes fondamentaux vont à l encontre des principes sous tendant les organisation européennes continentales: "L'implication active des utilisateurs est indispensable" [2]: c est un problème que l on rencontre dans tous les projets de systèmes d informations à travers le monde. Faire travailler les utilisateurs et les développeurs ensemble est la clef de la réussite d un projet. Les méthodes RAD ont érigé cet élément clef en principe fondamental. Il y de multiples raisons pour lesquelles il est difficile de faire travailler des équipes informatiques avec des utilisateurs, et l une d elles et la différence de culture et d éducation entre les 2 communautés. Il est clair que le fossé entre ces 2 communautés va être plus important sur le continent que dans les pays anglo-saxons, par l importance qui est portée au niveau d études et la nature même de votre diplôme. Ce fossé est une barrière importante à la constitution d une équipe commune entre les utilisateurs et les informaticiens. "L'approche DSDM est centrée sur l'utilisateur." [2]: une notion particulièrement importante et difficile a réaliser dans des pays tels que la France ou l Allemagne. Comment réconcilier des processus de pensée radicalement différents? L ingénieur informaticien Français va t-il accepter facilement de reconnaître la supériorité de l avis de l utilisateur sur le sien. Cela va bien entendu dépendre du contexte, mais le risque est que l'ingénieur informaticien va toujours vouloir garder une certaine indépendance part rapport à l utilisateur, et développer une solution qui le satisfait pleinement du point de technique. "Pouvoir de décision des équipes DSDM" [2]: l Empowerement" des équipes RAD est essentielle pour accélérer la vitesse décisionnelle. L'équipe doit être constituée d individus en contact avec la réalité quotidienne du business, à qui on a délégué un pouvoir de décision sans restriction concernant le projet. C est une notion intéressante, mais est-elle pratiquement applicable dans les organisation continentales? Qu ils fassent partie de la communauté des utilisateurs ou des développeurs, les membres de l'équipe, par leur culture, n oseront probablement pas prendre d importantes initiatives, sans en référer au supérieur hiérarchique approprié. Certaines décisions vont mettre en cause une stratégie établie au plus haut niveau,
et va donc demander un processus d autorisation dont la longueur va être complètement incompatible avec le cycle RAD. Les tests ne sont pas traités comme des activités indépendantes. [2]: or, lorsque, comme nous l avons vu, la structure de l organisation a défini une séparation claire entre les équipe de test et les équipes de développement, il y a à nouveau obstacle a la philosophie RAD. Il n est pas rare, en effet, que les organisations continentales aient divisé l équipe en développement, d un cote, et en test fonctionnel, test d acceptance et test de régression de l autre. Une approche basée sur la collaboration et la coopération [2]: la prééminence du line management par rapport au project management, dans la plupart des organisations continentales, et une barrière au management de projet a travers les pays anglo-saxons et le continent, du manière générale. Elle devient un problème quotidien qui peut être fatal dans les projets RAD. Le project manager sera perpétuellement contrarié par les supérieurs hiérarchiques des membres de son équipe, qui auront tendance a ne pas considérer l autorité du project manager comme légitime. Les conséquences seront des délais dans l exécution de tâches ou de coopération a des ateliers qui sont essentielles au bon déroulement du projet. On m a demande d aller à cette réunion ou, je dois d abord régler ce problème sont des phrases qui vont devenir la torture lente du project manager RAD. Les personnes concernées par le projet incluent non seulement le métier et l équipe de développement directement concernés, mais aussi d autres équipes telles que celles de support et de gestion des ressources. [2]: les organisations continentales auront tendance a avoir partitionné les contributeurs au projet en diverses équipes Ces diverses équipes travaillerons en général selon un plan de communication non transversal, c est à dire que toute flot de communication sera centralise à un niveau supérieur de hiérarchie. Il va donc s agir d introduire un changement radical dans le plan de communication. RUP reprend l ensemble des principes que nous avons mentionnés ci-dessus, même si cette méthode ne va pas nous les imposer aussi explicitement. Tout project manager ayant dirigé un projet RUP s accordera néanmoins à dire que ce sont des principes implicites qui seront essentiels pour un progrès satisfaisant, essentiels pour la réussite ou la l échec de l approche. DSDM et RUP divergent dans les principes plus implicites liées aux deux méthodes : DSDM se concentre sur un allégement de la bureaucratie. La documentation est réduite à un minimum, dont le seul but est de fournir un historique permettant une gestion correcte de la
configuration. Cette philosophie crée souvent de grandes résistances parmi la communauté ayant un intérêt dans le projet. Il est naturel d associer cette approche avec un manque de rigueur. Cette résistance, que l on rencontre, dans toute organisation a travers le monde, va être plus forte encore en Europe continentale, ou l on va préférer une spécification fonctionnelle détaillée synonyme de rigueur. DSDM est une approche qui favorise l aspect fonctionnel du produit, au détriment de la complexité technique. DSDM se concentre sur les parties du développement qu un esprit français, de par les processus de pensée que nous avons couvert plus haut, va considérer comme peu important, ou de peu d'intérêt. Il s ensuit une difficulté d établir la crédibilité de la méthode. Elle aura tendance a être cataloguée comme une méthode qui n adresse pas les vrais problèmes, les vrais risques. Pour DSDM, la prioritisation des requirements va être commandée par la nécessité du business. La plus grande priorité va donc être accordée à ce qui est critique pour la continuité du business. Cela donne au business et a l utilisateur une responsabilité voulue, mais qui est en rupture avec l échelle des valeurs continentales. Alors que DSDM déclare clairement que la méthode ne s'adresse qu à un sous-ensemble bien précis de projets -un filtre en 17 points pour guider la décision d adoption- RUP est une méthode dont l ambition est de couvrir tout type de développements. Cette ambition a conduit ses auteurs à produire une méthode de plus haute complexité que DSDM. On remarque que sont imposés la méthode d analyse et de modélisation (UML), le design (Design oriente objet), le développement (objet, le plus souvent Java, J2EE ou C++). Les outils, également, sont ceux de Rational Inc. Il y a, d autre part, un composant architecture important attaché à la méthode. L architecte est un rôle obligatoire, et est prééminent dans les premières itérations du projet. L architecte a pour mission de se concentrer sur les fondations technologiques du projet, l infrastructure, les interfaces. On voit donc qu il y a une volonté claire de prendre en compte la complexité technologique du projet. RUP n a d autre part pas la prétention de réduire la documentation liée au développement du projet. Elle propose de la produire différemment, plus efficacement. La plupart de la documentation sera issue du modèle d analyse et du design. Voila donc une méthode qui semble vouloir contraindre RAD dans une structure qui correspond mieux au modèle Cartésien Français. Mais cela n est plus une surprise, dès lors que l on se souvient que,
bien que Rational soit une compagnie Nord Américaine, la méthode été largement créée et développée par Philippe Kruchten, Français expatrié à Vancouver. L ambition de vouloir couvrir des systèmes de différentes natures a conduit RUP a ne point contraindre les équipes dans la prioritisation des développements. Alors que DSDM, comme nous l avons vu, privilégie la priorité du business, RUP va privilégier les développements pour lesquels on estime que le risque technique est le plus grand. L argument consiste à réduire au maximum les risques techniques lie au projet, en attaquant les vrais problèmes de front. Il n y a néanmoins aucune contrainte dans l évaluation et l estimation de ces risques. Nous avons vu plus haut, que l estimation des risques n est pas une science exacte, mais plutôt le résultat de notre propre culture. Il en résulte une lecture différente de la méthode. Dans des projets d envergure internationale, la priorisation des spécifications est un domaine ou la différence de cultures va joue un rôle prépondérant, et introduire un risque inattendu: l incapacité de planifier le projet correctement. Des solutions Jouer sur les valeurs L introduction des méthodes RAD Avant de pouvoir commencer à développer selon un méthode RAD, il est évidemment impératif d introduire l approche dans l organisation, et, dans notre cas, dans toutes les sous organisations qui pourraient différer par leur cultures. Dans un souci de clarté, prenons l exemple d un projet dont le développement va être distribué entre des équipes françaises et britanniques, pour la satisfaction d utilisateurs des deux pays. Le projet a été initié à Londres, et il a été reconnu que le projet satisfait les critères fondamentaux de DSDM. Comment obtenir l adhérence des Français aux principes de DSDM? Au premier abord, il semblerait que l interlocuteur privilégié soit le chef de projet désigné au sein de l'équipe française. En réalité, la décision de suivre l approche DSDM va être vraiment décidée à un niveau stratégique. Il est peu probable qu un chef de projet sera en mesure de promouvoir l approche auprès de sa hiérarchie. Il s exposera au risque de ne pas paraître professionnel, par le manque de connaissances et de préparation qui va supporter son initiative. La meilleure approche consistera certainement a cibler un niveau de hiérarchie supérieur, qui pourra prendre la décision au nom de son organisation. La responsabilité de la promotion devra être donnée a un niveau équivalent dans l organisation Britannique. Le Chief Information Officer, assisté de un ou plusieurs experts de DSDM, devront préparer le meeting
d introduction avec la personne qui prendra la décision, probablement le directeur du développement de l organisme français. A ce point du développement, il est important de comprendre que l on se retrouve dans une classique situation de vente. L organisation britannique va devoir vendre un produit une approche dont l acheteur français ne connaît pas encore vraiment la nature. Des trois catégories classiques d acheteurs (économique, utilisateur ou technique), il est probable que le directeur de développement français va se trouver essentiellement dans la première. C est lui qui va formuler la décision, et c est lui qui va poser les questions du retour sur l investissement d une telle initiative. La différence fondamentale d avec le modèle anglo-saxon va être que le directeur du développement va également se positionner comme acheteur technique. Il va se faire fort de montrer qu il comprend également le problème d un point de vue technique. Les questions posées vont être alors d une nature totalement différentes: comment va t-on inscrire les processus dans les équipes, comment gère t-on les configurations, comment contrôler le projet, comment va t-on faire procéder pour l autorisation de spécification etc. En résumé, la présentation faite au directeur du développement français devra être préparée en détail, de sorte qu il puisse trouver les réponses a tous les niveaux (technique, management) dont il a besoin pour prendre sa décision Un vente réussie jouera sur les valeurs que le directeur du développement jugera importantes: Les méthodes RAD souffrent d une réputation de non structure, d où une formalisation très structurée de l approche a travers DSDM ou RUP RAD a ses limites: nous avons jugé que le projet est un bon candidat pour RAD pour les raisons suivantes ( ), et nous avons décidé de garder une approche plus classique pour les composants de haute complexité technique du projet DSDM et RUP sont des méthodes rigoureuses, éprouvées, et dont l inconvénient essentiel est qu elles demandent en réalité encore plus de structure de la part des chefs de projets DSDM est le fruit d un consortium majoritairement Britannique. Une plus grande adhérence de personnalités européennes vous donnera la possibilité d influer sur son évolution, pour lui donner un angle plus technique Il ne fait pas de doute que les méthodes RAD ne sont pas très populaires en France, mais c est une approche en pleine croissance, et les organisations adhérant à ces principes aujourd hui auront un avantage décisif sur les autres dans les années qui viennent. Durant le développement
Une fois que la décision a été prise d emprunter la voie RAD, les procédés employés pour la vente de l approche au niveau stratégique vont être les mêmes au niveau individuel. La connaissance et la compréhension des valeurs qui motivent les individus sont les clefs de leur adhérence à la méthode, et ces valeurs, nous l avons vu, diffèrent lorsque nous atteignons les niveaux supérieurs de la pyramide des besoins de Maslow. L introduction de contrôles supplémentaires durant le développement (points de contrôle, autorité de changement, validation formelle des utilisateurs) rassurera la communauté que le projet est sous contrôle. Des audits réguliers de qualité peuvent aussi être des signaux rassurants que le chemin emprunte est reconnu par les autorités centrales. D autres valeurs sont partagées par la majorité des individus, indépendamment de leur culture: RAD peut être utilisé comme processus pilote dans l entreprise pour valoriser les talents et permettre aux individus engagés dans l aventure d en retirer les bénéfices dans l organisation. La sélection des utilisateurs Une bonne coopération entre les utilisateurs et les développeurs repose sur un respect mutuel. Il est donc impératif de sélectionner des utilisateurs qui vont pouvoir imposer ce respect de la part des ingénieurs. Dans des secteurs tels que ceux de l ingénierie civile ou des hautes technologies, cela ne va présenter aucun problème. Dans d autres secteurs, s adressant à une communauté moins éduquée, il est important de sélectionner des représentants d utilisateurs qui se sentiront à l aise pour évoluer dans un milieu qui ne leur est pas familier. On portera donc une attention particulière aux caractères et qualités individuelles des personnes concernées. Les critères plus rationnels lies a leurs attributions quotidiennes et leur connaissance des processus seront d une priorité plus basse. Il va également être impératif d inclure la hiérarchie senior des utilisateurs. Dans le cadre de DSDM, on sélectionnera des «vrais» utilisateurs pour les rôles d ambassadeurs-utilisateurs, faisant partie de l'équipe, et le management senior comme utilisateur conseiller. Prendre le pouvoir! (de décision) Il est essentiel que l'équipe de projet puisse prendre des décisions a très court délai. Nous avons vu que les organisations européennes vont offrir une certaine résistance, résistance qui ne sera annihilée que part l inclusion du senior management des utilisateurs dans l équipe. Il est peu probable que l on obtienne un engagement important en temps, mais l objectif est d obtenir d eux un engagement en terme de responsabilité vis a vis du projet, et d accessibilité de la part des
utilisateurs quotidiens. Les utilisateurs ambassadeurs vont donc participer au processus décisionnel, et en référer à leur supérieurs hiérarchiques pour les décision les plus importantes, ces derniers ayant acquis la culture RAD a travers un programme de training et leur engagement dans le projet. L expérience montre que ce processus invite le senior manager, par son engagement au côté de ses subordonnés, à re-considérer leur valeur décisionnelle, et vont graduellement déléguer les décisions a ceux ci. Nous proposons donc de transférer graduellement le centre de décision par un processus naturel, plutôt que de tenter une révolution culturelle vouée a échec. Il s agit de prendre le pouvoir sans effusion de sang. Les ateliers facilites JAD workshop une proposition de format Les «JAD sessions» poursuivent les objectifs suivants : interactivité, responsabilité, productivité, consensus, prise de décision de qualité, et vision partagée. Pour atteindre ces objectifs, il est nécessaire d avoir tous les acteurs du projet dans une seule pièce, ou, dans le cas équipes géographiquement séparée, dans la même téléconférence. DSDM et RUP décrivent chacune le format idéal de workshop, DSDM interdisant tout observateur toutes les personnes présentes doivent contribuer au débat alors que RUP encourage les observateurs, dans le cadre de projets de grande envergure. Nous avons vu que l inclusion du senior management des utilisateurs est impératif pour la prise de décision, au moins au début du projet. Il est donc également impératif de les inclure dans les JAD sessions. Le risque lié à cette décision, est que la présence du senior management bride la liberté d expression des «vrais» utilisateurs. Il est donc particulièrement recommandé d inviter ces senior managers, mais de le confiner à un rôle d observateur. Leur présence justifie la prise d importantes décisions, et les utilisateurs peuvent de reporter vers eux pour obtenir leur aval, mais leur rôle n est pas de faire des propositions, qui pourraient aller envers l intérêt des utilisateurs. Le facilitateur de workshop doit garder cet état d esprit en tête, et régler son style de facilitation en utilisant son propre jugement par rapport à la compétence technique des senior managers. Les activités de test s inscrire dans la structure Inscrire les activités de tests tout au long du développement implique que les testeurs font également partie de l'équipe de projet. Les structures formelles équipe de test ne s adaptent pas a RAD. Dans la plupart des cas, vouloir changer la structure des ces équipes va signifier avoir à se
heurter à la résistance forcenée du manager de test, qui va voir dans cette initiative une attaque a sa souveraineté sur les activités de test et sur ses équipes. C est s exposer à un risque inutile que de vouloir lutter contre des individus qui ont réellement le pouvoir de faire échouer l initiative. La solution consiste à tester les livraisons sans le dire. Il va donc s agir de recruter des testeurs a l extérieur de l organisation, ou d utiliser des contractuels, pour faire le travail nécessaire de test, et lui accorder le moins de publicité possible. Une bonne solution est de réunir l ensemble des tests sous l appellation de unit test, même si les tests sont fait de façon formelle et incluent les tests de régression et d acceptance. Une fois le produit délivré, il suivra malheureusement le processus institué par l organisation, de sorte que les équipes de test traditionnelles ne se sentent en rien menacées par cette nouvelle pratique. C est un moindre mal nécessaire. L estimation et évaluation de risques une seule voix Que l on utilise DSDM ou RUP, l un des grands bénéfices que ces méthodes apportent est la réduction globale des risques, qu ils soient commerciaux ou lies au projet. Le management de risques est donc au centre des considérations des méthodes RAD, et, dans le cas du RUP, il devient un principe sous tendant la planification. Nous avons vu plus haut que notre appréhension des risques, à travers l identification, l estimation et l évaluation, est fortement influencée par notre culture. Dans un projet transculturel, le consensus va s avérer extrêmement difficile a trouver, et cette difficulté va mettre en danger la rapidité de décision. J ai bien peur que la seule réponse que l on apporter a ce problème est l instauration de la dictature, ou, tout au moins, de la monarchie constitutionnelle. Un unique individu doit prendre la responsabilité du management de risque. Il consultera l équipe, mais la décision finale lui appartiendra. Selon la taille du projet, ce rôle incombera au project manager, a l architecte technique, ou bien à un spécialiste. Il est plus que fortement recommandé de choisir un individu de la même culture que la communauté des utilisateurs. Conclusion "Ce qui ne nous tue pas nous rend plus fort" F. Nietzsche Les méthodes RAD sont nées en Amérique du Nord, et par la même véhiculent des approches qui ne sont pas toujours directement exportables. Il ne fait néanmoins pas de doute que la philosophie les sous-tendant est celle qui apporte les meilleurs résultats pour le développement des systèmes d information. Les organisations qui ont su s adapter en ressortent aujourd hui renforcées. A
terme, les organisations qui vont avoir acquis la maturité nécessaire pour optimiser le management des méthodes RAD auront un avantage décisif. Il ne fait aucun doute que l émergence des méthodes RAD sur le continent européen, et plus particulièrement en France, n a pas connu le même succès que dans les pays anglo-saxons. Comme nous l avons vu, les raisons sont multiples, mais les difficultés rencontrées ne sont pas insurmontables. Les solutions : Une compréhension de nos modèles respectifs, leur force et leur faiblesse Une analyse de l impact de ses différences sur les méthodes envisagées Une approche pragmatique pour l implémentation de ces méthode - changer la forme, pas le fond Prendre en considération les différences culturelles dans l élaboration de ces méthodes, et dans leur évolution, est un facteur clef de leur succès. Développer une plate-forme commune de processus et de communication à travers l Union Européenne est une nécessité pour une vraie collaboration, pour une vraie union. C est là le vrai défi de l Europe dans les années a venir, c est le vrai défi des organisations pan-européennes aujourd hui. Bibliographie [1] Hofstede,G. 1989 Motivation, Leadership and Organization: Do American Theories Apply Abroad? [2] Multiples auteurs DSDM consortium 1997 DSDM V3 en Francais