Rapportjlf.axnet.free.fr/IMI/PPI V2.0.doc · Web view2.0 Titre du document Pathologies des Projets...

Diplôme d’Etudes Supérieures en Management de l’InformationPromotion 38 Février

Gérard Balantzian, Maître d’Ouvrage du Projet

Pathologies des Projets Informatiques

Projet réalisé du 19 mars 2008 au 27 juin 2008

Equipe de projet :

Jean-Luc Fiquet (chef de projet)

Fattah Abdessadak

Pierre-Yves Arades

Laurent Carette

Napoléon Djen

Yvan Erard

Encadrée par :Mélissa Saadoun

Jean Joskowicz


Nom du fichier PPI

N° Version 2.0

Titre du document Pathologies des Projets Informatiques

Résumé Partant des 3 mini-projets (Management structuré de Projet, Management de l’équipe de projet et Management de projet e-collaboratif), des dysfonctionnements sont identifiés et analysés selon leurs causes et leurs effets sur les 3 dimensions : humaine et managériale, organisationnelle et technique (informatique).

Des solutions de progrès, des facteurs clés de succès ainsi que des recommandations sont formulés pour aider le chef de projet à bien conduire son projet informatique.

Illustré d’exemples issus de l’expérience des membres de l’équipe IMI38F et complété par un approfondissement des différentes thématiques telles que la gestion des émotions et des conflits, la capitalisation des connaissances, ce document offre une véritable base de connaissances des pathologies des projets informatiques.

Mots clés Management équipes de projet – Management projet e-collaboratif - Management structuré de projet – Pathologie projet informatique - Projet informatique.

But du document Servir de référence voire de référentiel du sujet « brûlant » : Pathologies des Projets Informatiques.

Diffusion Jury composé de :

Gérard Balantzian, Directeur IMI et Maître d’Ouvrage du projet PPI

Jacques Printz, Professeur au CNAM

Mélissa Saadoun, Directrice de MS Institute, Intervenant IMI.

Jean Joskowicz, Président AFISI, Intervenant IMI.

Plus un exemplaire pour chaque membre du groupe IMI38F

Date de diffusion 15 juin 2008

Rédaction du document

Groupe IMI38F

Validation du document

Mélissa Saadoun et Jean Joskowicz

Equipe IMI38F – DESMI UTC/IMI, 2008 2


Table des matières

Avant-propos................................................................................................................................7

I – Pour une meilleure compréhension du sujet...................................................................9I.1. Rappel du contexte............................................................................................................9

I.1.1. Contrôle commun IMI.......................................................................................................9I.1.2. Objectifs généraux du contrôle commun.............................................................................9I.1.3. Cerner les besoins et attentes de la MOA............................................................................9

I.2. Démarche et organisation du projet..............................................................................11I.2.1. Du cahier des charges provisoire au cahier des charges définitif.........................................11I.2.2. Démarche permettant d’atteindre l’objectif du projet.........................................................12I.2.3. Planning du projet...........................................................................................................13I.2.4. Processus de validation du projet.....................................................................................14I.2.5. Ressources du projet.......................................................................................................15I.2.6. Moyens de communication..............................................................................................15

I.3. Les fondamentaux du sujet.............................................................................................17I.3.1. Un projet informatique et ses 3 dimensions.......................................................................17I.3.2. La notion de dysfonctionnement......................................................................................17I.3.3. Les facteurs clés de succès..............................................................................................18I.3.4. Processus de capitalisation..............................................................................................18

II – Le Management Structuré de Projet.............................................................................19

II.1. Rappel des 6 items du MSP...........................................................................................19II.1.1. Expression des besoins..................................................................................................19II.1.2. Découpage en phases et panorama des outils...................................................................19II.1.3. Phase de planification et gestion du temps.......................................................................20II.1.4. Phase de lancement........................................................................................................21II.1.5. Phase de production.......................................................................................................21II.1.6. Phase de pilotage...........................................................................................................21

II.2. Expression de besoins....................................................................................................23II.2.1. Constat des dysfonctionnements.....................................................................................23II.2.2. Argumentaire expliquant ces dysfonctionnements............................................................23II.2.3. Pistes de solutions de progrès.........................................................................................23II.2.4. Facteurs clés de succès...................................................................................................24

II.3. Découpage en phases et panorama des outils..............................................................25II.3.1. Constat des dysfonctionnements.....................................................................................25II.3.2. Argumentaire expliquant ces dysfonctionnements............................................................25II.3.3. Pistes de solutions de progrès.........................................................................................26II.3.4. Facteurs clés de succès...................................................................................................26

II.4. Phase de planification et gestion du temps..................................................................27II.4.1. Constat des dysfonctionnements.....................................................................................27II.4.2. Argumentaire expliquant ces dysfonctionnements............................................................27II.4.3. Pistes de solutions de progrès.........................................................................................28II.4.4. Facteurs clés de succès...................................................................................................28



II.5. Phase de lancement........................................................................................................29II.5.1. Constat des dysfonctionnements.....................................................................................29II.5.2. Argumentaire expliquant ces dysfonctionnements............................................................29II.5.3. Pistes de solutions de progrès.........................................................................................30II.5.4. Facteurs clés de succès...................................................................................................30

II.6. Phase de production.......................................................................................................31II.6.1. Constat des dysfonctionnements.....................................................................................31II.6.2. Argumentaire expliquant ces dysfonctionnements............................................................31II.6.3. Pistes de solutions de progrès.........................................................................................32II.6.4. Facteurs clés de succès...................................................................................................32

II.7. Phase de pilotage............................................................................................................33II.7.1. Constat des dysfonctionnements.....................................................................................33II.7.2. Argumentaire expliquant ces dysfonctionnements............................................................33II.7.3. Pistes de solutions de progrès.........................................................................................33II.7.4. Facteurs clés de succès...................................................................................................34

II.8. Capitalisation des connaissances du MSP....................................................................35

III – Management des Equipes de Projet.............................................................................38

III.1. Rappel des 5 items du mini-projet MEP....................................................................38III.1.1. Gestion de ses priorités.................................................................................................39III.1.2. Gestion des priorités collectives....................................................................................39III.1.3. Management d’équipes de projet...................................................................................40III.1.4. Implication des utilisateurs............................................................................................41III.1.5.Soutien de la DG...........................................................................................................42

III.2. Gestion de ses priorités.................................................................................................43III.2.1. Constat des dysfonctionnements....................................................................................43III.2.2. Argumentaire expliquant ces dysfonctionnements...........................................................43III.2.3. Pistes de solutions de progrès........................................................................................44III.2.4. Facteurs clés de succès.................................................................................................44

III.3. Gestion des priorités collectives...................................................................................45III.3.1. Constat des dysfonctionnements....................................................................................45III.3.2. Argumentaire expliquant ces dysfonctionnements...........................................................45III.3.3. Pistes de solutions de progrès........................................................................................46III.3.4. Facteurs clés de succès.................................................................................................46

III.4. Management d’équipes de projet................................................................................47III.4.1. Constat des dysfonctionnements....................................................................................47III.4.2. Argumentaire expliquant ces dysfonctionnements...........................................................47III.4.3. Pistes de solutions de progrès........................................................................................48III.4.4. Facteurs clés de succès.................................................................................................48

III.5. Implication des utilisateurs..........................................................................................49III.5.1. Constat des dysfonctionnements....................................................................................49III.5.2. Argumentaire expliquant ces dysfonctionnements...........................................................49III.5.3. Pistes de solutions de progrès........................................................................................50III.5.4. Facteurs clés de succès.................................................................................................50

III.6. Soutien de la DG...........................................................................................................51



III.6.1. Constat des dysfonctionnements....................................................................................51III.6.2. Argumentaire expliquant ces dysfonctionnements...........................................................51III.6.3. Pistes de solutions de progrès........................................................................................51III.6.4. Facteurs clés de succès.................................................................................................52

III.7. Capitalisation des connaissances du MEP..................................................................53

IV – Management de Projets e-Collaboratifs......................................................................55

IV.1. Rappel des 5 items du MPeC.......................................................................................55IV.1.1. Charte des valeurs de l’équipe de projet.........................................................................55IV.1.2. Règles d’utilisation de l’espace e-collaboratif.................................................................56IV.1.3. Règles d’utilisation par équipe de projet de l’espace e-collaboratif...................................64IV.1.4. Tableaux de bord.........................................................................................................65IV.1.5. Capitalisation des connaissances...................................................................................66

IV.2. Charte des valeurs de l’équipe de projet....................................................................67IV.2.1. Constat des dysfonctionnements....................................................................................67IV.2.2. Argumentaire expliquant ces dysfonctionnements...........................................................67IV.2.3. Pistes de solutions de progrès........................................................................................68IV.2.4. Facteurs clés de succès.................................................................................................68

IV.3. Règles d’utilisation de l’espace e-collaboratif............................................................69IV.3.1. Constat des dysfonctionnements....................................................................................69IV.3.2. Argumentaire expliquant ces dysfonctionnements...........................................................69IV.3.3. Pistes de solutions de progrès........................................................................................70IV.3.4. Facteurs clés de succès.................................................................................................70

IV.4. Règles d’utilisation par l’équipe de projet de l’espace e-collaboratif......................71IV.4.1. Constat des dysfonctionnements....................................................................................71IV.4.2. Argumentaire expliquant ces dysfonctionnements...........................................................71IV.4.3. Pistes de solutions de progrès........................................................................................72IV.4.4. Facteurs clés de succès.................................................................................................72

IV.5. Tableaux de bord..........................................................................................................73IV.5.1. Constat des dysfonctionnements....................................................................................73IV.5.2. Argumentaire expliquant ces dysfonctionnements...........................................................73IV.5.3. Pistes de solutions de progrès........................................................................................74IV.5.4. Facteurs clés de succès.................................................................................................74

IV.6. Capitalisation des connaissances.................................................................................75IV.6.1. Constat des dysfonctionnements....................................................................................75IV.6.2. Argumentaire expliquant ces dysfonctionnements...........................................................75IV.6.3. Pistes de solutions de progrès........................................................................................76IV.6.4. Facteurs clés de succès.................................................................................................76

IV.7. Capitalisation des connaissances du MPeC................................................................77

Conclusion.................................................................................................................................80

Bibliographie.............................................................................................................................82Articles..................................................................................................................................82Ouvrages................................................................................................................................82Support de cours.....................................................................................................................82Pages Web visitées..................................................................................................................82



Annexes......................................................................................................................................84

Annexe 1 : CdC provisoire du 18 mars................................................................................85

Annexe 2 : CdC définitif du 31 mars....................................................................................88

Annexe 3 : Plannings du projet.............................................................................................98

Annexe 4 : Interviews de spécialistes du thème.................................................................100

Annexe 5 : CR des revues de projet....................................................................................105

Annexe 6 : Fiches mission....................................................................................................110

Annexe 7 : Norme et modèle pour projets informatiques................................................113

Annexe 8 : Questionnaire utilisé pour identifier les dysfonctionnements.......................115

Annexe 9 : Dysfonctionnements..........................................................................................122

Annexe 10 : Recommandations..............................................................................................153



Avant-propos

« Pathologies des Projets Informatiques »…quel vaste sujet !

Un des moyens d’aborder ce sujet aurait été de l’aborder sous l’aspect purement médical du mot « pathologie ».

Pathologie : altération de la santé caractérisée par l'apparition de symptômes.

Transposé à l’entreprise, on pourrait également parler de « santé » de l’entreprise, puisque les « indicateurs de performance » ou encore « signes vitaux » permettent de jauger de « l’état de santé » d’un projet informatique. « L’apparition de symptômes », laisse entrevoir des dysfonctionnements dont les causes et les effets peuvent être de trois origines : humaine (managériale), organisationnelle et technique (technologique).

Alors, quels sont les dysfonctionnements les plus fréquents ou graves des projets informatiques ? Quels en sont les causes et les effets ? A chaque étape de la vie d’un projet (naissance, lancement, études, cadrage, etc.) y a-t-il des dysfonctionnements plus spécifiques ? Existe-t-il des dysfonctionnements irréversibles ? Peut-on parler de prévention ? Quels indicateurs de performance ou encore facteurs clés de succès mettre en place pour veiller à la « bonne santé » des projets informatiques ? Peut-on en tirer des enseignements ?

Autant de questions à se poser pour tenter de comprendre ce phénomène qui touche toutes les organisations humaines, surtout dans le cadre d’un projet. Celui-ci se caractérise par un objectif que l’équipe de projet devra atteindre. Est-il bien défini ? On perçoit rapidement qu’il est nécessaire de communiquer et de partager l’objectif du projet avec tous les membres de l’équipe de projet. Qu’en est-il de cette équipe ? Comment gérer la diversité du choix des personnes qui la compose ? Ont-elles la volonté, les capacités et les moyens de travailler ensemble sur le projet ? Quelle place tiennent les problèmes de communication et plus généralement les problèmes humains dans les causes des pathologies des projets informatiques ?

J-L Gassé propose sa propre vision des différentes phases d’un projet informatique : indifférence, ignorance, lancement, enthousiasme, désenchantement, premiers craquements, panique à bord, abandon des objectifs, recherche des coupables, punition des innocents, arrivée in extremis, récompense de ceux qui n’ont rien fait…

Selon Francis Odier : « Dans les projets pathologiques, tout l’art du management consiste à confier à Monsieur X une tâche que Madame Y saurait mieux faire et vice versa ».

Ce qui promet bien des problèmes de management d’équipe…

Venant d’organisations différentes mais suivant le même cursus de l’IMI, les membres de l’équipe de projet ont tenté de comprendre les pathologies des projets informatiques de leur



propre entreprise. Ainsi, l’équipe s’est transformée en détective à la recherche de pathologies, de dysfonctionnements, de causes, d’effets, etc. Elle a traqué l’information, analysé ces informations pour être capable de les transformer en connaissances. Celles-ci sont rassemblées dans une annexe prête à servir à d’autres chefs de projet. Qui a dit qu’il était impossible de faire de la prévention ?

Grâce à cette base de connaissances des « Pathologies des Projets Informatiques », l’équipe IMI38F espère voir exploiter ces connaissances afin que les projets informatiques soient tous de véritables « success stories ».

Cette base de connaissances intitulée « Pathologies des Projets Informatiques » a été structurée en 4 parties :

La première partie rappelle le contexte de ce travail, l’organisation de l’équipe IMI38F entourée de ses 2 coaches et soutenue par son maître d’ouvrage. Des éléments fondamentaux tels que « la capitalisation des connaissances », « les moyens de communication », « le processus de validation du projet », etc. sont expliqués. En tant que maître d’œuvre, nous avons voulu illustrer notre démarche avec un schéma de « bâtisseurs », travailleurs sans relâche pour vivre une « œuvre commune ».

De l’expression des besoins au pilotage en passant par la planification, le lancement du projet, la production, des dysfonctionnements sont listés, analysés et capitalisés dans cette deuxième partie intitulée « Management Structuré de Projet ».

La troisième partie est consacrée au « Management des Equipes de Projet ». Gérer ses priorités mais aussi les priorités collectives, motiver son équipe et ses collaborateurs, gérer les conflits, impliquer les utilisateurs et surtout avoir le soutien de la Direction générale, tels sont les éléments pris en compte dans cette partie.

Enfin, dans la quatrième partie « Management de Projets e-Collaboratifs », sont listés les dysfonctionnements mais également des solutions pour bâtir une charte des valeurs de l’équipe de projet, savoir utiliser un espace e-collaboratif, tenir un tableau de bord et capitaliser les connaissances acquises tout au long du projet informatique.

Une conclusion en guise de bilan achève notre travail démarré un jour à l’IMI, un 19 mars 2008…

De copieuses mais nécessaires annexes complètent astucieusement cette base de connaissances. On y trouve les interviews de spécialistes du thème, des fiches mission, mais aussi les 39 cas de dysfonctionnements, avec leurs argumentaires, leurs causes et effets, les pistes de solutions et les facteurs clés de succès. Les comptes-rendus des 3 revues de projet, des normes et méthodes de développement pour projets informatiques ainsi que des recommandations pour réussir son projet informatique complètent la partie « Annexes ».

Un des buts fixés par le Directeur de l’IMI et Maître d’ouvrage était de « Vivre une expérience humaine commune pour enrichir ses démarches ultérieures dans son métier de demain ». Nous pensons avoir atteint ce but, ainsi que les autres.

Avant de découvrir les mille et un conseils de cette base de connaissances, l’équipe projet IMI38F tient à remercier Gérard Balantzian, pour le sujet qu’il nous a confié et pour son soutien sans faille tout au long du projet ainsi que pour l’invitation à l’IMI de Jacques Printz. Nous remercions nos coaches, Mélissa Saadoun et Jean Joskowicz pour leur totale implication dans le



projet. Ils nous ont aidés à bâtir et consolider cet édifice commun par leurs conseils sur les méthodes, la structure et le fond du document.



I – Pour une meilleure compréhension du sujet

I.1. Rappel du contexte

I.1.1. Contrôle commun IMI

Le Directeur de l’Institut du Management de l’Information (IMI) de l’Université de Compiègne, a mandaté les auditeurs de la promotion IMI38F pour conduire un projet dans le cadre du contrôle des connaissances des auditeurs. Ce premier contrôle des connaissances se fait sous la forme d’un contrôle commun, c'est-à-dire un travail réalisé et soutenu en commun par ces auditeurs.

Gérard Balantzian, en tant que Maître d’Ouvrage, a transmis aux auditeurs le cahier des charges provisoire (cf. annexe 1) du travail à réaliser du 19 mars au 27 juin 2008, jour de la soutenance du projet.

I.1.2. Objectifs généraux du contrôle commun

En tant qu’action enrichissante, le projet exige de l’équipe de projet, de travailler ensemble, d’œuvrer ensemble, pour réussir à fournir le produit et/ou service attendu par la maîtrise d’ouvrage (MOA). A cet effet, les objectifs généraux fixés par la MOA ont été formulés comme suit :

Passer à l’acte et partager des savoirs et des retours d’expérience d’entreprise autour d’un thème brûlant : Pathologies des projets informatiques.

Vivre une expérience humaine commune pour enrichir ses démarches ultérieures dans son métier de demain.

Utiliser les technologies collaboratives pour formaliser et capitaliser les travaux réalisés en commun.

Déposer dans les délais requis les résultats à l’IMI et enrichir son fonds commun de savoirs et savoir-faire.

I.1.3. Cerner les besoins et attentes de la MOA

S’étant réunie le 19 mars, le groupe IMI38F, encadré par Mélissa Saadoun (MS) et Jean Joskowicz (JJ), a pris connaissance du cahier des charges provisoire (voir annexe 1).



Après analyse, ajustements, les membres du groupe IMI38F et leurs 2 coaches MS et JJ, se sont mis d’accord pour formuler l’objectif du projet en ces termes :

Bâtir une base de connaissances des pathologies des projets informatiques

Cette base de connaissances sera supportée par des livrables demandés par la MOA :

1. Le rapport (format Word) avec pour chaque item (le projet dans sa totalité comporte 16 items) :

Constat des dysfonctionnements de l’entreprise de l’auditeur. Argumentaire expliquant ces dysfonctionnements. Pistes de solutions de progrès. Facteurs clés de succès (FCS).

2) Un jeu de diapositives (PowerPoint) de la soutenance du 27 juin.

3) Le Road book recommandé par la MOA qui est cependant facultatif et non évalué. Ce document relate le vécu du groupe tout au long du projet.

Les 2 premiers livrables doivent être déposés à l’IMI le 15 juin 2008.



I.2. Démarche et organisation du projet

I.2.1. Du cahier des charges provisoire au cahier des charges définitif

Dans le cahier des charges provisoire (annexe 1), le projet « Pathologies des projets informatiques » comporte 3 mini-projets :

Mini projet Tronc (travaux réalisés en commun autour du délégué de promotion, Jean-Luc Fiquet) : Démarche de Management Structuré de Projet :

1. Expression des besoins.2. Découpage en phases et panorama des outils.3. Phase de planification et gestion du temps.4. Phase de lancement.5. Phase de production.6. Phase de pilotage.

Mini projet 1 (sous-groupe 1 sous la responsabilité de Laurent Carette) : Management des équipes de projet :

1. Gestion de ses priorités.2. Gestion des priorités collectives.3. Management d’équipes de projet.4. Implication des utilisateurs.5. Soutien DG.

Mini-projet 2 (sous-groupe 2 sous la responsabilité de Fattah Abdessadak) : Management de projets e-collaboratifs :

1. Charte des valeurs de l’équipe de projet.2. Charte d’utilisation de l’espace e-collaboratif.3. Règles d’utilisation par équipe de projet de l’espace e-collaboratif.4. Tableaux de bord.5. Capitalisation des connaissances.

Ayant recueilli et analysé les besoins et attentes de la MOA, l’équipe de projet, a rédigé le cahier des charges à faire valider par la MOA (cf. annexe 2). Celui-ci a reçu la validation de la MOA le 31 mars 2008.

Le projet a donc été lancé le 31 mars puisque les 2 parties (MOA et MOE) étaient d’accord sur les termes du contrat.



I.2.2. Démarche permettant d’atteindre l’objectif du projet

Pour bâtir une base de « connaissances PPI » (pathologies des projets informatiques), l’équipe IMI38F, encadrée par ses 2 coaches, a œuvré pour réaliser le projet pouvant être illustré par la figure 1.

Figure 1 : Démarche de projet pour bâtir une base de connaissances PPI

Cette illustration reflète-t-elle la complexité du sujet, nos doutes et espoirs, nos craintes et enthousiasme, notre dynamique et inertie ?

Si la question nous avait été posée la 1ère quinzaine d’avril, nous aurions certainement répondu : sujet complexe et brûlant : par où commencer ?

Grâce à notre point fort : « la satisfaction du client (MOA) », le groupe IMI38F, encadré par les 2 coaches, s’est rapidement soudé autour de son chef de projet : Jean-Luc.

Le démarrage du projet était bien de la COHESION d’équipe. Il nous restait à acquérir de la COHERENCE, (méthodes, cadres de travail, techniques, moyens de communication mais aussi étapes de validation).



Ces 2 piliers de la matrice cohésion/cohérence ont fait naître une EQUIPE prête à relever tous les défis.

Le sujet « brûlant » pathologies des projets informatiques, était devenu accessible et le cahier des charges provisoire, s’est vite transformé en cahier des charges définitif. Du 19 mars, jour de démarrage du projet au 31 mars, 12 jours après, l’équipe IMI38F avait parfaitement compris et reformulé l’objectif fixé par la MOA.

Le compte à rebours avait alors commencé…

De la recherche d’information, aux sollicitations de spécialistes du sujet, en passant par la sensibilisation dans notre entreprise, l’information se dispersait comme une traînée de poudre, comme la voie lactée brillant dans le ciel.

Ces recherches, ces informations transformées en connaissances nous ont permis de rédiger le Cahier des Charges à faire valider par la MOA, en quelque sorte un contrat signé entre les 2 parties. Aussitôt ce contrat signé, tous les membres de l’équipe savaient quelles tâches leur incombaient.

Comme ces petits personnages sur le schéma, chacun s’y est attelé pour contribuer à construire cet ouvrage : connaissances des pathologies des projets informatiques. Aidés par des spécialistes du sujet, enrichis par nos propres lectures et expériences, recadrés par nos coaches, nous avions percé le mystère du sujet « brûlant »

Cependant, le temps, les responsabilités professionnelles et privées, la fatigue, le manque de compétences dans certains domaines, nous ont perturbés. Il fallait rassembler les troupes et régler la situation. Après échanges et discussions, chacun reprit son travail avec autant d’énergie et de force.

La construction du rapport, des annexes, de la base de connaissances, du road book, et bien d’autres travaux, commençaient à prendre forme.

15 juin 2008 : date pour déposer notre «ouvrage » ou « œuvre » (pourquoi pas les 2 ?) au maître d’ouvrage. Nous sommes dans les temps. Pouvions-nous faire autrement ? La réponse est NON.

Les matériaux, de cette construction commune, étaient la confiance et le respect mutuel. Ces 2 valeurs ont été notre ligne rouge à ne pas dépasser pour nous permettre d’avancer sereinement et atteindre l’objectif fixé par la MOA.

Décrire la démarche de notre projet, mieux qu’un simple schéma de démarche avec des termes techniques, cette expérience humaine nous a tout simplement donné l’inspiration pour relater fidèlement et naturellement « comment nous avions procédé pour vous fournir ce rapport et les autres livrables ».

I.2.3. Planning du projet

Pour atteindre les objectifs du projet, l’équipe IMI38F accompagnée par ses 2 coaches, a été amenée à structurer le projet en une série de tâches devant être planifiées et coordonnées avec le plus grand soin. Une fois la base du projet validée par MS+JJ, le planning initial (voir annexe 3) a vu le jour. Ce planning a permis de déterminer : ce qui doit être fait, qui doit le faire et à quel moment cela doit être fait.



Ainsi, l’équipe a pu :

Fixer les dates de début et de fin de projet : du 19 mars 2008 (cadrage de l’objectif avec les 2 coaches) au 27 juin 2008 (jour de la soutenance).

Définir les étapes de validation, c’est-à-dire, les jalons du projet (les 3 revues de projet, date de remise des livrables, soutenance, etc.).

Diviser le projet en éléments (mini-projet Tronc, MP1 et MP2) et en actions/opérations ou encore tâches.

Estimer le temps requis pour réaliser ces éléments.

Répartir le travail aux 6 ressources du projet (voir section I.2.5.)

Les plannings (version initiale et dernière version) sont en annexe 3.

I.2.4. Processus de validation du projet

Les revues de projet

Les étapes de validation du projet (jalons) ont été faites sous forme de 3 revues de projet (RP) fixées par Mélissa et Jean : RP1 le 14 avril, RP2 le 07 mai et RP3 le 05 juin. Ces RP ont eu lieu à l’IMI de 12h30 à 14h.

Le but de ces RP est de passer en revue ce qui a été fait, les contraintes, les risques, les prévisions, etc. A cet effet, avant chaque RP, l’équipe devait préparer un jeu de slides (05) pour présenter ce qui lui était demandé par les coaches. A l’issue de ces séances, un recadrage a été fait, des compléments ont été apportés, etc. Les comptes-rendus sont en annexe 5.

Les séances de travail en présentiel

Outre les trois revues de projet, deux séances de travail se sont tenues dans les locaux de l’IMI : séance 1 : 13 mai de 17h30 à 19h15 et la 2ème séance le, 05 juin de 13h à 14h.

Ces séances ne sont pas des étapes de validation (évaluation) mais bien des séances permettant d’avancer de concert avec les coaches qui sont ici des conseillers et non des évaluateurs. L’équipe IMI38F n’était pas chargée de préparer des présentations pour évaluer ce qui a été fait, le reste à faire, les difficultés, etc. mais de recalculer et/ou replanifier les charges de travail, compte tenu de l’échéance, opter pour tel ou tel autre choix des cas de dysfonctionnement, etc. Enfin, tout au long de la vie du projet, les 2 coaches ont été très réactifs et ont su recadrer les travaux. Ils ont également communiqué un ensemble de documents, venus enrichir la base de connaissances du projet.



I.2.5. Ressources du projet

L’équipe IMI38F comporte 6 membres :

Jean-Luc Fiquet, chef de projet Mini-projet MSP et Membre du sous-groupe 2.

Laurent Carette, Responsable du sous-groupe 1, mini-projet MEP.

Fattah Abdessadak, Responsable du sous-groupe 2, mini-projet MPeC.

Yvan Erard, Membre du sous-groupe 1.

Napoléon Djen, Membre du sous-groupe 1.

Pierre-Yves Arades, Membre du sous-groupe 2

Dans le mini-projet Management Structuré de Projet, tous les membres étaient membres contributeurs. L’équipe s’est répartie en 2 sous-groupes dans les 2 autres mini-projets. Cependant il est à noter que pour la production et l’analyse des cas de dysfonctionnement l’ensemble des membres de l’équipe a participé indépendamment des mini-projets.

Les fiches missions de chaque membre de l’équipe IMI38F sont jointes en annexe 6.

I.2.6. Moyens de communication

La communication, la coordination et la collaboration sont des facteurs clés de succès d’un projet quelle que soit sa taille et quels que soient ses enjeux. Ainsi, il a été proposé, dès le 19 mars à l’équipe IMI38F, de choisir une plate-forme collaborative entre l’intranet de l’IMI, le site de partage de l’information proposé par AX-NET (société de Jean-Luc) et BSCW (plate-forme collaborative gratuite de l’Union européenne). Après démonstration des 2 plates-formes : celle de AX-Net (par JL) et BSCW (par MS), l’équipe, à l’unanimité a opté pour BSCW.

Dès le 19 mars soir, les 6 membres de l’équipe IMI38F et JJ avaient chacun son identifiant et son mot de passe. MS avait également téléchargé sur BSCW, un tutorial pour faciliter la prise en main de cet espace collaboratif.

Un intervenant de l’IMI ayant proposé à l’équipe IMI38F d’héberger leurs travaux dans l’espace collaboratif eRoom, l’équipe a aussitôt accepté.

Après cette manifestation d’intérêt pour un autre espace collaboratif, MS a contacté la société EMC, propriétaire de eRoom (plate-forme payante), afin de bénéficier gratuitement des services de cette plate-forme. C’est alors que le 14 mai, un identifiant et un mot de passe ont été attribués à MS, qui les a aussitôt communiqués au chef de projet JL, l’invitant à accéder à eRoom et à en faire profiter les autres membres de l’équipe IMI38F.

Pour apporter d’autres éléments de comparaison de plates-formes e-collaboratives (pour le MP2), MS a contacté la société OODRIVE, propriétaire de l’espace e-collaboratif payant MAYETIC. Après discussion avec les dirigeants de OODRIVE, ceux-ci ont accepté de céder gratuitement un espace de 1024 MO ! Ainsi, depuis la mi-mai, l’équipe IMI38F et ses 2 coaches JJ et MS peuvent utiliser à leur convenance 3 plates-formes e-collaboratives : BSCW, eRoom et



MAYETIC, sans oublier la messagerie électronique, le téléphone et même l’intranet de l’IMI, qui était mis à la disposition de l’équipe !

Tous les moyens ont été déployés pour faciliter les 3C.

Cependant, la technologie pour faciliter les 3C n’est qu’un moyen et non une fin… En effet, la véritable valeur réside dans l’entente et la synergie entre tous les acteurs concernés et impliqués par le projet, c’est-à-dire, la MOA, les membres de l’équipe IMI38F et leurs 2 coaches.



I.3. Les fondamentaux du sujet

I.3.1. Un projet informatique et ses 3 dimensions

Un projet informatique doit être conduit en intégrant simultanément le management, l'organisation et l'informatique.

En effet, vouloir améliorer ou changer une entreprise (ou une des ses parties) exige d'agir sur ce qui la concrétise (sa stratégie, sa structure, ses produits…) et sur ce qui l'anime (ses valeurs partagées, ses compétences, ses règles…) et de considérer l'influence mutuelle de ces deux types de composantes qui sont intimement liés. Cela suppose d'avoir une vue globale de l'entreprise, même si le projet informatique ne semble devoir porter que sur une de ses parties.

Ainsi, il faut faire évoluer les valeurs et les comportements et les styles de management pour qu'ils soient en adéquation avec l'organisation et les technologies de l'information. Il faut également faire évoluer l'organisation. Celle-ci regroupe les processus dont la conception et l’efficacité opérationnelle conditionnent la performance de l’entreprise et la relation qu’elle veut entretenir avec ses clients, ainsi que les structures organisationnelles qui doivent favoriser la dynamique de l’entreprise, c’est-à-dire sa réactivité et sa flexibilité. Enfin, il faut faire évoluer l'informatique. Celle-ci regroupe tous les dispositifs matériels et immatériels permettant de transformer l’information en connaissances.

A cet effet, les dysfonctionnements sont rapportés en fonction de leurs causes et effets sur la dimension humaine (y compris managériale), la dimension organisationnelle et la dimension technique (et technologique).

I.3.2. La notion de dysfonctionnement

La notion de fonctionnement et inversement, de dysfonctionnement, d’un projet est liée à l’action. Les dysfonctionnements d’un projet informatique, ici dans notre étude, résident dans ce qui est fait (activités), par qui cela est fait (acteurs) et comment cela est fait (procédés ou procédures). Mais ces dysfonctionnements n’apparaissent souvent qu’au travers de conséquences ou symptômes, jamais ou rarement au travers de leurs causes profondes.

Les dysfonctionnements qui sont relevés au cours de ce long travail, se situent généralement à plusieurs niveaux et concernent toujours plusieurs variables humaines, organisationnelles et techniques voire technologiques. Ces dysfonctionnements se situent :

Au niveau des activités (par exemple, passage du franc à l’euro).

Au niveau des flux d’activités (par exemple, développement d’un progiciel de gestion hôtelière).

Au niveau des interfaces entre activités (par exemple, relation MOA-MOE).

Cette réflexion conduit tout naturellement à définir un cycle de relations MOA-MOE (relation de type client-fournisseur) prenant en compte toutes les informations recueillies auprès des clients MOA, (comité d’utilisateurs, par exemple) pour assurer le bon fonctionnement du système. En effet, ce qui entre dans le système (le projet informatique) provient d’un autre



système. Ce qui en sort, permet d’alimenter un autre système. Chaque système a donc ses propres caractéristiques et exigences en fonction de la mission qu’il assume dans un réseau de clients et de fournisseurs.

Le questionnaire qui a été utilisé pour identifier les 39 dysfonctionnements est en annexe 8. Les dysfonctionnements identifiés, analysés ainsi que des facteurs clés de succès qui ont été formulés sont en annexe 9.

I.3.3. Les facteurs clés de succès

Les facteurs clés de succès (FCS) expriment en termes qualitatifs et quantitatifs, le résultat des différentes activités d'un projet informatique en fonction d'un objectif donné. Ils indiquent à chaque individu où il se situe par rapport au groupe. Ils véhiculent dans toute l'entreprise des informations essentielles : la stratégie définie par la direction, qu'ils communiquent à la base, les résultats des activités, qui remontent des niveaux inférieurs jusqu'au sommet et l'effet des contrôles et des améliorations au sein du processus.

Force est de constater que la majorité des dirigeants consacrent beaucoup de temps à énoncer la mission de leur entreprise, mais sont souvent distraits de la tâche qui consiste à définir un ensemble de facteurs clés de succès. Pourquoi ? Parce que développer de telles mesures est difficile car il faut tenir compte des intérêts de toutes les parties concernées, comprendre la mentalité et comportements des clients (internes et externes) et ce qu'ils attendent, identifier tous les processus au sein de l'entreprise, etc. Tout ceci, ne peut se faire en un week-end réunissant l'équipe dirigeante !

I.3.4. Processus de capitalisation

Un chapitre « Capitalisation des connaissances » clôture la partie de chacun des 3 mini-projets.

Capitaliser les connaissances, c'est considérer certaines connaissances utilisées et produites par le groupe IMI38F comme un ensemble de richesses et en tirer des intérêts contribuant à augmenter son capital et celui des personnes qui seraient susceptibles de se référer à notre rapport.

Même si la création de connaissances est inhérente à notre groupe IMI38F et finalisée dans ce rapport celui-ci répond au premier des trois objectifs généralement attribués au management des connaissances : créer, partager, capitaliser.

Les deux autres objectifs sont tout aussi fondamentaux et participent à relancer un nouveau cycle de création de connaissances, tout en constituant les bases propres de l’entreprise.

La capitalisation des connaissances issues de notre projet a donc pour objectif de mettre à disposition l'expérience du groupe IMI38F qui y a participé, constituant ainsi un réservoir de ressources et d'idées tant pour ceux qui y ont participé et qui se remémorent l'intérêt de certaines situations que pour les autres qui peuvent trouver là des réponses pour l'exploration de nouvelles pistes de recherche.



II – Le Management Structuré de Projet

II.1. Rappel des 6 items du MSPDans une première partie, l’étude va porter sur les différentes phases d’un Management Structuré de Projet (MSP). En parallèle des phases du MSP, d’autres équipes travaillent autour du projet à sa bonne réalisation. On trouve ainsi des équipes chargées de :

La communication auprès du métier du projet.

La formation des utilisateurs et de la documentation.

La préparation de la production, du site pilote et du déploiement.

La préparation du support utilisateurs.

Ces missions ne sont pas étudiées dans ce rapport.

II.1.1. Expression des besoins

Avant de lancer un projet de développement d’une solution informatique, l’entreprise aura fait au préalable une étude en détail de l’opportunité, de la faisabilité et de la rentabilité. Le projet étant décidé, il faut maintenant mettre en évidence ce que le métier attend de cette nouvelle solution informatique.

L’expression correcte des besoins constitue un préalable essentiel pour la réussite de tout projet. Elle consiste en l’élaboration d’un cahier des charges qui doit être le reflet de la demande de la maîtrise d’ouvrage (MOA). Celle-ci est constituée des gens du métier représentés par les utilisateurs finaux, les organisateurs et les experts du métier. Dans certaines organisations, il existe une équipe d’assistance à la MOA qui a la double connaissance du métier et des techniques informatiques. Cette équipe aide et accompagne les utilisateurs dans leurs demandes afin que l’expression des besoins soit la plus précise et complète possible pour les équipes de la maîtrise d’œuvre (MOE).

Ce cahier des charges ou cette analyse des besoins est ensuite transmis au chef de projet qui va mettre en œuvre une organisation pour livrer ce produit. Sa démarche doit utiliser le MSP.

II.1.2. Découpage en phases et panorama des outils

Le Management Structuré de Projet (MSP) donne au chef de projet une méthode pour préciser ses objectifs, planifier le déroulement du projet et le réaliser dans les délais. Pour cela, le MSP



découpe le projet en 4 phases : phases de planification, de lancement, de production et de pilotage.

Il existe différents outils pour aider à gérer le projet dont les techniques d’estimation des charges :

