Ainsi SOA-t-il !

Il a peu de temps encore, les entreprises s’organisaient autour des projets. Chaque département ou gros service implémentait son système, un îlot. Cette construction que l’on baptise ‘en silo’ a amené l’introduction de technologies différentes et, pire encore, la redondance et l’incohérence de données. C’est là la cause profonde de la fameuse « architecture accidentelle » subie par tout professionnel de l’IT qui a un peu de bouteille.

Et c’est ainsi qu’un fossé se creuse entre les besoins métiers et le service de l’IT.

Entre temps, la pression s’est accentuée sur les entreprises.
Les fusions et acquisitions se multiplient. La performance est demandée. La quantité de travail croît. Les règles et lois évoluent et rendent la gestion plus complexe et plus exigeante. Certaines branches sont outsourcées (pas nécessairement l’informatique). Bref, la compétition et la mondialisation sont au rendez-vous.

Les sociétés de services se sont penchées sur la problématique : apporter une réponse était indispensable.

La théorie que l’on nous a enseignée il y a 30 ans ne devait pas ressurgir : l'approche cartésienne (Descartes) qui prône le découpage d’un problème en sous-problèmes. Cette approche prend peu en compte les interactions entre problèmes et c’est bien là sa tare.
Par contre, l'approche systémique favorise une vision globale sur la réalité considérée comme un système. Et comme l’entreprise est un système ouvert (càd en interaction avec le monde qui l’entoure), la pensée systémique offre une bonne base à l’amélioration de ses éléments organisés en fonction d’un but. Dans son cours d’Organisation et de Management le professeur Mohamed Bayad de l’Université de Nancy 2 nous confirme que « Lorsque la complexité (degré d’organisation) d’un système augmente, les propriétés qui le caractérisent dépendent de plus en plus de sa structure (ensemble des relations) et moins en moins de la nature de ses parties. ».
Il faut donc comprendre l’entreprise comme un ensemble de variables en interaction ayant un certain de degré de finalité. Et la modélisation en ‘Business Process’ répond à la demande de formalisation que demande un système informatique.
Des packages informatiques qui reprennent les logiques métiers ont été développés. Ils comportent néanmoins différents inconvénients : d’une flexibilité limitée, ils n’apportent pas ou peu de différenciation ou d’innovation sur des marchés concurrentiels. Ils ont également le lourd inconvénient de rendre l’entreprise dépendant des tierces parties.

Le SOA (Services Oriented Architecture), qui est le pendant informatique du BPM (Business Process Management) est un modèle intéressant. Il aligne l’IT et les métiers sur l’organisation en processus. Il accroît les capacités des investissements informatiques consentis. Enfin, son implémentation se veut incrémentale et non radicale. C’est d’ailleurs un point très fort de l’approche car le « big bang » n’est souvent pas une option envisageable.
Alors que pendant des années, l’IT s’est focalisé sur la ‘complexité de gérer cette complexité’ (et de la maintenir), le principal objectif de l’IT peut ici être de permettre l’exécution de processus métiers et d’accompagner les changements. Et ce sont bien ces derniers qui apportent la différenciation tant recherchée par les entreprises.
Autre avantage du SOA, l’entreprise peut établir des plans d’expansion ou d’amélioration en se basant sur des capacités informatiques plus claires.

Alors comment mettre du SOA dans le moteur d’une entreprise ?
Le SOA se construit sur 4 dimensions, les 4 P : People, Process, Platform et Practice. Tout va partir d’un modèle de service qui va aligner les objectifs d’entreprise et les besoins (attentes clients, les lois, …).

D’une cartographie de l’organisation existante (AS IS) on sera en mesure de construire une vision d’amélioration, un futur (TO BE). Et l’IT sera en mesure de suivre et de s’adapter, ayant abandonné son architecture ‘spaghetti’ pour une structure en ‘bus’ que certains qui ne manquent pas d’humour baptiseront ‘lasagne’.
En marge des solutions proposées par les ‘sofware houses’ (je citerai par exemple le white paper de SUN de févier dernier : a pragmatic approach to implementing a SOA with sun java composite application platform suite), quelques sites décrivent l’approche en long et en large. Une récente présentation m’a permis de découvrir le site de http://www.praxeme.org/ que je vous invite à consulter.