COCOMO : Cette méthode permet d’estimer la charge de travail à fournir pour développer un logiciel et la ressource nécessaire en homme. Cette méthode s’appuie sur des modèles statistiques auxquelles on applique ensuite des calculs en fonction du degré de complexité du logiciel à livrer.

Points de fonction : Cette méthode permet également d’estimer la charge de travail d’un projet de développement d’un logiciel. Cette méthode s’appuie sur la mesure des interactions (entrée, sortie, calcul, interrogation, consultation…) faite par des utilisateurs sur l’application demandée.

Il existe aussi des logiciels de gestion de projet dont :

Microsoft Project : Ce logiciel permet de planifier l’ensemble du projet .Il fournit le réseau PERT, le diagramme de Gantt et d’autres tableaux de bord de gestion du projet.

Ganttproject : Ce logiciel open source, développé par l’Université de Marne La Vallée, fournit les mêmes fonctionnalités que MS Project.

Il existe également de nombreux autres logiciels de gestion de projet tels que Open Workbench, openproj, PSNext, Taskjuggler, Primavera, Planview, Visual project.

Le chef de projet peut aussi utiliser des normes de fait, parmi lesquelles:

CCMI : méthode de certification des processus de gestion d’un système d’information qui contient un niveau de gestion de projet.

Prince2 : méthode de certification de gestion de projet. Cette norme, mondialement reconnue, permet de certifier des projets et également des chefs de projet.

Pour plus d’informations, voir Annexe 7.

II.1.3. Phase de planification et gestion du temps

La phase de planification assure en premier lieu le dialogue entre MOE et la MOA. Elle fournit l’occasion de valider les objectifs réels de cette dernière et de s’assurer que toutes les tâches à réaliser sont bien prises en compte et affectées à un responsable. Cette phase amène alors le chef de projet à réaliser une simulation complète du déroulement du projet. Cette simulation est la partie la plus délicate. Il n’existe pas de méthode universelle pour estimer la charge de travail et les délais de réalisation. Le chef de projet décompose le projet en activité puis ordonne l’ensemble des activités en mission. Cette étape est formalisée sous la forme d’un schéma réseau PERT (Project Evaluation and Review Technique). Ensuite le diagramme de Gantt permet de visualiser l’ensemble des missions entre elles dans le planning du projet. En fonction de la taille du projet, le chef de projet peut décomposer le projet en sous-projets ou modules afin de mieux le maîtriser.

Le chef de projet propose ensuite cette simulation à sa hiérarchie, puis au maître d’ouvrage, afin d’obtenir leurs accords sur les moyens, ressources et délais dont il doit disposer pour mener à



bien son projet. La dernière étape clé de cette phase consiste à qualifier l’équipe nécessaire au projet. Le chef de projet définit en fonction de ses besoins en compétences techniques, les profils des membres de sa future équipe. Le chef de projet élabore également toutes les règles nécessaires au management et au fonctionnement de son équipe et la communication au sein de son organisation.

II.1.4. Phase de lancement

Durant cette phase, le chef de projet devient un manager à part entière de son projet. Il recrute les membres de son équipe en fonction des qualités techniques et humaines nécessaires à la réussite de son projet. Il ne s’agit pas d’avoir une somme d’individualités mais de construire une équipe. Chaque membre de l’équipe doit être solidaire des autres afin d’atteindre ensemble le même objectif qui est la réalisation du projet. Chaque membre doit connaître précisément sa mission qui s’inscrit dans le planning global du projet et maîtriser les outils et méthodes utilisés pour le projet. Si nécessaire, les membres de l’équipe suivent des formations complémentaires. L’équipe doit être la plus performante possible et avoir à sa disposition tous les moyens (outils, locaux, conditions de travail) nécessaires à la réussite du projet.

II.1.5. Phase de production

Durant cette phase, le projet prend décrit son cycle de développement. L’équipe développe et transforme le cahier des charges en une réalité de plus en plus perceptible et concrète. Le chef de projet contrôle régulièrement selon le planning validé, la bonne production de l’équipe. Des contrôles qualités valident chaque stade de développement. Le chef de projet formalise l’ensemble de la production, les tests, les comptes-rendus d’avancement. Si des écarts dans les délais ou la qualité, sont constatés, il faut réactualiser les délais ou refaire les développements. Les coûts sont contrôlés et éventuellement ré-estimés.

Si les développements sont planifiés en modules et en lots, ceux-ci sont livrés au fur à mesure à la maîtrise d’ouvrage pour valider les fonctionnalités en déroulant des scénarios tests. Durant cette phase, la communication avec le comité de pilotage ou la maîtrise d’ouvrage est permanente.

II.1.6. Phase de pilotage

Cette phase se déroule en parallèle des autres phases. Après avoir collecté toutes les informations (planning individuel, charge de travail, fiche de recette), le chef de projet réactualise le tableau de bord. Il doit mettre en valeur les dérives éventuelles (charges, délais, qualités…) du projet.

Il convient donc de corriger régulièrement les dérives constatées. Certaines dérives devront parfois nécessiter la mise en œuvre de solution plus radicale : revoir les objectifs, revoir les ressources. Le chef de projet doit avoir une communication permanente, claire et transparente avec la MOA et/ou le comité de pilotage. Il est important d’avoir dans ce comité un représentant de la Direction générale. Ce représentant est l’interface humaine entre le projet et la direction générale. Il doit remonter toutes les informations sur l’avancement du projet. Il doit avoir



autorité pour valider les éventuels aménagements découlant des retards, des dépassements de coûts, etc.

A l’issu du projet, le chef de projet établit un dossier de bilan du projet qui notifiera et expliquera en détail toutes les réalisations et l’organisation du projet. Ce dossier doit pouvoir servir de base de connaissance pour d’autres projets. Il est également important de faire le point individuellement et collectivement sur la gestion de ce projet.

Dans les chapitres suivants (y compris pour les parties 3 et 4), nous avons rapporté des cas de dysfonctionnements qui nous ont paru les plus fréquents et donc les plus maîtrisables. Ces cas de dysfonctionnements sont analysés et un argumentaire avec les causes et effets de ces dysfonctionnements y est dressé. Des solutions de progrès ainsi que des facteurs clés de succès complètent chaque analyse de cas.

Cette méthode a été appliquée aux 39 cas recensés auprès des 6 entreprises des membres de l’équipe IMI38F. Ce sont donc des cas de dysfonctionnements réels.

Enfin, pour les autres cas dysfonctionnements, se reporter à l’annexe 9.



II.2. Expression de besoins

II.2.1. Constat des dysfonctionnements

C02 : MOA/MOE : Sélection d’un progiciel de gestion hôtelière

Contexte : solution non conforme aux besoins « métier » des hôtels français dans un groupe international.

II.2.2. Argumentaire expliquant ces dysfonctionnements

En 2004, un groupe hôtelier international décide de changer son progiciel de gestion hôtelière des hôtels français. Le produit, développé dans les années 1980, est techniquement obsolète et ne permet plus d’évoluer rapidement. Après une rapide présentation à un panel d’hôteliers, il est décidé de choisir le progiciel déjà installé en Allemagne. Sans autre forme d’analyse des fonctionnalités et des besoins du métier, un site pilote français est installé en 2005.

Durant les formations, les utilisateurs constatent des manques de rapports de contrôles internes, des fonctionnalités métiers manquantes, une comptabilité client non conforme à l’organisation des hôtels en France. Après la mise en production du progiciel dans l’hôtel, les manques et anomalies apparaissent plus flagrants. Cela provoque des erreurs dans les contrôles de gestion et perturbe l’organisation de l’hôtel. Des tâches de contrôles manuels doivent être mises en place.

Les causes identifiées sont :

Technique : Le progiciel a été conçu en fonction de certaines règles métiers qui ne sont pas celles des hôtels français. Son fonctionnement ne correspond donc pas au besoin des hôtels.

Humaine : La sélection de ce progiciel n’a pas été validée par un groupe d’hôteliers experts qui aurait pu contrôler l’ensemble des fonctionnalités.

Les effets sont :

Humain : Les équipes de l’hôtel pilote ont été démotivées et ne se sont donc pas investies dans le suivi du projet.

Organisationnel : Il a été nécessaire de revoir les procédures de contrôle dans l’hôtel et surtout d’en créer de nouvelles. Cela a engendré une charge de travail quotidienne supplémentaire. Il a fallu également créer un comité utilisateurs afin de faire remonter les anomalies et manques et activer un groupe de travail avec l’éditeur pour faire évoluer ce progiciel. Cette charge de travail n’était pas budgétée.

II.2.3. Pistes de solutions de progrès

Après quelques mois, le groupe de travail et le comité utilisateurs ont validé 200 évolutions à mettre en œuvre par le concepteur du progiciel. Une nouvelle version répondant aux besoins de l’hôtel a été développée.



II.2.4. Facteurs clés de succès

Il est important de considérer qu’une solution informatique doit être validée par les utilisateurs finaux avant tout achat ou développement. De plus, dans un Groupe international, un progiciel doit toujours être validé en fonction des règles spécifiques à une organisation ou un pays.



II.3. Découpage en phases et panorama des outils


C06 : DG/MOA – Une mauvaise équation économique dans un environnement de revente indirecte a des conséquences techniques importantes

Contexte : mauvaise anticipation de l'évolution des coûts de licences base de données relationnelle dans une PME.


Dans les années 1995-1997, dans le cadre d’un nouveau développement d’un progiciel de gestion intégré (PGI) d’un développement majeur pour l’éditeur (PME), l’alternative suivante s’est posée :

Peut-on utiliser une base de données relationnelle pour le développement du nouveau progiciel ? Ceci suppose des coûts supplémentaires de licences pour chaque utilisateur (1800 FRF soit 275 EUR par utilisateur).

Doit-on rester avec un gestionnaire de fichiers, type séquentiel indexé, comme par exemple Access, qui n’engage pas de surcoût par utilisateur ?

L’équation économique d’un éditeur de progiciels de gestion fonctionnant en indirect via un réseau de grossistes et de revendeurs était du type :

Prix de vente client final = prix d’achat revendeur + marge revendeur (38%)

Prix d’achat revendeur = prix de achat grossiste + marge grossiste (38%)

Prix d’achat grossiste = prix de revient éditeur + marge éditeur

Ainsi pour un prix de vente client final de 100 le chiffre d’affaires restant à l’éditeur n’était que de 38 environ soit 62% de remise globale. Or la part restant à l’éditeur se décompose ainsi :

Prix de revient éditeur = coûts fixes (salaires, loyers…) + coûts variables (ceux engagés pour chaque vente = licences, publicité, conditionnement, expédition…)

Il est évident que dans ce schéma, toute augmentation des coûts (C) a pour conséquence soit une hausse du prix client final de 1,6 x C, soit une diminution de la marge éditeur.

Compte tenu du système de cascade de marge et du positionnement produit/client, la direction générale a décidé que le surcoût lié à l’utilisation d’une base de données relationnelle était trop important. La MOA a imposé un développement SQL pour se ménager un recours ultérieur à une base de données relationnelle. La MOE a développé suivant les recommandations, mais rapidement de gros problèmes de performance sont apparus : le traitement des ordres SQL par un gestionnaire de fichier de type Access n’était pas assez performant, il fallait réagir.

La MOA et la DG n’ont pas su anticiper l’évolution des tarifs des licences base de données relationnelle : 18 mois plus tard, le coût des licences utilisateurs pour l’usage d’une base de données relationnelle s’effondrait !



La cause identifiée :

Managériale : La MOA a imposé une solution technique pour un motif économique qui allait s’avérer inconsistant à terme (mauvaise anticipation). La MOE a accepté un développement dans des conditions de performance insuffisante, elle aurait du refuser.

Les effets :

Organisationnel : Des ressources importantes ont été consacrées à optimiser la solution. De plus, les limitations du gestionnaire de fichier n’ont pas permis d’adresser commercialement les entreprises ayant de gros volumes.

Technique : La solution technique adoptée a généré d’autres problèmes, tels que les accès concurrents en réseau. L’usage d’une base de données relationnelle n’aurait pas engendré ces dysfonctionnements.


Face à l’inefficacité de traitement des ordres SQL de lecture (SELECT), la MOE a conçu et développé une couche d’analyse et d’interprétation des ordres SQL et réécrit ces ordres. Ces travaux ont permis d’améliorer la performance du progiciel de façon spectaculaire (gain d’un facteur 10). Ils ont cependant coûté cher en temps de développement et généré un retard de livraison du projet.


Face au développement d’un progiciel nouveau, durable et majeur pour l’entreprise, il faut :

Veiller à faire les bons choix technologiques.

Essayer d’anticiper les tendances.

Envisager, s’il le faut, d’adapter le modèle économique de l’entreprise aux offres technologiques du marché.



II.4. Phase de planification et gestion du temps


C11 : MOA/MOE – Emploi de mêmes ressources en parallèle sur deux projets

Contexte : mauvaise anticipation des tâches de maintenance dans le cadre d’une sortie commerciale prématurée, dans une PME.


Le développement de progiciel répond le plus souvent au cycle suivant :

Développement de la version 1.0.

Qualification (tests) et correction de la version 1.0.

Sortie de la 1ère version commerciale 1.x à une date donnée (le plus souvent imposée par des préoccupations commerciales).

Maintenance version 1.x.

Développement de fonctionnalités supplémentaires, réglementaires et optimisations dans des versions commerciales successives.

Dans les années 1996-1998, dans le cadre du développement d’un nouveau progiciel comptable et financier, le recrutement d’une équipe de développement roumaine a été nécessaire. La formation des équipes à l’environnement de développement objet et au mode de fonctionnement avec la MOA a été progressivement réalisée. Durant 18 mois les équipes roumaine et française ont co-développé la version 1.0 du progiciel. Les campagnes de qualification (tests) ont été réalisées en phase avec les équipes MOE qui corrigeaient quasiment en temps réel les bogues signalés.

Sous la pression des clients, une 1ère version commerciale du progiciel a vu le jour à une date commercialement intéressante imposée par la DG. Au même moment l’annonce de la date de sortie de la version 2.0, fonctionnellement plus complète, a été faite.

La MOA a établi le planning de développement du fonctionnel manquant pour la version 2.0 en sous-estimant la phase inéluctable de maintenance liée au lancement d’un nouveau progiciel.

Le succès relativement important du nouveau produit a amené son lot de maintenance qui a largement dépassé les capacités optimistes prévues. Les équipes de développement et de qualification se sont retrouvées en charge de 2 projets antagonistes :

Corriger, qualifier et sortir une version corrective 1.y indispensable dans le cadre de la maintenance.

Développer, qualifier et sortir une version 2.0 fonctionnellement et commercialement indispensable.




Organisationnelle : Sortie prématurée de la 1ère version. Mauvaise estimation de l’effort de maintenance. Annonce prématurée d’une date de sortie de la version 2.0.

Les effets :

Humain : La pression sur les équipes de développement et de qualification sur les 2 projets n’a pas été propice à un travail serein.

Organisationnel : La sortie de la version corrective a été retardée par la version 2.0 et vice et versa. Résultat : la clientèle en attente d’une version corrective et celle en attente d’une nouvelle version ont été mécontentes.


Au bout de quelques semaines MOA et MOE ont décidé d’une pause dans le développement de la version 2.0 et d’une concentration totale de l’entreprise sur la sortie de la version corrective.


La détermination de la date de sortie d’un nouveau produit est un acte commercial important qui est du ressort de la DG. Il convient donc de :

Ne pas annoncer publiquement une date de sortie trop prématurée : il faut se réserver des marges.

Ne pas affecter à une équipe deux projets en parallèle.

Il est important de ne pas sous-estimer :

L’effort nécessaire de maintenance d’un nouveau produit (accru par une sortie prématurée) qui mobilisera des équipes de développement et de qualification au détriment éventuel des évolutions fonctionnelles du produit.

L’impact commercial négatif lié aux retards des versions correctives et/ou évolutives.



II.5. Phase de lancement


C12 : MOE : Mauvaise sélection de l'atelier de développement

Contexte : phase insuffisante de sélection de l’atelier de développement, dans une PME.


Période concernée : novembre 1995- avril 1996.

A cette période, l’entreprise éditrice de progiciels de gestion disposait de 3 produits fonctionnant dans l’environnement MS-DOS et en réseau (configurations allant de 2 à 40 postes) : un progiciel comptable, un progiciel financier et un progiciel de gestion commerciale. Le gestionnaire de fichiers (séquentiel indexé) était d’origine « maison » et donnait toute satisfaction. Ces 3 logiciels étaient modulables, géraient les droits utilisateurs ainsi que des niveaux de fonctionnalités. Ils disposaient d’une interface fenêtrée mais en mode caractères. Les 3 produits s’étaient vendus à plusieurs milliers d’exemplaires et constituaient l’aboutissement de 12 années de travail et d’évolution.

Mais en cette fin d’année 1995, le système d’exploitation Windows 95 tant attendu de Microsoft, sort enfin. L’interface graphique est « révolutionnaire » et il s’agit d’un système 32 bits. Depuis le 7 février 1992 le Traité de Maastricht prévoit l’instauration d’une monnaie unique, au plus tard le 1er janvier 1999, mais c’est aussi en 1995 que le conseil européen de Madrid adopte le nom de la future monnaie (Euro) et les modalités de passage à l'Euro.

L’avènement de l’Euro et de Windows 95 conduisit l’entreprise à décider d’une réécriture complète d’un progiciel de gestion intégré 32 bits en mode graphique qui couvrirait fonctionnellement les 3 produits existants en prenant en compte complètement l’Euro.

Durant la phase de lancement du projet, en parallèle des études, la MOE se charge de la sélection d’un nouvel atelier de développement graphique, 32 bits et orienté objet. Une sélection d’ateliers du marché est faite, elle aboutit à retenir l’atelier de développement n°1 en France. Ce choix a été réalisé pour plusieurs raisons : proximité de l’éditeur de l’atelier, complétude de la solution, facilité d’utilisation et notoriété (en France) de la solution.

Progressivement toute l’équipe MOE est formée.

Au bout de quelques mois de développement et de mise au point du « framework » applicatif, il s’avère que l’environnement choisi ne donne pas satisfaction. Pire, certaines limites de l’atelier sont déjà atteintes et de gros problèmes de performance inhérents à la conception même de l’atelier apparaissent. La direction et toute l’équipe MOE sont dans une impasse, le projet risque d’être remis en cause si une nouvelle version de l’atelier de développement ne voit pas le jour rapidement.



Les causes identifiées :

Technique : La phase de sélection de l’atelier de développement n’a pas été assez poussée et n’a pas permis de voir les limites du produit (MOE). La facilité d’utilisation, la complétude et la notoriété de l’atelier ainsi que la promesse d’une nouvelle version imminente (finalement longuement retardée) mais aussi l’absence d’atelier concurrent à la hauteur ont finalement eu raison des hésitations et emporté le choix final.

Les effets :

Humain : Les soucis sur l’atelier ont été mal perçus par l’équipe de développement ce qui a engendré une démotivation générale durant cette période.

Organisationnel : Temps perdu : la formation au nouvel atelier ainsi que l’ensemble des travaux réalisés pour le framework ont dû être refaits.


Après de multiples tentatives avec l’éditeur de l’atelier de développement initial, aucune solution n’a été trouvée.

Vers le mois de mars 1996, un nouvel atelier américain totalement orienté objet, bien conçu et très performant a vu le jour. Après des tests approfondis la MOE a pu convaincre la DG de faire le grand saut : le changement d’atelier. L’entreprise ne pouvait se permettre un échec sur ce projet essentiel à son activité et qui allait représenter 120 années-homme d’études et de développement.


Dans un contexte technologique changeant (ici interface graphique 32 bits, développement objet…), la sélection d’un nouvel atelier de développement est essentielle.

Il convient de :

Prendre le temps nécessaire à la sélection de l’atelier.

Valider l’atelier si possible sur un projet réel de taille moyenne et non sur un projet colossal et vital pour l’entreprise.

Opter pour l’adage « Voir global, agir local ».

Le cas échéant, savoir remettre en cause la sélection faite si l’effort d’adaptation reste mesuré par rapport au reste du projet.



II.6. Phase de production


C14 : MOA/MOE : Difficulté à exprimer sa non compréhension dans un environnement délocalisé

Contexte : qualité de production irrégulière d’un développeur et non en phase avec les spécifications, dans une PME.


Période concernée : 1997.

Depuis le début 1996, l’entreprise éditrice de progiciels de gestion s’est lancée dans le développement d’un projet essentiel pour son activité : la refonte complète de 3 progiciels existants en un seul intégré (PGI) prenant pleinement en compte la gestion de l’Euro. 120 années hommes d’étude et de développement représentaient un investissement totalement impossible à supporter par l’entreprise.

Une seule solution possible, en avance sur son temps, par rapport à ce que nous connaissons aujourd’hui : la délocalisation. Après une tentative avec le Maghreb qui n’a pas abouti (à l’époque essentiellement pour cause du niveau d’étude en informatique des candidats) le hasard a voulu que l’entreprise recrute en Roumanie. Cette fois le niveau universitaire était élevé, les premières personnes recrutées parlaient toutes français plus ou moins bien. La formation aux outils de développements et aux analyses en provenance de la MOA fut faite et les développements informatiques furent lancés. L’équipe roumaine travaillait bien. Rapidement elle grossit pour arriver à une douzaine de développeurs. Parmi les développeurs roumains, on s’aperçut vite qu’une personne ne suivait pas le rythme : son travail était de qualité mais ne correspondait pas toujours aux spécifications exprimées dans les documents d’analyse. Lorsque nous lui demandions si elle avait bien compris ce que nous attendions d’elle, elle répondait oui.

Compte tenu de l’éloignement et de la langue il n’était pas toujours facile de pouvoir se comprendre facilement par téléphone dont la liaison était de mauvaise qualité à cette époque avec la Roumanie. Par ailleurs, par souci de cohésion et d’efficacité, il est rapidement apparu indispensable d’être présent sur place en Roumanie le plus souvent possible pour :

Expliquer les analyses aux intéressés

Suivre les développements

Motiver l’équipe

Une fois sur place la discussion avec les développeurs était la plus part du temps efficace sauf avec cette personne qui persistait à dire qu’elle avait bien compris les explications données. Le face-à-face loin d’arranger les choses l’impressionnait encore plus.



Se présentait à nous l’alternative suivante :

Fallait-il nous séparer de cette personne sans comprendre ce qui se passait ?

Prendre le temps de nouer des relations de confiance et essayer de comprendre ?


Humaine : Une personne de l’équipe n’ose visiblement pas dire qu’elle ne comprend pas certains développements qui lui sont confiés.

Les effets :

Humain : La personne impliquée est mal à l’aise ainsi que ses managers qui perdent confiance en elle.

Organisationnel : Certains développements ne sont pas réalisés comme il faudrait et doivent être revus.


Il a été décidé de faire le maximum pour accompagner la personne en cause. Présence physique d’un manager à son bureau pour travailler à côté d’elle afin de l’inciter à poser toutes les questions qu’elle souhaitait. Organisation de quelques manifestations communes extra professionnelles (restaurants ou autres sorties). Petit à petit la confiance a pu s’établir et les bonnes questions ont pu enfin être posées au bon moment et tout est rentré dans l’ordre au niveau de la qualité de sa production. En réalité cette personne n’osait pas dire qu’elle ne comprenait pas. Pire elle n’osait pas non plus poser les questions qui lui auraient permis de comprendre.


La gestion de projet met en jeu une dimension humaine primordiale pour sa réussite. Trop souvent cette dimension est sous-estimée. En face d’une difficulté évidente de communication, il est important de :

Pratiquer l’écoute active et la reformulation.

Prendre le temps de nouer des relations de confiance.



II.7. Phase de pilotage


C18 : MOA/MOE : Autocensure du comité de pilotage pour ne pas contrarier les décisions de la DG

Contexte : la date demandée de l’installation du premier site pilote n’a pas été respectée, dans un Groupe international.



Pour faire remonter les anomalies et les manques, il est créé un comité utilisateurs et un groupe de travail est activé avec le constructeur pour faire évoluer le progiciel.

En attendant cette nouvelle version, La DG décide d’arrêter le déploiement du progiciel dans les hôtels. En 2 mois, le groupe de travail et le comité utilisateurs valident 200 évolutions à mettre en œuvre par le constructeur. Une nouvelle version répondant aux besoins de l’hôtel doit être développé en 4 mois. Le développement est découpé en modules. Certains développements prennent du retard. Toutefois, la DG maintient la date d’installation du deuxième site pilote.

Lors du comité de pilotage à J-45 qui doit valider la date de l’installation, l’ensemble des responsables des équipes projets (développements, recette, formation, installation, etc.) reconnaît que tout n’est pas maîtrisé. Cependant, le comité afin de ne pas contrarier la décision de la DG, maintient cette date. Finalement, le déploiement sera annulé 2 semaines avant la date démarrage.


Humaine : La pression sur l’équipe projet de la part des opérations est importante. Le comité de pilotage ne veut pas contrarier le choix des dates demandées par la DG.

Les effets :

Humain : L’équipe de l’hôtel qui devait faire le pilote a été prévenue au dernier moment. Cette équipe n’a plus eu confiance dans le projet et n’était plus motivée pour s’y investir.

Organisationnel et technique : Les développements ont continué, mais pour respecter les délais, les fonctionnalités ont été dégradées et les tests bâclés.


Le comité de pilotage a quand même annoncé que les délais n’étaient pas respectés et a présenté des risques encourus lors du démarrage dans l’hôtel.



Le chef de projet a du revoir sa planification dans l’urgence en se donnant de nouvelles priorités de développement.


Le comité de pilotage doit obligatoirement inclure un membre de la Direction Générale. Sa présence doit permettre une communication claire, transparente et directe qui facilite la prise de décision.

La parole doit être suffisamment libre au sein de ce comité pour que de vrais problèmes soient évoqués et qu’il ne s’agisse pas d’un comité « Théodule » pour faire plaisir à la DG.

Le comité de pilotage doit avoir une autorité suffisante pour faire valoir son point de vue.



II.8. Capitalisation des connaissances du MSPA partir des différents dysfonctionnements recensés et de la collecte d’un certain nombre d’informations dans la littérature, nous avons pu établir un cadre assez précis de la bonne conduite de projet, dans sa dimension temporelle, au travers des grandes phases opérationnelles de la conduite de projet.

Ce paragraphe recense les pratiques qui nous ont semblé les plus pertinentes et qui nous paraissent garantir la bonne marche d’un projet.

Tout d’abord, nous avons identifié que la phase d’analyse des besoins est une phase particulièrement critique car elle est à l’initiative de la mise en œuvre du projet. Ainsi, une erreur de perception peut fortement impacter la position du point d’arrivée. Durant cette phase, il est nécessaire de bien identifier ce que Francis Odier appelle les « besoins perçus », qui correspondent à ce que l’utilisateur attend, généralement un service. Le projet lui fournit un produit qui doit rendre ce service. Le besoin perçu correspond généralement au besoin exprimé par le client, auquel s’ajoute le besoin implicite.

Besoins exprimés Besoins

retenus Besoins spécifiés Besoins

réalisés

Besoins perçus

Sur-qualité Produitlivré

Sous-qualité

Produitattendu

A chaque A chaque éétape, tape, ééviter les surviter les sur--qualitqualitéé et les souset les sous--qualitqualitéé

Figure 2 : Qualité et satisfaction des besoins selon Francis Odier

La capacité de l’équipe de projet à impliquer des utilisateurs finaux est une bonne garantie de succès de cette phase. Dans certains cas, cette tâche de définition des besoins peut être confiée à une maîtrise d’ouvrage déléguée. Généralement, l’analyse des processus existants ou des processus cibles permet aux utilisateurs de valider les orientations retenues.

Pour le découpage en phases, la méthode d’estimation semble être un élément majeur. En effet, c’est à partir de cette estimation que délais et ressources pourront être quantifiés. Suivant le type de projet, différentes méthodes existent, mais c’est dans les projets de développement informatique que ces outils sont les plus matures (COCOMO, points de fonction, par exemple).



Dresser le panorama des outils et arbitrer sur leur utilisation ou non est extrêmement impactant pour le projet. Comme le montre le cas décrit en II.3.1, l’équilibre économique global d’un projet peut être mis en jeu par les choix technologiques effectués. Pour limiter les risques liés à cette phase, il est essentiel d’effectuer les bons choix. Pour cela, il est important qu’une ressource technique de très bon niveau soit intégrée, même ponctuellement, sur le projet pour valider les choix d’architecture et de composants techniques (cf. cas C26 de l’annexe 8). De plus, le choix des outils peut être lié à des contraintes économiques (coût de licence) ou stratégiques (obligation d’utiliser une technologie promue par le groupe, modalités sur les royalties), ce qui exige d’intégrer très tôt la Direction des achats dans la démarche projet. En effet, choix stratégiques et choix techniques sont intimement liés.

La phase de planification d’un projet est également une source de dérive importante si elle n’est pas maîtrisée. Elle doit permettre de rythmer le projet et de donner une visibilité suffisante aux acteurs extérieurs. Ainsi, une des solutions est de disposer en parallèle de deux plannings stratégiques :

Le planning de l’équipe, réaliste et au plus proche de l’activité, partagé par les membres de l’équipe et le sponsor. Ce planning doit être très détaillé et permettre un suivi très fin de l’activité de chacun des collaborateurs du projet.

Le planning « commercial », de communication avec les utilisateurs et les instances externes. Ce planning représente les principales phases du projet et les jalons associés pour permettre une communication « macro » de l’avancement du projet. Ce dernier doit prendre en compte des marges de sécurité liées aux incertitudes du projet.

Ceci permet de laisser à l’équipe des marges de manœuvre vis-à-vis de ses clients, internes ou externes. Pour permettre une utilisation des ressources conforme aux prévisions, cela nécessite de prendre les précautions nécessaires dans la gestion des priorités individuelles et collectives comme cela sera évoqué dans le chapitre III.

Dans la phase de lancement, il est nécessaire de valider très rapidement un certain nombre d’options pour permettre un démarrage rapide de l’activité. Sur la base du travail réalisé dans la phase précédente, il est tout à fait possible de lancer l’activité et d’affiner le planning en fonction des options prises. Il est toutefois important de se ménager un temps de réflexion suffisant pour la sélection des outils et des méthodes de développement pour en tirer le bénéfice maximal des efforts réalisés lors de la phase de production. Cette phase ne parait pas stratégique a priori mais elle fixe un certain nombre d’options prises, qui seront structurantes pour la poursuite du projet.

La phase de production est la plus impactante car il s’agit alors d’ajuster constamment la trajectoire. Dans le cadre d’une course de voiliers autour du monde, on pourrait comparer cette phase à la période où le bateau est sur l’eau et où l’équipage manœuvre. L’équipage est alors dépendant de la stratégie de course et du niveau d’attente des donneurs d’ordre. Mais, cet équipage est alors seul à bord et doit composer avec les forces et faiblesses de chacun des membres pour en tirer pleinement profit. Le rôle du skipper est alors de donner les moyens aux différents membres de l’équipage de se surpasser pour assurer la victoire collective.

Dans le cadre de la gestion de projet, cela est comparable au rôle du chef de projet, amené à aider les collaborateurs à trouver leur place et à participer efficacement à la réussite du projet, en tenant compte des contraintes extérieures. La bonne conduite de cette phase est essentiellement liée à la capacité du manager à « gérer l’équipe » (cf. chap. III). Finalement, nous aborderons la phase de pilotage, qui couvre l’ensemble des phases décrites précédemment



sous un angle différent. Il s’agit ici d’être capable de remonter objectivement l’avancement du projet et les problèmes rencontrés. L’enjeu est donc de mesurer les écarts entre les actions réalisées et de confronter au prévisionnel, mais surtout de mettre en évidence les choix à effectuer pour guider le projet. Cela nécessite de disposer d’une instance reconnue et légitime pour effectuer les arbitrages opérationnels et stratégiques. Dans la pratique, il est indispensable de disposer d’un sponsor mandaté par la DG au sein du comité de pilotage.



III – Management des Equipes de Projet

III.1. Rappel des 5 items du mini-projet MEPDans un projet, quel qu’il soit, l’équipe de projet devra non seulement atteindre ou se rapprocher de l’objectif qui lui a été fixé par la MOA, mais aussi gérer ses tâches, ses ressources : temps, information, humaine (pour le chef de projet, surtout) et optimiser ses moyens.

Or dans le cadre de notre projet « Pathologies des projets informatiques », nous étions un groupe composé de 6 personnes ayant des compétences plus ou moins différentes, venant de structures totalement différentes. La ressource « temps » nous semble la plus délicate à gérer parce que non seulement, il faut gérer ses propres priorités et son temps, mais également le temps collectif, autrement dit, le temps de l’ensemble des membres de son équipe.

Ainsi, après avoir vécu cette expérience enrichissante de plus de 3 mois, nous aimerions formuler quelques conseils permettant de manager, de manière efficace, des équipes de projet mais aussi d’impliquer les utilisateurs et avoir le soutien de la Direction générale (c’est l’idéal !).

Toutefois, pour une meilleure compréhension des dysfonctionnements liés à cette thématique « Management des équipes de projet », nous définirons et donnerons quelques exemples, conseils et illustrations. Ensuite dans le chapitre III.2 nous rapporterons les dysfonctionnements qui seront argumentés, des solutions proposées et une liste de FCS sera dressée. Nous clôturerons cette partie par un « capital connaissances », qui sera en quelque sorte le résumé de cette 3ème partie.

Nous rappelons que ce mini projet « Management des équipes de projet » a été mené par Napoléon, Laurent et Yvan mais que les cas de dysfonctionnement sont issus de toute l’équipe.

Ce mini-projet comporte 5 items :

La gestion de ses priorités.

La gestion des priorités collectives.

Le management d’équipes de projet.

Implication des utilisateurs.

Le soutien de la DG.



III.1.1. Gestion de ses priorités

« Il n’est pas de vent favorable pour celui qui ne sait pas où il va » Sénèque.

Cap sur l'essentiel : la valeur de chaque tâche à accomplir doit être déterminée en fonction des objectifs du projet, mais aussi des objectifs opérationnels de chaque membre de l’équipe, puisque les tâches sont réparties aux 6 membres de l’équipe. Ces objectifs sont alors à court et moyen termes. Pour l’équipe IMI38F, des tâches devaient être accomplies sur le court terme, par exemple « la rédaction du CdC et son envoi à la MOA au plus tard le 31 mars, soit 13 jours après démarrage du projet et sur le long terme, le 27 juin, jour de la soutenance, soit 14 semaines après le démarrage du projet !

Si l’objectif (résultat à atteindre) est clair, chaque membre de l’équipe saura, sans mal, distinguer l'essentiel du secondaire et faire le tri entre urgence et priorité.

Pour cela, la veille et pour certains, le matin avant de commencer la journée de travail, les membres de l’équipe définissaient deux ou trois priorités au maximum pour la journée du lendemain ou de la même journée et articuler le reste de son travail autour de ces points forts. Nous rappelons, que l’équipe IMI38F devait non seulement gérer le projet « Pathologies des projets informatiques », mais aussi gérer ses tâches quotidiennes inhérentes à son poste mais également gérer les cours à l’IMI, sa vie privée, etc. Les 14 semaines ont été très chargées de travail mais aussi d’émotions et de sensations.

Gérer ses tâches et ses priorités, c’est prendre en considération le temps, les outils de communication, par exemple, les informations, les collaborations avec nos 2 coaches, etc. nécessaires pour mener à bien chacune de nos missions.

Comme notre degré de concentration et d'efficacité n'est pas le même tout au long de la journée, il nous fallait éviter, coûte que coûte, les interruptions et dire halte aux chronophages. En effet, nos collègues de bureau aussi sympathiques soient-ils peuvent devenir parfois « des voleurs de temps ». Il en est de même pour le téléphone, les réunions interminables, les imprévus, la messagerie… Nous avions appris à faire la chasse au grignotage des minutes si l’on voulait mener à bien nos priorités du jour.

Pour la majorité des membres de l’équipe IMI38F, c’est en début de matinée que l'on était le plus performant, le plus frais. Même si ce n'était pas toujours plaisant, on s’obligeait à commencer par les tâches les plus ardues ou les plus délicates. Notre esprit libéré, nous pouvions rentabiliser le reste de notre temps de travail. Nous étions devenus notre propre gardien de notre temps !

III.1.2. Gestion des priorités collectives

« L’important n’est pas de tout faire, mais de faire le plus important » MS.

Dans toute fonction de management, la pression du temps se fait sentir. Tiraillé entre les actions essentielles, les sollicitations diverses venant de tous horizons, le besoin de garder un temps de réflexion personnelle et les multiples détails nécessaires à toute réalisation, le chef de projet, Jean-Luc se trouvait facilement débordé. Pourtant il faut bien parvenir à accomplir sa mission dans le temps dont il disposait. Pour cela, chaque membre de l’équipe devait jouer un double rôle : être membre de l’équipe mais aussi être le responsable de l’équipe. D’ailleurs, nos 2



coaches n’hésitaient pas à nous rappeler les échéances, les résultats à atteindre. C’était une pression supplémentaire qui nous donnait de l’adrénaline !

III.1.3. Management d’équipes de projet

« Il n’est de richesse, que d’hommes » Jean Bodin.

Passer du groupe IMI38F à l’équipe IMI38F n’était pas une mince affaire. En effet, décider de construire une équipe, c’est AGIR. Toute décision est un choix, mais c’est aussi un pari, le pari d’avoir fait le « bon choix ». Or, faire un pari c’est accepter l’incertitude et le risque. Nous avions assez d’incertitudes et de risques avec le projet, qu’ajouter ces risques, était pour nous un véritable challenge… Que nous avions su relever !

La construction d’équipe repose sur des considérations a priori. Quelques éclaircissements méritent d’être apportés : dans le rassemblement, les individus communiquent rarement entre eux, sinon pour échanger des banalités et se retrancher le reste du temps derrière des attributs personnels. Qu’ils aient des besoins ou des intérêts communs ne change rien à la situation, dans la mesure où cet intérêt commun leur reste extérieur, imposé « de dehors ». Ce qui manque au rassemblement pour devenir un groupe, c’est sa dimension d’acteur conscient et volontaire. Ceci est synonyme de capacité à influer sur son environnement. Cette acquisition s’effectue en deux temps :