Je vois dans le SOA de nombreux rapprochement avec la théorie des contraintes qui me séduit tant. J’ignore si des travaux ont déjà abordé les analogies ou ont réalisé des études d’écart. Si vous avez des références ou des liens, merci de me les transmettre !

Structure matricielle

Les grandes dimensions autour desquelles les décideurs conçoivent la structure d’une organisation relèvent souvent d’un besoin à un moment donné.
On peut définir les besoins de structure organisationnelle par un positionnement sur base de l’identification de quelques paramètres simples. Des maîtres en la matière tels Mintzberg[1] caractérisent une structure de la manière suivante (vue simplifiée) :

Qu’advient-il après ? Du stade de la création au stade de la montée en puissance (le plein développement), la croissance d’une entreprise impliquera un certain nombre de changements, d’adaptations organisationnelles nécessaires. C’est un besoin d’agilité qui se fera sentir car l’entreprise devra rester compétitive et atteindre ses objectifs de rentabilité.

Dans ce contexte d’adaptabilité vitale, les structures matricielles ont le vent en poupe. L’adoption des principes d’amélioration continue (PDCA: roue de Deming), le contexte de la réorganisation sur base des processus primaires et secondaires, de la mise en place de services de ‘support’ et l’introduction progressive de l’outsourcing y contribuent.

Ce changement, qui ne s’improvise pas, fait l’objet de bon nombre de discussions. La Théorie des Contraintes apporte ses réponses. Dans un échange avec le groupe de discussions qu’il a initié, David Laffineuse, qui dirige le bureau de gestion de projets de la société Bendix (groupe Knorr-Bremse) à Elyria dans l'Ohio, précise que certains principes se doivent d’être suivis : « trois principes fondamentaux doivent changer pour permettre une meilleure performance dans une structure matricielle.

1. Ces organisations doivent se rendre compte des effets néfastes d'une utilisation maximale de chaque ressource. Leur expliquer l'application de la loi de Little (théorie des files d'attente simples de type M/M/1) à leur processus de développement peut parfois les convaincre (principalement l'effet sur le temps moyen des tâches dans le système).


2. Il faut que l'organisation mette en place une discipline de séquençage des projets, sur base de la capacité de leur ressource critique. Bref, créer un système 'PULL' alors que maintenant ils utilisent en majorité un système 'PUSH'.