Constitution du groupe par dégagement du rassemblement.

Structuration du groupe en vue de sa conservation (pérennité).

Afin que le groupe se dégage du rassemblement, il faut :

L’existence d’un intérêt commun : passer de l’intérêt EN commun à l’intérêt commun. Pour cela, chacun de nous devait découvrir que son interdépendance avec les autres est nécessaire à la satisfaction de cet intérêt (tous pour un, un pour tous !).

L’existence d’un système d’information et de communication : nous avions besoin de partager des informations afférentes à nos objectifs, générer de l’information nouvelle par la mise en commun de nos informations particulières, etc.

Le partage d’une communauté de destin : dans l’environnement du groupe naissant, il doit exister d’autres groupes défendant des intérêts antagonistes, ce rôle était joué par nos 2 coaches. Le groupe se constitue dans un mouvement de tension entre un danger commun et un objectif commun qui modifie qualitativement les relations entre ses membres.

Mais un groupe n’est pas un phénomène naturel. C’est un construit humain, produit d’une volonté et d’une pratique managériale. Le groupe ne sort jamais définitivement du rassemblement. Pour assurer la permanence de son existence, le groupe met en place une organisation qui impose des contraintes (division du travail, coordination, structure organisationnelle). Le but de cette organisation est de maintenir la cohérence dans l’action et faire en sorte que les forces poussant au retour à l’état de rassemblement (non-organisation) ne l’emportent sur celles maintenant le groupe (organisation).

L’équipe se définit comme un groupe mature et équilibré entre la tâche et le groupe.



Le principal problème à résoudre dans la démarche de construction d’équipe est d’organiser des modalités de travail qui garantissent une collaboration (contrainte) entre les membres de notre équipe, sans supprimer la liberté de chacun, c’est-à-dire, notre capacité à poursuivre des objectifs qui peuvent être divergents sans se ruiner mutuellement et sans pour autant mettre en danger les résultats de l’action collective, voire en les améliorant.

Notre groupe fonctionne selon deux façons :

Structure organisationnelle du groupe (répartition du travail, coordination, partage du pouvoir de décision), qui représente en quelque sorte, la cohérence du groupe ou plus simplement le « vouloir ensemble » du groupe.

Qualité et intensité du sentiment d’appartenance au groupe, qui représente en quelque sorte, la cohésion du groupe ou tout simplement le « sentir ensemble » du groupe.

La performance de notre équipe tient à l’équilibre entre le « vouloir ensemble » (cohérence) et le « sentir ensemble » (cohésion). Ni la cohésion, ni la cohérence ne s’exclue l’une de l’autre. L'expérience montre que la stratégie de construction d’équipe centrée sur la cohérence donne rapidement des résultats, car le but de la construction d’équipe n’est pas tant de construire une mise en commun d’imaginaires individuels qu’un système de contraintes permettant l’efficacité et l’efficience. Enfin, un projet doit être intellectuellement pensé et affectivement ressenti par le groupe.

Défaut de cohésion : mésentente, défiance, conflit entre les membres d’un groupe ou résistance et crainte face au changement.

III.1.4. Implication des utilisateurs

« Celui dont les troupes sont unies autour d’un objectif commun, sera victorieux » Kuan Chung Kzu.

La mise en place d’un projet informatique nécessite l’implication des utilisateurs. Encore faut-il déterminer le moment idéal pour mobiliser les troupes.

Mais alors que la réussite ou l'échec d'un projet de refonte (technologique, applicatif...) découle bien souvent du degré suffisant d'implication des utilisateurs, encore faut-il que les directions informatiques et métiers identifient au préalable les étapes du projet où cette implication apparaît comme essentielle !

Le moment idéal d’implication est intimement lié à la nature du projet informatique (refonte du SI, amélioration de la communication, amélioration du processus de validation, etc.) avec soit une implication très en amont de l'ensemble des utilisateurs dans le cas d’une réorganisation des métiers ou de l’intégration de nouvelles directives réglementaires ou bien de façon ponctuelle, pour valider une non-régression dans le cadre d’un changement technologique.

Enfin, pour tout projet informatique, la participation et la proactivité des utilisateurs restent un facteur clé de succès. Des comportements qui sont facilités par la mise en place d’une démarche de conduite du changement. Bien entendu, pour surmonter les résistances des utilisateurs, il faut éviter de faire d’un projet informatique, un projet pour « experts techniques ». L’informatique est un moyen au service des utilisateurs.



III.1.5.Soutien de la DG

« Il faut autour de soi, pour exister, des réalités qui durent » St-Exupéry.

La mise en place d’un projet informatique revêt, de plus en plus, un caractère stratégique et, de ce fait, demande à ce que la Direction Générale soit impliquée le plus fortement possible. Son support actif sera un des facteurs clés du succès du projet.

Dès l’amorce du projet pendant les études de définition jusqu’au lancement du système, en présidant la réunion de démarrage avec le prestataire choisi à l’issue de la consultation. Ce soutien actif permet d’assurer au projet : l’intérêt et l’attention des utilisateurs, des moyens humains et financiers adaptés, une pérennité appréciée par les acteurs opérationnels, une limitation des retards…

En conclusion, le soutien de la DG est l’assurance de terminer dans les délais.



III.2. Gestion de ses priorités

III.2.1. Constat des dysfonctionnements

C12 : Mobiliser du temps sur une activité projet en conservant une activité opérationnelle

Contexte : Evolution de l’outil de CAO dans une PME – 400 jour homme.

III.2.2. Argumentaire expliquant ces dysfonctionnements

Période : 1998

Dans le cadre de l’évolution de version d’un logiciel de conception technique, une équipe projet a été constituée. Cette équipe était composée de 4 personnes : le chef de projet, un représentant de la maîtrise d’ouvrage, un développeur et un collaborateur technique amené à assurer le support et l’administration nationale du produit lors de son déploiement.

Cette dernière ressource n’était impliquée dans le projet qu’à 50% car elle conservait la prise en charge du support de la version précédente, déployée dans les entités opérationnelles.

Dans le cadre du projet, ce collaborateur avait comme mission d’évaluer le gap fonctionnel entre la version existante et la nouvelle, d’évaluer la charge d’acquisition des compétences pour les utilisateurs et d’assister le représentant de la maîtrise d’ouvrage pour la spécification des développements à réaliser.

Lors de la phase de spécification, la bonne connaissance du système existant par la ressource impliquée à 50% était importante pour assurer la qualité des spécifications produites. En effet, malgré les connaissances métier du représentant de la maîtrise d’ouvrage, de nombreux points particuliers ne pouvaient être alimentés que par la ressource support.

Compte tenu de son implication dans les activités opérationnelles, cette ressource devait organiser sa disponibilité entre l’activité récurrente et l’activité projet. De par l’impact opérationnel direct de son manque de disponibilité, sa priorité se portait assez naturellement vers la conduite des activités de support. Cela a induit des retards dans la définition des spécifications.

Causes identifiée :

Organisationnelle : La ressource de support était seule à traiter les problèmes opérationnels et ne pouvait donc pas s’appuyer sur une structure existante, même pour des actions simples.

Humaine : L’activité de support est plus exaltante que l’activité projet. Le travail en mode réactif est assez valorisant car il donne immédiatement des résultats et confirme l’importance du rôle du collaborateur.



L’effet :

Organisationnel : Les retards sont généralement non planifiables car ils sont générés par un surcroît d’investissement dans une activité survenant ponctuellement. Cela a un impact sur l’organisation globale de l’équipe.

III.2.3. Pistes de solutions de progrès

Afin de garantir un certain niveau de disponibilité, la solution retenue a été de faire monter en compétence une ressource externe pour assurer le support de premier niveau et de limiter l’intervention de la ressource existante sur le traitement de problème de support de niveau 2.

Toutefois, le modèle d’organisation n’a pu être opérationnel qu’après la phase de montée en compétence de la ressource externe.

III.2.4. Facteurs clés de succès

Lorsqu’une ressource est amenée à intervenir sur différentes activités, il faut s’assurer que son implication sur certaines activités ne sera pas trop consommatrice, afin de garantir un niveau de disponibilité suffisant sur les autres activités.

Cela passe par une évaluation de la charge de travail liée aux activités critiques et les possibilités de traitement de ces activités (possibilité de reporter, de déléguer, etc.). Ensuite, la structure organisationnelle doit être mise en place avant d’affecter les nouvelles tâches à cette ressource.



III.3. Gestion des priorités collectives


C20 : Carence de ressources MOE

Contexte : Notes de calcul informatisées dans une PME – 1000 jours-homme.


Période : 2004-2005

L’entreprise disposait d’un grand nombre de notes de calcul informatisées. Plus ou moins complexes, qui avaient été développées par la Direction technique et fiabilisées au cours des années pour finalement être mises à disposition de l’ensemble des collaborateurs des services opérationnels. Toutefois, compte tenu de leur mode de développement par itérations successives par des personnes quelque fois différentes, aucune documentation n’était disponible.

Après une phase de qualification, les notes ont été classées en deux catégories :

Les notes de calcul fiables et au domaine d’application parfaitement connu.

Les notes de calcul contenant des erreurs ou aux limites d’utilisation mal maîtrisées.

Pour la première catégorie, une mission de « reverse-engineering » a été confiée à une équipe de stagiaires afin d’établir la documentation fonctionnelle. Pour la seconde catégorie, un projet a été lancé. L’objectif était d’écrire la documentation fonctionnelle des notes de calcul en validant les hypothèses métier et en modifiant les étapes de calcul erronées.

L’ensemble de ces activités s’inscrivait par ailleurs dans une démarche d’homogénéisation des formats de données, pour permettre d’interconnecter les notes de calcul entre elles en modèle statique ou dynamique : ce qui implique que les données de sortie de la note de calcul 1 disposait des mêmes formats que les données d’entrée de la note de calcul 2. Le choix de l’outil de développement avait d’ailleurs été fait en tenant compte de cette volonté.

Pour les notes de calcul de la deuxième catégorie, l’implication des experts était essentielle, tant dans la phase de production des documentations que dans la phase de validation des notes produites. Or, certains d’entre eux devaient prendre à court terme (quelques mois à un an) leur retraite. Le planning avait donc été établi de manière à prioriser le développement des notes de calcul en fonction des disponibilités des experts et de leur départ programmé.

La phase de production des documentations s’est déroulée de manière globalement conforme aux prévisions. L’équipe de développement avait été constituée en interne, car possédant la connaissance de l’outil retenu pour produire ces notes. L’outil était également utilisé en production pour certains calculs et certaines simulations spécifiques, par une équipe dédiée, constituée exclusivement de prestataires. Suite à une défaillance de ce prestataire, les personnels mis à disposition ont quitté l’entreprise et les activités opérationnelles dont ils avaient la charge et se sont trouvées vacantes.



Compte tenu de l’impact fort sur le business de cette activité, il a été demandé à l’équipe de développement de palier cette carence opérationnelle. Cette décision a considérablement ralenti la phase de production et lorsque l’équipe a pu se reconstituer, certains experts étaient déjà partis. Ceci a compliqué le travail de développement pour lequel un certain nombre d’éléments de compréhension n’était plus accessible.

Cause identifiée :

Organisationnelle : Alors que l’entreprise était consciente de la nécessité de formaliser la connaissance de ses experts avant leur départ, le projet a été initié très tardivement. De plus, la disponibilité de ces experts était limitée par leur participation aux projets opérationnels stratégiques pour l’entreprise. Le choix d’un outil très spécifique induit une disponibilité faible de la ressource disposant des compétences sur cet outil.

Les effets :

Organisationnel : Après la mise à disposition d’une partie de l’équipe de développement auprès des équipes opérationnelles, les deux développeurs restant, ont été amenés à absorber une partie de la charge des activités lancées. De plus, il a été nécessaire de récupérer de l’expertise après le retour dans le projet des équipes de développement.


Le point le plus difficile à traiter a été la perte des ressources d’expertise. Il s’agit de ressources rares et disposant d’une bonne connaissance du contexte de l’entreprise. La solution retenue pour s’assurer de la continuité du projet fût de faire revenir les experts concernés à des points clé du projet. Cela a été très bien géré lors de leur départ et s’est déroulé sans aucun problème.


Dans un projet impliquant une ressource rare, il est impératif de se prémunir contre son indisponibilité, par quelque moyen que ce soit.

Dès que possible, il faut favoriser une solution limitant le recours à l’expertise afin de disposer d’une grande disponibilité de ressources alternatives en cas de défaillance des acteurs du projet.



III.4. Management d’équipes de projet


C21 : Piloter le changement : Basculement de 2 personnes sur un nouveau projet.

Contexte : développement d’un progiciel dans une PME

Période : 1999.


Une PME, éditeur de progiciels de gestion, gère 2 gammes de progiciels :

L’ancienne gamme qui a donné toute satisfaction pendant des années mais qui est en fin de vie sur laquelle les dernières ressources de maintenance, jusque là encore mobilisées, devront passer rapidement sur la nouvelle gamme.

La nouvelle gamme qui a reçu un bon accueil de la part de la clientèle mais qui nécessite de nombreux développements fonctionnels et de maintenance.

La direction générale (DG) annonce à la dernière équipe de 2 personnes qui se connaissent très bien et qui sont très expérimentées sur l’ancienne gamme de progiciel qu’elle va devoir basculer sur la nouvelle gamme tout en gardant une petite activité de maintenance sur l’ancienne gamme. La DG pensait bien faire en basculant les 2 personnes plutôt qu’une seule des deux (l’autre restant sur l’ancienne gamme) car :

Cela semblait plus motivant pour les deux.

Cela minimisait les risques de rejet de l’une des personnes : les 2 étaient traitées de la même manière.

Cela permettait de former simultanément les 2 personnes à la nouvelle gamme.

Enfin, cela permettait de conserver deux personnes opérationnelles pour les dernières maintenances à réaliser sur l’ancienne gamme.

Travaillant dans un même bureau, les 2 personnes furent rapidement formées au nouvel atelier de développement orienté objet. Cela représentait un changement important par rapport à l’approche traditionnelle de programmation qu’elles connaissaient.

De premiers développements leur étaient confiés. Rapidement leur manager MOE se rendit compte que la productivité des deux personnes n’était pas au rendez-vous. Une formation interne complémentaire leur fut proposée mais la productivité n’évolua que trop peu. Ces 2 personnes avaient une expérience et une expertise reconnues sur les progiciels de gestion commerciale mais n’arrivaient pas à acquérir la compétence requise par le nouvel atelier de développement.

Le constat qui a été fait était le suivant :

Manque d’aisance dans le nouvel atelier.



Manque d’envie d’apprendre (ce n’est pas comme avant…).

Dénigrement entre eux sur le nouvel atelier.

Bref au projet initial qui était de leur confier de nouveaux développements venait s’ajouter un nouveau défi : accepter le changement.


Humaine : Refus du changement. Tardive appréhension de la difficulté importante que représentait le changement demandé à ces 2 personnes. Formation standard non adaptée au profil des personnes visées.

Les effets :

Humains : Démotivation des personnes concernées.

Organisationnels : Basculement de l’équipe plus long que prévu pour atteindre une efficacité nominale.


Le constat a conduit la MOE a :

Négocier un changement de bureau temporaire, pour que chacun puisse être accompagné d’un développeur chevronné en capacité de les aider.

Retour dans un même bureau des protagonistes dès que possible (niveau de productivité normal). Ceci fut fait à l’issue d’une période de deux mois.


Le basculement d’équipes vers un nouveau projet qui implique une remise en cause importante des compétences acquises (ici technologie objet) doit s’accompagner :

De formations adaptées à la population visée.

D’un véritable pilotage du changement : prise en compte des appréhensions, du refus, rupture des habitudes…

De coaches individuels si nécessaire.



III.5. Implication des utilisateurs


C25 : Eclairage stratégique incompris par les acteurs du mouvement

Contexte : création d’un ensemble de 8 sites Web alimentés par les salariés dans une organisation de type associatif.

Période : 2005.


Au 1er septembre 2004 la fusion de deux associations prônant les mêmes valeurs donne naissance à une nouvelle entité dirigée par un pouvoir bicéphale issu des deux mouvements.

Pour insuffler un nouvel élan à l’organisation, la DG décide précipitamment la création de 8 sites Web alimentés par les salariés. A cet effet, elle mandate une nouvelle équipe de communication. Celle-ci en tant que MOA n’est pas bien comprise et provoque un malaise auprès des membres du mouvement. Sa méconnaissance de la culture maison ne facilite guère le dialogue et rend la tâche ardue lorsqu’elle annonce le projet de refonte des sites Web. Par ailleurs, les divergences au sein de la direction ont favorisé cette dérive. Il en résulte des délais, surcoûts et erreurs dont les dirigeants s’accommodent.

Les premiers sites sont mis en ligne mais les responsables de branche nommés pour les alimenter éprouvent de la difficulté à les faire vivre car ils ne sont pas suffisamment formés et ne comprennent pas toujours l’intérêt de le faire. Pour la direction, il s’agissait d’impliquer chacun des responsables dans la vie du site.

A l’issue d’une période de tests de quelques mois sans résultats, la MOA propose de nommer une seule personne responsable à temps plein de l’ensemble des sites.

Cause identifiée :

Humaine : La MOA n’a pas su expliquer à des acteurs concernés l’intérêt de la refonte des sites Web et sa gestion. Les acteurs impliqués dans la vie du site n’étaient pas représentés lors du lancement de la démarche.

Effets induits :

Humains : Une réticence des responsables à coopérer parce qu’ils n’ont pas été représentés et ont eu le sentiment de ne plus être légitimes en tant qu’acteur du mouvement.

Organisationnels : La mission que représente la gestion des sites Web n’est pas comprise et nécessite de repenser leur mode de travail.




A l’issue de la période de tests non concluante une cellule représentant les responsables de branche a été mise en place au sein du comité de pilotage. L’implication officielle de celle-ci dans le projet a permis d’élaborer une gestion adaptée et cohérente des sites Web.


Tout projet de réorganisation doit faire l’objet d’un accompagnement rigoureux et d’une écoute adaptée des différents acteurs. Pour cela, il faut :

Communiquer auprès des acteurs du mouvement afin de lever les incompréhensions et le malaise des sous-entendus.

Représenter dans le comité de pilotage les acteurs impliqués dans le projet.

Il est essentiel, dès le lancement d’un projet, de s’assurer de l’implication des utilisateurs et de leur compréhension de l’intérêt de la démarche. C’est une des garanties de leur appropriation du projet.



III.6. Soutien de la DG


C32 : MOA : Aucune implication et soutien de la DG

Contexte : Développement d’un progiciel de gestion hôtelière, dans un Groupe international.



Un groupe d’hôtel international décide de construire son propre progiciel de gestion hôtelière. La Direction du projet est assurée par la Direction informatique, qui à cette période a plus de poids dans le management du groupe que les Directions Opérationnelles. La direction informatique constitue une équipe projet composée d’utilisateurs représentant les métiers et d’une équipe d’informaticiens en sous-traitance (concepteur de base de données, développeur interface graphique, développeur base de données, etc.). Le chef de projet choisi qui ne vient pas du métier, ne possède ni les compétences techniques ni les compétences managériales nécessaire à cette mission. Il est en quelque sorte un gourou pour le Directeur informatique qui croit sa vision du métier et du progiciel métier. Les choix techniques, les choix d’ergonomie et de modèles de données ne sont pas validés par les utilisateurs. Malgré leurs avis et les remontées alarmistes vers les directions opérationnelles, celles-ci laissent faire pour ne pas entrer en conflit avec le Directeur informatique.

Après 12 mois d’égarement, un audit externe conclura à la non fiabilité du projet qui sera abandonné.


Humaine : le directeur informatique, pour des raisons historiques, a plus de poids dans le groupe que les directeurs opérationnels. Personne n’ose le contredire.

Les effets :

Humains : Les utilisateurs impliqués dans le projet ont passé 12 mois de leur vie professionnelle dans une démarche qu’ils savaient vouée à l’échec.

Organisationnels : Suite à l’audit, Le groupe a décide de créer une direction informatique rattachée aux opérations.


Aucune : le projet a été abandonné.




La Direction Générale doit absolument être le commanditaire des projets informatiques qui concernent le métier :

Elle doit déléguer sur le projet des experts métiers reconnus et représentatifs qui sauront prendre les décisions judicieuses pour la bonne réussite du projet.

La direction informatique doit accompagner la Direction Générale en apportant son expertise sur les aspects techniques du projet.

Il ne doit pas y avoir substitution du rôle de l’un par rapport à l’autre.



III.7. Capitalisation des connaissances du MEPL’analyse croisée des dysfonctionnements recensés par chacun des membres de l’équipe a permis d’identifier un certain nombre de facteurs clés de succès (FCS). Leur application permet de disposer d’indicateurs permettant d’évaluer le projet. Il ne s’agit pas d’établir une liste des FCS et de s’assurer de leur existence mais d’avoir une conduite adaptée au contexte du projet et de l’entreprise. Ainsi, en fonction de l’évaluation du projet, de la maturité technique de chacun des collaborateurs et de l’expérience de travail en commun des équipes, la pondération des différents FCS est totalement différente. Toutefois, on peut dégager deux grandes familles de bonnes pratiques :

Les pratiques liées au management des équipes (au sens large englobant la MOA, la MOE et l’équipe de projet). Ces éléments sont endogènes.

Les pratiques liées à la gestion des relations entre le projet et les acteurs extérieurs tels que les utilisateurs, la direction, etc. Ce sont des éléments exogènes.

Eléments endogènes

Une équipe de projet doit être constituée de ressources capables de « vivre ensemble », c’est-à-dire de partager les enjeux du projet et la stratégie mise en œuvre. L’échange, la communication, le partage des objectifs du projet, etc. permet à l’équipe de mobiliser toutes ses compétences et sa volonté pour tendre vers la réussite du projet. De plus, les membres de l’équipe doivent former un tout cohérent et harmonieux, dans lequel l’apport de chacun doit être valorisé et compris. Tels les habitants du village d’Astérix, la compréhension de leurs interactions permet de construire une « tribu » au sein de laquelle l’empathie dégagée conduit à une reconnaissance mutuelle qui assure la force de l’équipe, en particulier face aux perturbations venant de l’extérieur.

Cela peut être grandement facilité par l’existence d’un leader au sein de l’équipe. Cette dimension de leadership ne peut être négligée car si le chef de projet dispose du leadership suffisant, il pourra insuffler sans difficulté à l’ensemble de l’équipe la dynamique nécessaire à la bonne marche de l’équipe. Généralement, ce leadership s’installe naturellement dès lors que le chef de projet est réellement dans l’équipe et qu’il participe au projet, qu’il est le « rameur en chef » et non le « chef des rameurs ».

Parmi les facteurs endogènes, on trouve également les problématiques de gestion du temps. Cette dimension est particulièrement difficile à maîtriser. Bien que cette notion ait déjà été abordée dans le chapitre précédent, elle est essentielle car elle nécessite une gestion du temps individuel et du temps collectif. L’un et l’autre ont un impact sur la vie de l’équipe.

Eléments exogènes

Pour assurer la réussite du projet, un des éléments majeurs est l’implication des utilisateurs de sa phase de définition à sa phase de déploiement. Ces derniers sont la maîtrise d’ouvrage réelle du projet. Toutefois, compte tenu de leur immersion dans les activités opérationnelles, un des risques majeurs est leur manque de disponibilité. Pour y pallier, les structures suffisamment dimensionnées mettent en place des maîtrises d’ouvrage déléguées. Dans ce cas, il faut veiller à leur représentativité. Dans les maladies des projets identifiées par la Cegos, « la despote » est la



maladie que l’on rencontre généralement dans ce cas de figure (s’évertuer à faire le bonheur de tous sans leur consentement).

Dans le cadre de la mise en place de projets stratégiques, l’impact est généralement fort, sur le plan organisationnel, culture, social… Ces projets nécessitent durant toute leur durée le soutien de la Direction générale. Pour s’assurer de son soutien et de sa compréhension des problèmes rencontrés dans la mise en œuvre du projet, il est impératif qu’un membre du comité de direction soit identifié comme sponsor. C’est à lui, au sein du projet, de définir les orientations stratégiques à prendre, tant sur les aspects organisationnels majeurs (impacts dans les directions opérationnelles) que sur les réorientations éventuelles, voire l’arrêt du projet. Pour cela, le rôle du chef de projet est primordial pour lui fournir le niveau d’information nécessaire à l’analyse de la situation et à la prise de décision.



IV – Management de Projets e-Collaboratifs

IV.1. Rappel des 5 items du MPeCCe mini projet 2 comportant 5 items, sera traité par Jean-Luc, Pierre-Yves et Fattah.

Charte des valeurs de l’équipe de projet.

Charte d’utilisation de l’espace e-collaboratif.

Utilisation par l’équipe de projet de l’espace e-collaboratif.

Tableaux de bord.

Capitalisation des connaissances.

Nous expliquerons brièvement ces 5 items et ensuite, nous rapporterons les dysfonctionnements constatés dans nos entreprises.

IV.1.1. Charte des valeurs de l’équipe de projet

« Celui qui renonce à devenir meilleur, cesse déjà d’être bon » Max Bouyer.

Une valeur est intimement liée à l’individu et à sa conduite. Elle lui est intérieure et elle nomme ses gestes quotidiens. Ces gestes sont des faits observables qui se traduisent par un certain nombre de valeurs qui le guident, l’orientent. Les valeurs personnelles sont souvent confrontées à celles qui ont la primauté dans le milieu dans lequel l’individu travaille.

Dans les entreprises, les personnes orientent leur vie professionnelle sur des valeurs centrées sur la compétition, sur l’individualisme voire sur la rivalité, alors que le développement organisationnel et comportemental est centré sur les valeurs de partage, de solidarité et de collaboration.

Si dans un groupe, des individus ont des valeurs totalement opposées, ils ne peuvent donc pas travailler ensemble. Nous pouvons définir cette situation par l’expression suivante : plusieurs mondes dans un monde. Autrement dit, il y a des interactions différentes dans un monde univoque à cause de la domination de certaines valeurs. Cette interaction est fondamentale dans les jeux qui s’établissent entre l’individu et le milieu professionnel. Le milieu, tout comme l’individu, a des préférences pour un certain nombre de valeurs. Par le biais de choix plus ou moins conscients, il est demandé de faire la promotion de telle valeur plutôt que telle autre. Par exemple, « il serait préférable d’être compétitif plutôt que de développer le partage » ou « il serait préférable de respecter l’autorité plutôt que de favoriser l’indépendance personnelle ».



Autant de préférences qui sont en soi justifiables. Les préférences sont souvent étroitement liées à des aspirations individuelles et collectives.

La valeur est également une référence. Elle est intégrée à notre personne. Elle est intérieure et elle inspire nos gestes et nos décisions. Elle est plus profonde que nos préférences (aspirations). Ce qui nous semble important de retenir est qu’une valeur ou qu’un système de valeurs donne un sens à notre agir, mais qu’il reflète également une façon de penser, une façon d’entrer en relation avec les autres. Nos valeurs nous montrent ce qui est pour nous acceptable ou encore tolérable.

Il convient de noter un premier problème lorsqu’il s’agit de nommer des valeurs : c’est le problème de la terminologie. Il peut être facile de s’enfermer dans des questions de vocabulaire et de définition. Il est donc important de s’entendre sur le sens que l’on donne à ces termes.

Tout au long des mini-projets que nous avions conduits, des valeurs nous ont servi de référence et de préférence : la liberté, le sens du devoir, la responsabilité, le partage, la solidarité, le travail d’équipe, le respect et la confiance.

IV.1.2. Règles d’utilisation de l’espace e-collaboratif

Dans un environnement de plus en plus mondialisé, rapide, immatériel et interconnecté, les entreprises doivent faire évoluer leur organisation vers des formes plus collaboratives, fondées sur le réseau. L’organisation doit s’ouvrir à ses partenaires, clients et fournisseurs pour optimiser de bout en bout chacun de ses processus opérationnels, ses processus métier. Ses applications telles que les intranets doivent s’enrichir de nouvelles fonctionnalités pour devenir de véritables outils de travail, opérationnels et adaptés aux besoins de chaque métier: marketing, commercial, technique, R&D, achats, maintenance, etc.

Le travail collaboratif assisté par ordinateur ou encore le travail e-collaboratif est au cœur de ses nouveaux enjeux.

Pour la définition de la e-collaboration nous retiendrons celle de Kock : “collaboration among individuals engaged in a common task using electronic technologies”.

Ce terme a pris une grande importance ces dernières années. D’ailleurs, une recherche faite le 15 mai 2008, sur Google du mot « collaboration », révèle qu’il est aujourd’hui plus présent sur les pages francophones du Web (89 700 000 occurrences) que le mot concurrence (14 100 000). Ce phénomène s’explique de trois manières :

La mondialisation, qui tout en ouvrant les marchés aux entreprises, oblige celles-ci à confier certaines tâches où elles excellent moins à des partenaires plus compétents. En effet, la mondialisation entraîne de plus en plus les entreprises à collaborer les unes avec les autres. Les progrès techniques enregistrés dans des secteurs comme les télécommunications font en sorte que les entreprises ont aujourd’hui accès à des marchés auparavant inaccessibles. En contrepartie, la mondialisation a ouvert les portes du marché à des adversaires qui n’existaient pas autrefois. Cet accroissement de la concurrence force les organisations à repenser leurs façons de faire. Plutôt que de tout faire elles-mêmes, elles doivent désormais se concentrer sur ce qu’elles font de mieux et confier les tâches où elles excellent moins à des partenaires plus capables qu’elles.



Les technologies de l’information et la communication (TIC) permettent aux entreprises de s’affranchir des contraintes espace-temps. Les TIC facilitent la collaboration. Par le passé, à cause de la distance, il était souvent difficile à une entreprise, par exemple, française de travailler avec une société chinoise ou indienne possédant des compétences complémentaires aux siennes. De nos jours, les TIC rendent cela possible.

La capacité à satisfaire le client : De plus en plus d’entreprises collaborent les unes avec les autres parce qu’elles se rendent compte que leur capacité à satisfaire les besoins du client ne dépend plus seulement de la qualité de leur prestation, mais aussi de la performance d’ensemble du réseau d’affaires auquel elles appartiennent. Ces organisations repensent en profondeur la façon dont elles fonctionnent et la manière dont elles font des affaires avec leurs fournisseurs, sous-traitants, prestataires de services, etc.

Les entreprises collaborent donc de plus en plus…mais qu’entend-on au juste par le terme collaboration (ou coopération, selon la littérature) ?

Trois mots se transformant souvent en maux

Pour bien comprendre la « collaboration », prenons l’exemple d’un projet où la collaboration est nécessaire : tout au long du projet, l’équipe de projet va, la plupart du temps, éprouver des difficultés. Ces dernières viennent soit d’un manque d’information, soit d’un manque de temps. Ce manque d’information et de temps trouve lui-même ses causes dans les défauts inhérents aux mécanismes de coordination, de collaboration et de communication (3C).

Le processus projet, qui représente en soi une structure organisationnelle, va reposer sur une division du travail. Or diviser le travail consiste à répartir les tâches à réaliser entre les différents membres de l’équipe projet. Mais cette division du travail pose un problème lié à l’interdépendance qui s’établit entre les membres de l’équipe. Pour gérer cette interdépendance, il faut faire appel aux mécanismes de coordination. Dans sa définition la plus commune, la coordination désigne l’art de travailler ensemble et harmonieusement. Quatre principales composantes de la coordination et les processus de travail qui lui sont associés :

Les objectifs et la détermination des objectifs.

Les activités et la décomposition des objectifs en activités.

Les acteurs et la désignation des acteurs suivie de l’affectation des activités aux acteurs.

Les interdépendances et la gestion des interdépendances.

Ce qui amène une définition plus précise de la coordination : « C’est la gestion des interdépendances entre plusieurs activités réalisées par un ou plusieurs acteurs dans le but d’atteindre un objectif donné ».

La collaboration provient de la qualité du management de l’équipe et de la spécificité du leadership qui vont être de nature, ou non, à favoriser l’engagement de chaque membre de l’équipe, sur une co-responsabilité des résultats à atteindre. Les notions de « collaboration » et « d’équipe » sont indissociables. La collaboration entraîne de fait un certain nombre de contraintes pour les individus. Travailler à plusieurs pour atteindre en commun un même objectif, implique de renoncer à un certain degré de liberté, à accepter une coordination et une discipline propre à l’équipe.



Quatre critères caractérisent la collaboration :

La confiance entre les individus.

Les rapports d’égalité entre les individus.

Le travail d’équipe.

La communication entre les individus.

Parmi les obstacles habituels à la coordination et à la collaboration, on trouve la communication. Or la communication est un processus déterminant pour l’action la plus importante de l’équipe, qui est la décision. La communication est un outil permanent de gestion au sein de l’entreprise en général et de l’équipe projet en particulier. La communication est réputée difficile et elle l’est véritablement. Tous les spécialistes sont d’accord sur un point : l’individu n’aime pas communiquer. Et de fait, il ne suffit pas de dire « communiquons mieux » pour que tout se passe bien.

La communication peut être considérée comme le lien organique qui permet aux individus d’entrer en contact, d’échanger et, par conséquent, de vivre et de travailler en équipe. Dans cette définition, c’est le côté interpersonnel de la communication qui domine et qui est intéressant dans le travail en équipe. La communication est un processus très critique dans l’organisation, car c’est ce processus qui facilite ou limite la coordination rendue nécessaire par la division du travail. C’est encore ce processus qui contribue en grande partie à favoriser ou à limiter la collaboration qui caractérise le travail en équipe. Toutes ces problématiques sont à l’origine du développement des TIC.

De la collaboration à la e-collaboration

« La prochaine Grosse Idée qui dominera les discussions d’affaires pour la décennie à venir sera la destruction des barrières entre les entreprises » Michael Hammer.

La « e-collaboration » est l’utilisation des méthodes, techniques et outils issus des TIC permettant à des acteurs de réaliser un travail commun (par exemple rédaction d’un ouvrage, organisation d’un événement) en partageant des idées, des informations et des résultats.



Mondial

Unité de travailtraditionnelle

Même organisationinterne

Local

Même lieu

Inter-organisationinterne

Inter-entreprise

Allianceglobale

Equipeinter-département

mondiale

Equipe dispersée Alliance localeEquipe locale

inter-département

Co-entrepriseEquipe

Inter-département

Equipe globale

Niveau croissantde virtualité

Figure 3 : L’éloignement : effet de la géographie et des frontières organisationnelles

Les outils collaboratifs

Le groupware, travail collaboratif assisté par ordinateur est un ensemble d’applications flexibles, utiles au soutien d’efforts collaboratifs diversifiés. Ces applications possèdent diverses fonctionnalités et servent de soutien :

Aux échanges informels : ex : le groupware permet à deux ou plusieurs personnes de discuter en temps quasi réel.

Au partage et à la circulation d’information : ex : le groupware sert à expédier des documents multimédias par Internet ou permet à plusieurs personnes de travailler simultanément sur un même texte, plan ou autre).

A la prise de décision collective : ex : le groupware permet aux membres d’une réunion virtuelle de voter à distance.

A la coordination et au contrôle : ex : le groupware permet d’établir que telle personne aura le contrôle de l’écran commun lors d’une rencontre.

A la gestion de répertoires partagés : ex : le groupware permet de gérer l’annuaire contenant les coordonnées des membres du groupe, d’indexer les documents utiles à ce dernier selon l’auteur et la date, ou de gérer les versions.

Quelques exemples de collecticiel : e-mail, listes de distribution, groupes de discussion, chat, talk, IRC, workflow, agenda de groupe, éditeurs partagés, systèmes audio et vidéo…et le dernier né est le wiki. En plus de ces applications, on relève l’existence de solutions servant à soutenir des processus précis de collaboration. Ces solutions se greffent généralement à de gros systèmes tels les progiciels de gestion intégrée (ERP), des systèmes souvent très coûteux à l’achat comme à la maintenance.



Pour faire de la collaboration électronique, il ne suffit pas d’installer des logiciels. Il faut aussi et surtout tenir compte des facteurs organisationnels. En outre, leurs bénéfices seront difficiles à obtenir sans planification adéquate et sans transformation des façons de faire de l’organisation. La collaboration c’est d’abord un défi de gestion !

Le tableau 1 présente une liste non exhaustive de fonctionnalités collaboratives de base. Peu de produits incluent l’ensemble ou la majorité d’entre elles. Cependant, les applications lancées sur le marché en comprennent de plus en plus.

Type asynchrone Applications utilisées CommentairesEchange principalement de textes d’une personne vers une ou plusieurs personnes

Courrier électronique L’application la plus utilisée

Envoyer ou recevoir des fichiers et documents

Bibliothèque électronique Application très utilisée

Interface où est déposée des massages et/ou des documents à l’attention d’autres personnes ou équipe de projet

Forum de discussion Application peu utilisée

Répertoire des utilisateurs permettant d’éditer des informations

Gestion des contacts ou agenda électronique

Carnet d’adresses partagé, agenda

Type synchrone Applications utilisées CommentairesDiscussion en temps réel impliquant 2 ou plusieurs personnes

Discussion en ligne Communément appelé « Chat »

Zone partagée d’écran où chaque utilisateur peut dessiner, afficher, écrire du texte, être vu.

Tableau partagé Utilisé en conception collaborative

Utilisation du multimédia pour accroître, améliorer la présence humaine dans les rencontres virtuelles

Vidéoconférence Rencontre virtuelle, cours, présentation, démonstration, etc.

Tableau 1 : Liste d’applications de base

La congruence de vue, d’espace et de temps

Tandis que la plupart des autres logiciels cherchent à cacher et à protéger les utilisateurs les uns des autres, les applications groupware font prendre conscience à l’utilisateur qu’il fait partie d’un groupe. Lynch, Snyder & Vogel, 1990