3. Il faut que ces organisations adoptent une discipline de priorités claires (aussi bien au niveau des projets qu'à celui des tâches) qui mette fin au multitâche chronique de leurs ressources. Ici, toujours en utilisant la théorie des files d'attente, on peut voir l'effet du multitâche sur le temps moyen de service. Ce qui est intéressant par contre c'est de voir que quel que soit le niveau de multitâche, le temps moyen dans le système n'est pas affecté. Le multitâche se traduit en effet par une réduction du temps moyen d'attente mais par une augmentation proportionnelle du temps de service. Ce qui prouve d'ailleurs que le bon vieux système du multitâche ne procure qu'une illusion d'efficacité, son résultat étant en vérité une destruction complète de la productivité.

Si ces trois principes sont respectés, une organisation pourra fortement améliorer la performance de sa matrice en terme de son débit de projets. Ceci dit, il faudra quand même s'assurer que la structure de la matrice en elle-même contribue à cette amélioration de la performance.»

Orienter une société et ses départements vers la structure matricielle est un défi de gestion d’importance qui pourrait vite être perçu comme une bureaucratie naissante, une déstabilisation ou un alourdissement de toute une organisation.

Pour rendre performante la structure, il faut que les principes fondamentaux de gestion changent. C’est au niveau des décideurs de l’entreprise que le premier challenge se situe. Ils doivent être réelle partie prenante dans la démarche de changement.
Le pragmatisme, les douloureuses expériences passées d’un dirigeant ou simplement la crainte d’une perte de pouvoir (financier, humain, …) sont autant de freins à la formalisation et l’adaptation d’un nouveau fonctionnement. Mais un manque d’évolution, un maintien du concept organique fragilisera immanquablement une société à terme.

[1] Structure et dynamique des organisations
Henry Mintzberg – Editions d’Organisation – ISBN : 2-7081-1971-0

Qui soigne-t-on avec les ordinateurs ?

L’Inventaire des Systèmes d’Informations de la Santé (ISIS) et la recherche de l’état de l’art informatique sont aujourd'hui au cœur des débats qui animent le secteur hospitalier du Grand Duché de Luxembourg.
Face au nombre toujours croissant de patients à soigner, à la recherche permanente de la perfection technique, aux besoins grandissants de traçabilité, à l’exigence légitime de la protection des données personnelles et médicales, l'organisation et le fonctionnement de l’hôpital ont vu se développer de nouveaux défis de gestion. Pour relever ceux-ci, les messages politiques de tous horizons nous présentent l'outil informatique comme l’outil imparable.
En France, Xavier Bertrand, Ministre de la Santé, a présenté en février dernier son plan Hôpital 2012 qui met l’accent sur les systèmes d’information hospitaliers. « Je veux que les établissements soient complètement numérisés » … « c’est maintenant que nous devons prendre ce virage» déclare-t-il dans le journal La Tribune du 7 février 2007.
La balle serait-elle dans le camp des informaticiens ?

La monté en puissance de l’informatique dans le secteur hospitalier est notable sur ces cinq dernières années. Le métier a, quant à lui, également évolué. Les projets administratifs laissent la place à des projets visant les soignants. Ce rapprochement du cœur de métier implique un besoin de tenir de plus en plus compte des problèmes et des particularités organisationnels des services et métiers concernés par une informatisation.
Certains veulent laisser croire que l'informatique parviendra, à elle seule, à soigner des problèmes organisationnels alors que les professionnels s’épuisent à les résoudre sur papier. N’avons-nous tous pas rencontré des tentatives locales de changement dont l’effet final, malgré des efforts considérables, n’est que très sensible voire inexistant ? Au-delà des luttes intestines Administration-Soins-Médical, la volonté (souvent louable) de ces gens pleins d’illusions est de mettre enfin en place une solution « qui tourne » ; ils rêvent des logiciels parfaits que présentent les commerciaux. Mais malheureusement l'informatique n'est pas la panacée, la "baguette magique" qu’il suffit de pointer sur un département pour résoudre ses problèmes. Il faut analyser les véritables causes profondes de ces derniers. Cela commence en répondant à trois questions : Que changer ? Vers quoi changer ? Comment changer ?
Un support méthodologique s’impose. Quoi de mieux qu’une approche de résolution de problèmes tout à fait analogue à l’approche des cliniciens pour le traitement des patients (lire à ce titre le livre[1] de Burton-Houle qui exploite la Théorie des Contraintes) ?
Si nous avions à décrire l’ensemble du processus suivi par un clinicien, nous obtiendrions à peu près :

1. Diagnostic : connaître les symptômes. Un clinicien commence par dresser une liste des symptômes observables et utilise les causes-effets pour rechercher les causes sous-jacentes de chacun d’eux et déterminer l’affection ou le problème principal.


2. Conception d’un plan de soins : en considérant que le patient qu’il soigne est unique, un plan de soin est établi. Ce plan va cibler avant tout l’affection mais va également prendre en compte les autre choses qui doivent être considérées tout au long des soins pour guérir et pour assurer que le traitement fonctionnera (le médecin prescrit par exemple du repos au lit). Tous les effets secondaires du traitement sont identifiés et les moyens pour les éviter ou limiter deviennent des éléments importants du traitement (par exemple, soulager l’estomac lors de la prise d’anti-inflammatoires).


3. La prise du traitement : en considérant que chaque patient est unique, un plan est développé pour déterminer comment mettre le traitement en route.
   

Ce bon sens médical nous rappelle qu’il est bien essentiel de confirmer que la solution (informatique) entrevue pour une problématique va bien amener une véritable amélioration. Cela est d’autant plus vrai que le lancement d'un projet informatique demande avant tout du courage organisationnel. Il faut remettre à plat des pratiques traditionnelles et des habitudes de gestion. Il ne faut pas hésiter à envisager de nouveaux modes de fonctionnement.

Le succès d'un projet informatique relève d’une complicité étroite entre l’organisationnel, le fonctionnel et la technique, c'est-à-dire un engagement humain fort. Ce changement se gère dans le temps. Il doit permettre d’installer de nouvelles utilisations naturelles dans les pratiques de travail quotidiennes.

L'informatique Métier dans le Secteur de la Santé au Service de la Performance et de la Qualité est à ce prix. C’est le thème de la conférence organisée le 17 avril prochain au MEDETEL (Foires Internationales à Luxembourg). Une présentation lors du séminaire CRP-Santé me permettra de répondre a la question : dans un hôpital, « qui soigne-t-on avec les ordinateurs : le patient ou l’informaticien ? ». Amusé, j’entends déjà certains propos « c’est le discours d’un patient modèle et d’un informaticien averti…qui se porte bien ». Je devrai donc rappeler que, si je place un ordinateur au milieu d’une unité de soins, sans concept organisationnel et fonctionnel, nul doute qu’il va rendre malade bon nombre de professionnels du secteur santé !



[1] Burton-Houle, T.2001. The Theory of Constraints and the Thinking Process : A brief introduction to TOC. New Haven, Conn.:Avraham Y. Goldratt Institute

An Inconvenient Truth

C’est un show à l’américaine qu’a offert Al Gore lors de la conférence « Repères » de la Dexia Bil, tenue hier au Grand Théâtre de la Ville de Luxembourg. L’ex-vice Président des Etats-Unis était invité à présenter son film ‘An Inconvenient Truth’ qui porte sur le réchauffement de la planète et ses conséquences désastreuses.


Pendant près d’une heure et demie, utilisant des images fortes et des concepts simples, Al Gore a brillé dans un exposé qui ne laissait pas de place à l’improvisation. Posant ses arguments sur d’incontestables comptes-rendus scientifiques, il a présenté une machine remarquablement bien huilée. Elle lui permet de faire prendre conscience à tous que notre planète est en danger si on ne réagit pas dans l’urgence en introduisant des dynamiques de changement de comportement des Etats et des peuples.
On ne peut que saluer une initiative d’un représentant de la nation la plus impliquée dans la dégradation de l’environnement même si certaines connotations politiques ‘démocrates’ ne doivent pas nous rendre dupes à quelques mois des élections américaines…

Proche de sa conclusion, rappelant que les calligraphies asiatiques représentent généralement un concept ou une idée, Al Gore précise que le mot « crise » se représente par deux sinogrammes juxtaposés : le premier désigne le danger par contre le second symbolise l’opportunité. L’ex-vice Président invite le monde à réagir et à saisir cette dernière chance avant qu'il ne soit définitivement trop tard.

Combien de temps à la valse des titres ronflants ?

L’image et les paillettes l’emportent de plus en plus sur le fondement même de la fonction. Aujourd’hui, on n’est plus caissière mais ‘hôtesse de caisse’, on n’est plus vendeur mais ‘conseiller clientèle’. Et les bons vieux titres de ‘Responsable’, de ‘Chef de service’, de ‘Manager’, de ‘Directeur’ ? Ces labels, compréhensibles pour la plupart d’entre nous, sont en péril car ils reposent de moins en moins sur des repères communs. A cela s’ajoute l’arrivée de nouvelles dénominations anglo-saxonnes qui compliquent considérablement un jeu de positionnement mutuel. Et les dérives accompagnent ce phénomène. Le ‘System Engineer’ devient en français ‘Ingénieur Système’ alors qu’il n’a parfois jamais dépassé le stade du CATP. Cela me choque. Rien à voir avec un problème d’égo mais bien que l’étiquette s’inspire d’un titre académique diplômant. On est proche de la contrefaçon puisque l’on va imiter quelque chose sans en avoir le droit et probablement dévaloriser des études.

Mais comment en arrive-t-on à doper ainsi une série d’étiquettes dans une société qui tente de retrouver des repères ?
Ces dernières années ont été marquées par le phénomène de mondialisation de l’économie et, alors que l’on assiste fréquemment à des restructurations, il est indéniable que des opportunités de promotion se sont multipliées dans les entreprises. Les carrières s’en voient moins linéaires et des personnes se retrouvent vite parées d’un titre ronflant ne correspondant pas à leur fonction ou à leurs responsabilités.

Faut-il s’en inquiéter ? Je ne crois pas car le marché n’est pas dupe. J’en prends pour exemple la visite récente de deux commerciaux d’une société de services informatiques cotée en bourse. Visiblement jeunes et peu expérimentés, ces deux personnes se sont présentées à moi avec un bagage commercial très léger et une connaissance médiocre du secteur hospitalier et de surcroît du contexte luxembourgeois. En 20 minutes de questions-réponses je me suis fait une idée sur leur manque de compétence qui a de plus déteint sur l’image, neutre à ce stade, que j’avais de leur entreprise. Je me suis même fait la réflexion que des sociétés de renom ne devraient tout de même pas envoyer des ‘junior’ au front sans les faire accompagner d’une personne ayant un minimum de ‘bouteille’ et de connaissance du client. A ma grande surprise, alors que je classais verticalement les 2 cartes de visites, je dus constater que mes interlocuteurs arboraient un titre de ‘Manager’! Qu’avaient-ils géré à ce jour, en tout cas ni notre entrevue ni un potentiel marché avec moi et ma société.
Le phénomène de la surenchère des titres va de pair avec une volonté d’ascension hiérarchique que les hommes ont toujours recherché. Comme un vieil adage, le principe de Peter nous rappelle que « Dans une hiérarchie, tout employé a tendance à s'élever au niveau de son incompétence ».
Je préconise l’avancée progressive, compatible avec une évolution, une maturité et une expertise gagnée au fil du temps, de l’effort et des succès.

Avant-hier, alors qu’il effectuait une sortie hors de la station spatiale internationale, le cosmonaute Mikhail Tyurin s’est fait dire "Please pay attention to your condition while you work" … "If you feel it's too hot, then take a break.". A ceci il répondit avec beaucoup de philosophie: "One who knows something about life is never in a hurry".

Expérience - Inexpérience

Si la jeunesse (toujours relative) a certains avantages, elle souffre également de certains handicaps, l’inexpérience étant reconnue comme le majeur. Certains voudraient cependant opposer l’inexpérience à l’expérience. Comme si l’expérience était un gage de réussite, le terreau privilégié du succès.

L’apprentissage commence dès notre plus tendre enfance. Petit, il nous arrive de se voir refuser quelque chose auquel on tenait. A-t-on mal demandé ou s’y est-on mal pris ? Plus tard, ce sera peut-être un examen qu'on aura raté, un emploi qu'on aura manqué, une promotion qui nous sera refusée,...et chacun de ces échecs sera vécu plus ou moins bien.
Cette perception sera le résultat d’une interprétation d'un événement. La perte d'un emploi sera par exemple un événement perçu comme étant une chance de réorienter sa carrière pour une personne alors que ce sera une énorme difficulté à surmonter pour une autre.
L’approche par l’échec porte aussi avec elle une potentielle période d’écroulement, une destruction avant de reconstruire. Cependant, une personne ‘inexpérimentée’ qui a la capacité de réagir vivement à cet effondrement sera certainement plus performante que son homologue ‘expérimenté’ qui pourrait se laisser surprendre et abattre par l’inattendu, l’imprévisible.
En privilégiant l’expérience, on part du principe que le vécu sera ré-exploitable. Mais n’est–ce pas une erreur alors que notre mode de travail et de vie se base de plus en plus sur une multitude de projets ? Or chaque projet est bel et bien UNIQUE. C’est donc plus sur des capacités à innover, rassembler les références, planifier, organiser et contrôler ces projets qu’il faut juger les individus.
Il n’est donc pas irresponsable de confier des responsabilités à une personne qui n’a pas fait ses preuves sur un domaine. Il sera par contre indispensable que cette personne trouve le mélange subtil qui va allier la vue exprimée par les ‘anciens’ et la capacité à soulever des idées nouvelles ou non exploitées. L’inexpérience doit donc être comblée par des atouts. Ces derniers peuvent compenser judicieusement les manques (que certains adversaires ne failliront pas à reprocher aux premiers faux-pas d’ailleurs).
Ici, en Europe, notre approche a souvent tendance à voir l’échec avec un regard dévalorisant, alors qu’il peut être source d’apprentissage. La culture américaine, elle, exploite bien mieux les rebondissements de l’échec. Elle laisse également plus facilement la chance aux jeunes ambitieux.
Ainsi, le plus jeune Sénateur des Etats-Unis d’Amérique, Barack Obama, vient d’annoncer sa candidature à l’élection présidentielle. Attaqué sur son inexpérience, ce démocrate noir répond que les gens très expérimentés qui entourent Bush ont tout de même provoqué un fiasco en Irak.
Si l’on reste en politique, ce type de discours semble être également apprécié par Ségolène Royal face à ses rivaux dans la campagne présidentielle française. Cela lui a déjà bien réussi dans sa démarche interne au parti socialiste, face aux ‘éléphants’.
Les politiques nous apporteraient-ils la preuve que les mentalités doivent changer ?

Project Management = P.O.C. (Planning, Organisation and Control)

Alors que le changement, l’adaptation et la rapidité de réaction sont devenus le credo de toute entreprise qui veut rester compétitive, je rencontre trop souvent des cadres, des consultants ou des chefs de projet qui ne distinguent pas l’outil (le plus connu est certainement MS-Project) de la technique (citons par exemple le brainstorming) ou de la méthodologie. Or, je suis persuadé que cette dernière est nécessaire afin d’assurer une gestion de projet rigoureuse et de tenir compte de tous les aspects pendant l’analyse.
Pour de nombreux projets, j’ai côtoyé des « chefs de projet en herbe » dont l’optimisme frisait la naïveté. Souvent, ces personnes feignaient de maîtriser le projet parce qu’elles avaient dressé une liste (approximative) d'actions dans un fichier MSP !
Faut-il rappeler que les projets font partie du quotidien des entreprises, leurs succès les font de plus en plus vivre et l’échec d’un seul est parfois fatal ?

Je suis personnellement adepte du « bon sens organisé » pour amener à la réussite. Je l’ai retrouvé récemment dans la Théorie des Contraintes (lire Critical chain – La chaîne critique de Eliyahu M. Goldratt – Editions AFNOR –2002 ISBN 2-12-465613-9).
La méthodologie GDPM (Goal Directed Project Management) est sans doute plus accessible. Elle est notamment enseignée à l’Université de Genève et par des sociétés de conseil telles PricewaterhouseCoopers à Luxembourg. GDPM a l’avantage d’être très pragmatique et de s’appliquer à tous les projets : du projet de mariage au projet d’implémentation informatique en passant par la construction d’une maison.

Je vais tenter en quelques lignes de dresser de manière simplifiée les fondements de cette approche collaboratrice pour laquelle je fus formateur pendant 3 années.

Tout projet repose sur des fondements que GDPM invite à décrire dans la « charte » de projet. Cette charte doit tenir sur une feuille A4 et reprendre :

1. La description du projet
2. Les objectifs du projet: ils doivent être S.M.A.R.T. (Specific, Mesurable, Agreed, Realistic, Time Bound).
3. Le scope (la portée) : important de bien préciser ce qui sera repris dans le projet mais également ce qui sort du cadre.
4. Les hypothèses de base (assumption) : à un moment t, certaines hypothèses peuvent remettre en question le fondement même d’une démarche
5. Les parties prenantes (stakeholders) : qui sont-elles, quelles sont leurs craintes et quelles réponses peut-on déjà leur apporter?
6. Les risques : connaître les risques est essentiel si l’on veut gérer la feuille de route et éviter les écueils

Nous sommes au stade où la feuille de route peut être dressée. Les diverses étapes d’un projet vont être déterminées en suivant une approche qui repose sur la technique d'une planification de délivrables[1] (ou bornes[2]). Ceci à l’avantage d’être propice à la prise de décisions, ce qui est d’autant plus efficace face à un conseil d’administration auquel vous pourriez être amené à présenter votre projet.

Nous établissons une liste d’une quinzaine de grandes étapes réparties tout au long du projet. Moins de dix étapes rendent le Milestone Plan trop simplifié et plus de vingt le rendent trop complexe pour servir d’outil collaboratif. Ces bornes sont mises dans trois chemins de résultats[3] que l’on a pu identifier. L’objectif composite de ce projet rend en effet le plan multidimensionnel : l’aspect organisationnel (auquel nous ajouterons le respect des lois et règles), le côté humain (gestion des acteurs) et l’aspect technique.
En tant qu’objectifs intermédiaires, les bornes sont Spécifiques au projet, Mesurables, Acceptées, Réalistes et positionnées dans le Temps : S.M.A.R.T.[4] . Elles sont reliées entre elles par des liaisons ‘fin à fin’. C'est-à-dire qu’une borne reliée à une borne précédente ne peut être achevée que si la précédente est atteinte.
Les activités à réaliser pour atteindre les différentes bornes ainsi que les contraintes et interdépendances d’une activité par rapport aux autres sont définies après (vision précise à quelques semaines). Les activités indiquent comment atteindre les objectifs d’une borne. Elles sont regroupées dans une matrice d'activités. En introduisant un facteur temps dans cette matrice, il est possible de lier les bornes à des dates précises.

En résumé, le milestone plan :
. Spécifie les résultats à atteindre tout au long du projet (l’enchaînement est composé d’une série de résultats) ;
. Se concentre sur les objectifs (qu’est-ce qui doit être réalisé ?) ;
. Intègre toute une série de conditions ;
. Est complété par un ‘activity plan’ qui indiquera comment réaliser les objectifs .

Illustration





Une fois le plan de projet dressé, la méthodologie offre un outil permettant d’identifier et de formaliser les rôles et responsabilités des différents acteurs et intervenants dans le projet. Ceux-ci peuvent être décideurs, exécutants, consultés, consultants, informés ou encore formateurs. La matrice des rôles et responsabilités dresse une grille reprenant un symbole de ce rôle placé à la verticale de l’acteur et à l’horizontale de l’étape à atteindre.

La méthodologie GDPM a le souci permanent d'éviter la bureaucratie au moyen de rapports condensés. Le ‘Milestone Plan’ doit être compréhensible pour tous et logique. Il se doit d’être contrôlable qualitativement et quantitativement tout en se concentrant sur les décisions nécessaires. De plus, il donne la description des étapes induisant des solutions et non des techniques et constitue l'assurance de la qualité.

J’ai personnellement éprouvé l’approche GDPM sur de nombreux projets, du plus petit au plus grand. Elle est très efficace et je recommande aux chefs de projets « junior » d’y jeter un coup d’œil, en tout cas avant de venir me présenter leur Microsoft Project !

Lecture recommandée :
Goal Direct Project Management – Effective Techniques and Strategies
Erling S. Andersen, Kristoffer V Grude and Tor Haug – PricewaterhouseCoopers
ISBN 0-7494-2616-2

[1] Jargon utilisé par les consultants venant de l’anglais ‘deliverable’ – élément livrable
[2] Les bornes appelées ‘Milestones’
[3] Chemin de résultat : traduction du terme Result Path
[4] Moyen mnémotechnique, smart en anglais signifie ‘futé’