Réunions de petits groupes dans une pièce spécialement équipée:

WYSIWIS: What You See is What I See

WYSIAWIS: What You See Is Almost What I See.



WYSIWIS: congruence de vue stricte

WYSIAWIS: congruence relâchée

Figure 4: WYSIWIS / WYSIAWIS (Lynch, Snyder & Vogel, 1990)

Plusieurs classifications possibles selon :

Le temps, la distance et la taille du groupe.

La dimension partage et la dimension échange (ex: éditeurs partagés vs. e-mail).

Le côté restrictif (ex: workflow) ou au contraire permissif (ex: tableau blanc).

L’idéal de la production totale ou celui de la communication totale

Quelques points à considérer

Toute organisation intéressée à la e-Collaboration devrait se préoccuper des questions suivantes:

La direction de l’entreprise appuie-t-elle l’idée de faire de la e-collaboration ? Est-elle prête à s’engager activement dans le processus ? Possède-t-elle un plan d’action en matière de collaboration électronique ?

La direction peut-elle démontrer au personnel les avantages du recours aux outils collaboratifs ?

Le personnel de l’entreprise possède-t-il les qualifications requises pour utiliser les outils de collaboration choisis ? Si non, comment faire ?

Les pratiques de gestion de l’entreprise sont-elles alignées avec les objectifs qu’elle poursuit en prenant part à la collaboration. Par exemple, le mode de rémunération ou la description de tâches des employés incite-t-il ceux-ci à adhérer avec enthousiasme au projet collaboratif ? Dans le cas contraire, ils pourraient résister au changement.

Le processus de sélection et d’implantation des outils requis est-il adapté au contexte de l’entreprise, à son niveau de maturité technologique et à sa culture d’innovation ? À celle de ses partenaires?



L’entreprise avance-t-elle à petits pas, en utilisant d’abord les outils collaboratifs lorsque les bénéfices sont facilement identifiables et les chances de succès, importantes ? La visibilité d’un premier essai réussi aidera à aller plus loin à l’avenir.

L’entreprise a-t-elle les moyens financiers ? Se donne-t-elle le temps de réussir et d’obtenir un bon rendement sur le capital investi dans l’opération ?

L’entreprise a-t-elle l’équipement informatique requis pour faire de la collaboration électronique ?

L’information requise pour collaborer est-elle disponible au sein de l’entreprise et chez ses partenaires ?

Des dispositions ont-elles été prises par l’entreprise pour assurer que l’information est transmise en toute sécurité à ses partenaires et utilisée selon les modalités prévues ?

Les collaborateurs se sont-ils bien assurés que les données échangées seront en tout temps protégées des intrus ? Que les logiciels employés sont étanches ?

Comment les coûts et les bénéfices de la collaboration seront-ils partagés entre les partenaires ? Par exemple, dans les cas de collaboration avancée au stade de la R&D ou du design d’un produit, comment se fera le partage de la propriété intellectuelle ?

Malheureusement, le potentiel des TIC sur le plan collaboratif n’est pas toujours bien exploité. Cela s’explique en partie par la jeunesse de la e-collaboration comme champ d’étude. Par exemple, peu de travaux sont actuellement disponibles pour aider les organisations à choisir l’outil le mieux approprié à un contexte de collaboration donné. Cette sélection est encore plus difficile à réaliser lorsque les processus de collaboration ne sont pas bien formalisés. Cela dit, le succès en matière de e-collaboration est moins une affaire de technologie que de culture organisationnelle. Nos efforts dans le domaine ne donneront de bons résultats qu’à condition de faire un bon plan d’action et de tenir compte des attentes et des craintes de chaque collaborateur impliqué. Ici comme ailleurs, le défi consistera surtout à adapter les façons de faire des organisations, tant sur une base individuelle que collective.

De la gestion des émotions à la gestion des conflits

Le monde est habité d’humains eux-mêmes habités de projets et d’émotions. Le monde des projets informatiques vit, d’espoirs, de rêves et de réalités. Ainsi, pour obtenir l’adhésion à la stratégie définie par des décideurs et accompagner les changements nécessaires, il est utile de maîtriser les émotions et d’anticiper les conflits éventuels.

Selon A. Berthoz. Professeur au Collège de France, « les émotions jouent un rôle décisif dans plusieurs mécanismes de décision : sélection des objets dans le monde, guidage de l’action future en fonction du passé, flexibilité des choix de comportements ».

Le siège de nos émotions se situe dans le cerveau, au niveau du système limbique, qui gère notre « humeur ». Culturellement, l’homme occidental a une vision duale provenant de Socrate ou Descartes : le corps s’oppose à l’âme et la raison s’oppose à l’émotion !

Trois émotions sur quatre ont une connotation négative ! Transformer l’énergie dégagée par chaque émotion en une force d’action dynamisera le projet.



Pour Robert Zuili : « Les émotions fonctionnent comme un lion intérieur. Si on ne les laisse pas sortir régulièrement, elles peuvent se déchaîner brusquement ! Se taire, c’est laisser les tensions s’installer à coup sûr et augmenter les dérapages violents ».

Travailler ensemble est inhérent au travail en mode projet ; la cohésion d’équipe est nécessaire mais peut échouer si, en cours de projet, des conflits prennent le dessus. Une communication est à mener pour promouvoir et construire l’esprit d’équipe. Malgré tout, la pression induite par le triptyque « Coût – Délai – Performance » restreint souvent le spectre des émotions à un état de tensions pouvant évoluer en état de crise puis de conflit.

L’état de tension est souvent exprimé par un stress, une anxiété croissante engendrant une inhibition ou une agressivité, comme par exemple la définition des tâches dans un diagramme de Gantt. L’état de crise amène au blocage : non participation au dialogue, fuite, argutie ou mauvaise foi. Les problèmes sont exprimés sous forme de limites, par exemple « il n’est pas possible de savoir quand le travail risque d’être réalisé hors délai ».

4 temps pour lever la crise :

Description de la situation : Il s’agit de décrire la situation qui génère le problème en présentant les éléments factuels et précis : pas de généralisation ni d’accusation.

Expression du problème : exprimer le problème posé par la situation.

Proposition de solution : proposer une solution pour résoudre ou faire disparaître le problème. Se montrer constructif, demander aux interlocuteurs leur avis.

Mise en évidence des conséquences positives de la solution : présenter les conséquences positives de la solution pour la rendre séduisante.

Selon un expert international en systèmes d’information, le conflit est de 2 types :

Les conflits de fond qui se nourrissent de désaccords sur les fins et les moyens, des points de vue différents.

Les conflits émotionnels qui s'appuient sur des sentiments de colère : ce type de conflit peut être destructeur ou constructeur.

Mais les 2 conflits existent dans tous les projets parce que le projet est mené par des HUMAINS et que ces humains ont des antécédents (du vécu!).



C'est grâce ou à cause de ces antécédents, que les personnes sont capables de « PERCEVOIR un conflit » ou « RESSENTIR un conflit ». Le schéma ci-dessous illustre les 4 étapes du conflit.

AntécédentsAntécédents

Conflit manifeste

Résolution ousuppression du conflit

Conséquences du conflit

Conflit manifeste

Résolution ousuppression du conflit

Conséquences du conflit

Conflit ressentiConflit perçu

Figure 5 : Les 4 types de conflits

Les antécédents susceptibles d’amener un conflit sont l’interdépendance des flux de travail, l’ambiguïté de rôle, les obstacles de la communication, les conflits antérieurs non résolus, etc. Le conflit perçu est lié aux difficultés ou opposition entre les parties prenantes. Le conflit est ressenti quand se rajoutent les antécédents des personnes ou du projet.

Au stade du conflit manifeste, il y a en plus expression de violence avec un processus de rupture adossé à une volonté de modifier le rapport de force sur un point précis avec un gagnant et un perdant.

La prise de conscience de l’ensemble des dégâts potentiels siffle le coup d’arrêt du conflit. Une négociation entre les parties aboutit à une attitude constructive. Souvent le compromis nécessaire pour atténuer les effets secondaires préjudiciables aux parties prenantes est alors atteint. Pour chacune des parties, le conflit est souvent mal vécu. Même si la résolution du conflit peut renforcer la cohésion de l’équipe du projet, le conflit est pour un temps au moins, source de forte démobilisation puis de démotivation.

IV.1.3. Règles d’utilisation par équipe de projet de l’espace e-collaboratif

« Ce que tu gardes, est perdu à tout jamais. Ce que tu donnes, est à toi pour toujours ». Proverbe Soufi.

L’usage de l’espace e-collaboratif permet à chaque partenaire de l’équipe projet de pallier aux difficultés géographique, organisationnelle ou temporelle.



L’e-collaboration permet aux acteurs de l’équipe projet de réaliser un travail commun en partageant des idées, des informations et des résultats.

Mais pour faire de la collaboration électronique, il ne suffit pas d’utiliser les meilleurs outils technologiques de collaboration. Il faut aussi et surtout tenir compte des facteurs organisationnels.

La collaboration c’est d’abord un défi de gestion.

Règles d’utilisation de l’espace e-collaboratif BSCW du groupe IMI38F

Plan de classement des documents : Le classement se fera par ordre alphabétique pour une lisibilité de la base documentaire. Une éventuelle réorganisation pourra intervenir suite à une décision commune d’arborescence comme un plan provisoire de construction de nos écrits.

Format des documents : Les documents seront au format Word comme défini initialement afin de faciliter nos échanges respectifs.

Police des documents : La police utilisée sera la Times New Roman 11.

Gestion des versions des documents : Chaque version sera numérotée en x .x Un document issu d’un accord consensuel (réunion, conf call…) pourra être numérotée en x.0

Règles d’identification sur les documents : Chaque version complétée ou corrigée, comportera une couleur différente selon l’auteur afin de faciliter les identifications des auteurs multiples.

FORUM

Règles de courtoisie et de politesse : Inutile de rappeler que les règles, de courtoisie et de politesse, s’imposent. Le respect de soi commence par le respect de l’autre et vice et versa.

Règles de discussion : Il convient de pouvoir avoir une lecture partagée et équitable. Tout écrit nommant ou faisant référence à une personne doit être envoyé à la dite personne en tant que destinataire.

Forme : La forme est libre afin de faciliter nos échanges

Contenu et objet : Tous deux doivent apporter une plus value qualitative (informations, argumentations..) ou relationnel afin que le forum reste un forum ayant pour cadre notre travail collectif.

Remarques et compléments : Toute remarque et complément sont les bienvenus et seront lus avec intérêt afin d’optimiser au mieux notre travail collectif.

IV.1.4. Tableaux de bord

Un tableau de bord est un instrument de mesure de la performance facilitant le pilotage.

Le tableau de bord est un instrument d’aide au pilotage donnant aux acteurs, responsables, tous les éléments permettant de prendre visuellement et rapidement des décisions. Il sert à l’action, aide à effectuer des projections et à fixer des objectifs.



C’est aussi un outil de dialogue composé d’indicateurs significatifs, compréhensible par les différents acteurs impliqués dans l’usage de celui-ci.

Bien souvent, il est considéré comme un outil de contrôle. Le tableau de bord est un instrument de progrès permettant de suivre, de comprendre et d’améliorer un comportement du projet.

Les tableaux de bords peuvent avoir plusieurs rôles :

Rôle de description: c'est le rôle classique de tout document de synthèse. Il doit pouvoir donner une description de l'état réel à un moment donné.

Rôle de projection: les tableaux de bord doivent permettre, en se basant sur certaines tendances, de pouvoir contrôler l'évolution de certains indicateurs.

Rôle de simulation: les tableaux de bord doivent fournir la possibilité d'évaluer l'influence d'une action sur un processus ou sur un scénario.

IV.1.5. Capitalisation des connaissances

« Partager une valeur financière implique qu'on la divise. La connaissance, elle, est bien la seule valeur qui augmente lorsqu'on la partage ».

L'objectif des chefs d'entreprise est d'augmenter la productivité en améliorant l'organisation et en particulier, en diminuant le gaspillage par une réutilisation des savoirs et des savoir faire et des compétences développées au cours du temps. Un aspect important sera donc, en plus d'une bonne gestion du personnel, de mettre en place un système permettant de fournir à un individu l'information utile au moment où il en a besoin, dans les meilleurs délais, et de façon exploitable. En pratique, cette approche doit aussi permettre de sauvegarder le patrimoine intellectuel de l'entreprise, appelé capital immatériel ou avoirs intangibles.

La capitalisation des connaissances implique que l'on constitue un capital qui sera ensuite valorisé. Comme il est impossible de capitaliser toutes les connaissances de l'entreprise, on ne devra considérer que les connaissances qui seront jugées stratégiques pour certaines activités ; ceci, à la suite d’une analyse stratégique.



IV.2. Charte des valeurs de l’équipe de projet

IV.2.1. Constat des dysfonctionnements

C35 : Choc des cultures dans une structure associative

Contexte : création d'un ensemble de huit sites Web alimentés en contenu par les salariés dans un contexte associatif.

IV.2.2. Argumentaire expliquant ces dysfonctionnements

Site web 2004-2005 – 9 mois.

La nouvelle Direction Générale issue de la fusion de 2 associations avait pour objectif stratégique le rajeunissement de ses activités.

Elle propose rapidement la refonte de l’ensemble des sites web dans l’idée que ce projet soit moteur et contribue à relancer de manière significative les activités de celle-ci.

Pour mener à bien ce projet elle s’était entourée d’une nouvelle équipe de communication issue du secteur privé. Pensant bien faire, elle n’implique pas les collaborateurs concernés par la gestion des sites. Pour la DG il semblait que ce projet n’avait pas lieu de monopoliser les collaborateurs finaux durant la vie du projet que l’usage de l’outil, précédé d’une formation serait aisé et suffisant.

Par conséquent sa priorité était la mise en production rapide des sites web et qu’il n’y avait pas lieu de s’alarmer des différences culturelles d’entreprises

Dés le démarrage la MOA s’est difficilement approprier les informations nécessaires à la réalisation des sites internet. Celle-ci ayant que très peu de réactions de la part des collaborateurs, décide d’outrepasser certains choix.

Pendant la phase de production les collaborateurs impliqués ont éprouvé une certaine difficulté à s’approprier les nouvelles méthodes et ont fini par délégué à leur tour la gestion des sites voir pour certains l’abandonner.


Humaines : Lors de la composition de l’équipe de communication, la nouvelle DG a minimisé l’impact des différences culturelles. La précipitation du projet a amplifié cette situation .ayant pour conséquences des échanges tendus entre les différents collaborateurs.

Les effets :

Humains : L’équipe de communication a œuvré en faisant abstraction des collaborateurs concernés dans la vie des sites web jusqu’à la mise en production.



Organisationnels/humains : Adhésion difficiles des collaborateurs au projet car les valeurs véhiculées ne sont pas partagées. Rétention d’information lors des interviews rendant difficile le bon déroulement du projet.

IV.2.3. Pistes de solutions de progrès

Une réunion de crise a permis de remettre en bonne voie le projet Les différents acteurs ont pu exprimer officiellement leur attentes. La méthode de gestion de contenu des sites web a été revue. Un séminaire a été organisé dans le but d’intégrer la nouvelle équipe de communication.

IV.2.4. Facteurs clés de succès

Dans le cadre d’un projet où différents acteurs impliqués sont issus de culture d’entreprise différente il est essentiel :

De créer une synergie d’équipe dés le départ.

De prendre en compte la culture de l’entreprise afin d’obtenir plus facilement l’adhésion de tous.

De communiquer pour réduire les incompréhensions et le malaise des sous-entendus.



IV.3. Règles d’utilisation de l’espace e-collaboratif


C36 : La non rédaction d’une charte d’utilisation de l’espace e-collaboratif aboutit à une perte de corrections.

Contexte : La procédure de mises à jour des corrections sur l’espace e-collaborative n’a pas été suivie dans une PME


Période concernée : début 1997

Au début de la phase de production d’un nouveau projet majeur (développement d’un PGI), une PME éditrice de progiciels de gestion découvre la délocalisation et le travail e-collaboratif avec une équipe de développement située en Roumanie. Les équipes MOE françaises et Roumaines utilisent toutes les deux le progiciel de gestion de codes sources en réseau : Source Safe. Un développeur effectue une modification dans un module source en suivant depuis Source Safe la procédure suivante :

Le développeur « acquière » le module depuis le serveur sur son poste.

Le développeur réalise la modification sur son poste et identifie les lignes modifiées dans le code sources.

Le développeur valide ses modifications en mettant à jour le serveur Source Safe. Source Safe effectue automatiquement l’historisation des anciennes versions.

La procédure est classique et donne toute satisfaction localement tant en France qu’en Roumanie. Mais globalement il y a une difficulté car Source Safe ne prend pas en charge, à cette époque, le fonctionnement multi-sites ! Une procédure manuelle est nécessaire pour synchroniser les serveurs Source Safe français et Roumains. Un serveur FTP est mis en place pour la procédure de synchronisation. Une fois par semaine deux acteurs MOE l’un roumain et l’autre français sont chargés des actions suivantes :

Depuis Source Safe extraction de l’ensemble des modifications roumaines de la semaine.

Le vendredi avant 17h, mise à disposition des modifications dans un répertoire <date>\<modifications> sur le site FTP.

Le vendredi à partir de 17h30 intégration des modifications effectuées par les roumains et fusion manuelle des corrections.

Mise à disposition sur FTP des modules modifiés dans la semaine en France ou en Roumanie accessibles aux romains.

Au début 1997 un nouveau développeur roumain prit en charge cette procédure. Il fit sa première extraction en retard à 17h30 sans savoir que celle-ci avait été effectuée à 17h par l’ancien agent responsable de cette tâche. Seconde erreur, en faisant son extraction il créa sur



FTP un répertoire <jj-mm-aa> au lieu de <aa-mm-jj>. Deux répertoires étaient créés avec des noms différents.

Il est aisé de prévoir les conséquences de cet enchaînement d’erreurs : En France c’est le premier répertoire qui fut pris en compte, fusionnés et restitués en Roumanie. Des corrections avaient donc été perdues. L’erreur aurait été sûrement détectée si aucun répertoire n’avait été créé, car l’absence de répertoire aurait attiré l’attention.


Organisationnelle : Aucune charte d’utilisation de l’espace e-collaboratif (ici le site FTP) n’avait été rédigée : elle aurait permis de préciser la procédure (horaire et nomenclature des répertoires) à toute personne effectuant cette tâche. Aucun accompagnement n’a été prévu pour assurer les premières mises à jour.

Les effets :

Organisationnels : l’erreur n’a été détectée que plusieurs semaines après en phase de tests de qualification. Des développeurs roumains ont signalé les pertes de correctifs. Il a fallu retrouver via Source Safe les versions de modules contenant les corrections et les reporter dans la version actuelle des modules.


Ce dysfonctionnement a déclenché une étude pour rechercher la cause de la perte de correctifs. Elle a abouti à :

La définition de la procédure d’utilisation de l’espace e-collaboratif. En 1997 cette fonction se résumait à la synchronisation des sources (MOE) et au dépôt des analyses (MOA). Comment, quand, pourquoi et par qui doit être effectué le processus de synchronisation manuel de modifications.

Changement de la pratique MOE de synchronisation des sources côté français. Obligation de trier par date les répertoires pour détecter les répertoires créés en double.


D’une manière générale il est important de formaliser dans un document les processus métiers. Les processus manuels sont une source d’erreurs importantes. Le plus souvent l’espace e-collaboratif vient en support de processus manuels pour des personnes travaillant à distance. Cela renforce la nécessité de rédiger une charte d’usage de l’espace e-collaboratif. Elle doit formaliser les règles d’utilisation de l’espace et répondre aux questions : qui, quand, quoi, pourquoi, comment ?



IV.4. Règles d’utilisation par l’équipe de projet de l’espace e-collaboratif


C37 : MOE : mauvaise utilisation de l'espace collaboratif.

Contexte : La non complétude fonctionnelle d’un espace e-collaboratif conduit à mauvais usage - IMI


Période concernée : 2008

Le 1er contrôle commun de la promotion IMI38F dont le thème est « la pathologie des projets informatique » a été l’occasion d’utiliser la plateforme collaborative BSCW. Développée en Allemagne il y a quelques années dans le cadre d’un projet européen la plateforme BSCW offre un accès gratuit pour tous dont le but est de : partager, notifier, discuter, échanger autour d’un projet.

Lors de la phase de cadrage du projet, il a été convenu d’utiliser BSCW pour le projet commun. Après quelques semaines d’usage une frustration des utilisateurs s’est fait ressentir :

L’espace a été utilisé uniquement pour le dépôt et le partage des fichiers. Pire pour palier aux périodes d’inaccessibilité du serveur BSCW (maintenance ou autres), le dépôt des fichiers sur l’espace e-collaboratif était doublé de courriels incluant le fichier en pièce jointe. Par ailleurs la fonction d’abonnement à la notification journalière des modifications apportées à l’espace e-collaboratif n’a pas pu être activée. Enfin la notion de discussion n’avait pas, semble-t-il, une ergonomie suffisante : pour savoir si une réponse avait été apportée dans une discussion, il fallait entrer dans la discussion. Ces manques fonctionnels ont complètement dévié l’usage normal de la plateforme e-collaborative.


Techniques : le manque fonctionnel de la plateforme conduit à un usage restreint au simple partage de fichiers.

Humaine : le temps d’appropriation et de recherche de solutions sur l’outil n’a peut-être pas été suffisant.

Les effets :

Organisationnels : certaines mises à jour de fichiers se sont effectuées uniquement par échanges de courriels au lieu de passer par l’espace e-collaboratif.

Humains : les membres de l’équipe ont été « déçus » par l’espace BSCW.




Pour comparer avec d’autres espaces e-collaboratifs et pallier aux dysfonctionnements rencontrés, un espace Mayetic plus ergonomique et plus complet (agenda, notification aisée, planning…) a été ouvert pour la fin du projet. Cet espace collaboratif, de conception française, a été davantage apprécié par l’équipe projet.


La sélection d’un espace e-collaboratif doit offrir au minimum le fonctionnel suivant :

Gestion des utilisateurs (rôle d’administrateur de l’espace).

Création d’arborescences.

Dépose de fichiers et modification de fichiers.

Abonnement des utilisateurs au système notification journalière des nouveautés (créations, modifications…) ou facilité de notification des événements créés, modifiés ou détruits.

Notion de discussions ergonomiques.



IV.5. Tableaux de bord


C38 : De l’intérêt de mettre en place un indicateur de production.

Contexte : MOE : La non réactualisation des estimations en fonction du réalisé conduit à dérapage du projet dans une PME



Le projet majeur d’une PME, éditrice d’un nouveau PGI eurocompatible, se focalise sur la production d’un module de liasse fiscale. Le projet consistait à :

Définir et mettre en place la base de données financière : c'est-à-dire définir les cellules et formules de chacune des cases de la liasse fiscale (Bilan actif, passif, compte de résultat, Soldes intermédiaires de gestions…)

Composer les documents de la liasse fiscale (2050,2051…)

Développer la fonction de mise à jour des cumuls de la liasse à partir des cumuls comptables.

Offrir une traçabilité totale : depuis une cellule d’un document de la liasse fiscale, permettre de visualiser la formule, les comptes concernés, le détail des mouvements de comptes et remonter jusqu’aux écritures comptables impliquées. Cette traçabilité autorise une grande avancée dans la fonction de révision comptable.

Pour ce projet une personne était dédiée à la composition des documents de la liasse (25 documents en tout). La MOE avait planifié 50 jours pour cette tâche, en moyenne 2 jours par document. Quinze jours après le lancement de cette activité, une réunion du comité de pilotage général du projet (PGI) se tint.

Le responsable du projet, « surbooké », n’avait pas actualisé le planning concernant cette tâche en fonction du réalisé des 2 premières semaines, d’autant que la tâche ne faisait pas partie du chemin critique du projet. Il s’était contenté de noter le temps passé sur cette activité sans prendre en compte le nombre de documents réellement traités. Au lieu des 2 jours prévus par document, le réalisé montrait qu’il avait fallu 3,3 jours. L’attention ne fut pas portée sur cette dérive du projet ni aux moyens qu’il aurait fallu consacrer pour remédier au problème de production de la liasse fiscale.

Deux semaines se passèrent avant que le chef de projet ne réalise la conséquence de la non prise en compte de l’indicateur de production de cette activité : délais / nombre de document traités. La réalisation des documents de la liasse allait prendre 3 mois au lieu des 2 prévus ! La tâche entrait du coup directement dans le chemin critique de sortie commerciale du produit !




Humaine : le chef de projet n’a pas pris le temps de suivre son indicateur « délais / nombre de documents réalisés » fixé initialement à 2 jours/document. Avant que celui-ci n’atteigne 3 il aurait du réagir pour libérer une autre personne en renfort sur cette activité.

Organisationnelle : le chef de projet trop impliqué lui-même directement dans la réalisation du projet n’a pas libéré assez de temps au suivi du projet.

Les effets :

Organisationnels : le comité de pilotage a été informé tardivement de cette dérive. Certain développements ont été retardés pour pouvoir achever la composition des documents de la liasse fiscale.


Une fois saisi du problème de dérive de cette activité, le comité de pilotage du PGI a du affecté deux personnes supplémentaires pour achever la réalisation de la liasse fiscale. Ceci fut fait au détriment d’une autre activité moins prioritaire.


La fonction de suivi de projet est essentielle pour réagir à temps à toute dérive. Elle mérite d’y consacrer le temps nécessaire. Pour cela il convient que le chef de projet puisse matériellement avoir le temps de suivre correctement son projet.

Les indicateurs de suivi de projet ou d’activité tournent essentiellement autour des 3 axes suivants : Performance, Coût, Délais. Il n’est pas toujours aisé de définir, d’alimenter et de suivre un indicateur pertinent pour le suivi d’une activité de développement.

Mais pour une activité récurrente, ici 25 documents à réaliser, de difficulté sensiblement identique, il est aisé de mettre en place un indicateur de productivité comme : « délais de réalisation » / « nombre de documents produits » ou l’inverse. Ces indicateurs donnent le délai moyen de production d’un document ou le nombre moyen de document produit par jour. Actualisé chaque semaine, ces indicateurs peuvent permettre une réaction rapide en cas de dérive.



IV.6. Capitalisation des connaissances


C39 : Prendre conscience de l’intérêt de la phase de capitalisation d’un projet.

Contexte : Mauvaise capitalisation des connaissances dans un TPE



Une entreprise spécialisée dans la conception d’une solution web de partage d’information sort une nouvelle version de son produit phare. Cette nouvelle version implique une procédure de mise à jour complexe et longue. Un premier client fait le choix de migrer sur la nouvelle version. Pendant la procédure de migration un problème technique survient. Après moult tentatives infructueuses, la procédure est passée sous débogueur pour constater les erreurs.

Différentes erreurs sont trouvées dans les scripts de migrations, ils sont corrigés mais d’autres interventions manuelles sont nécessaires pour parvenir au terme du changement de version. Finalement la nouvelle version du progiciel a pu être installée et le client fut satisfait mais plusieurs jours de travail ont été nécessaires. Un document relatant les difficultés rencontrées dans cette première migration a été produit pour resservir lors d’un prochain upgrade client.

Quelques mois plus tard un second client se propose de passer à la nouvelle version. Le document constitué à la première tentative n’est pas retrouvé dans l’application du système de partage d’information. Bien que disposant d’un mécanisme puissant d’indexation, le document reste introuvable, aucun mot clé ne permet de le trouver.

Le dossier « électronique » de documentations techniques de l’entreprise ne contient pas l’événement contenant le document recherché. Que s’est-il passé ? De lourdes recherches ont été nécessaires pour retrouver le document. La personne avait bien créé un événement dans l’application mais, sans doute dérangée dans son action, elle n’avait ni indiqué de titre ni donné un objet à l’événement qui auraient permis de le retrouver. Par ailleurs elle n’avait pas classé l’événement dans le dossier de documentation technique. C’est la conjugaison des deux fautes qui posa ici problème, une seule des deux fautes aurait permis de retrouver plus facilement le document.


Humaines : la procédure de capitalisation n’a pas été respectée. Le document a été créé mais n’était pas exploitable lorsqu’il a été nécessaire de l’exploiter.

Organisationnelles : la procédure de capitalisation ne sert à rien si elle ne garantit pas que le document de capitalisation est pertinent et accessible.

L’effet :

Organisationnel : perte de temps.




L’événement de capitalisation fut retrouvé par une analyse systématique des événements enregistrés dans l’application de partage pour la période correspondant à la première migration client. Une nouvelle procédure de capitalisation a été définie en ajoutant les étapes suivantes :

Notification automatique d’un responsable pour chaque nouveau document de capitalisation déposé.

Recherche dans la base du document par le responsable (dossier de classement et mots clés).

Relecture par le responsable du document : est-il compréhensible, pertinent ?


La phase de capitalisation est l’une des phases finales d’un projet informatique. Elle n’en est pas moins indispensable au même titre que toute autre documentation technique.

La capitalisation pour être utile se doit d’être:

Pertinente et compréhensible par quelqu’un qui n’a pas suivi le projet.

Accessible aisément (classement, mots clés…).



IV.7. Capitalisation des connaissances du MPeCLes projets e-collaboratifs ne sont pas encore les plus nombreux. La difficulté à recenser parmi nous des cas de dysfonctionnements vécus en atteste : seuls deux personnes sur les six ont vécu de telles situations et seulement 6 expériences de dysfonctionnements ont pu être remontées.

Que ce soit pour le développement d’un projet e-collaboratif ou pour un projet de partage de l’information au sein de l’entreprise, le constat est le même : l’implication et l’adhésion des équipes au projet de collaboration ou de partage est essentiel à la réussite du projet.

Dans le cadre d’un projet de partage de l’information en entreprise quel intérêt le collaborateur trouve-t-il dans le fait de partager une information qu’il détient ? Cela peut être vécu par lui comme une perte de pouvoir et souvent des réticences se font jour. La solution passe nécessairement par :

Analyser les enjeux : qui a naturellement intérêt à partager, qui ne l’a pas ?

Développer l’adhésion au projet pour lever les blocages.

Favoriser au maximum le gain d’usage pour le collaborateur dès la mise en place de la solution de partage : présence de l’annuaire complet des collaborateurs, clients, fournisseurs.

S’assurer de l’implication sans faille des équipes dirigeantes qui doivent jouer le jeu en montrant l’exemple dans l’usage et le partage d’information.

Développer une pédagogie qui reconnaît et récompense l’acte de partage.

Mettre en place des indicateurs montrant au bout de quelque mois l’efficacité du système de partage : exemple d’indicateurs : satisfaction des utilisateurs ; baisse de la durée et du nombre d’appels internes en fonction de l’usage croissant de l’espace de partage ; nombre d’événements partagés…

De même dans un projet e-collaboratif il peut y avoir une certaine résistance à l’usage de la plate-forme collaborative. Quels intérêts ai-je à l’utiliser ? La plate-forme e-collaborative se résume-t-elle à un simple partage de fichiers ? Comment mesurer l’usage de la plate-forme e-collaborative ?

Les 5 items choisis : Charte des valeurs du projet, Charte d’utilisation de l’espace e-collaboratif, Règles d’utilisation par équipe de projet de l’espace e-collaboratif, Tableaux de bord et Capitalisation des connaissances permettent de favoriser l’usage des bonnes pratiques à développer dans le cadre d’un projet e-collaboratif.

La charte des valeurs du projet

La charte des valeurs du projet est probablement encore plus nécessaire dans un projet e-collaboratif que dans tout autre projet. Un projet e-collaboratif met souvent en jeu des équipes distantes, de langues et de cultures différentes… Pour mieux partager le but du projet, il faut aussi partager la façon de travailler. Se mettre d’accord, ensemble, sur une charte des valeurs du projet cela permet :

De mettre en évidence les différences culturelles qu’il est nécessaire de respecter.

De s’accorder sur les valeurs partagées par les équipes et les classifier.



De se mettre d’accord sur la façon de communiquer.

De fédérer les équipes du projet : chacun s’engage à respecter la charte négociée.

L’absence de charte ou l’adoption d’une charte non réellement négociée et partagée peut perturber le déroulement du projet, voire être une cause d’échec.

Charte d’utilisation de l’espace e-collaboratif

L’importance que revêt la formalisation des processus métiers de l’entreprise est de plus en plus répandue. L’usage qu’il doit être fait de l’espace e-collaboratif se doit aussi d’être formalisé. La charte d’utilisation de l’espace e-collaboratif permet de préciser :

Quelles personnes utilisent l’espace et avec quels rôles ?

Quelles procédures sont mises en places ? Que gèrent-elles ?

Comment et quand mettre en œuvre les procédures définies ?

En l’absence d’une charte d’utilisation de l’espace e-collaboratif bien définie, accessible et partagée de tous le projet encourt des risques importants de perturbations :

Interventions malencontreuses de personnes non compétentes.

Non exécution de procédures définies.

Exécution inopportune des procédures (mauvais moment…).

Règles d’utilisation par équipe de projet de l’espace e-collaboratif

Il est important de s’assurer que la plate-forme collaborative répond bien aux exigences de fonctionnement du projet e-collaboratif. Le risque est de voir l’espace e-collaboratif réduit à un simple espace de partage de fichiers. D’une manière générale, un minimum de services doit être proposé par la plate-forme collaborative :

Définition des rôles de chacun au sein de l’espace : administrateur, utilisateur.

Système d’arborescence de dossiers et d’événements commentés supports de pièces jointes (fichiers).

Système de notification aisée des modifications (ajout, suppression, modification des événements)

Notion de discussion ergonomique.

Evénements de typés : planning…

Nous avons eu l’expérience d’une plate-forme qui ne répondait pas complètement à ces critères et qui fut mal utilisée.

Tableaux de bord

La définition de tableaux de bord pour la conduite et le pilotage de projets informatiques, e-collaboratifs ou non, répond le plus souvent à des exigences de mesure de la performance, des délais et/ou des coûts. La définition d’un indicateur pertinent prend bien évidemment du temps. Son alimentation et son suivi aussi. Son intérêt est qu’il apporte une vision instantanée et



parlante de l’état d’avancement d’une activité. Il autorise aussi une réaction rapide en cas de dérive. La valeur ajoutée qu’apporte un tableau de bord au pilotage d’un projet est évidente. Il convient de :

Définir les bons indicateurs : ils doivent être parlant, significatifs et peu nombreux.

S’assurer de la bonne remontée des informations nécessaires aux indicateurs : fiabilité et fréquences des données remontées.

Capitalisation des connaissances

La phase de capitalisation des connaissances est une phase essentielle d’un projet quel qu’il soit. Elle consiste à dresser un bilan sur la réalisation du projet dans le but de faire fructifier le capital des connaissances acquises par les équipes pendant le projet.

Ne pas capitaliser les connaissances acquises c’est s’en remettre ultérieurement à la mémoire de personnes qui ne seront peut-être plus présentes dans l’entreprise. C’est aussi priver les autres équipes du retour d’expérience acquis sur le projet. C’est accroître délibérément aujourd’hui le coût des projets de demain.

La collaboration c’est avant tout accepter de coopérer et de communiquer.



Conclusion

Respect de nos engagements

Dans le cahier des charges définitif (voir III.3.3 de l’Annexe 2) l’équipe IMI38F s’est engagée à mesurer la couverture des solutions proposées aux dysfonctionnements identifiés. Sur les 39 cas de dysfonctionnements étudiés, il a été proposé :

Une ou plusieurs solutions de progrès proposées : 97,4% ;

Un ou plusieurs facteurs clés de succès : 100%.

Par ailleurs, nous avions proposé de mesurer le respect des engagements de livraison (livrables et échéances). Nous avons respecté l’ensemble de nos engagements prévus au cahier des charges en ce qui concerne les livrables tant en termes de contenu, de support qu’en termes de respect des échéances.

IMI : quand innovation rime avec formation…

14 semaines soit 100 jours à voyager au cœur des « Pathologies des Projets Informatiques » ! Un voyage offert par le Directeur de l’IMI, pour nous inciter à découvrir des trésors que sont les pratiques (bonnes ou mauvaises) des personnes qui nous entourent et qui un jour ont eu à conduire ou à faire partie d’un projet informatique.

Le recensement des dysfonctionnements réalisés par chacun d’entre nous a été source de partage et de discussion au sein du groupe. Leur analyse nous a conduits à nous interroger sur les principales causes ainsi qu’à leurs effets, que nous avons détaillés dans ce rapport.

Nous avons également proposé des pistes de progrès et dégager des facteurs clés de succès.

En plus du bénéfice retiré du recensement et de l’étude des dysfonctionnements vécus par l’un ou l’autre des membres de l’équipe, cette étude nous a permis de « doubler nos gains » en appliquant à nous-mêmes dans le cadre de notre projet, la plupart des phases des 3 mini-projets : Rédaction du cahier des charges, Réunion de cadrage, management structuré du projet (comité de pilotage, définition et répartition des activités, planning, fiches missions…), Management des équipes du projet (définition des équipes et rôles de chacun, charte de valeurs, communication, concertation…), Travail e-collaboratif (charte de l’espace e-collaboratif, travail collaboratif, capitalisation,…).

Au-delà de la production de ce rapport, cette expérience nous a ouvert les yeux, nous a rendus plus rigoureux et en même temps, plus flexibles. La nécessité de travailler ensemble, de collaborer, nous a amené à mettre en place des modes de fonctionnement particuliers, des stratégies de communication et de partage de l’information. Il nous a fallu faire converger nos visions pour aboutir à un document cohérent. Surtout, il a fallu que nous nous « apprivoisions »



afin de tirer le meilleur de chacun de nous. Les péripéties vécues durant cette période ont inévitablement créé une cohésion qui a permis de forger notre équipe.

Les enseignements les plus importants de ce projet ont été la difficulté à stabiliser une équipe, mettant en évidence la fragilité de l’homme face aux perturbations techniques, organisationnelles et émotionnelles. Plongé dans un univers instable, le plus pragmatique des hommes peut effectuer des choix totalement en décalage avec ceux qu’il réaliserait s’il analysait la situation d’un œil totalement extérieur.

Ceci amène à penser qu’il serait intéressant de disséquer les mécanismes mentaux qui amènent les hommes à procéder à certains choix, que l’on pourrait qualifier d’improductifs, voire d’absurdes. Mais cela pourrait faire l’objet d’une autre étude …

En nous inscrivant à l’IMI, nous pensions suivre une formation classique avec des études de cas classiques et des projets classiques. Or, c’est tout sauf « classique »… c’est INNOVANT !



Bibliographie

Articles

Van Hoorebeke Delphine, « La gestion des émotions au travail : responsabilité sociale mystique de l’entreprise ? », 2005.

Ouvrages

Fichter D., “The Many Forms of E-Collaboration: Blogs, Wikis, Portals, Groupware, Discussion Boards, and Instant Messaging Online”. Medford: Jul/Aug 2005. Vol.29, Iss. 4; 48-50.

Kock N., Davison R., Ocker R. and Wazlawick R., “E-collaboration: A look at Past Research and Future Challenges,” J. Syst. Inform. Technol., vol. 5, no. 1, 1-9, 2001

Odier F, « Gestion des projets informatiques », Université Joseph Fourier - MIAGE 3, Gestion de Projet Informatique, 17 septembre 2004.

Printz J. et Mesdon B., « Ecosystème des projets informatiques », Hermes-Lavoisier , 2006.

Saadoun M.; « Technologies de l’information et management », Hermes, 2000.

Saadoun M.; « Piloter le changement avec les cybertechnologies », Hermes-Lavoisier, 2002.

Support de cours

Joskowicz J., « Le Management Structuré de Projet », support de cours du 18/03/2008, IMI.

Saadoun M., « Management des TIC et Management des Equipes de Projet », support de cours du 19/03/2008, IMI.

Pages Web visitées

Quelques références sur le thème « Pathologie des projets informatiques » :

http://www.clubmoa.asso.fr/article.php?sid=54

http://www.informatique.weka.fr/affichage/dispMain.asp?ngcmid=WK4200801


http://www.informatique.weka.fr/affichage/dispMain.asp?ngcmid=WK4200801



http://209.85.129.104/search?q=cache:gAGCt41YY9EJ:stspirit.free.fr/cours/CoursMiage3/semestre1/GPI/GPI%2520-%2520le%2520poly%25202005.doc+pathologie+des+projets+informatiques&hl=fr&ct=clnk&cd=5&gl=fr&lr=lang_fr

Quelques références sur la « Gestion des émotions » :


http://www.sante-psychologie.com/emotions/

http://www.com-unique.org/out_espr.htm

http://www.verselejus.com/La-gestion-des-emotions.html

http://www.phosphenisme.com/z_emotions.html

http://www.nutrition-valley.com/modules-nutrition-valley/gestion-emotions.php

http://www.ssd.u-bordeaux2.fr/faf/archives/numero_8/articles/meidani.htm

http://www.lentreprise.com/3/2/2/article/15139.html

http://www.psychologue.levillage.org/aphasie.html

Quelques références de « normes et méthodologies de conduite de projet informatique » :

Software Engineering Institute : détenteur du modèle : http://www.sei.cmu.edu/

http://fr.wikipedia.org/wiki/Capability_Maturity_Model_Integration

http://www.fimarkets.com/pages/cmmi.htm

http://www.xdocs400.com/spip.php?article3

http://fr.wikipedia.org/wiki/Prince2

http://www.univ-angers.fr/docs/etudquassi/MP08_12.pdf

http://www.pmi.org

http://www.iso.org/iso/fr/iso_catalogue/management_standards/iso_9000_iso_14000/iso_9000_essentials.htm




http://www.pmi.org/

http://www.univ-angers.fr/docs/etudquassi/MP08_12.pdf

http://fr.wikipedia.org/wiki/Prince2

http://www.xdocs400.com/spip.php?article3

http://www.fimarkets.com/pages/cmmi.htm

http://fr.wikipedia.org/wiki/Capability_Maturity_Model_Integration

http://www.sei.cmu.edu/

http://www.psychologue.levillage.org/aphasie.html

http://www.lentreprise.com/3/2/2/article/15139.html

http://www.ssd.u-bordeaux2.fr/faf/archives/numero_8/articles/meidani.htm

http://www.nutrition-valley.com/modules-nutrition-valley/gestion-emotions.php

http://www.phosphenisme.com/z_emotions.html

http://www.verselejus.com/La-gestion-des-emotions.html

http://www.com-unique.org/out_espr.htm

http://www.sante-psychologie.com/emotions/






Annexes

Annexe 1 : Cahier des Charges provisoire du 18 mars 2008

Annexe 2 : Cahier des Charges définitif du 31 mars 2008

Annexe 3 : Plannings du projet

Annexe 4 : Interviews de spécialistes du thème (J. Printz et F. Odier)

Annexe 5 : Comptes-rendus des 3 revues de projet

Annexe 6 : Fiches mission de l’équipe IMI38F

Annexe 7 : Normes et méthodes pour projets informatiques

Annexe 8 : Questionnaire utilisé pour identifier les dysfonctionnements

Annexe 9 : Dysfonctionnements (base de connaissances annexe)

Annexe 10 : Recommandations



Annexe 1 : CdC provisoire du 18 marsCahier des Charges provisoire du Contrôle des connaissances n°1

Promotion Février 38 (version du 18 mars 2008)

Thème du contrôle : Pathologie des projets informatiques

Encadrement du contrôle : Mélissa Saadoun et Jean Joskowicz, chargés respectivement des cours

« Management des TIC et Management des Equipes de projet »

« Principes du Management Structuré de projet »

But de cette pédagogie :

1. Responsabiliser et aider l’auditeur à s’approprier la connaissance du management.

2. Le rendre plus autonome dans son rapport à la connaissance tout en faisant l’expérience de la solidarité en équipe.

3. L’entraîner à faire preuve d’initiative et d’engagement pour s’approprier les connaissances requises en management des systèmes d’information et en particulier en management de projets.

Objectifs :

Passer à l’acte et partager des savoirs et des retours d’expérience d’entreprise autour d’un thème brûlant (ci-dessus).

Vivre une expérience humaine commune pour enrichir ses démarches ultérieures dans son métier de demain.

Utiliser les technologies collaboratives pour formaliser et capitaliser les travaux réalisés en commun.

Déposer dans les délais requis les résultats à l’IMI et enrichir son fonds commun de savoirs et savoir-faire.

Sujet du contrôle :

Mini projet Tronc (travaux réalisés en commun autour des délégués de promotion) : Démarche de Management Structuré de Projet :

1. Expression des besoins

2. Découpage en phases et panorama des outils

3. Phase de Planification et Gestion du temps

4. Phase de Lancement

5. Phase de Production

6. Phase de Pilotage.



Mini projet 1 (sous-groupe 1) : Management des équipes de projet :

1. Gestion de ses priorités

2. Gestion des priorités collectives

3. Management d’équipes de projet

4. Implication des utilisateurs

5. Soutien DG

Mini-projet 2(sous-groupe 2) : Management de projets e-collaboratifs :

1. Charte des valeurs de l’équipe de projet

2. Charte d’utilisation de l’espace e-collaboratif

3. Utilisation par équipe de projet de l’espace e-collaboratif

4. Tableaux de bord

5. Capitalisation des connaissances.

Résultat escompté et livrables remis au pilote d’ensemble de l’IMI :

1. Pour chaque item ci-dessus (sous Word) :

1. Constat des dysfonctionnements dans votre entreprise

2. Argumentaire expliquant ces dysfonctionnements

3. Pistes de solutions de progrès

4. Facteurs clés de succès (FCS).

2. Copie du support PowerPoint de la présentation au jury.

3. La rédaction d’un Road book (facultatif et non évalué) est recommandé. Ce document tracera le vécu du groupe (expression libre).

Date de présentation de ce contrôle : fin juin 2008.

Constitution des deux sous-groupes et désignation des rapporteurs : le 19 mars 2008. Chaque sous-groupe choisit un des deux mini-projets (hors du tronc commun).

A préciser pour le 31 mars 2008, au plus tard, afin de déboucher sur un cahier des charges définitif:

1. Composition des sous-groupes : décidé par chaque auditeur.

2. Méthode et dynamique de travail en équipe auto-organisée : décidé par chaque sous-groupe

3. Pilote et rapporteur : décidé par chaque sous-groupe

4. Outillage collaboratif : décidé par chaque sous-groupe

5. Métrique : décidé par chaque sous-groupe.



Déroulement du contrôle : Trois points de contrôle (d’avril à juin) en présentiel à l’IMI avec Mélissa Saadoun et Jean Joskowicz (durée : une heure par rencontre). Ces derniers seront également accessibles à distance en cas de besoin.

Travaux en mode coopératif : à distance et sur place pour les auditeurs.

Outillage : intranet de l’IMI et autres

Echanges : outils au choix des auditeurs (Open Source, autres)

Dépôt des résultats définitifs : remise du texte Word + PowerPoint à l’IMI au plus tard le 15 juin 2008.

Ces espaces collaboratifs ne seront pas ouverts au grand public. Chacun respectera la charte d’utilisation et de conduite responsable (à concevoir par les auditeurs).

Contrôle du jury : chaque sous-groupe présente en 30 minutes le résultat de ses travaux.

Evaluation : auto-évaluation par chaque sous-groupe.

« Maître d’ouvrage » : Gérard Balantzian, directeur de l’IMI.



Annexe 2 : CdC définitif du 31 marsAprès analyse, étude et ajustements, le cahier des charges du projet Pathologies des Projets Informatiques a été rédigé et envoyé à la MOA le 30 mars. La MOA a définitivement validé le CdC du projet le 31 mars 2008 que nous reprenons ci-dessous.

I – Processus de gestion du RBA

L’objectif du document « Recueil des Besoins et Analyse » (RBA) est de décrire les besoins du client (voir chapitre III §2, §3 et chapitre IV §1)), de définir quels seront les livrables à fournir (cf. chapitre IV) pour répondre à ces besoins et les délais y afférent.

Le RBA décrit également les documents de travail et les règles, convenus entre le client et le fournisseur (l’équipe de projet : voir chapitre II), nécessaires à la réalisation de cette étape (voir chapitres III.4. et III.5.).

Ce document précise les attentes du client (définis dans son cahier des charges provisoire du 18 mars 2008 et complété par le questionnaire MOA) et permet aux deux parties de valider leur compréhension mutuelle.

I.1. Gestion du RBA

Rédacteurs Vérificateur(s) Approbateurs

Nom Visa Nom Visa Nom Visa

Fattah Abdessadak FA Laurent Carette LC Mélissa Saadoun MS

Pierre-Yves Arrades PYA Jean-Luc Fiquet JLF Jean Joskowicz JJ

Laurent Carette LC

Napoléon Djen ND

Yvan Erard YE

Jean-Luc Fiquet JLF

I.2. Gestion des versions du RBA

N°version Date Auteur Action Nom fichier

2.0 30/03/2008 IMI38F Validation MS+JJ RBA-CDC_v2.03.doc

3.0 31/03/2008 IMI38F Validation Client RBA-CDC_v3.00.doc



I.3. Validation du RBA

A chaque modification du RBA, le responsable de projet valide le nouveau document.

Référence : RBA-CDC Créé le 30/03/2008 Version : n° 2.0

X Document validé par l'équipe pédagogique, le 30 mars 2008 version 2.00X Document validé par le chef de projet le 31 mars 2008 version 2.03X Document déposé au client le 31 mars 2008 version 2.03 Document validé par le client le Commentaires :

II - Principaux acteurs du projet

II.1. Client du projet (MOA)

Nom Fonction E-mailGérard BALANTZIAN (GB) Directeur IMI [email protected]

II.2. Equipe de projets (MOE)

Nom Mini-projet, rôle E-mail

Napoléon DJEN (ND) MP1, [email protected]

Laurent CARETTE (LC) MP1, Pilote MP1 [email protected]

Yvan ERARD (YE) MP1, Rapporteur [email protected]

Fattah ABDESSADAK (FA) MP2, Pilote MP2 [email protected]

Jean-Luc FIQUET (JLF) MP2, Chef de projet [email protected]

Pierre-Yves ARRADES (PYA) MP2, Rapporteur MP2 [email protected]

II.3. Equipe pédagogique

Nom Rôle E-mail

Mélissa SAADOUN (MS) Intervenant IMI [email protected]

Jean JOSKOWICZ (JJ) Intervenant IMI [email protected]

II.4. Rôle et responsabilités des acteurs du projet

Le client, représenté par Gérard Balantzian, exprime de façon concise ses besoins, fixe l’objectif du projet et valide les livrables du projet.

Le chef de projet (JLF) informe le client sur les solutions retenues pour réaliser le projet ainsi que sur son avancement. Il veille à la cohérence globale du projet et au respect des délais. Il est


mailto:[email protected]









le pilote et le rapporteur pour le tronc commun. Il diffuse les informations aux pilotes et rapporteurs de chaque sous-groupe de projet.

L’équipe projet est constituée de 2 sous-groupes. Chaque sous-groupe possède un pilote et un rapporteur.

Le pilote assure l’animation et la bonne conduite du groupe. Il informe l’équipe pédagogique de tout changement dans l’organisation du sous-groupe.

Le rapporteur assure la distribution et la restitution des livrables au client. Il est le garant du respect des échéances. De même, si des documents sont émis par le client (MOA), c’est lui qui est en charge de les faire suivre au groupe et aux sous-groupes.

Si cela s’avère nécessaire, la désignation du pilote comme du rapporteur peut être changée par le groupe ou le sous-groupe. Dans ce cas, le nouveau rapporteur en informera le client et l’équipe pédagogique.

L’équipe projet doit fournir dans les délais impartis, les livrables répondants au cahier des charges.

L’équipe pédagogique (Mélissa Saadoun et Jean Joskowicz) a pour rôle de conseiller et d’encadrer l’équipe de projet et/ou de lui fournir tout moyen lui permettant de mener à bien son projet.

III - Recueil des besoins

III.1. Présentation du client

La société cliente du projet est l’IMI, acronyme de l’Institut de Management de l’Information. L’IMI est l’antenne parisienne de l’Université de Technologie de Compiègne (UTC), organisme public de formation reconnu en France pour la qualité des diplômes délivrés.

L’IMI a été créé par l’UTC en 1974 et compte actuellement 3 personnes salariées. Elle est représentée par son directeur, Gérard BALANTZIAN.

L’IMI a été parmi les toutes premières institutions à proposer un cycle de formation sur le Management des Systèmes d’Information.

Son activité consiste à recruter des « étudiants » dans le cadre de la formation continue, organiser le cursus du cycle de formation en sélectionnant les cours et les intervenants, accueillir, suivre et assister les « étudiants », organiser le contrôle continu et délivrer le diplôme de master en conception et management des systèmes d’information.

Dans le cadre des projets qu’il commandite, l’IMI a mandaté la promotion 38 Février (IMI38F) pour réaliser une étude portant sur le thème « Pathologies des projets informatiques » comportant de 3 mini projets :

Mini-projet Tronc : démarche de management structuré de projet.

Mini-projet 1 : Management des équipes de projet.

Mini-projet 2 : Management des projets e-collaboratifs.



III.2. Objectifs du projet

L’objectif du projet est de mener une étude sur les pathologies des projets informatiques qui se concrétisera par la fourniture au client d’une liste de livrables, au plus tard le 15 juin 2008 (cf. livrables au IV.1).

Mini-projets

Pour chacun des 3 mini-projets les aspects suivants seront traités :

Constat des dysfonctionnements dans votre entreprise (pouvant être enrichi d’autres expériences).

Argumentaire expliquant ces dysfonctionnements.

Piste de solution de progrès.

Facteurs clés de succès (FCS).

Adéquation du sujet au thème de l’étude

Les 3 mini-projets couvrent l’ensemble du cycle de gestion d’un projet informatique depuis la gestion des besoins jusqu’à la phase de pilotage, en couvrant les aspects humains des équipes de projets tant en entreprise qu’en mode e-collaboratif.

Ainsi le recensement des pathologies, leur explication, la fourniture de solutions et de facteurs clés de succès permettront d’apporter une réponse adéquate à la problématique posée.

III.3. Champ du projet

III.3.1. Ce que couvre l’étude

La démarche proposée par le client est de partir des cas de dysfonctionnements des projets informatiques rencontrés dans les entreprises des membres du groupe IMI38F, pouvant être élargis à d’autres retours d’expérience.

Sur la base de cet inventaire, nous établirons :

L’argumentaire permettant d’expliquer les cas de dysfonctionnement rencontrés.

Les pistes de solution de progrès proposées pour apporter des corrections aux dysfonctionnements identifiés.

Tous ces travaux permettront de dégager les enseignements principaux, véritables facteurs clés de succès pour la gestion des projets informatiques.

III.3.2. Ce que ne couvre pas l’étude

L’étude n’a pas pour vocation de recenser l’intégralité des pathologies possibles des projets informatiques ni d’apporter toutes les solutions ou facteurs clés de succès.

III.3.3. Métrique proposée

Dans le cadre de cette étude, l’IMI38F se propose de mesurer :



Le respect des engagements convenus avec la MOA : délais, livrables,… (cf. III.5 grille d’évaluation et IV.2 Indicateurs de satisfaction client)

La couverture des solutions proposées aux dysfonctionnements identifiés : elle indique le pourcentage de solutions proposées aux dysfonctionnements identifiés.

III.4. Charte d’éthique Projet/Client (MOE/MOA)

A la demande du client, il est proposé une charte d’éthique en 9 points que les deux parties s’engagent à respecter.

III.4.1. Relation client

Engagements du client (MOA) : Communication explicite avec l’IMI38F (MOE) sur ses attentes, items, documents

et présentation dans le cadre du projet. Disponibilité et communication : la MOA est disponible sous 48 heures. Contact MOA : Gérard BALANTZIAN : [email protected]

Engagements de l’équipe IMI38F (MOE) : Engagement à prendre et à tenir dans les limites de ses capacités, disponibilités et

compétences. Respect des engagements pris. Mise en œuvre de toutes ses capacités, disponibilités et compétences. Information rapide du client de tout élément risquant de nuire à l’atteinte de

l’objectif défini dans le Cahier des Charges. Disponibilité et communication : la MOE est disponible sous 48 heures maximum,

mais souvent dans un délai plus court. Contact MOE : Jean-Luc FIQUET : [email protected] ou autres contacts de

l’équipe IMI38F.

III.4.2. Communication

Etre attentif à la qualité des relations humaines au sein de l’équipe élargie à l’équipe pédagogique et bien sûr lors des échanges avec le client.

Les éléments échangés seront disponibles à l’ensemble du groupe et sous-groupes. Le rapporteur de chaque sous-groupe sera le point de passage entre MOA et MOE. Il s’engage donc à restituer les informations obtenues de la MOA à l’ensemble du groupe dans les meilleurs délais.

III.4.3. Intégrité

Les membres s’interdisent de porter atteinte à la réputation du groupe IMI38F, de l’IMI de l’UTC. De même, autant que possible, les éléments produits seront de nature objective et ne comporteront pas de jugement de valeurs.





III.4.4. Indépendance

L’équipe IMI38F est libre d’expression quant à son retour d’expérience vécue utilisée pour remplir les objectifs définis dans le cahier des charges.

III.4.5. Formation

Démarche de développement :

Des connaissances et des savoirs, des compétences.

Des savoirs faire et des comportements.

De la pratique du management et des savoirs être.

III.4.6. Développement durable

Eviter toute édition inutile afin de respecter l’environnement dans une démarche de développement durable.

III.4.7. Protection du caractère confidentiel de certaines informations

Changer les noms des sociétés et des personnes, années et lieux.

III.4.8. Respect des Lois Connaître et appliquer les lois et se tenir au courant de leur évolution.

Citer ses sources si besoin et respecter la propriété intellectuelle.

III.4.9. Respect de la charte

Il appartiendra à chacun d’entre nous, en cas de doute sur la conduite qu’il doit tenir, de consulter sans attendre les membres du « cabinet virtuel » IMI38F.



III.5. Grille d’évaluation soutenance

A la demande du client il a été défini cette grille dévaluation pour la soutenance :

Mini-projet Management Structuré de Projet Notation1. Compréhension de l’objectif du sujet2. Pertinence de la réalisation par rapport au sujet3. Qualité de rédaction et de présentation4. Qualité du contenu5. Qualité de restitution (présentation orale)6. Qualité globale du mini-projet

Sous-total /30Mini-projet Management des Equipes de Projet

1. Compréhension de l’objectif du sujet2. Pertinence de la réalisation par rapport au sujet3. Qualité de rédaction et de présentation4. Qualité du contenu5. Qualité de restitution (présentation orale)6. Qualité globale du mini-projet

Sous-total /30Mini-projet Management des Projets e-Collaboratifs

1. Compréhension de l’objectif du sujet2. Pertinence de la réalisation par rapport au sujet3. Qualité de rédaction et de présentation4. Qualité du contenu5. Qualité de restitution (présentation orale)6. Qualité globale du mini-projet

Sous-total /30TOTAL /90

Vécu du groupe et étude des conditions à réunir pour bien « Vivre «ensemble » un projet Condition de réalisation Organisation et méthodologie de travail Qualité des échanges Implication dans l’équipe Perception du travail d’équipe Difficultés rencontrées et surmontées Difficultés non surmontées Respect des délais/planificationAPPRECIATION :



IV – Proposition de solutions

IV.1. Livrables du projet

Les livrables du projet sont le rapport et le jeu de diapositives PowerPoint de la soutenance.

Le Rapport comportera au moins 3 parties :

1. Démarche de Management Structuré de Projet : Expression des besoins. Découpage en phases et panorama des outils. Phase de Planification et Gestion du temps. Phase de Lancement. Phase de Production. Phase de Pilotage.

2. Management des équipes de projet : Gestion de ses priorités. Gestion des priorités collectives. Management d’équipes de projet. Implication des utilisateurs. Soutien DG.

3. Management de projets e-collaboratifs : Charte des valeurs de l’équipe de projet2 Charte d’utilisation de l’espace e-collaboratif. Utilisation par équipe de projet de l’espace e-collaboratif. Tableaux de bord. Capitalisation des connaissances.

Le jeu de diapositives PowerPoint

Une présentation sera établie pour chaque sous-projet. Le contenu de ces présentations sera une synthèse des points clés des rapports. Afin de garantir l’homogénéité de l’ensemble, la charte graphique sera commune aux trois présentations.

Le Road Book

Le road book de l’équipe ne sera pas remis a priori. Si cela est rendu nécessaire compte tenu de son contenu, une restitution sera faite à l’issue des présentations, sous une forme restant à déterminer.



IV.2. Indicateurs de satisfaction du client

Délai : Deux dates clés sont définies entre MOE et MOA, le 30 mars et le 15 juin. A ces dates, un certain nombre de livrables sont attendus. Le respect de ces délais et la complétude des documents doivent être mesurés.

Forme : Pour le 15 juin, le groupe doit fournir 1 rapport (en 3 exemplaires et les diapositives de la soutenance. L’homogénéité de présentation doit être validée. Une organisation des rapports est présentée en 4.1. Les rapports devront donc s’appuyer sur cette structure. Le temps alloué pour la présentation des résultats est d’une heure pour l’ensemble. Le respect de ce temps (hors échanges avec le jury) est important.

Fond : La pertinence du contenu sera un des principaux éléments de satisfaction. Toutefois, à ce stade, il parait difficile de définir les indicateurs de mesure. La qualité de restitution des éléments lors de la présentation est également un point à prendre en compte.

Vécu : La réalisation de ce projet, dans un délai relativement court et avec des conditions de réalisation particulière (peu de moments de rencontres physiques et par conséquent beaucoup d’échanges électroniques) est une aventure. Il y aura nécessairement des moments plus difficiles que d’autres et des recalages à effectuer dans nos modes de fonctionnement. Il est attendu que le groupe sache piloter son aventure et ajuster son cap tout au long de la réalisation. Le projet sera un succès si, à la sortie de cette réalisation, la cohésion du groupe est renforcée et que tous aient pu tirer des enseignements de cette « vie de groupe et vie en groupe ».

IV.3. Conditions de mise en œuvre

Sont ici évoqués les conditions de livraison et de restitution des documents (mise en œuvre) :

Livraison des Livrables : Trois rapports au format Word (1 par mini projet) seront envoyés par courriel à Pascale Charpentier avec copie à Gérard Balantzian. Ce courriel sera envoyé au plus tard le 15 juin 2008.

Restitution et soutenance : L’ensemble de la solution sera présenté lors de la soutenance du jury à une date comprise entre le 24 et le 26 juin 2008.

Chaque mini projet est restitué séparément :

Le mini projet tronc commun est restitué par l’ensemble IMI38F.

Le mini projet 1 par le sous-groupe 1.

Le mini projet 2 par le sous-groupe 2.

Un retour sur le road book sera possible sous forme libre.

L’ensemble des restitutions des 3 projets ne dépassera pas 1 heure.

Le lieu choisi est la salle de cours plénière de l’IMI. Cette salle devra être disponible 30mm avant la soutenance et être équipée d’un vidéo projecteur ainsi que d’un paper board.

Si la soutenance nécessite d’autres équipements, l’équipe projet pourra solliciter l’IMI au plus tard 7 jours avant la date de la soutenance.



A l’issue des délibérations du jury, l’ensemble des travaux sera mis à disposition sur l’intranet de l’IMI.

IV.4. Contraintes et risques majeurs - Solutions

Nous considérons ici les contraintes et risques de gestion de notre projet ainsi que les solutions envisagées.

Contraintes et risques

Manque de ressources humaines : Compte tenu du nombre de personnes affectées à chaque mini projet (3 personnes), il est essentiel que la réactivité et l’implication de chacun soient maximum sur le projet. Toute défection supplémentaire d’un membre de l’équipe pourra avoir des répercutions sur la réalisation du projet.

Manque d’expérience sur le sujet (pathologies des projets) : Un manque significatif d’expériences dans la gestion de projets informatiques pourra nuire à la qualité et au niveau du projet.

Contrainte de temps pour répondre à l’ensemble du sujet : Compte tenu de l’étendue du projet, l’équipe devra inévitablement se limiter sur les pathologies les plus fréquemment rencontrées au risque de ne pas pouvoir aboutir sur l’ensemble des items à traiter.

Plate-forme d’échange collaborative : L’usage d’un outil collaboratif public et sécurisé, mais nouveau pour l’équipe, comme BSCW, peut être à l’origine de dysfonctionnements importants pour la gestion du projet : perte d’information par écrasement involontaire, site collaboratif inaccessible…

Les solutions pour limiter les risques

Manque de ressources humaines : Si le manque d’effectif ou de disponibilité des membres est un facteur bloquant pour l’avancement d’un des mini-projets, il peut être envisageable de fusionner les équipes des sous-groupes avant de restreindre en dernière limite le nombre de pathologies étudiées.

Manque d’expérience sur le sujet : Les membre de l’equipe pourront s’appuyer sur d’autres retours d’experiences hors de leurs entreprises (interviews, autres recherches, etc.).

Contrainte de temps pour répondre à l’ensemble du sujet : L’équipe peut décider de restreindre le nombre d’expériences ou de pathologies à analyser ou ne pas approfondir certaines expériences. Dans ce cas, cela sera alors clairement explicité.

Outil plate-forme collaborative : Pour pallier au risque de perte ou d’écrasement de documents, chaque membre de l’équipe conserve l’ensemble des fichiers téléchargés ou mis à jour sur la plate-forme collaborative. En cas de constat de dysfonctionnements ou bloquant de cette plate-forme, l’équipe peut changer de plate-forme et/ou décider d’un fonctionnement par un autre canal (courriel, intranet IMI ou autres).



Annexe 3 : Plannings du projet

Annexe 3.1. Planning initial du 18 avril

Quoi Qui Débute le Pour le Fait le

Soutenance RP1 TOUS 14 avril 12h30 14 avril 13h45

Compte rendu RP1 à MS+JJ JLF 15 avril 15 avril

Réunion IMI38F - Pose déjeuné TOUS 15 avril midi 15 avril midi

Compte rendu interview F. Odier JLF 15 avril 16 avril soir 16 avril soir

Réunion IMI38F - Points/Actions TOUS 16 avril 14h 16 avril 16h 16 avril 16h

Activités/Planning provisoire JLF 16 avril soir 16 avril soir

Compte rendu interview J. Printz PYA 17 avril soir 17 avril soir 18 avril

Remontée des grilles de dysfonctionnements TOUS 18 avril soir 18 avril soir

Etude d'un cas de dysfonctionnement exemple LC 18 avril soir 18 avril soir

Echanges collaboratifs sur le cas TOUS 19 avril 22 avril

Etude des documents fournis par MS TOUS 19 avril 22 avril

Constitution projet/planning sous (MS Project) JLF 19 avril 20 avril

Capitalisation RP1 JLF 19 avril 20 avril

Réunion 1ère analyse grille des dysfonctionnements TOUS 22 avril 17h30

Réflexion sur l'élaboration d'une grille diagnostic

Elaboration du plan général du rapport

Préparation PowerPoint RP2 YE 7 mai



Annexe 3.2. Planning du 09 juin

Planning condensé sous MS-Project 2007 – 112 activités planifiées.

Planning condensé – Diagramme de Gantt.



Annexe 4 : Interviews de spécialistes du thème

Annexe 4.1. Interview de Francis Odier

Réalisé le 14 avril de 09h10-10h par téléphone.

Francis ODIER ([email protected]), auteur de l'excellent document dont toute une partie est consacrée aux Pathologies des Projet Informatiques (voir bibliographie) est professeur à l’université Joseph Fourier.

Question : Monsieur Odier, pouvez-vous me dire dans quels types de projets vous êtes intervenu ?

Francis Odier intervient le plus souvent à la demande de comités d’entreprise et de comités d’hygiène et de sécurité. La loi impose aux entreprises qui lancent un nouveau projet de consulter ces comités lorsque le projet a des répercussions sur les conditions de travail des employés : changement significatif des procédures de travail ou d’ergonomie dans les postes de travail. Trop souvent l’entreprise néglige ces consultations. Francis Odier intervient donc à la demande d’un comité qui constate les plaintes des utilisateurs.

Question : quelles pathologies avez-vous identifiées ?

Le point de vue des salariés n’a pas été pris en compte dès le début du projet (le comité d’utilisateurs n’existe pas, n’est pas représentatif. On a Privilégié une catégorie d’acteurs et oublier les autres : vision tronquée du collectif. L’ergonomie ou la performance de l’application ne convient pas à l’exploitation : trop de fenêtres pour réaliser une tâche récurrente (perte de temps) ou au contraire trop d’informations dans un même écran pour une fonction rarement utilisée (incompréhension).

Le projet a négligé les données : problème de reprise de données mal étudiée, perte de données lors de la migration. Problème de montée en charge : les tests utilisateurs en condition quasi réelles n’ont pas été effectués (ou simulés).

Question : Pensez-vous à d’autres pathologies non présentes dans le questionnaire ?

Intégration multi projets mal maîtrisée : ressources communes à plusieurs projets entrant à un moment en concurrence ou déploiement/mise en œuvre de plusieurs projets déstabilisants simultanément (trop proches) impliquent une prise de risque pour le projet. Exemple : un déménagement peut complètement perturber certaines étapes importantes d’un projet.

Cause humaine : bien identifier et anticiper les enjeux de pouvoir (perte) pour certains acteurs : il faut aborder le sujet clairement dès le début et bien préparer la communication. Mauvaise communication au près des utilisateurs.

Question : quels facteurs clés de succès ?

Privilégier le cycle : (phase de déploiement progressive + retour des utilisateurs + adaptations) au déploiement « big bang » en une seule fois (diminution des risques).

Adopter une démarche d’analyse du travail réel (dans toutes les dimensions notamment humaine) et pas uniquement sur les flux.

Définir des scénarios d’usage précis et conforme à la réalité.



Mettre en place une gestion des erreurs/anomalies.

Ne pas refuser d’affronter l’impacte social.

Identifier, anticiper les enjeux de pouvoir en s’assurant de faire un bilan équilibrer ou positif pour chaque acteur : « Tous les acteurs devraient pouvoir s’y retrouver ».



Annexe 4.2. Interview de Jacques Printz

Interviewe réalisée le 18 avril 2008 à l’IMI.

Jacques PRINTZ et Gérard BALANTZIAN son co-animateurs du séminaire traitant des Pathologies des Projets Informatiques ((http://www.clubmoa.asso.fr/article.php?sid=166).

Jacques Printz ([email protected]), professeur et Titulaire de la Chaire de Génie Logiciel au CNAM, Lauréat du prix Roberval (prix créé par l'UTC) est un des spécialistes dudit thème.

La question que je me pose quand j’audite un projet qui est en échec : comment en est-on arrivé la ? Personne n’a vu les signes annonciateurs, les effets visibles de la dérive.

Quel doit être le dispositif qui permet de prendre la température du projet pour traiter en amont les problèmes.

La meilleure technique est l’estimation du projet : on établit une trajectoire cible puis au fur à mesure, on mesure l’écart avec la trajectoire constatée du projet. Les écarts sont les signes annonciateurs du dysfonctionnement du projet. Le modèle d’estimation s’appuie sur le somme des processus du projet, qui sont avant tout des processus humains.

Donc quels processus ont mal été réalises ou oubliés ?

Dans ¾ des projets, les processus de tests ont été oubliés ou mal réalisés.

Comment porter un diagnostic sur un projet ?

Les meilleurs modèles d’estimation sont du type COCOMO ou point de fonction. Ces modèles doivent expliciter toutes les hypothèses. Ainsi par exemple, en faisant une hypothèse sur la productivité des programmeurs, on se pose les questions sur leur rendement. Si ce rendement n’est pas atteint, il faut rechercher la cause (mauvais calcul hypothèse de base ou mauvais rendement).

Qu’est-ce que l’échec d’un projet ?

Etre en retard mais livrer toutes les fonctionnalités opérationnelles, est ce un échec ?

Livrer à temps mais sans couvrir toutes les fonctionnalités, est-ce un échec ?

Il existe une gradualité dans l’échec. Il existe aussi des échecs « total ».

Ex : un vrai échec, le dossier médical personnel

Ex : GEODE, le système de l’ANPE.

Au déploiement, on constate des temps de réponses de plusieurs minutes sur le poste client. Le système est non opérable. L’architecture de la SGBD n’était pas performante. Il a été oublié l’aspect physique du système, la bande passante et le nombre de PC en connexion. Cela aurait du être spécifié dans le cahier des charges. Mais cela pose le problème de la compétence dans l’équipe MOE et MOA.




Ex : un Grand producteur d’énergie en France, a découvert le non fonctionnement d’un nouveau système à l’installation malgré le passage des tests techniques. En effet, le sous-traitant en charge des tests fonctionnels ne les avaient pas faits. Il n’y avait aucun informaticien dans l’équipe projet.

Quels conseils pour la réussite d’un projet ?

Il faut appliquer les règles de bonnes pratiques.

Ex : un projet ou le seul document a été le document d’expression des besoins pour faire les développements. Il n’a pas été fait le document de conception détaillé. On viole les règles de bonnes pratiques connues depuis des décennies par méconnaissance ou pour de raisons politiques de la DG ou de coûts.

Quels sont les dysfonctionnements les plus fréquents ?

Il n’est pas aisé de déterminer tous les dysfonctionnements les plus fréquents, car chaque projet est différent. Il faut comprendre quels sont les risques du projet par rapport à la nature du projet. Il faut donc définir ce système en fonction du service qu’il rend, à quoi il sert, à qui, dans quel contexte…Ainsi l’ergonomie du système doit être adapté à son public ; la borne SNCF se doit d’être plus simple que l’outil des contrôleurs aériens car ils ont 18 mois de formation.

L’incompétence des équipes projets (MOE & MOA) est un élément principal de l’échec des projets. La profession informatique n’a pas plus de comportement rationnel qu’une autre. On ne peut pas mesurer cette part d’irrationnel.

Quels sont les facteurs clés de réussite d’un projet ?

La confiance est un facteur clé du bon fonctionnement d’une équipe et du projet. De même, il est important d’avoir des profils complémentaires (créatifs et finisseurs). L’équipe doit être solidaire et de connivence.

Un bon projet, c’est une équipe compétente, solidaire, managée par un chef de projet ayant de fortes compétences humaines pour gérer chaque personne de l’équipe et ayant une maîtrise technique reconnue.

Les américains pratique la méthode d’inclure dans les comités de pilotage un expert externe au projet. Cela oblige à un maximum de clarté et d’homogénéité dans les présentations.

Un indicateur intéressant est le contenu et la tenue des réunions, il faut regarder et interpréter, l’attitude, et les manières des intervenants.

Il est nécessaire dans l’équipe projet d’avoir une expertise sur les risques possibles sur le projet.

Le chef de projet et son équipe de projet doivent connaître les bonnes pratiques de gestion des projets. Ils doivent être formés. Si l’on n’applique pas les bonnes pratiques, on prend des risques donc on prépare des causes de dysfonctionnement. On s’écarte de la norme.

Les causes des problèmes sont souvent une accumulation d’erreurs humaines.

Il existe une problématique des besoins implicites, évidents qui ne sont pas exprimés par le client et donc non perçus par la MOE. D’autre part le système est dépendant de l’environnement, du contexte.



Ex : la centrale d’inertie d’Ariane 4 utilisé pour Ariane 5 qui ne possède pas les nouveaux paramètres de la nouvelle fusée. Le système a réagit en fonction des paramètres prévues pour A4 et non en fonction de ceux de A5.

La chaîne de décision n’a pas pris en compte la problématique informatique dans ce nouveau projet. La culture de l’entreprise est plus orientée risque industrielle (moteur, mécanique …) que risque informatique.



Annexe 5 : CR des revues de projetQuelques phrases sur les 3 revues de projet : objectifs, déroulement, dates, etc.

Annexe 5.1. CR de la RP1

Synthèse de la RP 1 réalisée le 14/04/2008 à l’IMI de 12h30-13h30

Objectif principal du projet :

Construire une base de connaissances des pathologies des projets informatiques, comportant une liste de dysfonctionnements, un argumentaire expliquant les causes et les effets, des pistes de solutions et des facteurs clés de succès (FCS).

Sur le Timing Nous avons passé 1/3 du temps du projet => NOUS SOMMES EN RETARD

Planning : pourriez-vous nous repréciser la date de notre prochain RP ? le mercredi 7 mai en fin de journée, à l’heure qui conviendrait le mieux à la majorité. Cela nous laissera 3 semaines de travail.

Jean souhaite une meilleure visibilité sur notre avancement (planning, retour sur le site collaboratif) : nous allons mettre en ligne prochainement un planning plus détaillé...

Sur le fond :

Travailler sur les 3 niveaux (comme le questionnaire) : organisationnel, humain et informatique

Meilleur découpage de notre démarche en 4 phases (workpackage):

1. Réaliser le cadrage du projet du 19 au 31 mars

Faire préciser l’objectif du projet.

Identifier les livrables attendus.

Organiser les ressources et les moyens (rôle de chaque membre de l’équipe, BSCW, méthode de travail, etc.)

Faire des recherches pour mieux comprendre le sujet « pathologies des PI ».

Etablir des références bibliographiques.

Etablir le planning général.

Recueillir et analyser les besoins de la MOA : rédaction du RBA-CDC.

Résultat de cette 1ère étape : RBA/CDC validé par la MOA le 31/03 donnant le top de départ du projet.

2. Dresser une liste commentée des dysfonctionnements (avec impact sur les 3 niveaux) du 1er avril au 10 mai.

Etablir un questionnaire à envoyer aux personnes susceptibles de fournir des dysfonctionnements.



Faire valider le questionnaire par MS + JJ.

Envoyer le questionnaire aux personnes (mettre la liste des personnes avec fonction + autres informations importantes dans la suite du projet et pour la base de connaissances).

D’autres actions et tâches seront détaillées ultérieurement.

- RP 1 le 14 avril

- RP 2 le 7 mai

3. Emettre des recommandations, des pistes de solutions, des plans d'action et des FCS, en fonction des dysfonctionnements analysés : du 11/05 au 31/05.

Cette étape sera détaillée ultérieurement.

- RP 3 la 2ème semaine de juin

4. Formaliser et communiquer les résultats du projet du 1er juin à la fin juin, date de la soutenance

Finaliser la base de connaissances des pathologies des PI (produit phare de ce projet)

Boucler les rapports + road books.

Préparer les jeux de diapositives pour la soutenance.

Envoyer les rapports au plus tard le 15/06.

Faire des répétitions (qui fait quoi et qui dit quoi).

Soutenir le travail réalisé.

Debriefing pour tirer des enseignements et clôturer le projet, à la fin de la soutenance.

Sur la forme et le PPT de la RP1 : Etre plus synthétique et compréhensible : le planning + démarche. En fait, il faut garder

la vue globale pour maîtriser le processus projet. Il vous sera plus facile d’aller ensuite dans le détail.

Dans la démarche, placer un axe de temps et indiquer la production de chaque phase (workpackage avec résultat de chaque phase).

Etre plus cohérent : exemple : démarche <==> planning (code de couleurs)

Forces et faiblesses de l’équipe de projet : toujours par rapport au projet

Opportunité : MOA tjrs disponible

Menaces : disponibilité des experts, voire des coaches.

Créer notre modèle PowerPoint : entête et pied page personnalisés (nom, date, n° page), puces et polices, etc. Des diapositives qui seront à l’image de l’équipe : cela dépend de ce que vous voudriez montrer : peut-être montrer votre dynamisme, votre engagement, synergie, respect… des valeurs communes qui seront véhiculées par votre « template » PPT.



Nos demandes :

Mélissa pourriez-vous ? Nous transmettre les éléments concernant la réalisation d'un diagnostic. Depuis notre

réunion, je travaille sur le diagnostic adapté à notre sujet. Vous aurez également des outils pour vous faciliter l’analyse des questionnaires, etc. Je vous enverrai le document, d’une vingtaine de pages, au plus tard demain dans la matinée.

Nous transmettre un modèle de rapport, un modèle a été déposé sur l'espace BSCW. Il sera déposé/envoyé par mail, au plus tard demain dans la matinée.




Sur le timing NOUS SOMMES EN RETARD. Il faut mettre les bouchées doubles.

La RP3 est prévue entre le 9 et 14 juin. Sachant qu’il ne s’agit pas de corriger. Tout doit être parfait pour cette dernière RP.

Etre plus synthétique concernant le travail sur la base de connaissances des PPI.

Etudier 5 à 7 cas max dans le détail. Concertation collective sur les cas sélectionnés. Le reste en faire une synthèse, sachant qu’à ce jour nous n’avons pas assez travaillé sur les cas.

Estimation des charges. JJ réclame une estimation des charges.

Ne plus retoucher les documents amendés par MS et JJ. Ne pas oublier de noter les références bibliographiques en cours, risque de perte de temps lors de la réalisation finale.

Elément transmis par MS :

Document « Méthode pour réaliser un diagnostic ».

Lister les dysfonctionnements

Les analyser : causes et effets (grille diagnostic MS) y compris suivi.

Lister les actions d’amélioration (des solutions de progrès).

Faire des recommandations par priorité

Dresser des FCS

Dysfonctionnement Action Suivi FCS

Recommandations pour la soutenance :

Ne rien faire entre le 16 et le 22 juin

Du 23 au 26 juin répétition et ajustement :

Concernant la répétition chacun doit penser à sa préparation sans concertation. On scénarise la présentation.

Ajustement -> Cohérence d’ensemble




CR RP3 : du 5 juin 2008 - 12h à l’IMI

Nous arrivons en phase 4 : Finalisation : c'est-à-dire, assemblage des livrables (rapport, présentation, road book).

Nous faisons le constat de dépassement de plus de 50% de la charge de travail :Heures

Charges Prévues Charges réalisées Ecarts

Rédaction Rapport 40 59 50%

Rédaction Annexes 16 24 50%

Rédaction dysfonctionnement 51 93 82%

Road book 18 12 33%

Finalisation du Rapport : Annexes : planning : bien intégrer première et dernière version, Bibliographie : compléter

Soutenance : confirmée le vendredi 27 juin à 10h !

Voici ce que Pierre-Yves propose pour les thèmes de la présentation :

- Chacun doit faire cet exercice de style, chacun doit scénariser la présentation. -On se mettra d’accord ensuite ensemble sur le scénario ! - JJ : Il ne faut passer de temps sur les 2 points de la fin, ce n’est pas l’objet du projet, ce qu’on veut c’est obtenir une base connaissances des dysfonctionnements en recherchant les causes et solutions. Plate-forme collaborative n’est qu’un outil (pas important par rapport au sujet).Vie du groupe : ne pas passer trop de temps dessus.

Remarques diverses : JJ : Le groupe n’a pas réagi suffisamment rapidement aux remarques faites par mail, Les avis de Mélissa sont plus suivis. Concernant Cocomo et Point de Fonction il n’y a pas d’évolution par rapport à mes remarques, merci de nuancer…je suis prêt à vous donner des explications supplémentaires. MS : L’important pour les coaches est d’arriver au 27 en voyant que le groupe a avancé ensemble… On apprend ensemble.

Revue de Projet, MS : n’oubliez pas de les faire dans vos projets futurs… revue de ce qui a été fait, évaluation et comment améliorer…

13h15 : Clôture de la réunion



Annexe 6 : Fiches missionLes missions pour chaque membre du groupe IMI38F ont été affectées le 19/05/2008, par Jean-Luc Fiquet, chef de projet.

Fiche mission de Napoléon

TâchesCharges (h) Dates de début Dates de fin

Prévues Réelles Prévues Réelles Prévues Réelles

Rédiger Chapitre 1 6 12 13/05 25/05 18/05 03/06Formaliser 2 dysfonctionnements 3 4 18/05 01/06 20/05 03/06

Mettre en forme Partie MEP : à partir des PI sélectionnés mettre en forme cette partie du document. 2 2 26/05 26/05 28/05 01/06Prise en compte des retours – MEP – Intégrer et mettre en forme les retours sur partie MEP 2 2 28/05 28/05 03/06 03/06

Rédiger « Normes de développement des projets informatiques »: 4 4 01/06 01/06 03/06 08/06

Relecture Rapport et Annexes 3 3 05/06 08/06 08/06 08/06Rédiger Road book personnel 3 6 13/05 13/05 15/06

Préparer Présentation 5 06/05 09/06 06/05 21/06TOTAL 30 33

Fiche mission de Yvan



Rédiger III.1. du rapport 6 15 13/05 18/05 Formaliser 4 dysfonctionnements 5 6 18/05 03/06 28/05 03/06

Rédiger « Gestion des conflits » 7 8 26/05 26/05 03/06 08/06Relecture Rapport et Annexes 4 4 05/06 06/06 08/06 08/06

Rédiger Road book personnel 3 1 13/05 13/05 15/06 Préparer RP3 3 3 28/05 01/06 05/06 05/06

Relecture Rapport et Annexes 3 3 05/06 07/06 08/06 08/06Préparer Présentation 5 05/06 15/06

TOTAL 31 40



Fiche mission de Fattah



Rédiger IV.1. du rapport 6 11 13/05 24/05 18/05 03/06Formaliser 3 dysfonctionnements 5 12 18/05 19/05 20/05 03/06

Mettre en forme partie IV-MPE : Mettre en forme la partie Management des projets e-collaboratif à partir des cas sélectionnés 2 2 26/05 02/06 28/05 03/06Prise en compte des retours – MPE – Intégrer et mettre en forme les retours sur partie IV-MEP 2 1 28/05 03/06 03/06 03/06

Responsable partie II - MSP 3 2 28/05 01/06 03/06 03/06Rédiger annexe « Recommandations » 6 9 01/06 02/06 06/06 08/06Relecture Rapport et Annexes 3 6 05/06 07/06 08/06 08/06

Rédiger Road book personnel 3 2 13/05 27/05 03/06 15/06 Préparer Présentation 5 05/06 15/06

TOTAL 35 45

Fiche mission de Pierre-Yves

Tâches

Charges (h) Dates de début Dates de fin

Prévues Réelles Prévues Réelles Prévues RéellesRédiger II.1.du rapport 6 9 13/05 15/05 18/05 01/06

Formaliser 9 dysfonctionnements 11 14 18/05 22/05 20/05 01/06Mettre en forme Partie II- MSP = Mettre en forme la partie Management Structurée de projet avec les cas sélectionnés 2 2 26/05 01/06 28/05 03/06Prise en compte des retours – MSP – Intégrer et mettre en forme les retours sur partie IV-MS 2 2 25/05 01/06 03/06 03/06

Responsable Partie – IV - MPE 3 0 28/05 03/06 Rédiger Road book personnel 3 2 13/05 26/05 15/06

Constituer Annexes sauf An.7 3 3 30/05 02/06 03/06 04/06Préparer RP3 3 4 28/05 28/05 0506 04/06

Relecture Rapport et Annexes 3 3 05/06 05/06 08/06 07/06Préparer Présentation 5 1 05/06 02/06 15/06

TOTAL 35 38



Fiche mission de Laurent



Formaliser 8 dysfonctionnements 11 25 13/05 13/05 20/05 29/05Sélectionner cas MSP 2 1 21/05 30/05 28/05 30/05

Capitalisation connaissance MSP 3 3 28/05 01/06 03/06 03/06Sélectionner cas MEP 2 1 26/05 30/05 28/05 30/05

Capitalisation connaissance MEP 3 4 28/05 01/06 03/06 02/06Responsable Partie – III – MEP 3 4 28/05 28/05 03/06 03/06

Responsable Annexe gestion des émotions 3 1 28/05 28/05 03/06 03/06

Manager projet MEP – Chef de projet du mini projet MEP 3 3 13/05 13/05 03/06 03/06

Relecture Rapport et Annexes 3 3 05/06 06/06 08/06 07/06 Rédiger Road book personnel 3 3 13/05 13/05 15/06

Préparer Présentation 5 05/06 15/05 TOTAL 41 48

Fiche mission de Jean-Luc



Formaliser 13 dysfonctionnements 16 38 13/05 13/05 25/05 01/06Sélectionner cas partie IV-MPE 2 1 26/05 30/05 28/05 30/05

Management projet MPE 3 3 13/05 13/05 03/06 04/06Management projet MSP 3 3 13/05 13/05 03/06 04/06

Responsable partie I 2 1 28/05 28/05 03/06 03/06Capitalisation MPE 3 3 28/05 01/06 03/06 02/06

Responsable Annexe base des DPI (Annexe 7) 2 4 28/05 31/05 03/06 03/06

Rédiger Avant-propos et conclusion 4 3 28/05 01/06 03/06 01/06Etudier Cross Knowledge : Constitution doc sur ce site 2 2 16/05 25/05 25/05 25/05Relecture Rapport et Annexes et consolidation corrections 6 6 05/06 08/06 08/06 08/06Rédiger Road book personnel 3 2 13/05 20/05 15/06

Préparer Présentation 5TOTAL 53 66



Annexe 7 : Norme et modèle pour projets informatiquesQuel que soit le modèle, la norme ou la méthodologie de conduite de projet que l’on choisit, l’important est de choisir un modèle pour avoir un référentiel commun pour tous les acteurs du projet, mais aussi d’adapter ce modèle à la démarche spécifique du projet.

Voir Bibliographie, pour plus d’informations sur ces normes et méthodologies.

CMMI

Le CMMI (Capability Maturity Model Integrated) est un modèle d'évaluation du niveau de maturité d'une organisation concernant le développement de systèmes, de produit et/ou de logiciels, qui a pour objectif la maîtrise des processus d'ingénierie et par conséquent celle de la qualité des produits et des services issus de ces processus. Il propose un référentiel des meilleures pratiques en matière de développement logiciel. Il donc à :

Améliorer la qualité du produit livré et la productivité du projet.

Augmenter la satisfaction du client en répondant mieux à ses exigences.

Réduire les coûts et respecter les délais.

Donner une meilleure visibilité au management et permettre une meilleure gestion des risques.

Les bénéfices de la mise en place d'un modèle comme CMMI dans une organisation sont très rapidement visibles :

Moins de « re-work » car les processus sont standardisés et rationalisés

Des bugs détectés plus tôt dans le cycle de vie du projet,

Des risques anticipés, et donc des problèmes évités

Des succès répétés

Une amélioration de la productivité

Un produit de meilleure qualité

Des clients plus satisfaits

Rationalisation des coûts

PRINCE2

PRINCE2 (PRojects IN Controlled Environments) est une méthodologie de gestion et de certification de projet structurée qui se focalise sur trois points : l'organisation, la gestion et le contrôle du projet.

Cette méthodologie se concentre sur la justification économique, définit une organisation pour l'équipe de direction de projet et l'approche de base de PRINCE2 est basée sur le planning. Elle met l'accent sur un découpage du projet en phases qui peuvent être dirigées et contrôlées.

La souplesse de cette méthode permet de l'appliquer à un niveau adapté au projet.



SDMS

SDMS ("System Design Method", Méthodologie de développement des systèmes) est une méthode de conduite de projet par phases.

Un projet géré via la méthode SDMS est découpé en 10 phases de 9 tâches chacune. Chacune des phases a une liste de tâches qui leur sont propres.

Ces 10 phases sont : DS / EO, Demande de service - Etude d’opportunité DBS, Définition des besoins CAS, Choix d’architecture SES, Spécifications externes SIS, Spécifications internes PRG, Programmation TST, Tests CONV, Conversion INST, Installation BILAN, Bilan

Cette méthodologie n’est pas récente. Il y a peu de littérature « actuelle » pour cette méthode mais son approche par phases auxquelles sont associées des tâches est intéressante car elle permet de structurer efficacement la conduite d’un projet.

BILAN

Cette méthodologie moins récente a souvent été associée à Merise. Il y a peu de littérature disponible sur Internet pour cette méthode mais son approche par phase auxquelles sont associées des tâches est intéressante car elle permet de structurer efficacement la conduite d’un projet.

PMI, PM Book

PMI propose des certifications dans le domaine de la gestion, la planification et le développement des projets. PMI s’adresse en priorité à destination des Directeurs de Projets.

ISO 9001/2000

ISO 9001/2000 est une norme qui permet de certifier une organisation quelle qu’elle soit, pourquoi pas un projet.

La norme ISO 9001:2000 fournit un cadre bien éprouvé pour adopter une approche systématique de la gestion des processus d'une organisation de façon à ce qu'elle produise régulièrement des produits qui répondent aux attentes des clients.

Pour plus d’informations sur ces normes voir Bibliographie.



Annexe 8 : Questionnaire utilisé pour identifier les dysfonctionnements

1- Introduction

Nous sommes membres de la promotion 38 février 2008 de l’IMI (Institut pour le Management de l’information). Dans le cadre de notre cursus, notre groupe (6 personnes) doit mener un projet sur « les pathologies des projets informatiques ».

2 - Notre but

Nous avons rédigé ce document dans le but de recueillir l’avis et les conseils d’experts sur le sujet ou de personnes ayant eu à manager ou ayant participé à des projets informatiques.

Les réponses et conseils que vous nous fournirez permettront d’alimenter notre recensement des pathologies les plus fréquentes ou importantes des projets informatiques, de les expliquer, de proposer des remèdes et enfin d’en tirer des facteurs clés de succès.Pour information l’étude que nous devons mener, doit couvrir le panorama suivant des phases d’un projet informatique :

- Expression des besoins (cahier des charges).

- Découpage en phases et panorama des outils.

- Phase de planification et gestion du temps.

- Phase de lancement.

- Phase de production.

- Phase de pilotage.

- Gestion de ses priorités.

- Gestion des priorités collectives.

- Management d’équipes de projet.

- Implication des utilisateurs.

- Soutien de la Direction Générale

- Charte d’utilisation de l’espace e-collaboratif.

- Règles d’utilisation par équipe de projet de l’espace e-collaboratif.

- Tableaux de bord.

- Capitalisation des connaissances.

3 - Cadrage contexte questionnaire

Afin de couvrir un éventail plus large de pathologies des projets informatiques, nous nous plaçons pour ce questionnaire, dans le cadre théorique d’un projet informatique important d’une grande entreprise multinationale devant mettre en place une solution au cœur de son activité.

Des problématiques de localisation touchant la réglementation, la traduction, la documentation et le support utilisateur doivent être prises en compte pour chaque pays et/ou langues dans lesquels la solution devra être déployée.

Il est fait appel à un progiciel de gestion intégrée du marché pour certaines parties fonctionnelles de la solution. Le projet fait appel à des équipes externes à l’entreprise pour une partie du développement informatique en sous-traitance locale et distante, mais l’essentiel de la conception et du développement sont réalisés avec des équipes internes. Enfin pour certaines parties non critiques de la solution, il est envisagé un développement de type « open source ».



4 - Les acteurs du projet informatique

Il nous semble important de définir les différents acteurs du projet informatique, afin de mieux identifier les dysfonctionnements provenant de chaque acteur :

4.1 – Identification des équipes du projet

Pour un projet de cette envergure nous identifions les équipes suivantes en donnant une définition succincte :

Comité de pilotage du projet : Présidé par un représentant de la direction générale, qui coordonne, initie et prend les décisions importantes du projet.

Equipe MOA (Maîtrise d’ouvrage) : Connaissance métier, en charge de l’élaboration du cahier des charges et des études.

Equipe MOE (Maîtrise d’œuvre) : Gère avec ses équipes internes ou externes, la réalisation de la solution en adéquation au cahier des charges.

Equipe Qualité : Veille au respect des standards de qualité définis dans l’entreprise (notamment d’éventuelles certifications qualité ISO)

Equipe Sécurité : Veille au respect des standards de sécurité et de réglementation définis et applicables à l’entreprise. Exemples : politique d’accès, SSO (Single Sign On), Réglementation applicables aux banques.

Equipe Tests Applicatifs (TA) : Conception, réalisation, exécution de scripts de tests applicatifs et des tests manuels. S’assure que la solution est fonctionnelle et répond bien aux attentes. S’assure de la non régression des versions successives de la solution.

Equipe support exploitation (EXP) : Veille aux exigences liées à la mise en exploitation et au déploiement de la solution : performance en montée en charge, etc.

Equipe sous-traitance interne développement (STI) : développements sous-traités en interne à des personnels en forfait faisant équipe avec les développeurs internes.

Equipe sous-traitance externe développement (STE) : développements sous-traités en travail collaboratif à des équipes externes et distantes.

Equipe consultants du progiciel de gestion intégré (PGI) : personnels détachés pour une mission de conseil, de mise en place, de paramétrage et de formation au PGI.

Communauté des Contributeurs Open Source (COS) : ensemble des contributeurs volontaires au sous-projet open source.

Equipe Formateurs et Support Utilisateurs (FSU) : personnels du centre de support utilisateurs, dédiés au projet, en charge de l’élaboration des cours utilisateurs et des procédures de supports des utilisateurs.

Equipe Documentation (Doc) : équipe en charge de la rédaction de la documentation en ligne site web, de la traduction, des procédures d’utilisation de la solution.

Equipe, représentant les utilisateurs, appelée « comité utilisateurs » : prend en charge et représentes les préoccupations et intérêts de l’ensemble des utilisateurs de la solution : ergonomies, procédures…

Q4.1-1: Ce découpage est-il pertinent ?



………………………………………………………………………………………………………

Q4.1-2 : Manque-t-il des équipes à ce découpage ?

……………………………………………………………………………………………………..

Q4.1-3 : Quels dysfonctionnements les plus fréquents peuvent être générés si l’un ou plusieurs des rôles importants listés ci-dessus ne sont pas représentés dans le projet ?

……………………………………………………………………………………………………..

Q4.1-4 : Autres remarques sur la définition des équipes ?

…………………………………………………………………………………………................

4.2 – Comité de pilotage du projet

Le comité de pilotage est présidé par un représentant de la direction générale, faisant référence pour « sponsoriser » le projet et animer le comité.

Le comité est composé d’un représentant des équipes les plus importantes : MOA, MOE, Tests Applicatifs, Qualité, Sécurité, Exploitation, Support utilisateurs, Documentation, Comité Utilisateurs.

En fonction de la taille de l’entreprise et du projet, il se peut qu’une personne joue plusieurs rôles à la fois.

Le rôle du comité de pilotage est d’initier le projet, de prendre les décisions importantes aux problèmes qui lui sont soumis, d’assurer le pilotage du projet (via un tableau de bord qu’il a défini), et de reporter à la direction générale de l’avancement du projet.

Comité de pilotage du projet

MOA Tests applicatifs

MOE QualitéPrise

en compte

des enjeux

de qualité

SécuritéPrise en compte

des enjeux

de sécurité

Consultants PGI

EXPSupport Exploit.

FSUFormation Support

Utilisateurs

Comité Utilisateurs

Doc

STI STE COS



Q4.2-1: Selon vous, le rôle du comité est-il bien décrit ?

…………………………………………………………………………………………..................

Q4.2-2: La composition de ce comité est-elle pertinente ?

………………………………………………………………………………………………………

Q4.2-3: Autre remarque sur le comité de pilotage ?

……………………………………………………………………………………………………..

5 - Les pathologies des projets informatiques

Si l’on tente de résumer d’une phrase les raisons de l’échec d’un projet informatique, bien souvent on pourra entendre :

« Le projet était bien trop lourd, mal conçu dès le départ, les effectifs pas assez nombreux et pas assez qualifiés, le délai accordé trop court et sur une technologie dépassée. »

5.1 – Classification des pathologies

En fonction de nos expériences sur les projets informatiques nous pouvons lister des classes de dysfonctionnements de projets informatiques dont les causes se répartissent selon les trois dimensions suivantes du projet : organisationnelle, humaine et/ou informatique.

Causes organisationnelles

Mauvaise définition ou partage du but (finalité) du projet : pourquoi fait-on le projet ? Que va-t-il apporter concrètement (gain) à l’entreprise ? Pour quel coût ?

Absence de soutien de poids : aucun sponsor déclaré pour le projet… Le projet est-il prioritaire ?

Mauvaise structuration : pas de comité de pilotage ou comité fantôme (rôles non représentés) ; exemples : non prise en compte de la sécurité dans le projet ou décisions incohérentes.

Mauvaise réactivité : faute d’un tableau de bord à jour et pertinent, réaction trop tardive du management du projet aux dérives.

Perte d’information : Insuffisance ou pas de capitalisation des connaissances. Mauvaise gestion des sauvegardes des documents, mauvaise utilisation ou sous utilisation du gestionnaire de version, mauvaise qualité de documentation (analyse fonctionnelle, commentaires dans le code source…).

Manque de cohérence : le management des équipes du projet n’a pas pris le temps de rédiger les conventions de fonctionnement (pour les études ou le développement) ou celles-ci ne sont pas utilisées par les équipes, chacune faisant à sa guise.

Insuffisance des Tests Applicatifs : l’équipe Tests Applicatifs a été mise en place tardivement ou n’a pas été assez impliquée dans le projet. Campagnes de tests insuffisantes car pas assez de temps.



Evolution stratégique de l’entreprise : Changement du top management, rachat d’une société, le mariage avec une autre société /groupe peuvent remettre en cause les orientation du projet, voir aboutir à son abandon.

Autres causes organisationnelles… ?

Causes humaines

Problèmes de management des équipes : problème de leadership ou de communication, manquement dans l’animation ou la (re)motivation du groupe, pas assez ou trop de délégation, pas assez de contrôle, affrontements ou non respect des personnes. Failles d’exemplarité : le management ne joue pas le jeu en ne suivant pas lui même les consignes édictées.

Difficultés de management des consultants : consultants « juniors » pas assez expérimentés.

Mauvais management des priorités : mauvais choix de priorité, mauvais ordonnancement.

Mauvaise planifications : sous-estimation ou surestimation des tâches, mauvaise planification des tâches, difficultés ignorées, mauvaise estimation des ressources réellement disponibles pour le projet (tâches chronophages mal estimées).

Carences liées aux études MOA : insuffisances des spécifications, trop de remises en cause (corrections) ou trop d’évolutions (améliorations), ambiguïtés, non anticipation, non implication d’un acteur important pour les études, incompétences.

Carences liées aux études MOE : Avant le lancement des développements, non rédaction d’un cahier des charges détaillé mettant en valeur les difficultés techniques, levant les ambiguïtés et présentant l’ergonomie de la solution.

Ne pas savoir dire NON (MOE) : en présence d’une non maturité des besoins fonctionnels, de délais d'études insuffisants, d’effectifs sous-estimés ou de date de mise en production irréaliste, la MOE se doit de dire NON.

Turnover des membres : équipes inconstantes en perpétuel mouvement.

Carences liées aux tests applicatifs: Mauvaise conception des scénarios de tests, non capitalisation des tests (tests de non régression). Couverture fonctionnelle incomplète des tests applicatifs.

Formation insuffisante des membres : équipe pas assez formée sur le sujet ou sur un outil, manque d’expertise dans l’équipe.

Mauvaise représentation des utilisateurs : les préoccupations des utilisateurs n’ont pas été ou mal prises en comptes.

Autres causes humaines… ?

Causes informatiques

Liées aux choix technologiques : mauvaise anticipation, non anticipation ou prise de risque trop importante.

Liées aux outils : absence d’outils, inadéquation, changement de version en cours de projet, outil inopérant (bogué), incomplet.



Non prise en compte de la performance : Manque d’anticipation sur les problèmes de performances liés à la montée en charge de la solution dans des conditions réelles d’utilisation : vitesse d’exécution trop lente, base de données mal dimensionnée, optimisation des index non effectuée. Non prise en compte de la nécessité de fonctionnement minimal dans un environnement dégradé ou aucune solution de secours (redondance) prévue.

Autres causes informatiques… ?

Q5.1-1: Manque-t-il des causes de dysfonctionnements importants à cette liste ?

………………………………………………………………………………………………………

Q5.1-2: A votre avis quelles sont les causes de dysfonctionnement les plus graves pour le projet ?

………………………………………………………………………………………………………

Q5.1-3: A votre avis quelles sont les causes de dysfonctionnement les plus récurrentes ?

………………………………………………………………………………………………………

Q5.1-4: Autre remarque ?

………………………………………………………………………………………………………

5.2 –Autres Pathologies

Q5.2-1 : Existe-t-il des pathologies spécifiques… A la relation avec des consultants ?

……………………………………………………………………………………………………… Aux projets e-collaboratifs ?

……………………………………………………………………………………………………… Aux projets Open Source ?

………………………………………………………………………………………………………

Q5.2-2 : Autres pathologies non listées ci-dessus ?

………………………………………………………………………………………………………

5.3 – Diagnostic et prévention

Quelques questions sur les diagnostics et la prévention des problèmes :

Q5.3-1 : Comment s’assurer qu’un projet est bien portant ?

………………………………………………………………………………………………………

Q5.3-2 : Plus généralement comment réaliser un diagnostic d’un projet ? Existe-t-il une méthode, des outils… ?

………………………………………………………………………………………………………

Q5.3-3 : La prévention (des problèmes) est-elle payante ? Comment la rendre plus efficace ?



………………………………………………………………………………………………………

5.4 – Normes de développement de projets informatiques

Certains travaux ont conduit à l’élaboration de normes pour processus de développement logiciel : CMMI (Capability Maturity Model Integration), ISO 15504 (SPICE).

Q5.4-1 Que pensez-vous de ces normes ? Sont-elles utilisées ? En existe-t-il d’autres ?

………………………………………………………………………………………………………

6 - Les remèdes & Facteurs clés de succès

Dans cette partie nous allons essayer de recenser les remèdes connus aux pathologies citées au précédemment et dégager si possible les facteurs clés de succès d’un projet informatique.

6.1 – Remèdes aux pathologies identifiées

Q6.1-1 : Quels remèdes apporter aux principaux dysfonctionnements listés ?

………………………………………………………………………………………………………

6.2 – Facteurs clés de succès

L’exploitation des remontées d’expérience de chacun devra nous permettre de dégager des facteurs clés de succès pour la réussite d’un projet informatique.

Exemple : Définir clairement les responsabilités de chaque équipe (MOA, MOE…)

Q6.2-1 : Quels autres facteurs clés de succès (règles générales) à appliquer pour la réussite d’un projet informatique avez-vous identifiés ?

………………………………………………………………………………………………………

7 - Votre contribution au projet

Votre participation à cette étude est libre de prendre la forme que vous jugerez la plus utile. Qu’il s’agisse de réponses aux questions posées, de conseils, d’explications, de solutions ou de bonnes pratiques concernant les projets informatiques ou bien tout renvoi vers une documentation, un livre, un site ou un autre spécialiste du sujet.

Merci de retourner si possible votre contribution avant le 15 avril.

Merci beaucoup de votre participation à notre étude. Avec les remerciements de la promotion IMI 38 de Février 2008-



Annexe 9 : DysfonctionnementsPour ne pas alourdir le rapport et faciliter la lecture au jury, nous avons voulu enrichir notre base de connaissances avec 24 autres cas de dysfonctionnements. Au total, nous avons pu identifier 39 cas de dysfonctionnements pour les 3 mini-projets et 16 items.

Mini-projet : Management structuré de projet (18 cas)

Item Cas de dysfonctionnementExpression des besoins

C01 : Etude MOA insuffisante dans un contexte réglementaire incertain

C02 : Sélection d’un progiciel de gestion hôtelière (ce cas est présenté dans le rapport au II.2.)

C03 : Appel d’offres infructueux : logiciel de virtualisation du système d'information

C04 : Oubli de prise en compte de spécificités localesC05 : Manque du code devise

Découpage en phases et panorama des outils

C06 : MOA/MOE – Sélection d’outils UML/objets innovants mais incomplets (ce cas est présenté dans le rapport au II .3)

C07 : Mauvaise analyse des outils du marchéC08 : DG/MOA – Une mauvaise équation économique dans un environnement de revente indirecte a des conséquences techniques importantes.C09 : Implication insuffisante de la MOA

C10 : Inadéquation entre un outil de gestion et un automate fabriqué sur mesurePhase de planification et gestion du temps

C11 : MOA/MOE – Emploi de mêmes ressources en parallèle sur deux projets (ce cas est présenté dans le rapport au II .4.)

Phase de lancement C12 : MOE - Mauvaise sélection de l'atelier de développement (ce cas est présenté dans le rapport au II .5.)C13 : MOE - Manque d’un interlocuteur de l’équipe réseau dans l’équipe projet

Phase de production C14 : MOA/MOE - Difficulté à exprimer sa non compréhension dans un environnement délocalisé (ce cas est présenté dans le rapport au II.6.)

C15 : MOA/MOE - Tests incomplets sur plate-forme laboratoireC16 : MOE - Mauvais choix d’une solution technique

Phase de pilotage C18 : MOA/MOE - Autocensure du comité de pilotage pour ne pas contrarier les décisions de la DG (ce cas est présenté dans le rapport au II.7)



Mini-projet Management des équipes de projet (14 cas)Item Cas de dysfonctionnement

Gestion de ses priorités

C19 : Mobiliser du temps sur une activité projet en conservant une activité opérationnelle (ce cas est présenté dans le rapport au III .2)

Gestion des priorités collectives

C20 : Manque de disponibilité des équipes de développement (ce cas est présenté dans le rapport au III.3)

Management d’équipes de projet

C21 : L’art de composer une équipe et de piloter le changement (ce cas est présenté dans le rapport au II .4)C22 : Manque de leadership du chef de projet

C23 : Mauvaise gestion des plannings des membres utilisateurs de l’équipe MOAC24 : Déficit de communication

Implication des utilisateurs

C25 : Eclairage stratégique incompris par les acteurs du mouvement (ce cas est présenté dans le rapport au III .5)

C26 : La non prise en compte des exigences de performance des utilisateurs conduit à un gâchis colossal

C27 : Appréhension insuffisante des enjeux par les utilisateurs finauxC28 : MOA - Manque d’implication des utilisateurs du site pilote

C29 : Implication des utilisateursSoutien de la Direction Générale

C30 : Non soutien de la DG pour un projet dont elle n’était pas à l’origine

C31 : Changement du cadre d’application de la solution développéeC32 : MOA - Aucune implication et soutien de la DG (ce cas est présenté dans le rapport au III .6)

Mini-projet : Management des projets e-collaboratifs (7 cas)Item Cas de dysfonctionnement

Charte des valeurs de l’équipe de projet

C33 : MOA – Absence de charte de fonctionnement aboutit à des incohérencesC34 : Faire collaborer des personnes de cultures différentes

C35 : Choc des cultures dans une structure associative (ce cas est présenté dans le rapport au IV .2)


C36 : L’absence d’une charte d’utilisation de l’espace e-collaboratif aboutit à une perte de corrections (ce cas est présenté dans le rapport au IV .3)

Règles d’utilisation par l’équipe projet de l’espace e-collaboratif

C37 : MOE - mauvaise utilisation de l'espace collaboratif (ce cas est présenté dans le rapport au IV .4)

Tableaux de bord C38 : Intérêt de mettre en place un indicateur de production (ce cas est présenté dans le rapport au IV.5)


C39 : Prendre conscience de l’intérêt de la phase de capitalisation d’un projet (ce cas est présenté dans le rapport au IV.6)



1. Management structuré de projet

1.1. Expression des besoins

C01 : Etude MOA insuffisante dans un contexte réglementaire incertain

Dysfonctionnement Obsolescence du modèle de classes fourni par la MOA faute d’une fonction « reverse » - Contexte PME

Argumentaire Projet de 120 années hommes (1996 – 2000) : A la veille de l’introduction de l’Euro (en 2000, puis 2002), la gestion de la double comptabilisation simultanée en Francs et en Euros a été très difficile à définir correctement. De nombreuses modifications ont été apportées par la MOA alors que le projet était en phase de développement, impactant de nombreux modules et provoquant des retards dans le développement.Le développement d’un PGI comptable et financier, dans les années 1996-2000, juste avant l’introduction de l’Euro, a soulevé deux grandes difficultés aux concepteurs de progiciels comptables :- Comment tenir simultanément une double comptabilité en Francs et en Euros ? - Doit-on proposer une conversion à la volée des documents d’une monnaie dans l’autre ou doit-on proposer de basculer à tout instant de la monnaie Franc à la monnaie Euro et vice versa ? La première proposition aboutit à une impasse : les documents comptables équilibrés dans une monnaie ne l’étaient plus dans l’autre. Il s’agissait donc de concevoir des techniques de comptabilisation simultanée en double monnaie et même en triple monnaie avec la prise en compte des devises étrangères. Ainsi chaque mouvement comptable devait être enregistré en partie triple : montant en devise (celle de la transaction : devise, franc ou euro), correspondance du montant en monnaie 1 (Franc), correspondance du montant en monnaie 2 (Euro). Des écritures d’écarts de conversion, correspondantes aux différences d’arrondis, devaient se générer automatiquement et être prises en comptes dans la saisie comptable, l’ensemble des éditions légales, les tableaux et bilans financiers, les reports à nouveaux, le lettrage, etc.Malgré la participation d’un expert sur les techniques de comptabilisation, la mise au point finale n’a pu être réalisée que par tâtonnements successifs, la loi introduisant l’euro comme monnaie n’ayant prévu aucun texte d’application pour les règles de comptabilisation. L’ordre des experts comptables n’a pas pu émettre les recommandations utiles faute d’un accord en son sein. Il a été nécessaire de définir nous-mêmes, les techniques de comptabilisation et de les promouvoir auprès de l’ordre des experts comptables. Dans ce contexte réglementaire incertain, les modifications de la MOA ont été fréquentes, importantes et perturbantes pour le développement. Il n’était pas possible d’attendre d’être certains que les techniques de comptabilisation n’évolueraient plus.

Causes et effets Les causes :- Organisationnelles : La MOA n’a pas su ou pu définir directement la bonne technique de comptabilisation à utiliser. La réglementation comptable (Loi, ordre) ne préconisait aucune solution à adopter.Les effets :- Organisationnels : Redéfinition des modèles comptables et de certains traitements : saisie comptable, lettrage des mouvements, éditions comptables & financières, reports à nouveaux, etc. Tout ceci a engendré plusieurs semaines de



retard de développement.Pistes de solutions Aucune solution ne permet de lever totalement les incertitudes qui planent dans

un contexte réglementaire incertain. Après 3 à 4 modifications apportées au modèle de comptabilisation, une réunion de crise impliquant MOA et MOE a permis de déterminer le bon modèle technique et d’aboutir à la comptabilisation des mouvements en partie triple stable, car suffisamment paramétrable pour répondre aux évolutions. Les impacts définitifs sur les modules concernés ont été progressivement étudiés.

FCS Le lancement d’un projet lié à une évolution législative ou réglementaire est particulièrement risqué si des incertitudes demeurent. Dans la mesure du possible il convient de :- Lever toute incertitude avant de lancer la production.- Identifier au plus tôt les difficultés techniques ou réglementaires et leurs éventuels impacts.- S’entourer d’experts pour résoudre au mieux les difficultés.- En cas d’incertitude résiduelle, isoler au maximum les parties concernées par les incertitudes de manière à limiter l’impact des changements à un seul module.

1.1. Expression des besoins (suite)

C02 : Sélection d’un progiciel de gestion hôtelière

Ce cas est présenté dans le rapport au II.2.


C03 : Appel d’offres infructueux : logiciel de virtualisation du système d'information

Dysfonctionnement Besoin non cadré et flouArgumentaire En 2005, ce grand groupe français décide de réduire drastiquement ses coûts. Un

programme est lancé au niveau du système d’information pour le rationaliser et dégager des économies. En 2005, les grands acteurs informatiques prônent « l’informatique à la demande » et estiment avoir des technologies permettant de considérer l’informatique comme un service « activable » et disponible quand on en a besoin (un peu comme l’électricité, qui fait partie des « utilities » (en anglais). Certains parlent même d’ « Utility Computing ». C’est dans ce contexte que la Direction des achats du Groupe, sur la base d’une expression de besoin d’un architecte qui a décelé dans ces solutions une possibilité de faire des économies (conformément à la stratégie du groupe), lance un appel d’offres pour le choix et l’acquisition d’une solution logicielle de virtualisation du Système d’Information (virtualisation des applications, des systèmes et des infrastructures). Cette solution doit être implémentée sur l’ensemble des infrastructures et des applications (+de 2000 serveurs et + de 200 applications cibles).Plusieurs fournisseurs importants répondent et une négociation s’engage. Rapidement, les premiers problèmes apparaissent, les acteurs : achats et architectes ne connaissent pas le sujet et n’arrivent pas à aligner cette négociation au besoin exprimé et au périmètre du système d’information. Le service achat négocie sur un sujet qu'il ne connait pas, le besoin est mal défini et l'appel d'offres



pour une proposition commerciale (RFP : Request for Proposal) s'avère en fait être une demande d'informations ou appel d’offres à candidature (ou RFI : Request for Information).

Causes et effets Les causes identifiées :- Organisationnelle : dès le départ il est évident qu’il est impossible de mettre en place une solution si novatrice sur l’ensemble du SI et sur les 3 composantes (Applications, Systèmes, Infra), le besoin a mal été défini.- Humaine : l’architecte et le service achat n’ont pas été formés à ce genre de solutions.Les effets :- Humain : Le dysfonctionnement a causé un flou dans le processus d’appel d’offres, les personnes en charge de cette négociation ne répondaient plus aux sollicitations des fournisseurs. - Organisationnel : L’appel d’offres a du être déclaré infructueux.

Pistes de solutions Cet échec d’appel d’offres a conduit les acteurs du projet à redéfinir des besoins en adéquation avec le contexte du système d’information. Une réduction drastique du périmètre a été envisagée. Un choix a été fait 2 ans plus tard pour un logiciel permettant d’allouer « à la demande » des ressources systèmes (OS).

FCS Dans un projet qui peut devenir majeur pour l’évolution du SI et qui a la prétention d’afficher des économies pour l’entreprise, il faut : - Définir un besoin en adéquation avec le périmètre.- Benchmarker les solutions via des tests.- Commencer une implémentation sur un périmètre restreint.


C04 : Oubli de prise en compte de spécificités locales

Dysfonctionnement Bascule de SI composé de 5 applications locales sur une plateforme unique paneuropéenne

Argumentaire Dans le cadre de la bascule d’applications différentes dans une nouvelle plateforme paneuropéenne, une banque privée de gestion de fortune gérant des avoirs de sa clientèle internationale nomade souhaitait proposé un outil unique à ses différentes filiales afin que le client ait une connaissance globale de ses positions financières quelque soit le lieu ou la demande est émise.Dans le souhait de fournir une prestation de services équivalente sous un format semblable quel que soit le pays ou la demande de position des avoirs est émise, un groupe bancaire international décide de faire migrer toutes les différentes applications nationales de ses filiales sur une plateforme paneuropéenne.Les expressions des besoins ont été réalisées auprès de :- La direction commerciale réalisant la gestion des comptes clients- La direction ‘Trade’ pour activités de front-office pour ses opérations de boursières en directs (actions, obligations, options.) - La direction comptable et financière pour les opérations de back-office, comptabilité générale, comptabilité analytique finance.

Causes et Effets Les causes identifiées :- Organisationnelle : Les expressions de besoins n’ont pas été hiérarchisées collégialement. De fait l’arbitrage dans les expressions de besoins s’est fait de façon floue et arbitraire. La MOA a considérée qu’elle était très importante alors



que la MOE l’a négligée. La décision du directeur de programme l’a emportée, ne laissant pas la possibilité d’argumenter de nouveau la portée de l’expression de besoin.- Humaine : Les commerciaux, gestionnaires de portefeuille et les professionnels du Trade ont en commun de faire du business. Réaliser des opérations financières pour réaliser des plus-values ou dans l’espoir de gains est un objectif partagé tant par les clients, gestionnaires que les traders. Les différences entre les achats ou vente entre les clients et l’Etablissement ou les commissions directes sont générées par ces opérations. Effet :- Organisationnel : Des spécificités locales réglementaires n’ont pas été prises en compte.

Piste de solutions - Révéler des données a priori mineures dans un programme d’envergure.- Aucune expression de besoin ne doit être négligée par la MOE, sinon la MOA doit insister auprès du Directeur de programme pour lui faire comprendre la nécessité de tenir compte de cette particularité. - L’importance d’une expression de besoin ne tient pas uniquement dans sa particularité technique ou dans la probabilité de survenance mais dans les conséquences que sa négligence entraîne.- L’impact d’une particularité est différent selon le pays dans lequel elle apparaît, et des raisonnements nationaux ne sont pas transférables à un autre pays.

FCS - Identifier dès que possible les points essentiels que la MOA doit faire passer dans ses expressions de besoins.- Organiser une notation collégiale du poids des spécifications- Organiser en amont du projet une instance permettant d’arbitrer le poids d’un besoin dans le projet.


C05 : Manque du code devise

Dysfonctionnement Bascule à l’euro d’un système d’information de crédit d’un Etablissement bancaire parapublic

Argumentaire Lors de l’étude de l’impact de la bascule à l’Euro, un SI d’un Etablissement bancaire parapublic il est identifié de l’absence de la référence ‘Devise’ dans le SI.Nécessaire pour faire la conversion et obligatoire sur tous les documents publiés par l’Etablissement auprès des tiers, l’absence de la ‘Devise’ est un problème majeur pour réussir le passage à l’Euro.Obligation réglementaire européenne, la double tenue des comptes en devise locale et européenne, l’absence de la référence de devise dans le SI nécessite une analyse détaillée de toutes les chaînes du SI.Gérant plus de 10.000.000 de comptes personnels, cette charge doit être réalisé de façon parfaite et dans les délais impérativement.

Causes et effets Les causes identifiées :- Organisationnelles : L’Etablissement n’a que des agences fixes sur le territoire français (littoral, Dom-Tom) et mobile mais de droit français. Ne pouvant s’implanter à l’étranger, ni traiter de devises reçues à convertir en Franc, il ne fut jamais envisagé de pouvoir avoir besoin de devises. De fait la devise par défaut est le franc français ; c’est une économie dans les traitements pendant 30 ans des



chaînes informatiques de négliger la devise.- Humaines : les responsables financiers de l’Etablissement et les DSI n’ont jamais considéré comme important de pouvoir véhiculer la notion de devise dans les comptes ni dans les chaînes d’information.Les effets de la nouvelle réglementation sont :- Organisationnels : l’ensemble des SI a du être revu et une étude d’impact a été mener pour identifier les évolutions à faire dans le SI afin qu’il puisse fournir les deux devise sur chaque transaction et chaque montant véhiculé avec la bonne parité.- Humains : culturellement les utilisateurs des outils informatiques durent se former pour penser en devise double et oublier que les montants étaient exprimés en deux devises. A terme une des deux devises seraient ‘perdue’, la devise par défaut de départ (le Franc).

Pistes de solutions La considération comme non stratégique d’un événement ne pouvant pas arriver, n’a pas donnée au SI l’agilité nécessaire de pouvoir intégrer cette notion apparue ultérieurement. Pouvoir remettre en cause une donnée considérée comme une vérité universelle immuable est nécessaire. Des renseignements fiables et des indicateurs économiques permettant de faire des simulations sur des coûts d’opportunité (choix 1 ou choix 2) permet de réagir rapidement aux changements réglementaires incertains. Réagir dans l’urgence est toujours plus coûteux que l’anticipation en amont d’un changement inéluctable.La création d’un référentiel des choix stratégiques réalisés permettra de réactualiser, de reconsidérer ces choix régulièrement, et comprendre sur un SI des impacts éventuels en lien avec ces choix.

FCS - Classement des prises de décisions de choix stratégique dans la création d'outil - Anticipation d'une zone de référencement.

1.2. Découpage en phases et panorama des outils

C06 : MOA/MOE – Sélection d’outils UML/objets innovants mais incomplets

Ce cas est présenté dans le rapport au II.3

1.2. Découpage en phases et panorama des outils (suite)

C07 : Mauvaise analyse des outils du marché

Dysfonctionnement Refonte d’un système CAO - PME – 500 jour homme (2006)

Argumentaire Dans le cadre d’une concurrence de plus en plus forte sur les projets internationaux, une société d’ingénierie de conception/construction d’usines a souhaité modifier son modèle d’organisation pour pouvoir répondre de manière plus efficace à ses contraintes de production d’études, à savoir réactivité et réduction des coûts. La première étape fut de revisiter les processus afin de :- Identifier de mettre en évidence les tâches principales et leur valeur (pour mieux externaliser ou automatiser)- Identifier les points de blocage potentiel dans le processus (afin de mettre en place des indicateurs pour focaliser les expertises sur la maîtrise des dérives éventuelles)Ceci a conduit à l’implémentation d’un système CAO avec une double fonction :



- Permettre de concevoir les assemblages de pièces pour réaliser une installation- Produire les documents de construction et/ou d’approvisionnement des pièces rentrant en jeu dans l’assemblage défini.Les objectifs principaux de cet outil étaient de permettre l’interaction entre les intervenants internes (à qui étaient confiées les études générales) et externes (à qui étaient confiées les études de détail), d’automatiser un certain nombre de tâches (aide à la décision, production de plans de détail,…) et d’apporter aux responsables d’étude une visibilité sur l’activité des équipes. Une équipe Projet a été constituée avec deux objectifs principaux :- Fournir une solution opérationnelle et en rupture avec les pratiques en cours- Mettre à disposition un outil opérationnel sous 18 moisA la tête de cette équipe, la direction a mandaté un chef de projet, recruté spécifiquement pour cette mission, compte tenu de ses succès engrangés lors de la mise en place de solution du même type dans le monde industriel (automobile, machines spéciales, automatisme). Son approche très structurée et sa maîtrise de la conduite de projet était évidente, mais sa connaissance du monde de l’ingénierie d’usines était nulle. Pour satisfaire aux contraintes de délais, ce chef de projet a favorisé des solutions déjà éprouvées. Face à cette position, un des leaders du marché de la CAO mécanique a répondu à ces attentes en proposant un son outil avec des modules « adaptés aux activités de conception d’usines ». De nombreux développements ont été réalisés, avec plus ou moins de succès, avant de se rendre compte que la société sélectionnée n’avait aucune compétence sur ce marché. Ses efforts de R&D étaient d’ailleurs essentiellement dirigés vers son marché initial.Après un an, il a été nécessaire d’abandonner ce choix alternatif et de se revenir au produit déjà utilisé en s’appuyant sur des compétences spécialisées pour mettre en œuvre les modules complémentaires nécessaires. De plus, un certain nombre de développements spécifiques ont dû être fait pour compléter l’offre de cet éditeur.

Causes et effets Les causes identifiées :- Humaines : Le chef de projet a réussi à convaincre que la mise en place d’outils largement adoptés dans l’ingénierie mécanique était la solution, et les équipes ont suivi cette préconisation. La volonté d’un schéma de rupture a dominé la réflexion.Les effets :- Techniques : Changement complet des technologies mises en œuvre. Les développements démarrés ont été perdus. Solution totalement inadaptée au contexte. De plus, lors de l’abandon de cette solution, il a été nécessaire de « courtiser » les prestataires pour les amener à s’impliquer dans la refonte du système existant. - Organisationnels : Le projet a subi un retard de six mois et les nouvelles fonctionnalités ont été livrées au compte-goutte, induisant un effort d’adaptation permanent des utilisateurs.

Pistes de solutions Dans un projet, aucun arbitrage n’est définitif. Simplement, le coût du changement de cap doit être mis en regard du coût de continuation. Le choix radical du changement d’outil a eu un coût évident sur le projet et le retour à la solution initiale complétée de quelques modules a été vécu par la direction comme une régression. Mais quel aurait été le coût de la mise en place d’une solution inadaptée ?La stratégie retenue a été de mettre en œuvre différents modules, avec un pas de



temps suffisamment long pour permettre leur assimilation, mais induisant la nécessité d’un apprentissage permanent. Il est important de mettre en œuvre les bons outils, au bon moment.

FCS Le choix des outils est primordial car c’est de celui-ci que dépendent :Pour l’utilisateur : l’acceptation, l’appropriationPour l’équipe projet : la crédibilité, la motivation.Il est donc essentiel lors de la phase de sélection des outils, de :- Prendre le temps de faire une analyse détaillée du marché- Sélectionner des outils adaptés au contexte, même si cela devra avoir des impacts sur les délais.- Se doter dès que possible des ressources adéquates.- Identifier la capacité d’assimilation d’une nouvelle solution (mettre en regard la valeur des ressources que l’entreprise va perdre et les gains attendus par cette mise en place).


C08 : DG/MOA – Une mauvaise équation économique dans un environnement de revente indirecte a des conséquences techniques importantes

Dysfonctionnement Mauvaise anticipation de l'évolution des coûts de licences base de données relationnelle – Contexte PME

Argumentaire Dans les années 1995-1997, dans le cadre d’un nouveau développement d’un progiciel de gestion intégré PGI, développement majeur pour l’éditeur (PME), l’alternative suivante s’est posée :- Peut-on utiliser une base de données relationnelle pour le développement du nouveau progiciel ? Ceci suppose des coûts supplémentaires de licences pour chaque utilisateur (1800 FRF soit 275 EUR par utilisateur).- Doit-on rester avec un gestionnaire de fichiers, type séquentiel indexé, comme par exemple Access, qui n’engage pas de surcoût par utilisateur ?L’équation économique d’un éditeur de progiciels de gestion fonctionnant en indirect via un réseau de grossistes et de revendeurs était du type : - Prix de vente client final = prix d’achat revendeur + marge revendeur (38%)- Prix d’achat revendeur = prix de achat grossiste + marge grossiste (38%)- Prix d’achat grossiste = prix de revient éditeur + marge éditeurAinsi pour un prix de vente client final de 100 le chiffre d’affaires restant à l’éditeur n’était que de 38 environ soit 62% de remise globale. Or la part restante à l’éditeur se décompose ainsi : - Prix de revient éditeur = coûts fixes (salaires, loyers…) + coûts variables (ceux engagés pour chaque vente = licences, publicité, conditionnement, expédition…) Il est évident que dans ce schéma, toute augmentation des coûts (C) a pour conséquence soit une hausse du prix client final de 1,6 x C, soit une diminution de la marge éditeur d’autant.Compte tenu du système de cascade de marge et du positionnent produit/client, la direction générale a décidé que le surcoût lié à l’utilisation d’une base de données relationnelle était trop important. La MOA a imposé un développement SQL pour se ménager un recours ultérieur à une base de données relationnelle. La MOE a développé suivant les recommandations, mais rapidement de gros problèmes de performance sont apparus : le traitement des ordres SQL par un gestionnaire de



fichier de type Access n’était pas assez performant, il fallait réagir.La MOA et la DG n’ont pas su anticiper l’évolution des tarifs des licences base de données relationnelle : 18 mois plus tard, le coût des licences utilisateurs pour l’usage d’une base de données relationnelle s’effondrait !

Causes et effets Les causes identifiées :- Humaines : La MOA a imposé une solution technique pour un motif économique qui allait s’avérer inconsistant à terme (mauvaise anticipation).- Techniques : La MOE a accepté un développement dans des conditions de performance insuffisante, elle aurait du refuser.Les effets : - Organisationnels : Des ressources importantes ont été consacrées à optimiser la solution. De plus, les limitations du gestionnaire de fichier n’ont pas permis d’adresser commercialement les entreprises ayant de gros volumes.- Techniques : la solution technique adoptée a généré d’autres problèmes, tels que les accès concurrents en réseau. L’usage d’une base de données relationnelle n’aurait pas engendré ces dysfonctionnements.

Pistes de solutions Face à l’inefficacité de traitement des ordres SQL de lecture (SELECT), la MOE a conçu et développé une couche d’analyse et d’interprétation des ordres SQL et réécrit ces ordres. Ces travaux ont permis d’améliorer la performance du progiciel de façon spectaculaire (gain d’un facteur 10). Ils ont cependant coûté cher en temps de développement et généré un retard de livraison du projet.

FCS Face à un nouveau projet majeur et engageant de l’entreprise il faut :- Veiller à faire les bons choix technologiques.- Essayer d’anticiper les tendances. - Envisager, s’il le faut, d’adapter le modèle économique de l’entreprise aux offres technologiques du marché.


C09 : Implication insuffisante de la MOA

Dysfonctionnement Mise en place d’un système de SGDT – PME – 1000 jour homme (2002-2003)Argumentaire Afin de rationaliser les échanges entre les personnes collaborant à un projet, une

société d’ingénierie de conception/construction d’usines a souhaité mettre en place un outil de partage/validation des données échangées entre les collaborateurs participant à la définition des composants d’une installation pour :- Disposer d’un référentiel commun entre les acteurs (études, achat, appro, experts…)- Historiser les opérations de chaque intervenant du projet.- Mettre en place un système multilingue afin de favoriser la coopération inter-BU.Ces concepts nécessitent l’implication des maîtrises d’ouvrages opérationnelles pour être complètement mis en œuvre car il rebat les cartes du système existant.Dans un premier temps, les maîtrises d’ouvrage se sont impliquées et ont mis des ressources pertinentes à disposition de l’équipe projet. Après six mois, les ressources mises à disposition ont été reprises et réaffectées à des tâches opérationnelles. Les ressources mises à disposition à partir de ce moment ont été de qualité largement moindre. Ces ressources n’étaient pas représentatives et avaient comme seul point commun de « ne pas manquer à leur organisation



d’origine ».L’équipe projet a développé un outil de gestion des données sur la base des demandes établies par la maîtrise d’ouvrage. Toutefois, la solution comportait un certain nombre d’imperfections « métier », en particulier sur la définition des profils des utilisateurs et donc de leurs droits, qui n’ont pas été identifiées par les collaborateurs en place. Pire, les choix ont été validés par les représentants de la maîtrise d’ouvrage, compte tenu de leur éloignement à l’activité de leurs services.

Causes et effets Les causes identifiées :- Organisationnelles : Les maîtrises d’ouvrages, peu concernées par le projet, ont minimisé l’importance de leur apport et mis à disposition des ressources inadéquates.- Humaines : Les ressources mises à disposition, bien que conscientes de leur manque de représentativité, ne se sont pas retournées vers leurs mandants pour effectuer les arbitrages pour lesquels ils ne disposaient des compétences. L’équipe projet s’est appuyée sur cet échantillon, bien que le sachant non représentatif, pour développer le produit en souhaitant lui faire porter les choix faits.Les effets :- Techniques : La solution mise en place, paramétrée avec les éléments fournis par les représentants de la maîtrise d’ouvrage, ne répondait pas aux besoins et a dû faire l’objet de nombreuses évolutions post-déploiement pour infléchir certains choix. - Humains : Un travail de fond a dû être mené pour rationaliser le nombre de champs mis à disposition des utilisateurs, leur nombre nuisant à la qualité de remplissage En effet, cet aspect a particulièrement nuit à l’appropriation de l’outil par les utilisateurs. De plus, l’effort de formation initial a été plus important que prévu.

Pistes de solutions La mauvaise définition par les représentants de la maîtrise d’ouvrage des droits et profils des utilisateurs ayant conduit rapidement à des blocages dans la phase pilote, un groupe de travail spécifique a été monté, en impliquant les responsables d’études et un animateur externe spécialisé dans la mise en place de plateforme collaborative. Sur la base des constats de dysfonctionnement lors de la phase pilote, une nouvelle cartographie des profils et des droits a été établie. De manière itérative, sur un pas de temps plus long, une analyse détaillée des champs disponibles a été réalisée pour limiter leur nombre, homogénéiser leur usage et leur format.L’accompagnement s’est poursuivi sur plusieurs années afin de garantir la bonne utilisation du système. Un référent a été identifié dans chaque entité opérationnelle. Nous avons demandé qu’il soit un collaborateur reconnu par ses pairs pour ses compétences métier.

FCS L’implication de la maîtrise d’ouvrage durant toute la durée du projet est essentielle. En particulier, il faut veiller à la pertinence des ressources allouées par elle. Au-delà de ce point, l’équipe constituée doit être unie et les enjeux doivent être partagés par tous. La maîtrise d’ouvrage doit être la garante de l’acceptation de la solution mise en œuvre.Une solution consiste à lui confier la responsabilité des budgets mis en œuvre et de disposer d’un sponsor « métier » évalué sur l’appropriation des outils par les utilisateurs finaux.Quand cela est possible, (taille d’entreprise, nombre de projets suffisants), il peut être intéressant de créer une structure « maîtrise d’ouvrage déléguée » pour assister les maîtrises d’ouvrage dans la définition des besoins et leur assurer le reporting des actions menées par la MOE. Cette structure doit être composée de



personnes proches du métier mais disposant d’une culture SI.


C10 : Inadéquation entre un outil de gestion et un automate fabriqué sur mesure

Dysfonctionnement Problème d’interface entre le logiciel d’entrepôt et l’automate.

Argumentaire Refonte du SI d’un entrepôt – plusieurs milliers de jours 1997 -1999 – Afin de rester dans la course et se différencier de ses concurrents, une chaîne de magasins spécialisée dans la distribution de produits culturels et électroniques décide de replacer le client au centre de la finalité de l’activité. Une des actions principale consistait à libérer au maximum les vendeurs des tâches de passage de commande et de réapprovisionnement dans l’entrepôt.Pour mener à bien ce projet l’automate en charge du tri automatique des ordres de réapprovisionnements a été remplacé par une nouvelle plateforme fabriquée sur mesure à l’étranger. Celle-ci devait permettre d’automatiser les tâches récurrentes et sans valeurs ajoutées effectués par les vendeurs. L’équipe projet a développé les modules spécifiques devant répondre aux besoins de la nouvelle plateforme. Lors de la mise en production il a été constaté que certains scénarios n’étaient pas valides, malgré la vigilance de l’équipe projet certaines réactions de l’automate n’étaient pas prévisibles. Ceci a conduit à repenser la chaîne logistique de l’entrepôt et à effectuer de nombreux ajustements.

Causes et effets Les causes identifiées :- Techniques : Les ordres envoyés par le logiciel de gestion sont trop évolués pour être traités de façon automatisée par le nouvel automate. - Organisationnelle : Effet tunnel du cycle de développement en V. Insuffisance des tests applicatifs. Les effets :- Organisationnels et Humains : Retard pris dans les développements, réduction de la couverture fonctionnelle. Les vendeurs n’ont pas pleinement tiré profits des nouvelles fonctionnalités de l’automate puisque certaines actions restaient manuelles.

Pistes de solution Dans un contexte de mise en place d’outil singulier et non éprouvé, il est difficile d’anticiper certains dysfonctionnements inhérents à ce type de projet. La couverture fonctionnelle a été revue à la baisse et des actions manuelles ont été conservées.

FCS Dans tout projet d’envergure il est important de livrer des premiers lots rapidement afin de mettre en évidence les dysfonctionnements. Le plus tôt possible et de rectifier la trajectoire. L’implication forte de l’équipe tests applicatifs dans le projet doit être mis en avant dés le début du projet.

1.3. Phase de planification et gestion du temps

C11 : MOA/MOE – Emploi de mêmes ressources en parallèle sur deux projets




1.4. Phase de lancement

C12 : MOE - Mauvaise sélection de l'atelier de développement


1.4. Phase de lancement (suite)

C13 : MOE - Manque d’un interlocuteur de l’équipe réseau dans l’équipe projet

Dysfonctionnement Infrastructure réseau non opérationnelle pour accueillir la nouvelle solution – Contexte : Groupe international

Argumentaire En 2007, l’équipe commerciale française d’un Groupe décide de supprimer le traitement papier des fax et demande à la structure informatique la mise en œuvre d’un serveur de fax. Le site commercial est autonome et ne possède pas d’équipe informatique sur le site. En effet, cette équipe est installée au siège central. Après étude du marché, l’équipe commerciale retient la solution proposée par la société qui fournissait les fax. Cette solution, pour des raisons de maintenance et de sécurité, ne doit pas être installée sur le LAN du site commercial. Le chef de projet informatique décide d’élaborer une solution avec l’équipe de la production et de la sécurité et avec les ingénieurs de la société de fax. Il est construit une solution client serveur sur un réseau DMZ. Ce choix est validé sur une plate-forme laboratoire. Une semaine avant la mise en production, l’équipe sécurité s’aperçoit que le LAN est saturé (panneaux de brassage et switchs) et ne peut pas accueillir les éléments actifs (routeurs, firewall) et le serveur. En urgence, il est aménagé une solution provisoire (mini hub sur 1 port libéré) pour ne pas retarder l’installation.

Causes et effets La cause identifiée :- Humaine : le chef de projet n’a pas, lors de la constitution de l’équipe projet, fait appel à l’équipe réseau.L’effet : - Technique : L’infrastructure réseau étant saturée, la solution provisoire n’est pas performante.

Pistes de solutions Il a fallu rapidement acheter des équipements supplémentaires puis intervenir après la mise en production pour réaménager l’installation de la solution (Serveur, routeur, firewall).

FCS Le chef de projet doit bien qualifier les interlocuteurs nécessaires aux projets et avoir une vision globale du projet.

1.5. Phase de production

C14 : MOA/MOE - Difficulté à exprimer sa non compréhension dans un environnement délocalisé




1.5. Phase de production (suite)

C15 : MOA/MOE - Tests incomplets sur plate-forme laboratoire

Dysfonctionnement Mauvaise performance de l’application sur les pc des utilisateurs – Contexte : Groupe international

Argumentaire En 2000, un groupe international hôtelier décide de développer un outil intranet commercial à destination de ses hôtels. Cet intranet doit servir à informer les hôtels des contrats commerciaux et doit remonter des statistiques de ventes saisies par les commerciaux des hôtels à la Direction commerciale France. Cela doit permettre une meilleure réactivité dés équipes commerciales dans un environnement très concurrentiel.Lors de la mise en production des premiers hôtels, les commerciaux constatent que les temps de réponse en consultation et remontée des informations ne sont pas satisfaisants. Il s’avère que les tests ont été effectués sur des PC de dernières générations et seulement en laboratoire sur le LAN de l’équipe de développement. Les PC des utilisateurs étaient des modèles plus anciens avec de la RAM et des processeurs aux performances très inférieures aux machines de test. De plus, le réseau WAN, de type RNIS n’était pas assez performant pour cet intranet.

Causes et effets La cause identifiée :- Organisationnelle : Dans le cahier des charges, le contexte matériel et réseau de l’utilisation de l’application intranet n’ont pas été pris en compte.Les effets :- Organisationnels : La mise en place de cet outil a été retardée de plusieurs mois. Les hôtels ont du continuer à remonter des informations manuellement par courriel. La consolidation à la Direction commerciale France n’est pas améliorée. La direction commerciale France perd ainsi un avantage face à la concurrence.- Techniques : l’application n’est pas performante pour une mise en production.

Pistes de solutions Il a fallu revoir le développement de l’application pour optimiser les traitements sur les PC et sur le réseau WAN. Il a fallu changer le parc PC des commerciaux des hôtels pour qu’ils soient plus puissants.

FCS Dans le cahier des charges, il est essentiel de décrire de contexte technique (matériel, LAN, WAN) dans lequel va être utilisé le développement. Il est aussi important de faire des tests qui soient les plus proches possibles de la réalité du terrain. Un test en grandeur réelle sur un site pilote permet de confirmer le fonctionnement.


C16 : MOE - Mauvais choix d’une solution technique

Dysfonctionnement Solution technique non évolutive – Contexte Groupe InternationalArgumentaire Période concernée : 2004-2005

Un groupe hôtelier possède un progiciel de gestion hôtelière qui contient un module de facturation des clients. L’ancienneté du progiciel hôtelier ne permet pas de stocker numériquement les factures des clients dans les systèmes. En 2004, Suite à des contrôles fiscaux, il est décidé par le groupe hôtelier de développer sa propre solution d’archivage et de sauvegarde des factures. La solution consiste à transférer les factures du progiciel vers un PC construit spécifiquement pour cette



fonction. Le PC doit stocker les factures sous un format PDF, puis permet une gravure pour un stockage en sécurité hors du local informatique. L'équipe informatique, pour des raisons de coûts et de contrainte d’OS des serveurs (Unix, Windows), choisit un logiciel « open source ». Ce logiciel est ensuite modifié en interne pour améliorer les performances et la sécurité des traitements. Plusieurs mois après l’installation de cette solution dans les hôtels, il est constaté 2 problèmes importants :Sur certains hôtels, la taille des données à graver dépasse la capacité de gravure du DVD. Certains hôtels possèdent 20 Giga de données. Le logiciel n’arrive pas à compresser les données et ne permet pas de graver dans des temps satisfaisants plusieurs DVD. Il faut en moyenne plus de 2h pour faire la gravure et contrôler automatiquement les 3 DVD.Le PC qui sert à cette solution de stockage et de gravure a été élaboré spécialement chez un constructeur .Lors des premières pannes et remplacements des graveurs par un modèle plus récent, la solution ne grave plus. Il s’avère que le logiciel de gravure ne possède pas les bons jeux d’instruction pour tous les modèles de graveurs du marché.

Causes et effets La cause identifiée :- Technique : La solution open source est limitée. Elle doit en permanence être améliorée.Les effets :- Techniques : La solution ne donne pas satisfaction dans tous les cas. Certaines gravures ne sont plus possibles. Il faut aussi contrôler avec le mainteneur matériel qu’il possède bien en stock des graveurs compatibles avec le logiciel.- Organisationnels : l’équipe qui avait choisi et amélioré le logiciel de gravure n’était plus disponible pour remettre à niveau le logiciel. Il a été nécessaire d’affecter une ressource régulière à la gestion de ce logiciel.

Pistes de solutions Le logiciel a été modifié pour compresser les données avant la gravure puis pour pouvoir graver plusieurs DVD dans des temps acceptables.

FCS Le choix d’une solution open source implique d’avoir en interne des compétences techniques et des équipes disponibles. [On utilise l’expression « d’autre part » si vous utilisez d’abord « d’une part »]. Il faudra également faire évoluer cette solution en fonction des matériels des constructeurs.


C17 : Projet de gestion de stockage

Dysfonctionnement Mauvaise anticipation du besoin en capacité de stockage, explosion des coûts informatiques

Argumentaire En 2006, dans un contexte d’économies et de réductions budgétaires, le Directeur des Systèmes d’information de ce groupe industriel français, pressé par ses clients internes, impose à son directeur de production de mettre à disposition rapidement du stockage additionnel pour plusieurs applications. Un réseau de stockage est déjà en place (SAN : storage area network) et suite à un sondage manuel, le taux de remplissage des baies de stockage est de 80% (il n'est en fait que de 40%). La Direction de production ne dispose pas d'un outil de mesure permettant de confirmer cette information pour l'ensemble de son stockage en réseau SAN. Cette direction demande alors des budgets additionnels et non prévus pour effectuer des achats massifs de stockage.



L’accord est donné et le dépassement de budget a des effets collatéraux importants et multiples sur les projets en cours de développement : achats retardés, décalages de mise en œuvre de certains projets… Compte tenu des délais de réception des nouvelles infrastructures de stockage, la mise en production s’effectue précipitamment et les interruptions de services sont fréquentes. L’équilibre en production sera retrouvé plus d’un mois après la mise en œuvre des nouvelles baies de stockage.

Causes et effets Les causes identifiées :- Organisationnelle : Mauvaise anticipation due à un manque de visibilité de l’existant.- Technique : Manque d’outils de mesure Les effets : - Organisationnel : impacts forts sur les projets : décalages, reports et impacts sur la production informatique : mise en production précipitée provoquant des indisponibilités sur des applications en production, perte de chiffre d’affaires.- Technique : interruptions de service

Pistes de solutions Par l’implémentation de supervision, de tableaux de bord de production liés au stockage (même manuels), le directeur de production aurait pu répondre simplement et favorablement aux nouveaux besoins dans des délais raisonnables.

FCS Face au à l’accroissement des besoins en capacité de stockage, la Direction du SI se doit de mettre en place une organisation informatique dédiée à la gestion du stockage : créer de nouvelles fonctions comme Architecte Stockage, Responsable de Supervision Stockage, Responsable Stockage…La DSI doit aussi mettre l’accent sur les outils : il faut mettre à la disposition de ces nouveaux acteurs des outils adaptés de gestion qui permettent de piloter la fonction stockage, anticiper les besoins, améliorer la mise à disposition des infrastructures...La veille technologique est nécessaire pour le choix de ces solutions :- Création de nouveaux « métiers » orientés « stockage » au sein de la DSI. - Sélection d’outils de gestion de stockage.- Veille technologique.

1.6. Phase de pilotage

C18 : MOA/MOE - Autocensure du comité de pilotage pour ne pas contrarier les décisions de la DG

Ce cas est présenté dans le rapport au II .7.



2. Management des équipes de projet

2.1. Gestion de ses priorités

C19 : Mobiliser du temps sur une activité projet en conservant une activité opérationnelle

Ce cas est présenté dans le rapport au III .2

2.2. Gestion des priorités collectives

C20 : Manque de disponibilité des équipes de développement


2.3. Management d’équipes de projet

C21 : L’art de composer une équipe et de piloter le changement


2.3. Management d’équipes de projet (suite)

C22 : Manque de leadership du chef de projet

Dysfonctionnement Remplacement d’une GED technique

Argumentaire Dans une entreprise dont le cœur de métier est l’ingénierie, une GED documentaire classique pour des documents simples a été mise en œuvre avec succès incluant des workflow de validation et des fonctions de suivi de production.La direction a comme objectif d’étendre la « solution » aux documents de type techniques (CAO/DAO).Compte tenu du nombre d’applications impactées, il a été décidé de compléter l’équipe de la DSI par un chef de projet dédié aux applications d’ingénierie. Le choix s’est porté sur un consultant qui intervenait depuis plusieurs années sur les différents projets de ce type, qui a été embauché pour prendre en charge le projet de refonte de la GED.L’objectif fixé était d’aligner le mode de gestion des descriptifs techniques détaillés (plans) avec le mode gestion des descriptifs techniques généraux (spécifs, Notes de Calcul).Le chef de projet a accepté la mission. Après une phase d’analyse du marché et d’évaluation des solutions disponibles, une évaluation du coût a été faite. Ce budget était crédible au regard des ressources dont il disposait et de l’objectif visé.Durant la phase de spécification détaillée, les coûts de développement et de paramétrage proposés ont été validés.Dans un contexte de réduction des coûts, la direction a décidé des coupes budgétaires dans le projet et le chef de projet n’a pas été en mesure de porter le



budget de manière suffisante. Le chef de projet a tenté de maintenir la couverture fonctionnelle en réduisant la performance de chacune des fonctions de la solution globale. A de nombreuses reprises, il a été alerté par ses équipes sur les manques fonctionnels mais a communiqué sur la tenue des délais et sur la conservation du niveau de fonctionnel. Il pensait pouvoir dégager des marges de manœuvre ultérieurement.Le déploiement a échoué par le manque de service rendu aux utilisateurs qui ont favorisé l’utilisation du réseau en simple partage de fichier pour le traitement des fichiers CAO.Finalement, le directeur de projet a été discrédité : - Par ses équipes, qui comptaient sur lui pour défendre le produit qu’ils développaient.- Par son client interne, qui n’a pas eu ce qu’il attendait.Le chef de projet :- N’a pas été capable de dire Stop au projet dans ces conditions.- N’a pas su créer un environnement propice à la liberté de parole : certains « sentaient » que ça ne marcherait pas.- A fait croire à l’équipe qu’il maîtrisait le sujet.

Causes et effets Les causes identifiées :- Humaines : Le chef de projet ne disposait pas des compétences managériales requises pour la mission qui lui avait été confiée. Il ne maîtrisait pas suffisamment son environnement pour défendre son projet auprès de la direction.Les effets :- Humains : Perte de confiance des équipes ; - Perte de légitimité du chef de projet Licenciement. - Utilisateurs finaux réticents à la mise en place d’un projet de récupération.- Organisationnels : Création d’un mode de fonctionnement alternatif par les utilisateurs finaux. Refonte de l’équipe projet après le départ du chef de projet. Les entités opérationnelles, ayant pris conscience tardivement de la nécessaire reprise des données, elles ont détaché une ressource compétente pour assurer la reprise des données saisies. L’impact financier de cette reprise a été évalué à 1800 jours homme.

Pistes de solutions Lors de l’embauche d’une ressource « décisionnaire », la période d’adaptation doit être bien identifiée afin de s’assurer qu’elle dispose de la légitimité nécessaire et de la bonne évaluation de son environnement lors de sa prise de fonction. Il doit également être capable d’affirmer ses positions clairement.

FCS Il est nécessaire d’avoir un chef de projet :- Reconnu pour son expertise métier en externe (qu’il noue des partenariats avec la MOA s’il ne peut pas le faire en direct).- Légitime auprès de ses équipes.- Capable de s’opposer à la hiérarchie si l’équipe projet n’est pas capable de le faire.




C23 : Mauvaise gestion des plannings des membres utilisateurs de l’équipe MOA

Dysfonctionnement Aucune gestion par le chef de projet MOA des congés des membres de l’équipe – Contexte : Groupe International

Argumentaire Période concernée : 1995.Un Groupe d’hôtel international décide de construire son propre progiciel de gestion hôtelière. La direction du projet est assurée par la Direction Informatique, qui à cette période, a plus de poids dans le management du groupe que les Directions Opérationnelles. La Direction Informatique constitue une équipe projet composée d’utilisateurs représentant les métiers et d’une équipe d’informaticiens en sous-traitance (concepteur base de données, développeur interface graphique, développeur base de données, etc.). Le chef de projet choisi, ne venant pas du métier, ne possède ni les compétences techniques ni les compétences managériales nécessaires à cette mission. Le projet doit se dérouler sur 12 mois. Le chef de projet, pour respecter les délais qu’il s’est fixé, refuse de donner les congés à l’équipe utilisateurs. L’équipe est fatiguée et plusieurs membres de l’équipe quittent le projet.

Causes et effets La cause identifiée :- Humaine : Le chef de projet MOA refuse de prendre en compte les congés des équipes estimant que cela ralentit le projet.Les effets :- Humains : Démotivation des membres de l’équipe MOA.- Organisationnels : Plusieurs membres de l’équipe quittent le projet. Il faudra revoir la constitution de l’équipe projet MOA.

Pistes de solutions Le chef de projet a maintenu cette pression sur l’équipe. Les départs des membres de l’équipe l’ont obligé de revoir la charge de travail et trouver de nouveaux membres pour intégrer l’équipe MOA.

FCS Le chef de projet doit toujours prendre en considération les absences dans la gestion du planning des équipes :- Il doit gérer les congés des équipes nécessaires à l’équilibre entre vie professionnelle et familiale et au repos des individus.- Il doit créer un climat de confiance et de bonne humeur au sein de l’équipe.- Il doit respecter les délais légaux de travail.


C24 : Déficit de communication

Dysfonctionnement Bascule de SI composé de 5 applications locales sur une plateforme unique paneuropéenne

Argumentaire Dans le cadre de la bascule d’applications différentes dans une nouvelle plateforme paneuropéenne, une banque privée de gestion de fortune gérant des avoirs de sa clientèle internationale nomade souhaitait proposé un outil unique à ses différentes filiales afin que le client ait une connaissance globale de ses positions financières quelque soit le lieu ou la demande est émise.Dans le souhait de fournir une prestation de services équivalente sous un format



semblable quel que soit le pays ou la demande de position des avoirs est émise, un groupe bancaire international décide de faire migrer toutes les différentes applications nationales de ses filiales sur une plateforme paneuropéenne.Le déficit de communication est constatée dans la non prise en compte des l’expression de besoin de la Moa locale. Des informations de première importance ne sont pas prises ne compte au niveau de la direction du projet.L’expérience des membres de la direction du projet est loin des métiers exprimant ces besoins spécifiques et réglementaires. La culture anglo-saxonne d’alors n’est pas-sensible aux contraintes strictes de la réglementationLa moa n’a pas appuyée suffisamment ses demandes et trouvée des sponsors de ses demandes primordiales pour l’Etablissement.

Causes et effets Causes identifiées :- Humaines : Exprimer des spécificités locales par une MOA locale face à une MOE multiculturelle anglaise nombreuse et des donneurs d’ordres Suisses n’est pas aisé. Exprimer ces spécificités locales dans un projet paneuropéen, alors même que l’objectif est d’homogénéiser les méthodes de travail et les outils ne va pas dans le sens favorable du rapport de force. La MOA a considérée qu’elle était très importante alors que la Moe l’a négligée. La décision du directeur de programme l’a emportée, ne laissant pas la possibilité d’argumenter de nouveau la portée de l’expression de besoinEffet :- Organisationnel : des spécificités locales réglementaires n’ont pas été prises en compte, temporairement, dans l’organisation des lots de tests.

Pistes de solutions La difficulté à remonter la valeur d''informations par une équipe opérationnelle intervenant en plus dans le projet sans une maîtrise complète du rythme, des enjeux et des intervenants peut être jugulée. Il faut un langage commun entre des professionnels d'horizon varié et de cultures différentes. Toutefois il faut pouvoir s’assurer d’une ‘piste de remontée’ d’information à fort enjeu adéquate.

FCS Enrichissement de la culture commune au projet et compréhension des demandes obligatoires et souhaitées des utilisateurs et de la mise en œuvre des moyens techniques. Sensibiliser au un ‘détail’ local dans une démarche globale ‘standardisante’, homogénéisante, décloisonante, internationale et multiculturelle.

2.4. Implication des utilisateurs

C25 : Eclairage stratégique incompris par les acteurs du mouvement


2.4. Implication des utilisateurs (suite)

C26 : La non prise en compte des exigences de performance des utilisateurs conduit à un gâchis colossal

Dysfonctionnement Temps de réponse en condition réel de fonctionnement insupportable pour les utilisateurs – Contexte Public Grand compte

Argumentaire Période concernée : 2006 – Cas recueilli lors de l’interview de M. Printz.Au sein d’un organisme public important un projet majeur (100 000 000 €) de refonte du système d’information a été lancé. Le projet concerne 15 000 agents



dont l’usage de l’ordinateur est essentiel à l’exercice de leur fonction. Le comité de pilotage est constitué mais les utilisateurs ne sont pas ou mal représentés. Après une phase d’étude, les développements sont lancés. Des tests en simulation (non en situation réelle) semblent donner satisfaction pour ce qui concerne les temps de réponses.Lors de la mise en place de la solution dans l’environnement réel, les agents étaient dans l’incapacité de travailler correctement compte tenu des temps de réponse du système : les flux de données transitant sur le réseau étaient beaucoup trop volumineux.Le projet a finalement été abandonné, donnant lieu à un phénoménal gâchis.

Causes et effets Les causes identifiées :- Organisationnelle : mauvaise rédaction du cahier des charges qui n’insiste pas sur les contraintes fortes de fonctionnement (15 000 postes fonctionnant en réseau) et sur la nécessité de performance du système (temps de réponse notamment). Non prise en compte des utilisateurs et de leurs exigences.- Humaine : Un manque de compétence de la MOE semble évident concernant l’architecture de la solution retenue.- Technique : 15 000 postes qui « travaillent » sur un réseau consomment une bande passante importante. Cette bande passante n’est pas extensible. Elle était clairement une contrainte forte qu’il fallait prendre en compte dès la conception.L’effet :- Organisationnel : projet abandonné, perte financière immense pour la collectivité.

Pistes de solutions Aucune solution n’a été apportée puisque le projet a été abandonné.Dans ce type de projet avec un nombre d’utilisateurs simultanés important, une bande passante limitée, il convient de privilégier une conception web ou client léger qui limite la consommation de bande passante vers les postes : serveur web ou architecture n-tiers permettent de disposer d’une bande passante importante des serveurs applicatifs vers les serveurs base de données sans empiéter sur la bande passante des utilisateurs.

FCS Pour tout projet notamment d’envergure importante on se doit : - De prendre en compte les exigences de fonctionnement des utilisateurs : ergonomie et performance.- D’intégrer au plus tôt dans la conception les contraintes d’architectures : les serveurs web et l’architecture n-tiers sont moins consommateurs de bande passante utilisateur.- De sensibiliser les développeurs (MOE) aux contraintes : formulation de recommandations de développement. - De vérifier régulièrement et en condition réelle la performance de la solution.


C27 : Appréhension insuffisante des enjeux par les utilisateurs finaux

Dysfonctionnement Outil référentiel patrimoine - Grand groupe (2007)

Argumentaire L’entreprise, dont le cœur de métier est la gestion opérationnelle d’unités de production et de distribution confiées par les clients, doit disposer d’outils de gestion de ces installations. Un outil, mis en place depuis plusieurs années pour la partie distribution a fait l’objet d’une normalisation du modèle de données et rend



aujourd’hui le service attendu. En revanche, pour la gestion des unités de production, aucun outil fédérateur n’existait et chaque entité gérait cela avec ses propres moyens.Un projet a été lancé pour uniformiser le mode de description et de gestion de ces unités, avec un double enjeu : Avoir un référentiel partagé pour l’ensemble des unités et s’appuyer sur ce socle pour mettre en place un certain nombre d’outils de gestion des opérations.Une méthode de description et un outil ont été développés et mis à disposition des utilisateurs. Toutefois, l’outil souffrait d’une ergonomie un peu rebutante et l’uniformisation sémantique réalisée nécessitait un accompagnement important des utilisateurs. Cette phase d’accompagnement, bien que largement encadrée, n’a pas permis de faire prendre conscience aux utilisateurs de l’aspect stratégique de la qualité de remplissage. Cela les a conduits à confier cette tâche de remplissage des données à des personnes ne disposant pas toujours du niveau de compréhension requis, voire à des personnes extérieures ne disposant d’aucunes compétences techniques liées au métier.La qualité des données saisies était donc assez mauvaise, sans que cela ne soit détecté par l’équipe d’accompagnement qui a focalisé son attention sur les indicateurs quantitatifs de remplissage. Toutefois, cela est apparu lors de la phase de mise en place des briques complémentaires, s’appuyant sur ces données. Un travail de reprise des données a donc été démarré dans les entités opérationnelles, à leur initiative. Une ressource a été mise à disposition, au niveau national, pour établir et suivre des indicateurs qualitatifs de ces données.

Causes et effets La cause identifiée:- Organisationnelle : Les équipes de terrain, utilisateurs finaux de l’application, ont été insuffisamment impliquées dans la phase de conception de la méthode et de l’outil, et ne disposait pas de la vision nécessaire sur les traitements qui seraient mis en place sur les données. Ils ne se sont donc pas appropriés le caractère stratégique de leur qualité. De plus, les équipes d’accompagnement ont déployé des indicateurs de suivi des entités opérationnelles principalement quantitatifs, ce qui n’a pas permis de détecter cette dérive.L’effet :- Organisationnel : Les entités opérationnelles, ayant pris conscience tardivement de la nécessaire reprise des données, elles ont détaché une ressource compétente pour assurer la reprise des données saisies. L’impact financier de cette reprise a été évalué à 1800 jours-homme.

Pistes de solutions Ce point a été traité en mode réactif car il n’est apparu que largement après le déploiement et identifié par la mise en œuvre d’autres outils. Le mode de traitement et de supervision du retraitement des données a résidé dans la mise à disposition d’une ressource au niveau national pour fédérer les différentes entités opérationnelles et les faire converger autour d’un référentiel sémantique commun. Pour cela, des indicateurs qualitatifs des données ont été mis en place avec un comité de suivi, impliquant les responsables du patrimoine « Unités de production ».

FCS - L’implication des utilisateurs réside essentiellement dans leur compréhension du projet et leur appropriation de l’intérêt de la démarche. Plus ceux-ci sont intégrés tôt dans la démarche, plus leur capacité de compréhension du sujet est forte.- De plus, il faut prêter une attention particulière à la proximité des maîtrises d’ouvrage déléguées avec les utilisateurs finaux, afin que ces derniers soient informés des démarches engagées et de leurs impacts.- Enfin, la phase de déploiement est essentielle, surtout dans le cas d’outils de



gestion de référentiels, car l’accompagnement des utilisateurs à ce stade permet aux utilisateurs d’assimiler le référentiel sémantique et à l’équipe d’accompagnement d’identifier les éventuels facteurs de risque.


C28 : MOA - Manque d’implication des utilisateurs du site pilote

Dysfonctionnement Les utilisateurs du site pilote ne remontent pas les informations – Contexte Groupe International

Argumentaire Période concernée : 2005.En 2004, Un Groupe hôtelier international décide de changer son progiciel de gestion hôtelière des hôtels Français. Le produit, développé dans les années 1980, est obsolète techniquement et ne permet plus d’évoluer rapidement. Après une rapide présentation à un panel d’hôteliers, il est décidé de choisir le progiciel déjà installé en Allemagne. Sans autre forme d’analyse des fonctionnalités et des besoins du métier, un site pilote français est installé en 2005. Durant les formations, les utilisateurs constatent des manques de rapports de contrôles internes, des fonctionnalités métiers manquantes, une comptabilité client non conforme à l’organisation des hôtels en France. Après la mise en production du progiciel dans l’hôtel, les manques et anomalies apparaissent plus flagrants. Cela provoque des erreurs dans les contrôles de gestion et perturbe l’organisation de l’hôtel. Cependant les chefs de services et les équipes ne s’impliquent pas entièrement dans le projet. Les informations qui remontent à l’équipe projet sont parcellaires, incomplètes, voire erronées. Afin mieux faire remonter les anomalies et les manques, il est créé un comité utilisateurs et un groupe de travail est activée avec le constructeur pour faire évoluer le progiciel.

Causes et effets La cause identifiée :- Humaine : les chefs de services de l’hôtel pilote n’étaient pas réellement motivés. Ils ne sont pas investis dans le pilote. Leurs remontées ne permettaient pas d’analyser précisément la situation.Les effets :- Humains : Démotivation des personnes concernées. - Organisationnels : Il a fallu plusieurs mois pour comprendre les vrais problèmes et permettre à l’équipe projet de réagir.

Pistes de solutions Afin de faire mieux faire remonter les anomalies et les manques, il est créé un comité utilisateurs et un groupe de travail est activée avec le constructeur pour faire évoluer le progiciel. Parallèlement, l’hôtel a été accompagné durant plusieurs mois par des experts utilisateurs détachés pour analyser les problèmes et adapter les procédures opérationnelles.

FCS - L’implication des utilisateurs dans le démarrage du site pilote est essentielle.- La communication en amont doit être la plus claire et la plus transparente sur les risques techniques et le besoin d’adaptation des équipes.- Il faut également déléguer auprès des utilisateurs des experts qui vont les aider à exprimer les besoins et constatations.- Il faut aussi expliquer au management du site pilote que ce projet va entraîner un surcroît de travail des collaborateurs.




C29 : Implication des utilisateurs

Dysfonctionnement Bascule de SI composé de 5 applications locales sur une plate-forme unique paneuropéenne

Argumentaire Dans le cadre de la bascule d’applications différentes dans une nouvelle plateforme paneuropéenne, une banque privée de gestion de fortune gérant des avoirs de sa clientèle internationale nomade souhaitait proposé un outil unique à ses différentes filiales afin que le client ait une connaissance globale de ses positions financières quelque soit le lieu ou la demande est émise.Dans le souhait de fournir une prestation de services équivalente sous un format semblable quel que soit le pays ou la demande de position des avoirs est émise, un groupe bancaire international décide de faire migrer toutes les différentes applications nationales de ses filiales sur une plateforme paneuropéenne.Les utilisateurs opérant en bout de process et conscients de l’importance de la réglementation imaginent que la Moa de la Direction Financière et la Moe ont respecté les règles réglementaires locales.Pas assez rompu à la culture de projet et plus attachés à voir évoluer leur modes de travail et l’organisation du travail en interne, les utilisateurs n’imaginent pas que la nouvelle plateforme soit moins performante réglementairement que la précédente.Ils laissent à la Direction générale locale et à la Direction financière le soin de se garder garant du respect réglementaire de leurs activités

Causes et effets Causes identifiées :- Organisationnelles : Les expressions de besoins n’ont pas été hiérarchisées collégialement. De fait l’arbitrage dans les expressions de besoins s’est fait de façon floue et arbitraire. La MOA a considéré qu’elle était très importante alors que la MOE l’a négligée. La décision du directeur de programme l’a emportée, ne laissant pas la possibilité d’argumenter de nouveau la portée de l’expression de besoin.- Humaines : Les fonctionnels des fonctions support sont plus isolés et perçus comme pouvant donner des limites à des transactions. De fait le rapport de force existant ne porte pas en leur faveur. Exprimer des spécificités locales par une MOA locale face à une Moe multiculturelle anglaise nombreuse et des donneurs d’ordre suisses n’est pas aisé. Exprimer ces spécificités locales dans un projet paneuropéen, alors même que l’objectif est d’homogénéiser les méthodes de travail et les outils ne va pas dans le sens favorable du rapport de force.Effet :Organisationnel : Des spécificités locales réglementaires n’ont pas été prises en compte, et les lots de tests nécessaires à la validation du plan de recette ont été réalisés dans un second lot, alors que leur importance était majeure.

Pistes de solutions - Correction via un second lot de tests, dont la qualité de réalisation donnait certification auprès de l’autorité réglementaire, a été réalisé au cours du projet et avant sa mise en production.- L’importance réglementaire doit ordonnancer les ordres de passage afin que l’ordre réalisé soit en corrélation avec les degrés d’importance des enjeux.

FCS - Les tests doivent être intégrés dans l’expression de besoin et l’ordonnancement doit permettre d’ajuster les importances des besoins avec l’urgence des tests et des modifications à apporter.



2.5. Soutien de la Direction Générale

C30 : Non soutien de la DG pour un projet dont elle n’était pas à l’origine

Dysfonctionnement Le projet non soutenu par la DG a failli être abandonné – Contexte PMEArgumentaire Période concernée : 1994

Au sein d’une PME éditrice de progiciels de gestion, le directeur des développements proposa d’inclure pour la prochaine mise à jour annuelle des progiciels un projet de rafraîchissement de l’interface visuelle. Celle-ci n’avait pas subi d’évolution depuis plusieurs années… La MOE souhaitait revoir l’interface visuelle des applications pour : - Introduire un effet visuel de fenêtrage avec visualisation d’une ombre portée. - S’aligner sur la concurrence dont les dernières évolutions de produit incluaient cette évolution visuelle.La Direction commerciale soutint le projet, la DG hésita et finit par laisser faire.Le projet, de petite envergure, fut assez rapidement bouclé sur un prototype, mais quelques difficultés techniques firent retarder son achèvement. La DG, qui n’était pas à l’origine de la demande, essaya d’enterrer le projet.Les questions qui se sont alors posées étaient :- Devait-on attendre l’achèvement du projet (légèrement en retard) pour pouvoir livrer la mise à jour annuelle ?- Devait-on livrer la mise à jour annuelle sans intégrer l’évolution de l’interface visuelle et repousser à un an cette amélioration ?Le projet, à deux doigts d’être abandonné, a finalement été achevé par un forcing de la MOE, puis livré. Le retour client a été immédiatement favorable et la DG a reconnu le bénéfice apporté par cette amélioration et a elle-même commandé son extension à toute la gamme.

Causes et effets Les causes identifiées:- Organisationnelle : Le projet n’a pas été considéré comme prioritaire par la DG, car il a été mal promu par la direction des développements.- Humaine/managériale : Problème de leadership sur le projet : la DG qui n’en était pas à l’origine n’était pas enclin à le soutenir.L’effet :- Managérial : la compréhension de l’importance de la promotion d’un projet a été renforcée.

Pistes de solutions Ce petit projet montre l’importance du temps qu’il faut accorder à sa promotion, ce n’est pas du temps perdu. Il aide à obtenir l’adhésion au projet du maximum de dirigeants et notamment celle de la DG.

FCS Pour maximiser les chances qu’un projet d’entreprise soit sélectionné, il convient - De vérifier si le projet est aligné avec la stratégie de l’entreprise, c’est beaucoup plus facile s’il l’est.- De monter un dossier et des actions de promotion du projet.- D’obtenir si possible le soutien de la Direction générale.



2.5. Soutien de la Direction Générale (suite)

C31 : Changement du cadre d’application de la solution développée

Dysfonctionnement Intranet. - PME (2001)Argumentaire Dans le contexte très porteur des technologies web, l’entreprise a souhaité mettre

en place un portail Intranet pour fédérer les différentes entités, réparties sur l’ensemble du territoire français. Après une étude détaillée des besoins utilisateur et des applications existantes pouvant être centralisées au travers de ce portail, une équipe projet a été constituée pour mettre en œuvre la solution.Compte tenu de l’impact important sur le poste de travail et l’aspect « fédérateur » du projet, une communication large avait été faite, créant chez les utilisateurs une attente forte vis-à-vis de cet outil.Lors de la phase de production, les utilisateurs ont été impliqués dans les choix effectués pour s’assurer de la pertinence des portages applicatifs de l’outil existant vers l’intranet. Une dynamique forte était en œuvre entre l’équipe projet, la MOA et les utilisateurs.Suite à la volonté du groupe actionnaire de l’entreprise de développer un esprit groupe, il a été demandé à la direction de favoriser les outils du groupe plutôt que les développements spécifiques. Ainsi, sur un grand nombre de points, le portage de l’outillage existant vers l’intranet a été abandonné au profit des outils en vigueur dans le reste du groupe. Toutefois, la direction de l’entreprise a souhaité continuer le développement du portail mais les arbitrages de la direction vidaient peu à peu la solution de sa substance. Le portail ressemblait de plus en plus à un simple site de communication interne, proche des fonctionnalités offertes par un site d’information institutionnel.Les groupes d’utilisateurs ont fait part de leur déception et se sont progressivement désengagés du projet, compte tenu de la position de la direction générale. Finalement, après avoir gardé le projet sous perfusion pendant 6 mois, celui-ci a été abandonné au profit de l’intranet du groupe.

Causes et effets La cause identifiée :- Managériale : La DG a eu à faire face à une modification de son environnement, mais a tardé à se positionner. Compte tenu de l’engagement fort qu’elle avait mis dans le développement de cet intranet, elle n’a pris la décision de stopper ce projet que quand cela était inéluctable.L’effet :- Organisationnel : L’équipe projet a été maintenue et a continué à faire évoluer le contenu du site intranet, avec l’accord tacite de la direction. Toutefois, l’outillage a été vidé de sa substance au fil des semaines. Les représentants des utilisateurs se désengageant progressivement, le projet a été arrêté et les développements réalisés n’ont jamais été utilisés.

Pistes de solutions Dans le cas présent, le chef de projet a laissé le temps œuvrer en faveur ou en défaveur du projet. Aucune action particulière n’a été menée. Il aurait été souhaitable d’établir, dès le changement de stratégie, les impacts potentiels en fonction des arbitrages effectués et de demander à la direction d’arbitrer clairement sur l’évolution du projet.

FCS L’implication de la Direction générale est essentielle sur les sujets stratégiques car ils sont généralement porteurs de modifications organisationnelles importantes. La Direction générale a un rôle moteur dans les projets transversaux qui participent à une dynamique d’entreprise. Dans ce cas, une des possibilités est



de désigner un sponsor, membre du comité de direction, qui participe au comité de pilotage.Dans le cas de modification des orientations stratégiques, la direction doit se positionner fermement sur la poursuite ou l’arrêt du projet. Dans les deux cas, il lui faudra fournir un argumentaire fort pour conduire les équipes à adhérer à la réorientation identifiée.

2.5. Soutien de la Direction Générale (suite)

C32 : MOA - Aucune implication et soutien de la DG

Ce cas est présenté dans le rapport au III.6



3. Management des projets e-collaboratifs

3.1. Charte des valeurs de l’équipe de projet

C33 : MOA – Absence de charte de fonctionnement aboutit à des incohérences

Dysfonctionnement Un référentiel de définition des devises et des cours a été redéfini pour rien – Contexte PME

Argumentaire Période concernée : 1997Une PME éditrice d’un nouveau PGI « eurocompatible » se lance dans une version 2.0 de son progiciel. La version 1 se limitait uniquement à la comptabilité générale, analytique et budgétaire. La version 2.0 du PGI introduisait les modules de la gestion commerciale : gestion des achats, ventes, stocks, commandes, bons de livraison, facturation, nomenclature et fabrication. Une nouvelle équipe « gestion commerciale » tant MOA que MOE prit en charge les études et les développements des modules de la gestion commerciale. L’équipe « comptabilité » préparerait l’introduction des modules états financiers : établissement des situations comptables, bilans, comptes de résultat et liasses fiscales.Les équipes se répartissaient fonctionnellement et géographiquement ainsi :

Equipe Comptabilité Gestion commerciale

MOA Localisée en France sur 2 sites : à l’Est et en île de France.

Localisée en France sur 1 site : île de France

MOE île de France Roumanie île de France Roumanie

Avec 2 sites MOA et 2 sites MOE pour la comptabilité, 1 site MOA et 2 sites MOE pour la gestion commerciale, les besoins en communication se faisaient sentir. Ils étaient assurés par des échanges de courriers électroniques, par téléphone et par un site FTP de synchronisation des codes source et documents d’analyses ainsi que par du présentiel en Roumanie.Le responsable MOA nouvellement recruté, n’avait pas de compétences particulières sur les progiciels de gestion et n’avait pas suivi le projet dans sa première version concernant des modules comptables. Mais il ne partait pas non plus d’une feuille blanche puisque lui étaient fournis comme pré requis, les documents d’analyse de la gestion commerciale précédente de l’entreprise.Les analyses des modules de la gestion commerciale commencèrent par la définition des référentiels : les clients, les fournisseurs, les articles, les classements d’articles (groupes, les familles, les sous-familles)…. Puis vint le tour des pièces : commandes, bons, factures… qui impliquaient la définition des devises (nom, nombre de décimales…) et de l’historique des cours en euro et en franc. L’équipe MOA définit donc les classes de gestion des devises, les relations avec l’historisation des cours…Bref tout cela était assez en phase avec les analyses de la gestion commerciale précédente. Une personne qui avait participé à la réalisation de l’ancienne gestion commerciale avait validé les analyses de référentiel.Lorsque le module fut mis en développement, l’un des développeurs qui avait travaillé sur la version 1 du PGI découvrit l’erreur qui avait été commise par la MOA : les gestions des devises et des cours avaient déjà été définies et développées pour la partie comptable du PGI !



Dans l’agitation et le souci d’avancement des 2 projets, personne n’avait pris le temps d’attirer l’attention du responsable MOA gestion sur les points qui devaient impérativement être traités différemment de l’ancienne gamme. Les gestions des devises et des cours faisaient partie des ces points.

Causes et effets La cause identifiée :- Organisationnelle : Aucun processus de validation des documents, précisant les circuits de relecture/validation croisée des analyses, n’avait été défini pour la MOA/MOE. Les 2 projets étaient perçus comme « concurrents » alors qu’ils avaient le même but. L’effet :- Organisationnel : Il a fallu revoir l’analyse faite pour intégrer les référentiels existants

Pistes de solutions A la suite de ce dysfonctionnement, le processus de validation des documents a été élaboré et accepté par toutes les équipes. Ce processus précisait notamment comment étaient déposés les documents d’analyse devant être relus et validés systématiquement par l’autre équipe MOA.

FCS Lorsque plusieurs équipes travaillent sur un même projet et davantage encore si plusieurs sites sont concernés, il est important de définir une charte des valeurs de l’équipe de projet qui précise :- Les valeurs partagées par les équipes : réalisation de l’objectif, qualité, entraide entre les personnes et les équipes…- Les méthodes et moyens de communications utilisés pour le projet.- Il est également nécessaire de définir les processus de production, d’analyse, de correction, de circulation, de modification, de validation et enfin de capitalisation des documents.

3.1. Charte des valeurs de l’équipe de projet (suite)

C34 : Faire collaborer des personnes de cultures différentes

Dysfonctionnement Outil de composition de gammes produit. - PME au contexte international (2001-2004)

Argumentaire Implantée dans de nombreux pays du monde, l’entreprise doit améliorer sa productivité et sa différenciation. Pour cela, elle a mis en œuvre un projet ambitieux de partage des compétences et des connaissances de chacune des filiales afin de mettre à disposition de l’ensemble des utilisateurs des composants élémentaires autonomes associables les uns aux autres pour construire une solution spécifique, tel un meccano.Pour mener ce projet à bien, il était nécessaire de définir la granulométrie des composants ainsi que les attributs caractérisant. Après cette phase de définition des contours de chaque composant, les ressources adéquates ont été identifiées (dans chacune des entités) et des contributeurs ont été identifiés pour composer une équipe de spécialistes capable de définir les entrées/sorties des éléments et de les décrire suffisamment précisément pour permettre leur modélisation. Ainsi, des équipes pluridisciplinaires ont été créées pour chacun des composants. Leur objectif commun était de mettre à disposition un ensemble de documents décrivant suffisamment ces derniers pour permettre leur intégration dans le système global.Assez rapidement, les échanges entre les différents collaborateurs ont mis en évidence deux points singuliers :



- Une certaine difficulté dans l’appropriation des modèles mis en œuvre.- Une incompréhension dans les modes d’arbitrageCeci a conduit à une sclérose du projet (chacun défendant ses choix), alors que l’objectif était de libérer la parole et de favoriser les échanges pour en tirer le meilleur de chacun.La direction, alertée sur ce dysfonctionnement, a alors alloué les moyens nécessaires à l’équipe projet pour mettre en place les synergies nécessaires. Dès lors, de nombreuses rencontres entre les collaborateurs ont été organisées pour aboutir à la mise en place d’un « plateau d’accueil » sur lequel évoluaient les responsables du projet, les ressources récurrentes et les ressources ponctuelles impliquées sur un thème spécifique.Bien que de nombreux ajustements aient été nécessaires, le projet a été finalisé. Les méthodes et les outils ont été déployés avec succès sur l’ensemble des filiales.

Causes et effets Les causes identifiées :- Organisationnelles / Humaines : La principale cause est la sous-estimation des différences culturelles entre les participants au projet et leur capacité à œuvrer à un but commun alors que leur niveau d’appropriation était très différent.Les effets :- Organisationnels et humains : Le démarrage du projet a été très difficile et la motivation commune s’est construite sur des éléments non mesurables tels que l’empathie et le partage de référentiels communs.

Pistes de solutions - L’élément déterminant dans la conduite de ce projet a été le regroupement en un lieu géographique, sur un temps suffisamment long, des ressources impliquées sur de projet. Dès lors, chacun des participants a pu appréhender les contraintes des autres et surtout exprimer son ressenti et le confronter à celui des autres participants.- Au-delà des relations professionnelles, des relations humaines se sont établies.

FCS - Le partage d’un certain nombre de valeurs est essentiel à la bonne marche d’un projet. Chacun doit se sentir libre d’agir en conscience et savoir que sa réaction sera comprise.- Il est indispensable que le but soit commun et la trajectoire soit partagée.- Si cela n’est pas le cas, il faut mettre en œuvre les moyens nécessaires à ce partage. La création d’espace physique d’échanges permet l’ajustement mutuel des comportements, clé essentielle à la poursuite du projet dans des conditions acceptables par tous.- La réussite d’un projet est collective et nécessite par conséquent la mise en œuvre des moyens nécessaires. De même, l’échec est collectif et est généralement la conséquence de cette incapacité de fédération.

3.1. Charte des valeurs de l’équipe de projet (suite)

C35 : Choc des cultures dans une structure associative

Ce cas est présenté dans le rapport au IV.2

3.2. Charte d’utilisation de l’espace e-collaboratif

C36 : L’absence d’une charte d’utilisation de l’espace e-collaboratif aboutit à une perte de corrections




3.3. Utilisation par l’équipe projet de l’espace e-collaboratif

C37 : MOE - mauvaise utilisation de l'espace collaboratif


3.4. Tableaux de bord

C38 : Intérêt de mettre en place un indicateur de production


3.5. Capitalisation des connaissances

C39 : Prendre conscience de l’intérêt de la phase de capitalisation d’un projet




Annexe 10 : RecommandationsEn s'appuyant sur l’analyse des dysfonctionnements rencontrés, l'équipe a construit une grille de recommandations. Cette grille doit aider le chef de projet à se poser les bonnes questions afin d’éviter les écueils les plus fréquents.

Démarche de projet Cas Questions Recommandations

Man

agem

ent s

truc

turé

de

proj

et

Expression des besoins

C01C02C03C04C05

La MOA a-t-elle la compétence suffisante pour formaliser le cahier des charges ?

A-t-on fait valider le cahier des charges par la DG et les utilisateurs ?

Le cahier des charges prend-il en compte les spécificités des pays, locales, des organisations, de la culture d’entreprise, des langues, etc… ?

Mise en place d’un comité de pilotage du projet.

Formaliser clairement les objectifs et périmètre du projet.

Disposer de méthodes de conception et de réalisation.

Utiliser des normes. Validation formelle de la DG

et des utilisateurs du cahier des charges

Intégrer les exigences qualités dès le début du projet.

Faire un suivi permanent, concrétisé par des points d'avancements réguliers.

Détermination de la DG à maintenir les coûts délais et périmètre fixés.

Découper le projet en unités gérables

Effectuer les bons choix (ni trop ancien, ni trop innovant) en matière de technologie

Affecter les ressources à plein temps sur le projet.

Découpage en phases et panorama des outils

C06C07C09

Existe-t-il une méthode de conduite de projet ?

Dispose-t-on de normes, procédures et d'outils permettant d'assurer un développement fonctionnellement satisfaisant et fiable ?

Phase de planification et gestion du temps

C11 Y a-t-il une définition claire des rôles et responsabilités respectifs MOA-MOE ?

Existe-t-il un planning du projet identifiant pour chacune des phases les tâches incombant à la MOE et à la MOA?

Phase de lancement

C13C12

La MOE dispose-t-elle de compétences et de ressources suffisantes dans les domaines suivants managériales, techniques et fonctionnelles ?

Est-ce que les objectifs et les missions sont compris par l'équipe projet ?

Phase de production

C16C17C14

Existe-t-il un dispositif de contrôles qualités (planning, production de l'équipe) ?

Existe-t-il une communication régulière entre MOA et MOE ?

Phase de pilotage

C18 Les membres du comité de pilotage sont-ils représentatifs de la DG et des directions opérationnelles concernées par le projet ?

Existe-t-il un planning général et détaillé du projet ?

Les outils utilisés pour suivre les délais et les coûts sont-ils adaptés ?



Démarche de projet Cas Questions Recommandations

Man

agem

ent d

es é

quip

es d

e pr

ojet

Gestion de ses priorités

C19 A-t-on hiérarchisé les besoins par ordres de priorités, d'importance et de valeurs ?

La MOA a-t-elle validé les choix de priorités, délais et budget ?

La MOE a-t-elle validé la faisabilité des attentes de la MOA

Fonctionner en mode projet, les principaux intervenants se consacrent à 100% au projet. (suppression des anciens liens strates hiérarchiques durant le projet).

S’assurer de la bonne répartition des rôles entre MOA et MOE. Expliciter les rôles de chacun et les valider.

Disposer d'une MOA ayant l'autorité nécessaire et soutenue par la DG. Elle doit valider les orientations métier et les délais proposés par la MOE.

Communiquer régulièrement pour obtenir l'adhésion des utilisateurs.

Les préconisations de la MOE doivent être pragmatiques et réalistes.

Disposer d'une équipe motivée et compétente, rigueur et méthode dans la gestion du projet.

Mettre en place une gestion du changement afin de minimiser au maximum les réticences.

Gestion des priorités collectives

C20 Dispose-t-on d'une équipe fortement impliquée ?

Les rôles de chacun sont ils clairement explicités ?

Management d'équipes de projet

C22 La MOE dispose-t-elle des compétences et ressources suffisantes dans les domaines managériales, techniques et fonctionnelles ?

Implication des utilisateurs

C26 La consultation et l'implication des utilisateurs a-t-elle été suffisante au cours des différentes phases du projet ?

Soutien de la DG

C30 Dispose-t-on d'un soutien fort de la DG ?

Man

agem

ent d

e pr

ojet

s e-c

olla

bora

tif

Charte des valeurs de l'équipe de projet

C33 Existe-t-il une charte des valeurs de l'équipe de projet ?

L’ensemble des acteurs impliqués dans le projet ont-ils connaissance de la charte ?

Y a-t-il eu suffisamment de temps consacrés aux actions de communications ?

Faire participer et rencontrer les utilisateurs pour prendre connaissances des cultures des équipes.

Définir la charte des valeurs de l’équipe projet et obtenir la meilleure adhésion possible au projet collaboratif.

Mettre en place des règles d’utilisation de l’espace collaboratif.

Communiquer pour obtenir l'adhésion des utilisateurs.

Définir des indicateurs de performance du projet.

Impliquer les acteurs concernés dans l’alimentation des données du tableau de bord.

Prendre en compte très tôt une méthode / procédure de capitalisation des connaissances.


C36 Existe-t-il une charte d'usage de l'espace collaboratif ?

L’ensemble des acteurs impliqués dans le projet ont-ils connaissance de la charte ?

Règles d’utilisation par équipe de projet de l'espace e-collaboratif

C37 Les équipes utilisatrices ont-elles été formées à l'utilisation des outils collaboratifs avant de lancer le projet?

Tableaux de bord

C38 Existe-t-il un tableau de bord du projet ?


C39 Dispose-t-on de procédures et d’outils permettant de capitaliser la connaissance ?

A-t-on mis en place une validation de la capitalisation des connaissances ?


Rapportjlf.axnet.free.fr/IMI/PPI V2.0.doc · Web view2.0 Titre du document Pathologies des Projets...

Documents

Transcript of Rapportjlf.axnet.free.fr/IMI/PPI V2.0.doc · Web view2.0 Titre du document Pathologies des Projets...