Td corrigé IMI - Free.fr pdf

IMI - Free.fr

Méthode d'analyse illustrée par SADT avec une décomposition fonctionnelle des ...... De même, si une anomalie est rapidement corrigée, cela ne signifie pas que ...... il suffit d'en voir pour preuve les différentes méthodes (COCOMO, COSMIC, ...




part of the document



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 fichierPPIN° Version2.0Titre du documentPathologies des Projets InformatiquesRé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ésManagement équipes de projet – Management projet e-collaboratif - Management structuré de projet – Pathologie projet informatique - Projet informatique.But du documentServir de référence voire de référentiel du sujet « brûlant » : Pathologies des Projets Informatiques.DiffusionJury 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 IMI38FDate de diffusion15 juin 2008Rédaction du documentGroupe IMI38FValidation du documentMélissa Saadoun et Jean Joskowicz Table des matières
 TOC \o "1-3" \h \z \u  HYPERLINK \l "_Toc201038616" Avant-propos  PAGEREF _Toc201038616 \h 7
 HYPERLINK \l "_Toc201038617" I – Pour une meilleure compréhension du sujet  PAGEREF _Toc201038617 \h 9
 HYPERLINK \l "_Toc201038618" I.1. Rappel du contexte  PAGEREF _Toc201038618 \h 9
 HYPERLINK \l "_Toc201038619" I.1.1. Contrôle commun IMI  PAGEREF _Toc201038619 \h 9
 HYPERLINK \l "_Toc201038620" I.1.2. Objectifs généraux du contrôle commun  PAGEREF _Toc201038620 \h 9
 HYPERLINK \l "_Toc201038621" I.1.3. Cerner les besoins et attentes de la MOA  PAGEREF _Toc201038621 \h 9
 HYPERLINK \l "_Toc201038622" I.2. Démarche et organisation du projet  PAGEREF _Toc201038622 \h 11
 HYPERLINK \l "_Toc201038623" I.2.1. Du cahier des charges provisoire au cahier des charges définitif  PAGEREF _Toc201038623 \h 11
 HYPERLINK \l "_Toc201038624" I.2.2. Démarche permettant d’atteindre l’objectif du projet  PAGEREF _Toc201038624 \h 12
 HYPERLINK \l "_Toc201038625" I.2.3. Planning du projet  PAGEREF _Toc201038625 \h 13
 HYPERLINK \l "_Toc201038626" I.2.4. Processus de validation du projet  PAGEREF _Toc201038626 \h 14
 HYPERLINK \l "_Toc201038627" I.2.5. Ressources du projet  PAGEREF _Toc201038627 \h 15
 HYPERLINK \l "_Toc201038628" I.2.6. Moyens de communication  PAGEREF _Toc201038628 \h 15
 HYPERLINK \l "_Toc201038629" I.3. Les fondamentaux du sujet  PAGEREF _Toc201038629 \h 17
 HYPERLINK \l "_Toc201038630" I.3.1. Un projet informatique et ses 3 dimensions  PAGEREF _Toc201038630 \h 17
 HYPERLINK \l "_Toc201038631" I.3.2. La notion de dysfonctionnement  PAGEREF _Toc201038631 \h 17
 HYPERLINK \l "_Toc201038632" I.3.3. Les facteurs clés de succès  PAGEREF _Toc201038632 \h 18
 HYPERLINK \l "_Toc201038633" I.3.4. Processus de capitalisation  PAGEREF _Toc201038633 \h 18
 HYPERLINK \l "_Toc201038634" II – Le Management Structuré de Projet  PAGEREF _Toc201038634 \h 19
 HYPERLINK \l "_Toc201038635" II.1. Rappel des 6 items du MSP  PAGEREF _Toc201038635 \h 19
 HYPERLINK \l "_Toc201038636" II.1.1. Expression des besoins  PAGEREF _Toc201038636 \h 19
 HYPERLINK \l "_Toc201038637" II.1.2. Découpage en phases et panorama des outils  PAGEREF _Toc201038637 \h 19
 HYPERLINK \l "_Toc201038638" II.1.3. Phase de planification et gestion du temps  PAGEREF _Toc201038638 \h 20
 HYPERLINK \l "_Toc201038639" II.1.4. Phase de lancement  PAGEREF _Toc201038639 \h 21
 HYPERLINK \l "_Toc201038640" II.1.5. Phase de production  PAGEREF _Toc201038640 \h 21
 HYPERLINK \l "_Toc201038641" II.1.6. Phase de pilotage  PAGEREF _Toc201038641 \h 21
 HYPERLINK \l "_Toc201038642" II.2. Expression de besoins  PAGEREF _Toc201038642 \h 23
 HYPERLINK \l "_Toc201038643" II.2.1. Constat des dysfonctionnements  PAGEREF _Toc201038643 \h 23
 HYPERLINK \l "_Toc201038644" II.2.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038644 \h 23
 HYPERLINK \l "_Toc201038645" II.2.3. Pistes de solutions de progrès  PAGEREF _Toc201038645 \h 23
 HYPERLINK \l "_Toc201038646" II.2.4. Facteurs clés de succès  PAGEREF _Toc201038646 \h 24
 HYPERLINK \l "_Toc201038647" II.3. Découpage en phases et panorama des outils  PAGEREF _Toc201038647 \h 25
 HYPERLINK \l "_Toc201038648" II.3.1. Constat des dysfonctionnements  PAGEREF _Toc201038648 \h 25
 HYPERLINK \l "_Toc201038649" II.3.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038649 \h 25
 HYPERLINK \l "_Toc201038650" II.3.3. Pistes de solutions de progrès  PAGEREF _Toc201038650 \h 26
 HYPERLINK \l "_Toc201038651" II.3.4. Facteurs clés de succès  PAGEREF _Toc201038651 \h 26
 HYPERLINK \l "_Toc201038652" II.4. Phase de planification et gestion du temps  PAGEREF _Toc201038652 \h 27
 HYPERLINK \l "_Toc201038653" II.4.1. Constat des dysfonctionnements  PAGEREF _Toc201038653 \h 27
 HYPERLINK \l "_Toc201038654" II.4.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038654 \h 27
 HYPERLINK \l "_Toc201038655" II.4.3. Pistes de solutions de progrès  PAGEREF _Toc201038655 \h 28
 HYPERLINK \l "_Toc201038656" II.4.4. Facteurs clés de succès  PAGEREF _Toc201038656 \h 28
 HYPERLINK \l "_Toc201038657" II.5. Phase de lancement  PAGEREF _Toc201038657 \h 29
 HYPERLINK \l "_Toc201038658" II.5.1. Constat des dysfonctionnements  PAGEREF _Toc201038658 \h 29
 HYPERLINK \l "_Toc201038659" II.5.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038659 \h 29
 HYPERLINK \l "_Toc201038660" II.5.3. Pistes de solutions de progrès  PAGEREF _Toc201038660 \h 30
 HYPERLINK \l "_Toc201038661" II.5.4. Facteurs clés de succès  PAGEREF _Toc201038661 \h 30
 HYPERLINK \l "_Toc201038662" II.6. Phase de production  PAGEREF _Toc201038662 \h 31
 HYPERLINK \l "_Toc201038663" II.6.1. Constat des dysfonctionnements  PAGEREF _Toc201038663 \h 31
 HYPERLINK \l "_Toc201038664" II.6.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038664 \h 31
 HYPERLINK \l "_Toc201038665" II.6.3. Pistes de solutions de progrès  PAGEREF _Toc201038665 \h 32
 HYPERLINK \l "_Toc201038666" II.6.4. Facteurs clés de succès  PAGEREF _Toc201038666 \h 32
 HYPERLINK \l "_Toc201038667" II.7. Phase de pilotage  PAGEREF _Toc201038667 \h 33
 HYPERLINK \l "_Toc201038668" II.7.1. Constat des dysfonctionnements  PAGEREF _Toc201038668 \h 33
 HYPERLINK \l "_Toc201038669" II.7.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038669 \h 33
 HYPERLINK \l "_Toc201038670" II.7.3. Pistes de solutions de progrès  PAGEREF _Toc201038670 \h 33
 HYPERLINK \l "_Toc201038671" II.7.4. Facteurs clés de succès  PAGEREF _Toc201038671 \h 34
 HYPERLINK \l "_Toc201038672" II.8. Capitalisation des connaissances du MSP  PAGEREF _Toc201038672 \h 35
 HYPERLINK \l "_Toc201038673" III – Management des Equipes de Projet  PAGEREF _Toc201038673 \h 38
 HYPERLINK \l "_Toc201038674" III.1. Rappel des 5 items du mini-projet MEP  PAGEREF _Toc201038674 \h 38
 HYPERLINK \l "_Toc201038675" III.1.1. Gestion de ses priorités  PAGEREF _Toc201038675 \h 39
 HYPERLINK \l "_Toc201038676" III.1.2. Gestion des priorités collectives  PAGEREF _Toc201038676 \h 39
 HYPERLINK \l "_Toc201038677" III.1.3. Management d’équipes de projet  PAGEREF _Toc201038677 \h 40
 HYPERLINK \l "_Toc201038678" III.1.4. Implication des utilisateurs  PAGEREF _Toc201038678 \h 41
 HYPERLINK \l "_Toc201038679" III.1.5.Soutien de la DG  PAGEREF _Toc201038679 \h 42
 HYPERLINK \l "_Toc201038680" III.2. Gestion de ses priorités  PAGEREF _Toc201038680 \h 43
 HYPERLINK \l "_Toc201038681" III.2.1. Constat des dysfonctionnements  PAGEREF _Toc201038681 \h 43
 HYPERLINK \l "_Toc201038682" III.2.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038682 \h 43
 HYPERLINK \l "_Toc201038683" III.2.3. Pistes de solutions de progrès  PAGEREF _Toc201038683 \h 44
 HYPERLINK \l "_Toc201038684" III.2.4. Facteurs clés de succès  PAGEREF _Toc201038684 \h 44
 HYPERLINK \l "_Toc201038685" III.3. Gestion des priorités collectives  PAGEREF _Toc201038685 \h 45
 HYPERLINK \l "_Toc201038686" III.3.1. Constat des dysfonctionnements  PAGEREF _Toc201038686 \h 45
 HYPERLINK \l "_Toc201038687" III.3.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038687 \h 45
 HYPERLINK \l "_Toc201038688" III.3.3. Pistes de solutions de progrès  PAGEREF _Toc201038688 \h 46
 HYPERLINK \l "_Toc201038689" III.3.4. Facteurs clés de succès  PAGEREF _Toc201038689 \h 46
 HYPERLINK \l "_Toc201038690" III.4. Management d’équipes de projet  PAGEREF _Toc201038690 \h 47
 HYPERLINK \l "_Toc201038691" III.4.1. Constat des dysfonctionnements  PAGEREF _Toc201038691 \h 47
 HYPERLINK \l "_Toc201038692" III.4.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038692 \h 47
 HYPERLINK \l "_Toc201038693" III.4.3. Pistes de solutions de progrès  PAGEREF _Toc201038693 \h 48
 HYPERLINK \l "_Toc201038694" III.4.4. Facteurs clés de succès  PAGEREF _Toc201038694 \h 48
 HYPERLINK \l "_Toc201038695" III.5. Implication des utilisateurs  PAGEREF _Toc201038695 \h 49
 HYPERLINK \l "_Toc201038696" III.5.1. Constat des dysfonctionnements  PAGEREF _Toc201038696 \h 49
 HYPERLINK \l "_Toc201038697" III.5.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038697 \h 49
 HYPERLINK \l "_Toc201038698" III.5.3. Pistes de solutions de progrès  PAGEREF _Toc201038698 \h 50
 HYPERLINK \l "_Toc201038699" III.5.4. Facteurs clés de succès  PAGEREF _Toc201038699 \h 50
 HYPERLINK \l "_Toc201038700" III.6. Soutien de la DG  PAGEREF _Toc201038700 \h 51
 HYPERLINK \l "_Toc201038701" III.6.1. Constat des dysfonctionnements  PAGEREF _Toc201038701 \h 51
 HYPERLINK \l "_Toc201038702" III.6.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038702 \h 51
 HYPERLINK \l "_Toc201038703" III.6.3. Pistes de solutions de progrès  PAGEREF _Toc201038703 \h 51
 HYPERLINK \l "_Toc201038704" III.6.4. Facteurs clés de succès  PAGEREF _Toc201038704 \h 52
 HYPERLINK \l "_Toc201038705" III.7. Capitalisation des connaissances du MEP  PAGEREF _Toc201038705 \h 53
 HYPERLINK \l "_Toc201038706" IV – Management de Projets e-Collaboratifs  PAGEREF _Toc201038706 \h 55
 HYPERLINK \l "_Toc201038707" IV.1. Rappel des 5 items du MPeC  PAGEREF _Toc201038707 \h 55
 HYPERLINK \l "_Toc201038708" IV.1.1. Charte des valeurs de l’équipe de projet  PAGEREF _Toc201038708 \h 55
 HYPERLINK \l "_Toc201038709" IV.1.2. Règles d’utilisation de l’espace e-collaboratif  PAGEREF _Toc201038709 \h 56
 HYPERLINK \l "_Toc201038710" IV.1.3. Règles d’utilisation par équipe de projet de l’espace e-collaboratif  PAGEREF _Toc201038710 \h 64
 HYPERLINK \l "_Toc201038711" IV.1.4. Tableaux de bord  PAGEREF _Toc201038711 \h 65
 HYPERLINK \l "_Toc201038712" IV.1.5. Capitalisation des connaissances  PAGEREF _Toc201038712 \h 66
 HYPERLINK \l "_Toc201038713" IV.2. Charte des valeurs de l’équipe de projet  PAGEREF _Toc201038713 \h 67
 HYPERLINK \l "_Toc201038714" IV.2.1. Constat des dysfonctionnements  PAGEREF _Toc201038714 \h 67
 HYPERLINK \l "_Toc201038715" IV.2.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038715 \h 67
 HYPERLINK \l "_Toc201038716" IV.2.3. Pistes de solutions de progrès  PAGEREF _Toc201038716 \h 68
 HYPERLINK \l "_Toc201038717" IV.2.4. Facteurs clés de succès  PAGEREF _Toc201038717 \h 68
 HYPERLINK \l "_Toc201038718" IV.3. Règles d’utilisation de l’espace e-collaboratif  PAGEREF _Toc201038718 \h 69
 HYPERLINK \l "_Toc201038719" IV.3.1. Constat des dysfonctionnements  PAGEREF _Toc201038719 \h 69
 HYPERLINK \l "_Toc201038720" IV.3.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038720 \h 69
 HYPERLINK \l "_Toc201038721" IV.3.3. Pistes de solutions de progrès  PAGEREF _Toc201038721 \h 70
 HYPERLINK \l "_Toc201038722" IV.3.4. Facteurs clés de succès  PAGEREF _Toc201038722 \h 70
 HYPERLINK \l "_Toc201038723" IV.4. Règles d’utilisation par l’équipe de projet de l’espace e-collaboratif  PAGEREF _Toc201038723 \h 71
 HYPERLINK \l "_Toc201038724" IV.4.1. Constat des dysfonctionnements  PAGEREF _Toc201038724 \h 71
 HYPERLINK \l "_Toc201038725" IV.4.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038725 \h 71
 HYPERLINK \l "_Toc201038726" IV.4.3. Pistes de solutions de progrès  PAGEREF _Toc201038726 \h 72
 HYPERLINK \l "_Toc201038727" IV.4.4. Facteurs clés de succès  PAGEREF _Toc201038727 \h 72
 HYPERLINK \l "_Toc201038728" IV.5. Tableaux de bord  PAGEREF _Toc201038728 \h 73
 HYPERLINK \l "_Toc201038729" IV.5.1. Constat des dysfonctionnements  PAGEREF _Toc201038729 \h 73
 HYPERLINK \l "_Toc201038730" IV.5.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038730 \h 73
 HYPERLINK \l "_Toc201038731" IV.5.3. Pistes de solutions de progrès  PAGEREF _Toc201038731 \h 74
 HYPERLINK \l "_Toc201038732" IV.5.4. Facteurs clés de succès  PAGEREF _Toc201038732 \h 74
 HYPERLINK \l "_Toc201038733" IV.6. Capitalisation des connaissances  PAGEREF _Toc201038733 \h 75
 HYPERLINK \l "_Toc201038734" IV.6.1. Constat des dysfonctionnements  PAGEREF _Toc201038734 \h 75
 HYPERLINK \l "_Toc201038735" IV.6.2. Argumentaire expliquant ces dysfonctionnements  PAGEREF _Toc201038735 \h 75
 HYPERLINK \l "_Toc201038736" IV.6.3. Pistes de solutions de progrès  PAGEREF _Toc201038736 \h 76
 HYPERLINK \l "_Toc201038737" IV.6.4. Facteurs clés de succès  PAGEREF _Toc201038737 \h 76
 HYPERLINK \l "_Toc201038738" IV.7. Capitalisation des connaissances du MPeC  PAGEREF _Toc201038738 \h 77
 HYPERLINK \l "_Toc201038739" Conclusion  PAGEREF _Toc201038739 \h 80
 HYPERLINK \l "_Toc201038740" Bibliographie  PAGEREF _Toc201038740 \h 82
 HYPERLINK \l "_Toc201038741" Articles  PAGEREF _Toc201038741 \h 82
 HYPERLINK \l "_Toc201038742" Ouvrages  PAGEREF _Toc201038742 \h 82
 HYPERLINK \l "_Toc201038743" Support de cours  PAGEREF _Toc201038743 \h 82
 HYPERLINK \l "_Toc201038744" Pages Web visitées  PAGEREF _Toc201038744 \h 82
 HYPERLINK \l "_Toc201038745" Annexes  PAGEREF _Toc201038745 \h 84
 HYPERLINK \l "_Toc201038746" Annexe 1 : CdC provisoire du 18 mars  PAGEREF _Toc201038746 \h 85
 HYPERLINK \l "_Toc201038747" Annexe 2 : CdC définitif du 31 mars  PAGEREF _Toc201038747 \h 88
 HYPERLINK \l "_Toc201038748" Annexe 3 : Plannings du projet  PAGEREF _Toc201038748 \h 98
 HYPERLINK \l "_Toc201038749" Annexe 4 : Interviews de spécialistes du thème  PAGEREF _Toc201038749 \h 100
 HYPERLINK \l "_Toc201038750" Annexe 5 : CR des revues de projet  PAGEREF _Toc201038750 \h 105
 HYPERLINK \l "_Toc201038751" Annexe 6 : Fiches mission  PAGEREF _Toc201038751 \h 110
 HYPERLINK \l "_Toc201038752" Annexe 7 : Norme et modèle pour projets informatiques  PAGEREF _Toc201038752 \h 113
 HYPERLINK \l "_Toc201038753" Annexe 8 : Questionnaire utilisé pour identifier les dysfonctionnements  PAGEREF _Toc201038753 \h 115
 HYPERLINK \l "_Toc201038754" Annexe 9 : Dysfonctionnements  PAGEREF _Toc201038754 \h 122
 HYPERLINK \l "_Toc201038755" Annexe 10 : Recommandations  PAGEREF _Toc201038755 \h 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 :
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).
Un jeu de diapositives (PowerPoint) de la soutenance du 27 juin.
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 :
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.
Mini projet 1 (sous-groupe 1 sous la responsabilité de Laurent Carette) : 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.
Mini-projet 2 (sous-groupe 2 sous la responsabilité de Fattah Abdessadak) : Management de projets e-collaboratifs :
Charte des valeurs de l’équipe de 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.
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 MSP
Dans 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
II.3.1. Constat des dysfonctionnements
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.
II.3.2. Argumentaire expliquant ces dysfonctionnements
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.
II.3.3. Pistes de solutions de progrès
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.
II.3.4. Facteurs clés de succès
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
II.4.1. Constat des dysfonctionnements
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.
II.4.2. Argumentaire expliquant ces dysfonctionnements
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.
La cause identifiée :
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.
II.4.3. Pistes de solutions de progrès
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.
II.4.4. Facteurs clés de succès
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
II.5.1. Constat des dysfonctionnements
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.
II.5.2. Argumentaire expliquant ces dysfonctionnements
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.
II.5.3. Pistes de solutions de progrès
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.
II.5.4. Facteurs clés de succès
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
II.6.1. Constat des dysfonctionnements
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.
II.6.2. Argumentaire expliquant ces dysfonctionnements
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 ?
La cause identifiée :
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.
II.6.3. Pistes de solutions de progrès
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.
II.6.4. Facteurs clés de succès
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
II.7.1. Constat des dysfonctionnements
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.
II.7.2. Argumentaire expliquant ces dysfonctionnements
Période concernée : 2005.
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.
La cause identifiée :
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.
II.7.3. Pistes de solutions de progrè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.
II.7.4. Facteurs clés de succès
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 MSP
A 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.
 EMBED PowerPoint.Slide.8 
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 MEP
Dans 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
III.3.1. Constat des dysfonctionnements
C20 : Carence de ressources MOE
Contexte : Notes de calcul informatisées dans une PME – 1000 jours-homme.
III.3.2. Argumentaire expliquant ces dysfonctionnements
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.
III.3.3. Pistes de solutions de progrès
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.
III.3.4. Facteurs clés de succès
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
III.4.1. Constat des dysfonctionnements
C21 : Piloter le changement : Basculement de 2 personnes sur un nouveau projet.
Contexte : développement d’un progiciel dans une PME
Période : 1999.
III.4.2. Argumentaire expliquant ces dysfonctionnements
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.
La cause identifiée :
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.
III.4.3. Pistes de solutions de progrès
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.
III.4.4. Facteurs clés de succès
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
III.5.1. Constat des dysfonctionnements
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.
III.5.2. Argumentaire expliquant ces dysfonctionnements
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.
III.5.3. Pistes de solutions de progrès
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.
III.5.4. Facteurs clés de succès
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
III.6.1. Constat des dysfonctionnements
C32 : MOA : Aucune implication et soutien de la DG
Contexte : Développement d’un progiciel de gestion hôtelière, dans un Groupe international.
Période concernée : 1995.
III.6.2. Argumentaire expliquant ces dysfonctionnements
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é.
La cause identifiée :
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.
III.6.3. Pistes de solutions de progrès
Aucune : le projet a été abandonné.
III.6.4. Facteurs clés de succès
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 MEP
L’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 MPeC
Ce 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.
 EMBED PowerPoint.Slide.8 
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 asynchroneApplications utiliséesCommentairesEchange principalement de textes d’une personne vers une ou plusieurs personnesCourrier électroniqueL’application la plus utiliséeEnvoyer ou recevoir des fichiers et documentsBibliothèque électroniqueApplication très utiliséeInterface où est déposée des massages et/ou des documents à l’attention d’autres personnes ou équipe de projetForum de discussionApplication peu utiliséeRépertoire des utilisateurs permettant d’éditer des informationsGestion des contacts ou agenda électroniqueCarnet d’adresses partagé, agendaType synchroneApplications utiliséesCommentairesDiscussion en temps réel impliquant 2 ou plusieurs personnesDiscussion en ligneCommunément appelé « Chat »Zone partagée d’écran où chaque utilisateur peut dessiner, afficher, écrire du texte, être vu.Tableau partagéUtilisé en conception collaborativeUtilisation du multimédia pour accroître, améliorer la présence humaine dans les rencontres virtuellesVidéoconférenceRencontre 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.
 EMBED PowerPoint.Slide.8 
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.
 EMBED PowerPoint.Slide.8 
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.
Les causes identifiées :
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
IV.3.1. Constat des dysfonctionnements
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
IV.3.2. Argumentaire expliquant ces dysfonctionnements
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 \ 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 au lieu de . 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.
Les causes identifiées :
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.
IV.3.3. Pistes de solutions de progrès
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.
IV.3.4. Facteurs clés de succès
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
IV.4.1. Constat des dysfonctionnements
C37 : MOE : mauvaise utilisation de l'espace collaboratif.
Contexte : La non complétude fonctionnelle d’un espace e-collaboratif conduit à mauvais usage - IMI
IV.4.2. Argumentaire expliquant ces dysfonctionnements
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.
Les causes identifiées :
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.
IV.4.3. Pistes de solutions de progrès
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.
IV.4.4. Facteurs clés de succès
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
IV.5.1. Constat des dysfonctionnements
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
IV.5.2. Argumentaire expliquant ces dysfonctionnements
Période concernée : 1998
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 !
Les causes identifiées :
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.
IV.5.3. Pistes de solutions de progrès
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.
IV.5.4. Facteurs clés de succès
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
IV.6.1. Constat des dysfonctionnements
C39 : Prendre conscience de l’intérêt de la phase de capitalisation d’un projet.
Contexte : Mauvaise capitalisation des connaissances dans un TPE
IV.6.2. Argumentaire expliquant ces dysfonctionnements
Période concernée : 2004
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.
Les causes identifiées :
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.
IV.6.3. Pistes de solutions de progrès
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 ?
IV.6.4. Facteurs clés de succès
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 MPeC
Les 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 » :
 HYPERLINK "http://www.clubmoa.asso.fr/article.php?sid=54" http://www.clubmoa.asso.fr/article.php?sid=54
 HYPERLINK "http://www.informatique.weka.fr/affichage/dispMain.asp?ngcmid=WK4200801" http://www.informatique.weka.fr/affichage/dispMain.asp?ngcmid=WK4200801
 HYPERLINK "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" 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 » :
 HYPERLINK "http://www.clubmoa.asso.fr/article.php?sid=166" http://www.clubmoa.asso.fr/article.php?sid=166
 HYPERLINK "http://www.sante-psychologie.com/emotions/" http://www.sante-psychologie.com/emotions/
 HYPERLINK "http://www.com-unique.org/out_espr.htm" http://www.com-unique.org/out_espr.htm
 HYPERLINK "http://www.verselejus.com/La-gestion-des-emotions.html" http://www.verselejus.com/La-gestion-des-emotions.html
 HYPERLINK "http://www.phosphenisme.com/z_emotions.html" http://www.phosphenisme.com/z_emotions.html
 HYPERLINK "http://www.nutrition-valley.com/modules-nutrition-valley/gestion-emotions.php" http://www.nutrition-valley.com/modules-nutrition-valley/gestion-emotions.php
 HYPERLINK "http://www.ssd.u-bordeaux2.fr/faf/archives/numero_8/articles/meidani.htm" http://www.ssd.u-bordeaux2.fr/faf/archives/numero_8/articles/meidani.htm
 HYPERLINK "http://www.lentreprise.com/3/2/2/article/15139.html" http://www.lentreprise.com/3/2/2/article/15139.html
 HYPERLINK "http://www.psychologue.levillage.org/aphasie.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 :  HYPERLINK "http://www.sei.cmu.edu/" http://www.sei.cmu.edu/
 HYPERLINK "http://fr.wikipedia.org/wiki/Capability_Maturity_Model_Integration" http://fr.wikipedia.org/wiki/Capability_Maturity_Model_Integration
 HYPERLINK "http://www.fimarkets.com/pages/cmmi.htm" http://www.fimarkets.com/pages/cmmi.htm
 HYPERLINK "http://www.xdocs400.com/spip.php?article3" http://www.xdocs400.com/spip.php?article3
 HYPERLINK "http://fr.wikipedia.org/wiki/Prince2" http://fr.wikipedia.org/wiki/Prince2
 HYPERLINK "http://www.univ-angers.fr/docs/etudquassi/MP08_12.pdf" http://www.univ-angers.fr/docs/etudquassi/MP08_12.pdf
 HYPERLINK "http://www.pmi.org" http://www.pmi.org
 HYPERLINK "http://www.iso.org/iso/fr/iso_catalogue/management_standards/iso_9000_iso_14000/iso_9000_essentials.htm" http://www.iso.org/iso/fr/iso_catalogue/management_standards/iso_9000_iso_14000/iso_9000_essentials.htm


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 mars
Cahier 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 :
Responsabiliser et aider l’auditeur à s’approprier la connaissance du management.
Le rendre plus autonome dans son rapport à la connaissance tout en faisant l’expérience de la solidarité en équipe.
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 :
Pour chaque item ci-dessus (sous Word) :
Constat des dysfonctionnements dans votre entreprise
Argumentaire expliquant ces dysfonctionnements
Pistes de solutions de progrès
Facteurs clés de succès (FCS).
Copie du support PowerPoint de la présentation au jury.
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 mars
Aprè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édacteursVérificateur(s)ApprobateursNomVisaNomVisaNomVisaFattah AbdessadakFALaurent CaretteLCMélissa SaadounMSPierre-Yves ArradesPYAJean-Luc FiquetJLFJean JoskowiczJJLaurent CaretteLCNapoléon DjenNDYvan ErardYEJean-Luc FiquetJLFI.2. Gestion des versions du RBA
N°versionDateAuteurActionNom fichier2.030/03/2008IMI38FValidation MS+JJRBA-CDC_v2.03.doc3.031/03/2008IMI38FValidation ClientRBA-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-CDCCréé le 30/03/2008Version : n° 2.0X Document validé par l'équipe pédagogique, le 30 mars 2008 version 2.00
X Document validé par le chef de projet le 31 mars 2008 version 2.03
X 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)
NomFonctionE-mailGérard BALANTZIAN (GB)Directeur IMI HYPERLINK "mailto:gbalantzian@club-internet.fr" gbalantzian@club-internet.frII.2. Equipe de projets (MOE)
NomMini-projet, rôle E-mailNapoléon DJEN (ND)MP1,  HYPERLINK "mailto:napoleon.djen@gmail.com" napoleon.djen@gmail.comLaurent CARETTE (LC)MP1, Pilote MP1laurent.carette@lyonnaise-des-eaux.frYvan ERARD (YE)MP1, Rapporteur HYPERLINK "mailto:yverard@gmail.com" yverard@gmail.comFattah ABDESSADAK (FA)MP2, Pilote MP2 HYPERLINK "mailto:fabdessadak@sgdf.fr" fabdessadak@sgdf.frJean-Luc FIQUET (JLF)MP2, Chef de projet HYPERLINK "mailto:jlfiquet@ax-net.fr" jlfiquet@ax-net.frPierre-Yves ARRADES (PYA)MP2, Rapporteur MP2 HYPERLINK "mailto:pierre-yves.arades@accor.com" pierre-yves.arades@accor.comII.3. Equipe pédagogique
NomRôleE-mailMélissa SAADOUN (MS)Intervenant IMI HYPERLINK "mailto:msaadoun@gmail.com" msaadoun@gmail.comJean JOSKOWICZ (JJ)Intervenant IMI HYPERLINK "mailto:jjoskowicz@tele2.fr" jjoskowicz@tele2.frII.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 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 :  HYPERLINK "mailto:gbalantzian@club-internet.fr" gbalantzian@club-internet.fr
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 :  HYPERLINK "mailto:jlfiquet@ax-net.fr" jlfiquet@ax-net.fr 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 ProjetNotationCompréhension de l’objectif du sujet
Pertinence de la réalisation par rapport au sujet
Qualité de rédaction et de présentation
Qualité du contenu
Qualité de restitution (présentation orale)
Qualité globale du mini-projetSous-total/30Mini-projet Management des Equipes de ProjetCompréhension de l’objectif du sujet
Pertinence de la réalisation par rapport au sujet
Qualité de rédaction et de présentation
Qualité du contenu
Qualité de restitution (présentation orale)
Qualité globale du mini-projetSous-total/30Mini-projet Management des Projets e-CollaboratifsCompréhension de l’objectif du sujet
Pertinence de la réalisation par rapport au sujet
Qualité de rédaction et de présentation
Qualité du contenu
Qualité de restitution (présentation orale)
Qualité globale du mini-projetSous-total/30TOTAL/90Vécu du groupe et étude des conditions à réunir pour bien « Vivre «ensemble » un projetCondition 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 :
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.
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
QuoiQui Débute lePour leFait leSoutenance RP1TOUS 14 avril 12h3014 avril 13h45Compte rendu RP1 à MS+JJJLF 15 avril15 avrilRéunion IMI38F - Pose déjeunéTOUS 15 avril midi15 avril midiCompte rendu interview F. Odier JLF15 avril16 avril soir16 avril soirRéunion IMI38F - Points/Actions TOUS16 avril 14h16 avril 16h16 avril 16hActivités/Planning provisoireJLF 16 avril soir16 avril soirCompte rendu interview J. PrintzPYA17 avril soir17 avril soir18 avrilRemontée des grilles de dysfonctionnementsTOUS18 avril soir18 avril soir Etude d'un cas de dysfonctionnement exempleLC18 avril soir18 avril soir Echanges collaboratifs sur le cas TOUS19 avril22 avril Etude des documents fournis par MSTOUS19 avril22 avril Constitution projet/planning sous (MS Project)JLF19 avril20 avril Capitalisation RP1JLF19 avril20 avril Réunion 1ère analyse grille des dysfonctionnementsTOUS 22 avril 17h30 Réflexion sur l'élaboration d'une grille diagnostic    Elaboration du plan général du rapport    Préparation PowerPoint RP2YE 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 (francis.odier@orange.fr), 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 (( HYPERLINK "http://www.clubmoa.asso.fr/article.php?sid=166" http://www.clubmoa.asso.fr/article.php?sid=166).
Jacques Printz (printz@cnam.fr), 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 projet
Quelques 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):
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.
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
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
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.
Annexe 5.2. CR de la RP2
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

DysfonctionnementActionSuiviFCS SHAPE \* MERGEFORMAT 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
Annexe 5.3. CR de la RP3
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 :
HeuresCharges PrévuesCharges réaliséesEcartsRédaction Rapport 405950%Rédaction Annexes 162450%Rédaction dysfonctionnement 519382%Road book 181233%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 mission
Les 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ébutDates de finPrévuesRéellesPrévuesRéellesPrévuesRéellesRédiger Chapitre 16 1213/0525/05 18/05 03/06Formaliser 2 dysfonctionnements3418/0501/06 20/0503/06Mettre en forme Partie MEP : à partir des PI sélectionnés mettre en forme cette partie du document.22 26/0526/05 28/05 01/06Prise en compte des retours – MEP – Intégrer et mettre en forme les retours sur partie MEP2 228/0528/05 03/0603/06Rédiger « Normes de développement des projets informatiques »:4 401/06 01/0603/06 08/06Relecture Rapport et Annexes3 305/0608/0608/0608/06Rédiger Road book personnel3 613/0513/05 15/06 Préparer Présentation5 06/0509/06 06/05 21/06TOTAL3033    Fiche mission de Yvan
TâchesCharges (h)Dates de débutDates de finPrévuesRéellesPrévuesRéellesPrévuesRéellesRédiger III.1. du rapport61513/05 18/05 Formaliser 4 dysfonctionnements5618/05 03/0628/05 03/06Rédiger « Gestion des conflits »7826/05 26/0503/06 08/06Relecture Rapport et Annexes4405/0606/0608/0608/06Rédiger Road book personnel3113/0513/0515/06 Préparer RP33328/0501/0605/0605/06Relecture Rapport et Annexes3305/0607/0608/0608/06Préparer Présentation505/0615/06TOTAL3140    
Fiche mission de Fattah
TâchesCharges (h)Dates de débutDates de finPrévuesRéellesPrévuesRéellesPrévuesRéellesRédiger IV.1. du rapport61113/0524/0518/05 03/06Formaliser 3 dysfonctionnements51218/0519/0520/05 03/06Mettre en forme partie IV-MPE : Mettre en forme la partie Management des projets e-collaboratif à partir des cas sélectionnés2226/0502/0628/05 03/06Prise en compte des retours – MPE – Intégrer et mettre en forme les retours sur partie IV-MEP2128/0503/0603/0603/06Responsable partie II - MSP3228/0501/0603/06 03/06Rédiger annexe « Recommandations »6901/0602/0606/0608/06Relecture Rapport et Annexes3605/0607/0608/0608/06Rédiger Road book personnel3213/0527/05 03/0615/06 Préparer Présentation505/0615/06TOTAL3545   Fiche mission de Pierre-Yves
TâchesCharges (h)Dates de débutDates de finPrévuesRéellesPrévuesRéellesPrévuesRéellesRédiger II.1.du rapport6 913/05 15/0518/05 01/06Formaliser 9 dysfonctionnements11 1418/0522/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és22 26/05 01/0628/05 03/06Prise en compte des retours – MSP – Intégrer et mettre en forme les retours sur partie IV-MS2 225/05 01/0603/06 03/06Responsable Partie – IV - MPE 3 0 28/05 03/06 Rédiger Road book personnel3 213/05 26/0515/06 Constituer Annexes sauf An.73 330/05 02/0603/06 04/06Préparer RP33 428/05 28/050506 04/06Relecture Rapport et Annexes3  305/06 05/0608/0607/06Préparer Présentation5 105/06 02/0615/06 TOTAL35 38    Fiche mission de Laurent
TâchesCharges (h)Dates de débutDates de finPrévuesRéellesPrévuesRéellesPrévuesRéellesFormaliser 8 dysfonctionnements 112513/0513/0520/0529/05Sélectionner cas MSP2121/0530/0528/0530/05Capitalisation connaissance MSP3328/0501/0603/0603/06Sélectionner cas MEP2126/0530/0528/0530/05Capitalisation connaissance MEP3428/0501/0603/0602/06Responsable Partie – III – MEP3428/0528/0503/0603/06 Responsable Annexe gestion des émotions3128/0528/0503/0603/06Manager projet MEP – Chef de projet du mini projet MEP3313/0513/0503/0603/06 Relecture Rapport et Annexes3305/0606/0608/0607/06 Rédiger Road book personnel3313/0513/0515/06  Préparer Présentation 5  05/06  15/05 TOTAL41 48    Fiche mission de Jean-Luc
TâchesCharges (h)Dates de débutDates de finPrévuesRéellesPrévuesRéellesPrévuesRéellesFormaliser 13 dysfonctionnements 163813/0513/0525/0501/06Sélectionner cas partie IV-MPE2126/0530/0528/0530/05Management projet MPE 3313/0513/0503/0604/06Management projet MSP3313/0513/0503/0604/06Responsable partie I2128/0528/0503/0603/06Capitalisation MPE3328/0501/0603/0602/06Responsable Annexe base des DPI (Annexe 7)2428/0531/0503/0603/06Rédiger Avant-propos et conclusion4328/0501/0603/0601/06Etudier Cross Knowledge : Constitution doc sur ce site2216/0525/0525/0525/05Relecture Rapport et Annexes et consolidation corrections6605/0608/0608/0608/06Rédiger Road book personnel3213/0520/0515/06 Préparer Présentation5TOTAL5366 Annexe 7 : Norme et modèle pour projets informatiques
Quel 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 projetMOA
Tests applicatifsMOEQualité Prise en compte des enjeux de qualitéSécurité Prise en compte des enjeux de sécuritéConsultants PGI EXP Support Exploit.FSU Formation Support UtilisateursComité UtilisateursDocSTISTECOS
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 : Dysfonctionnements
Pour 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)

ItemCas de dysfonctionnementExpression des besoinsC01 : Etude MOA insuffisante dans un contexte réglementaire incertainC02 : 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'informationC04 : Oubli de prise en compte de spécificités localesC05 : Manque du code deviseDécoupage en phases et panorama des outilsC06 : 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 MOAC10 : Inadéquation entre un outil de gestion et un automate fabriqué sur mesurePhase de planification et gestion du tempsC11 : 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 lancementC12 : 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 projetPhase de productionC14 : 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 techniquePhase de pilotageC18 : 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)
ItemCas de dysfonctionnementGestion 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 projetC21 : 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 projetC23 : Mauvaise gestion des plannings des membres utilisateurs de l’équipe MOAC24 : Déficit de communicationImplication des utilisateursC25 : 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 colossalC27 : Appréhension insuffisante des enjeux par les utilisateurs finauxC28 : MOA - Manque d’implication des utilisateurs du site piloteC29 : Implication des utilisateursSoutien de la Direction GénéraleC30 : Non soutien de la DG pour un projet dont elle n’était pas à l’origineC31 : 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)
ItemCas de dysfonctionnementCharte des valeurs de l’équipe de projetC33 : MOA – Absence de charte de fonctionnement aboutit à des incohérencesC34 : Faire collaborer des personnes de cultures différentesC35 : Choc des cultures dans une structure associative (ce cas est présenté dans le rapport au IV .2)Charte d’utilisation de l’espace e-collaboratifC36 : 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-collaboratifC37 : MOE - mauvaise utilisation de l'espace collaboratif (ce cas est présenté dans le rapport au IV .4)Tableaux de bordC38 : Intérêt de mettre en place un indicateur de production (ce cas est présenté dans le rapport au IV.5)Capitalisation des connaissancesC39 : 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
DysfonctionnementObsolescence du modèle de classes fourni par la MOA faute d’une fonction « reverse » - Contexte PMEArgumentaireProjet 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 effetsLes 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 solutionsAucune 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.FCSLe 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.
1.1. Expression des besoins (suite)
C03 : Appel d’offres infructueux : logiciel de virtualisation du système d'information
DysfonctionnementBesoin non cadré et flouArgumentaireEn 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 effetsLes 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 solutionsCet é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). FCSDans 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.1.1. Expression des besoins (suite)
C04 : Oubli de prise en compte de spécificités locales
DysfonctionnementBascule de SI composé de 5 applications locales sur une plateforme unique paneuropéenneArgumentaireDans 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 EffetsLes 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.1.1. Expression des besoins (suite)
C05 : Manque du code devise
DysfonctionnementBascule à l’euro d’un système d’information de crédit d’un Etablissement bancaire parapublicArgumentaireLors 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 effetsLes 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 solutionsLa 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é
DysfonctionnementRefonte d’un système CAO - PME – 500 jour homme (2006)ArgumentaireDans 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 mois
A 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 effetsLes 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 solutionsDans 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.FCSLe choix des outils est primordial car c’est de celui-ci que dépendent :
Pour l’utilisateur : l’acceptation, l’appropriation
Pour 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).1.2. Découpage en phases et panorama des outils (suite)
C08 : DG/MOA – Une mauvaise équation économique dans un environnement de revente indirecte a des conséquences techniques importantes
DysfonctionnementMauvaise anticipation de l'évolution des coûts de licences base de données relationnelle – Contexte PMEArgumentaireDans 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 é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 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 effetsLes 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 solutionsFace à 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.FCSFace à 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é.1.2. Découpage en phases et panorama des outils (suite)
C09 : Implication insuffisante de la MOA
DysfonctionnementMise en place d’un système de SGDT – PME – 1000 jour homme (2002-2003)ArgumentaireAfin 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 effetsLes 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 solutionsLa 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.FCSL’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.1.2. Découpage en phases et panorama des outils (suite)
C10 : Inadéquation entre un outil de gestion et un automate fabriqué sur mesure
DysfonctionnementProblème d’interface entre le logiciel d’entrepôt et l’automate.ArgumentaireRefonte 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 effetsLes 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 solutionDans 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.FCSDans 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
Ce cas est présenté dans le rapport au II.4.
1.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.
1.4. Phase de lancement (suite)
C13 : MOE - Manque d’un interlocuteur de l’équipe réseau dans l’équipe projet
DysfonctionnementInfrastructure réseau non opérationnelle pour accueillir la nouvelle solution – Contexte : Groupe international ArgumentaireEn 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 effetsLa 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 solutionsIl 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).FCSLe 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é
Ce cas est présenté dans le rapport au II.6.
1.5. Phase de production (suite)
C15 : MOA/MOE - Tests incomplets sur plate-forme laboratoire
DysfonctionnementMauvaise performance de l’application sur les pc des utilisateurs – Contexte : Groupe internationalArgumentaireEn 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 effetsLa 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 solutionsIl 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.FCSDans 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.1.5. Phase de production (suite)
C16 : MOE - Mauvais choix d’une solution technique
DysfonctionnementSolution technique non évolutive – Contexte Groupe InternationalArgumentairePé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 effetsLa 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 solutionsLe logiciel a été modifié pour compresser les données avant la gravure puis pour pouvoir graver plusieurs DVD dans des temps acceptables.FCSLe 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.1.5. Phase de production (suite)
C17 : Projet de gestion de stockage
DysfonctionnementMauvaise anticipation du besoin en capacité de stockage, explosion des coûts informatiquesArgumentaireEn 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 effetsLes 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 servicePistes de solutionsPar 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.FCSFace 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
Ce cas est présenté dans le rapport au III .3
2.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 III .4
2.3. Management d’équipes de projet (suite)
C22 : Manque de leadership du chef de projet
DysfonctionnementRemplacement d’une GED techniqueArgumentaireDans 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 effetsLes 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 solutionsLors 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.FCSIl 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. 2.3. Management d’équipes de projet (suite)
C23 : Mauvaise gestion des plannings des membres utilisateurs de l’équipe MOA
DysfonctionnementAucune gestion par le chef de projet MOA des congés des membres de l’équipe – Contexte : Groupe InternationalArgumentairePé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 effetsLa 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 solutionsLe 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.FCSLe 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.2.3. Management d’équipes de projet (suite)
C24 : Déficit de communication
DysfonctionnementBascule de SI composé de 5 applications locales sur une plateforme unique paneuropéenneArgumentaireDans 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églementation
La moa n’a pas appuyée suffisamment ses demandes et trouvée des sponsors de ses demandes primordiales pour l’Etablissement. Causes et effetsCauses 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 besoin
Effet :
- 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 solutionsLa 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.FCSEnrichissement 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
Ce cas est présenté dans le rapport au III .5
2.4. Implication des utilisateurs (suite)
C26 : La non prise en compte des exigences de performance des utilisateurs conduit à un gâchis colossal
DysfonctionnementTemps de réponse en condition réel de fonctionnement insupportable pour les utilisateurs – Contexte Public Grand compteArgumentairePé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 effetsLes 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 solutionsAucune 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.FCSPour 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. 2.4. Implication des utilisateurs (suite)
C27 : Appréhension insuffisante des enjeux par les utilisateurs finaux
DysfonctionnementOutil référentiel patrimoine - Grand groupe (2007)ArgumentaireL’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 effetsLa 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 solutionsCe 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.2.4. Implication des utilisateurs (suite)
C28 : MOA - Manque d’implication des utilisateurs du site pilote
DysfonctionnementLes utilisateurs du site pilote ne remontent pas les informations – Contexte Groupe InternationalArgumentairePé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 effetsLa 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 solutionsAfin 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.2.4. Implication des utilisateurs (suite)
C29 : Implication des utilisateurs
DysfonctionnementBascule de SI composé de 5 applications locales sur une plate-forme unique paneuropéenneArgumentaireDans 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ésCauses et effetsCauses 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
DysfonctionnementLe projet non soutenu par la DG a failli être abandonné – Contexte PMEArgumentairePé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 effetsLes 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 solutionsCe 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.FCSPour 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
DysfonctionnementIntranet. - PME (2001)ArgumentaireDans 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 effetsLa 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 solutionsDans 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.FCSL’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
DysfonctionnementUn référentiel de définition des devises et des cours a été redéfini pour rien – Contexte PMEArgumentairePériode concernée : 1997
Une 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 effetsLa 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 existantsPistes de solutionsA 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.FCSLorsque 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
DysfonctionnementOutil de composition de gammes produit. - PME au contexte international (2001-2004)ArgumentaireImplanté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’arbitrage
Ceci 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 effetsLes 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
Ce cas est présenté dans le rapport au IV.3
3.3. 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
3.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
3.5. Capitalisation des connaissances
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
Annexe 10 : Recommandations
En 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 projetCasQuestionsRecommandationsManagement structuré de projetExpression des besoinsC01
C02
C03
C04
C05La 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 outilsC06
C07
C09Existe-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 C11Y 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 lancementC13
C12La 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 productionC16
C17
C14Existe-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 pilotageC18Les 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 projetCasQuestionsRecommandationsManagement des équipes de projetGestion de ses prioritésC19A-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 collectivesC20Dispose-t-on d'une équipe fortement impliquée ?
Les rôles de chacun sont ils clairement explicités ?Management d'équipes de projetC22La MOE dispose-t-elle des compétences et ressources suffisantes dans les domaines managériales, techniques et fonctionnelles ?Implication des utilisateursC26La consultation et l'implication des utilisateurs a-t-elle été suffisante au cours des différentes phases du projet ?Soutien de la DGC30Dispose-t-on d'un soutien fort de la DG ?Management de projets e-collaboratifCharte des valeurs de l'équipe de projetC33Existe-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.
Charte d’utilisation de l’espace e-collaboratifC36Existe-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-collaboratifC37Les équipes utilisatrices ont-elles été formées à l'utilisation des outils collaboratifs avant de lancer le projet?Tableaux de bordC38Existe-t-il un tableau de bord du projet ?Capitalisation des connaissancesC39Dispose-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 ?








Pathologies des Projets Informatiques

PAGE 


#$.ST[vx‚„”—·¸ÊÝ   ïáïϽ²ª¢ª—‹sg[MsD8h[hÁ9í6CJaJhUX@6CJaJhAÉhUX@6CJ\aJhAÉhUX@6CJaJh[h…+6CJaJh[hUX@6CJaJh[h…+5CJaJh[hUX@5CJaJhjÛh…+CJaJh[CJ aJ hUX@CJ aJ hjÛh…+CJ aJ #h[hjÛ56B* CJ4aJ4ph€#h[hUX@56B* CJ4aJ4ph€hÁ9í6B* CJ(aJ(ph€ hÁ9íhÁ9í6B* CJ(aJ(ph€.T„—¸ÊÝíû   & 5 7 G K øñçÝÕÕÕÕÕÕÕËÁÁº¯¦ `$Ifgdò}¬ _¤$Ifgdò}¬¤gd[ $¤xa$gd…+ $¤Xa$gdjÛ$a$gdUX@ $¤àa$gd[ $¤°a$gdUX@7¤ gdÁ9í7¤hgdÁ9í   % & 5 6 7 8 G J K L W X Y Z [ \ n “ ” › œ ¸ ï ü 


Ô
Ö
} ~  € Ç e n œ Á  à öêÞÒÆÀµ¯¨¤¨¤¨¨™¨¤¨¤¨¤¨“Š“Š“Š“Š““}v}v}v}q *h[ h¹#h| 8h| 8h5mh| 8aJh¹#h| 8aJ
h| 8aJh>Y h±/Ih[h[ häh[
h[CJ$h9`h[CJaJ
h…+CJ$h[hUX@6CJaJh[h…+6CJaJh[hjÛ6CJaJh[h…+5CJaJhé.g5CJaJ*K L W [ ‚y `$Ifgdò}¬ _¤$Ifgdò}¬qkd$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
Faö[ \ n ” €u `¤´$Ifgd| 8
_¤´¤$Ifgd| 8qkd›$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
Faö” • œ Ö
 Ã Ä €wlcW `$$Ifa$gd| 8 `$Ifgd™%7 ¤x$Ifgd| 8 $Ifgd| 8
_¤´¤$Ifgd| 8qkd6$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
FaöÃ Ä Î Ï g
h
x
y
ß
à
á
ë
@G 
  )*158@ANP^fgvˆ‰Š‹žŸ¶·¸÷óìóìóìóìóìóåóìóìóìóìóáóáìÙÎÊáìÙÂÙ籚ˆšo0jht—ht—0JOJQJUaJmHnHu#ht—ht—56;CJ\]aJ,jht—ht—56;CJU\]aJ
h[CJ(h°[h[mH sH h°[mH sH hÁ9íhn­h[mH sH h[mH sH he9ˆ h*i£h[ häh[h[ *hþ)‡h #ï)Ä Å Ï h
€u `¤´$Ifgd| 8
_¤´¤$Ifgd| 8qkdÑ$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
Faöh
i
y
à
€u `¤´$Ifgd| 8
_¤´¤$Ifgd| 8qkdl$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
Faöà
á
ë
ý
@c¡Ó
‚yyyyyy `$Ifgdò}¬ _¤$Ifgdò}¬qkd$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
Faö
 *€u `¤´$Ifgd| 8
_¤´¤$Ifgd| 8qkd¢$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
Faö*+AO€u `¤´$Ifgd| 8
_¤´¤$Ifgd| 8qkd=$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
FaöOPg‰€u `¤´$Ifgd| 8
_¤´¤$Ifgd| 8qkdØ$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
Faö‰ŠžvÐ-œyƒà{{uooouooo
Æ-!

Æ-!

Æ-!
$¤¤Ða$gd[qkds$$If–FÖÖ0ºÿ{ØÁ]Ö0ÿÿÿÿÿÿöööÖÿÿÖÿÿÖÿÿÖÿÿ4Ö
Faö ¸¹ÕÖ×Øäåæ$%ëÛ뽤ë’|’d|’|¤N¤ëÛë+ht—ht—56CJ\]aJmHnHu.j‹ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu%&'TUVpqrstuvwx”•âɵ££u£É_H6*6ht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHu+ht—ht—56CJ\]aJmHnHu.j…ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jht—ht—>*B*CJUaJmHnHphÿu•–—®¯°ÊËÌÍÎÏÐÑÒîïæϽ¯¯‰¯ÏzaM=Mht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu&jht—ht—UmHnHu#jht—ht—UmHnHuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHu2jht—ht—>*B*UmHnHphÿuïðñ  
'()*+,-./KLMNz{|–âɵ££u£ÉeɵeµGɵ££:jö ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jy ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jüht—ht—>*B*CJUaJmHnHphÿu–—˜™š›œžº»¼½ìíî 
  
èÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—.jm ht—ht—CJUaJmHnHu:jð
ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.js
ht—ht—CJUaJmHnHu,-./VWXrstvwxyz{é×Ë×±é×£‘£}‘£‘énUA'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu&jg ht—ht—UmHnHu#jht—ht—UmHnHuht—ht—mHnHu2jê ht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHu{—˜™šáâãýþÿ"#$%`ab|ïÛ½¤Û’|’d|’|¤ï¤ÛïÛF¤Û’|’:jÞ
ht—ht—>*B*CJUaJmHnHphÿu.ja
ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jä ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu|}~€‚ƒ„…¡¢£¤½¾¿ÙÚÛÝÞßàáâþÿèÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.jUht—ht—CJUaJmHnHu:jØht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j[ht—ht—CJUaJmHnHuÿ)*+EFGIJKLMNjklmˆ‰Š¤âɵ££u£ÉeɵeµGɵ££:jÌht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jOht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jÒht—ht—>*B*CJUaJmHnHphÿuàL«
oäM³ƒæH¾4’ñN­‘û^Ò*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jIht—ht—CJUaJmHnHu
+,-.LMNhijlmnopqé×Ë×±é×£‘£}‘£‘énUA'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu&j=ht—ht—UmHnHu#jht—ht—UmHnHuht—ht—mHnHu2jÀht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHuqŽÁÂÃÝÞßáâãäåæ*+,FïÛ½¤Û’|’d|’|¤ï¤ÛïÛF¤Û’|’:j´ht—ht—>*B*CJUaJmHnHphÿu.j7ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jºht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHuFGHJKLMNOklmn‘’¬­®°±²³´µÑÒèÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.j+ht—ht—CJUaJmHnHu:j®ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j1ht—ht—CJUaJmHnHuÒÓÔö÷ø789:`ab|âɵ££u£ÉeɵeµGɵ££:j¢ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.j%ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j¨ht—ht—>*B*CJUaJmHnHphÿu|}~€‚ƒ„…¡¢£¤ÃÄèÒÀÒ§‘zh\hBzh4ht—ht—mHnHu2jœht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHu+ht—ht—56CJ\]aJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jht—ht—CJUaJmHnHuÄÅßàáãäåæçè%&íßËíßí´¥ŒxhxJŒx8"ht—ht—CJaJmHnHu:j–ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu&jht—ht—UmHnHuht—ht—mHnHu#jht—ht—UmHnHu&'ABCEFGHIJfghi›œ·¸¹»¼½¾¿ÀÜÝé׿é×首¦‚–‚d¦‚×é×Lé×首¦‚–‚.j
ht—ht—CJUaJmHnHu:jht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu.jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHuÝÞß-./123456RSTUopq‹âɵ££u£ÉeɵeµGɵ££:j„ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jŠht—ht—>*B*CJUaJmHnHphÿu‹Œ‘’“”°±²³ÎÏÐêëìîïðñòóèÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.jûht—ht—CJUaJmHnHu:j~ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jht—ht—CJUaJmHnHu+,-GHIKLMNOPlmâɵ££u£ÉeN*B*UmHnHphÿuñòó5679:;Z[\]“”•¯âɵ££u£ÉeɵeµGɵ££:jH&ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jË%ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jN%ht—ht—>*B*CJUaJmHnHphÿu¯°±³´µ¶·¸ÔÕÖ×ýþÿ !">?èÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.j¿'ht—ht—CJUaJmHnHu:jB'ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jÅ&ht—ht—CJUaJmHnHu?@A`ab|}~€‚ƒ„…¡¢âɵ££u£ÉeN*B*UmHnHphÿu#!$!%!K!L!M!g!h!i!k!l!m!n!o!p!Œ!!Ž!!Å!Æ!Ç!á!âɵ££u£ÉeɵeµGɵ££:j 0ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.j/ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j/ht—ht—>*B*CJUaJmHnHphÿuá!â!ã!å!æ!ç!è!é!ê!""" "/"0"1"K"L"M"O"P"Q"R"S"T"p"q"èÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.jƒ1ht—ht—CJUaJmHnHu:j1ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j‰0ht—ht—CJUaJmHnHuq"r"s"’"“"”"®"¯"°"²"³"´"µ"¶"·"Ó"Ô"âɵ££u£ÉeN*B*UmHnHphÿu=%>%?%e%f%g%%‚%ƒ%…%†%‡%ˆ%‰%Š%¦%§%¨%©%ß%à%á%û%âɵ££u£ÉeɵeµGɵ££:jÐ9ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jS9ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jÖ8ht—ht—>*B*CJUaJmHnHphÿuû%ü%ý%ÿ%&&&&& &!&"&#&I&J&K&e&f&g&i&j&k&l&m&n&Š&‹&èÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.jG;ht—ht—CJUaJmHnHu:jÊ:ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jM:ht—ht—CJUaJmHnHu‹&Œ&&¬&­&®&È&É&Ê&Ì&Í&Î&Ï&Ð&Ñ&í&î&âɵ££u£ÉeNht—ht—>*B*UmHnHphÿu9(:(;(\(](^(x(y(z(|(}(~((€(((ž(Ÿ( (Ê(Ë(Ì(æ(âɵ££u£ÉeɵeµGɵ££:j¦@ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.j)@ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j¬?ht—ht—>*B*CJUaJmHnHphÿuæ(ç(è(ê(ë(ì(í(î(ï( ) )
))5)6)7)Q)R)S)U)V)W)X)Y)Z)v)w)èÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.jBht—ht—CJUaJmHnHu:j Aht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j#Aht—ht—CJUaJmHnHuw)x)y)ž)Ÿ) )º)»)¼)¾)¿)À)Á)Â)Ã)ß)à)á)â)ú)û)ü)*âɵ££u£ÉeɵeµGɵ££:j”Cht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jCht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jšBht—ht—>*B*CJUaJmHnHphÿu*********;**]*^*_*èÒÀÒ§—€nbnH€n:(#jht—ht—UmHnHuht—ht—mHnHu2jŽDht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jDht—ht—CJUaJmHnHu_*y*z*{*}*~**€**‚*ž*Ÿ* *¡*È*É*òÞÌò̵¦yiyKy9"ht—ht—CJaJmHnHu:jˆEht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu#jht—ht—UmHnHu&j Eht—ht—UmHnHuht—ht—mHnHu*€*ë*f+Ñ+5,¡, -‡-ò-V.¿.*/¥/0t0Û0F1Á1,22ë2V3Ñ3*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu.jFht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu…+†+‡+®+¯+°+Ê+Ë+Ì+Î+Ï+Ð+Ñ+Ò+Ó+ï+ð+ñ+ò+,,,.,âɵ££u£ÉeɵeµGɵ££:jvHht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jùGht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j|Ght—ht—>*B*CJUaJmHnHphÿu.,/,0,2,3,4,5,6,7,S,T,U,V,~,,€,èÒÀÒ§—€nbnH€n:(#jht—ht—UmHnHuht—ht—mHnHu2jpIht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jóHht—ht—CJUaJmHnHu€,š,›,œ,ž,Ÿ, ,¡,¢,£,¿,À,Á,Â,é,ê,òÞÌò̵¦yiyKy9"ht—ht—CJaJmHnHu:jjJht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu#jht—ht—UmHnHu&jíIht—ht—UmHnHuht—ht—mHnHuê,ë,--- -
- - -
--*-+-,---d-e-f-€--‚-„-…-†-‡-ˆ-‰-¥-¦-é׿é×首¦‚–‚d¦‚×é×Lé×首¦‚–‚.jáKht—ht—CJUaJmHnHu:jdKht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu.jçJht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu¦-§-¨-Ï-Ð-Ñ-ë-ì-í-ï-ð-ñ-ò-ó-ô-....3.4.5.O.âɵ££u£ÉeɵeµGɵ££:jXMht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jÛLht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j^Lht—ht—>*B*CJUaJmHnHphÿuO.P.Q.S.T.U.V.W.X.t.u.v.w.œ..ž.èÒÀÒ§—€nbnH€n:(#jht—ht—UmHnHuht—ht—mHnHu2jRNht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jÕMht—ht—CJUaJmHnHuž.¸.¹.º.¼.½.¾.¿.À.Á.Ý.Þ.ß.à.//òÞÌò̵¦yiyKy9"ht—ht—CJaJmHnHu:jLOht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu#jht—ht—UmHnHu&jÏNht—ht—UmHnHuht—ht—mHnHu/ /#/$/%/'/(/)/*/+/,/H/I/J/K/‚/ƒ/„/ž/Ÿ/ /¢/£/¤/¥/¦/§/Ã/Ä/é׿é×首¦‚–‚d¦‚×é×Lé×首¦‚–‚.jÃPht—ht—CJUaJmHnHu:jFPht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu.jÉOht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHuÄ/Å/Æ/í/î/ï/ 0
0 0
000000.0/00010Q0R0S0m0âɵ££u£ÉeɵeµGɵ££:j:Rht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.j½Qht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j@Qht—ht—>*B*CJUaJmHnHphÿum0n0o0q0r0s0t0u0v0’0“0”0•0¸0¹0º0èÒÀÒ§—€nbnH€n:(#jht—ht—UmHnHuht—ht—mHnHu2j4Sht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j·Rht—ht—CJUaJmHnHuº0Ô0Õ0Ö0Ø0Ù0Ú0Û0Ü0Ý0ù0ú0û0ü0#1$1òÞÌò̵¦yiyKy9"ht—ht—CJaJmHnHu:j.Tht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu#jht—ht—UmHnHu&j±Sht—ht—UmHnHuht—ht—mHnHu$1%1?1@1A1C1D1E1F1G1H1d1e1f1g1ž1Ÿ1 1º1»1¼1¾1¿1À1Á1Â1Ã1ß1à1é׿é×首¦‚–‚d¦‚×é×Lé×首¦‚–‚.j¥Uht—ht—CJUaJmHnHu:j(Uht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu.j«Tht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHuà1á1â1 2
2 2%2&2'2)2*2+2,2-2.2J2K2L2M2m2n2o2‰2âɵ££u£ÉeɵeµGɵ££:jWht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jŸVht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j"Vht—ht—>*B*CJUaJmHnHphÿu‰2Š2‹22Ž222‘2’2®2¯2°2±2È2É2Ê2èÒÀÒ§—€nbnH€n:(#jht—ht—UmHnHuht—ht—mHnHu2jXht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j™Wht—ht—CJUaJmHnHuÊ2ä2å2æ2è2é2ê2ë2ì2í2 3
3 3 33343òÞÌò̵¦yiyKy9"ht—ht—CJaJmHnHu:jYht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu#jht—ht—UmHnHu&j“Xht—ht—UmHnHuht—ht—mHnHu4353O3P3Q3S3T3U3V3W3X3t3u3v3w3®3¯3°3Ê3Ë3Ì3Î3Ï3Ð3Ñ3Ò3Ó3ï3ð3é׿é×首¦‚–‚d¦‚×é×Lé×首¦‚–‚.j‡Zht—ht—CJUaJmHnHu:j
Zht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu.jYht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHuð3ñ3ò344454647494:4;44Z4[4\4]4}4~44™4âɵ££u£ÉeɵeµGɵ££:jþ[ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.j[ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j[ht—ht—>*B*CJUaJmHnHphÿu™4š4›44ž4Ÿ4 4¡4¢4¾4¿4À4Á4ï4ð4ñ4èÒÀÒ§—€nbnH€n:(#jht—ht—UmHnHuht—ht—mHnHu2jø\ht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j{\ht—ht—CJUaJmHnHuñ4 5 5
555555505152535]5^5òÞÌò̵¦yiyKy9"ht—ht—CJaJmHnHu:jò]ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu#jht—ht—UmHnHu&ju]ht—ht—UmHnHuht—ht—mHnHu^5_5y5z5{5}5~55€55‚5ž5Ÿ5 5¡5Á5Â5é׿é×馐yg[gAyg3ht—ht—mHnHu2jì^ht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHu+ht—ht—56CJ\]aJmHnHu0jht—ht—0JOJQJUaJmHnHu.jo^ht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHuÂ5Ã5Ý5Þ5ß5á5â5ã5ä5å5æ566665666íßËíßí´¥ŒxhxJŒx8"ht—ht—CJaJmHnHu:jæ_ht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu&ji_ht—ht—UmHnHuht—ht—mHnHu#jht—ht—UmHnHu€5ä5X6Ó6c7¿7+8899ë9N:Ç:1;«;?}?÷?a@Ä@.A˜Aùóóóóóùóóóóùóóóóùóóóóùóóóóùó
Æ-!

Æ-!
6676Q6R6S6U6V6W6X6Y6Z6v6w6x6y6°6±6²6Ì6Í6Î6Ð6Ñ6Ò6Ó6Ô6Õ6ñ6ò6é׿é×首¦‚–‚d¦‚×é×Lé×首¦‚–‚.j]aht—ht—CJUaJmHnHu:jà`ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu.jc`ht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHuò6ó6ô6@7A7B7\7]7^7`7a7b7c7d7e77‚7ƒ7„7œ77ž7¸7âɵ££u£ÉeɵeµGɵ££:jÔbht—ht—>*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jWbht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jÚaht—ht—>*B*CJUaJmHnHphÿu¸7¹7º7¼7½7¾7¿7À7Á7Ý7Þ7ß7à78 8
8$8%8&8(8)8*8+8èÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—.jKdht—ht—CJUaJmHnHu:jÎcht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jQcht—ht—CJUaJmHnHu+8,8-8I8J8K8L8z8{8|8–8—8˜8š8›8œ88ž8Ÿ8é×Ë×±é×£‘£}‘£‘énUA'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—5\mHnHu&jEeht—ht—UmHnHu#jht—ht—UmHnHuht—ht—mHnHu2jÈdht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHuŸ8»8¼8½8¾8ä8å8æ899999999 9%9&9'9(9^9_9`9z9ïÛ½¤Û’|’d|’|¤ï¤ÛïÛF¤Û’|’:j¼fht—ht—>*B*CJUaJmHnHphÿu.j?fht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:jÂeht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHuz9{9|9~99€99‚9ƒ9Ÿ9 9¡9¢9È9É9Ê9ä9å9æ9è9é9ê9ë9ì9í9 :
:èÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.j3hht—ht—CJUaJmHnHu:j¶ght—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j9ght—ht—CJUaJmHnHu
: : :+:,:-:G:H:I:K:L:M:N:O:P:l:m:âɵ££u£ÉeN*B*CJUaJmHnHphÿuht—ht—CJaJmHnHu.jpht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHu:j†oht—ht—>*B*CJUaJmHnHphÿuå=æ=ç=é=ê=ë=ì=í=î=
> > >
>3>4>5>O>P>Q>S>T>U>V>W>X>t>u>èÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.j÷qht—ht—CJUaJmHnHu:jzqht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jýpht—ht—CJUaJmHnHuu>v>w>–>—>˜>²>³>´>¶>·>¸>¹>º>»>×>Ø>âɵ££u£ÉeN*B*CJUaJmHnHphÿu B B
BBBBBBB0B1B2B3BYBZB[BuBvBwByBzB{B|B}B~BšB›BèÒÀÒ§—§ƒ—ƒe§ƒÀÒÀMÒÀÒ§—§ƒ—ƒ.j»{ht—ht—CJUaJmHnHu:j>{ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.jÁzht—ht—CJUaJmHnHu˜AB|BßBQCŸCðC*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j€ht—ht—CJUaJmHnHu‡DˆD‰DŠD¦D§D¨D©D¹DºD»DÕDÖD×DÙDÚDÛDÜDÝDÞDúDûDüDýDïÖÂï¤Ö’|’d|’|ÖïÖÂïÂFÖ:jƒht—ht—>*B*CJUaJmHnHphÿu.j‘‚ht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu:j‚ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHu0jht—ht—0JOJQJUaJmHnHuht—ht—CJaJmHnHuýDEEE+E,E-E/E0E1E2E3E4EPEQERESEZE[E\EvEé×ÁשÁ×Á€l€lNl×Á×:j„ht—ht—>*B*CJUaJmHnHphÿu'ht—ht—0JOJQJaJmHnHuht—ht—CJaJmHnHu0jht—ht—0JOJQJUaJmHnHu.j‹ƒht—ht—CJUaJmHnHu+jht—ht—CJUaJmHnHu"ht—ht—CJaJmHnHu+ht—ht—0JKH$OJQJaJmHnHuvEwExEzE{E|E}E~EE›EœEEžEÂEÃEèÒÀÒ§‘zh\hBzh4ht—ht—mHnHu2j…ht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHu+ht—ht—56CJ\]aJmHnHu0jht—ht—0JOJQJUaJmHnHu"ht—ht—CJaJmHnHu+jht—ht—CJUaJmHnHu.j…„ht—ht—CJUaJmHnHuÃEÄEÞEßEàEâEãEäEåEæEçEFFFF)F*F+FEFFFGFIFJFKFLFMFNFjFkFíßËíßí´¥´“‡“m´“ßíßYíßí´¥´“‡“&jy†ht—ht—UmHnHu2jü…ht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu&j…ht—ht—UmHnHuht—ht—mHnHu#jht—ht—UmHnHukFlFmF‹FŒFF§F¨F©F«F¬F­F®F¯F°FÌFÍFÎFÏFýFþFÿFGGGæϽ¯¯‰¯ÏzϽn½TϽ¯¯@&jmˆht—ht—UmHnHu2jð‡ht—ht—>*B*UmHnHphÿuht—ht—mHnHuht—ht—5\mHnHu&js‡ht—ht—UmHnHu#jht—ht—UmHnHuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHu2jö†ht—ht—>*B*UmHnHphÿuGGG G!G"G#G?G@GAGBGdGeGfG€GG‚G…G†G‡GˆG‰GŠG¦G§G¨G©GÂGÃGÄGÞGòàɺɨœ¨‚ɨòàònàòàɺɨœ¨Tɨòàò2jä‰ht—ht—>*B*UmHnHphÿu&jg‰ht—ht—UmHnHu2jêˆht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu#jht—ht—UmHnHuht—ht—mHnHuÞGßGàGãGäGåGæGçGèGHHHHHXHYHZH]H^H_H`HaHbH~HHìÚÌÚµ¦µ”ˆ”nµ”ÌÚÌZÚÌÚµ¦µ”ˆ”&j[‹ht—ht—UmHnHu2jފht—ht—>*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHuht—ht—mHnHu#jht—ht—UmHnHu&jaŠht—ht—UmHnHuH€HHÈHÉHÊHäHåHæHéHêHëHìHíHîH
I I I
I*I+I,IFIGIHIæϽ¯¯‰¯ÏzϽn½TϽ¯¯@&jOht—ht—UmHnHu2jҌht—ht—>*B*UmHnHphÿuht—ht—mHnHuht—ht—5\mHnHu&jUŒht—ht—UmHnHu#jht—ht—UmHnHuht—ht—mHnHu#ht—ht—0JOJQJmHnHu,jht—ht—0JOJQJUmHnHu2j؋ht—ht—>*B*UmHnHphÿuHIKILIMINIOIPIlImInIoIŠI‹IŒI¦I§I¨I«I¬I­I®I¯I°I±IÀImJòàɺɨœ¨‚ɨòàònàòàɺYUJUBh[nH tH hÍ*B*UmHnHphÿuht—ht—mHnHu#ht—ht—0JOJQJmHnHuht—ht—5\mHnHu,jht—ht—0JOJQJUmHnHu#jht—ht—UmHnHuht—ht—mHnHumJ½JlL…NcQ§RTSSÔU±V!W
YÿYL[¢\]_` b
b=bUbpbêc·dúúúúúúúúúúõõõõúúúúîéäßÚÚgd[gd°[gd°[gd[¤gd[Xgd°[gdò}¬mJ½JÓKL"LQLjLkLlLjNkN…NcQlQmQ¹QÆQÇQÏQÒQÚQÝQèQëQRRR"R6R9RFRGRORRR^R_RgRjRqR|RR¤R§R¿RPSRSTSS×SæSøSûS=TóëàëàëàëÕÍÕëº볯³¯³¯³¯³¯³¯³¯³¯³¯³¯³¯³¨¯³¯ëššë„º„º„hM#h[nH tH h[6]nH tH h‡nQh[6]nH tH  h|RIh| 8h[ h|RIh[h%IìnH tH hvh[nH tH h| 8nH tH h[h[nH tH hah[nH tH h[nH tH hah[6nH tH 4=TBTST
U#U'U/U?U—WÙW'XdXhXkYzY2[Q[R[S[[[l[n[|[}[†[‡[“[•[å[æ[ç[\¡\¢\]]]|]}]³]·]¹]_]_²_³_Ã_Å_Æ_Ç_øðåðåðåðÚÏðÏðøðÏðÏðÏðÇÂÇÂÇÂÇ»³¬¨Ïððð••„~„~„~
h[aJhµÊh[aJhV\nH tH he9ˆnH tH hµÊh[nH tH h[ hú'Qh[h‚:Ãh[\ h[5\ h[\hú'Qh[\hú'Qh[nH tH h8âh[nH tH hM#h[nH tH h[nH tH h%IìnH tH 1Ç_…a
b b
b=bBbpbÙbêbSc[cÛcÜcècéc d
dddJd®d·df_f`fmf•fìfífÿfg^g`gÃgÅgÍgÎgÕgheh°hOiPi›iîiðiøíøÞÚÖÏÈÚÈÄÈÚÈÚÈÚÈÚȽÈÚ¶Ú¶Ú¶Ú¶Ú¶Ú¶Ú¶Ú¶Ú­¡­–„­ h[5#hAÉh[5B* CJ\^Jph€h[5CJ\^Jhþ)‡h[\^JaJ h[\^JaJ hGÀh[ hþ)‡h[h%Iì h+*"h[ h°[h[h°[h[hÍÑ@ÑFÑHÑ\ÑyÑ{ѻѼÑýÑÒdÒmÒ>Ô^Ô+Õ,ÕDÕWÕøîäîäÝäîäîäîäîäîäîÖîäîäîäîäÌÂÌä¾·¾³¬§ŸšŸšŸ§Ÿ¾–¾’¾Ž¾Ž¾Ž’¾hâffhürh] hâff6h°Òh[6 h[6 hù0øh[h
GÔ h©Göh[h[h —h–P 6CJh —hâff6CJ
hV\6CJ
h ;.6CJhâffhâff6CJhâffhDŒ6CJ
hâff6CJ8WÕXÕcՁՍÕãÕäÕ:ÖCÖrÖsÖ¼Ö½ÖáÖèÖùÖûÖ9×:×U×d×e×fׯכأØÔØêØïØñØÙÙñÙòÙÚÚ1ÚyÚ{Ú¦ÚÅÚÈÚ0ÛaÛˆÛŽÛ Ü
ÜÜPÜ~ܚâœâfågåiånåüøñéñâñéñâñÛñéñÛñâñéÓéñøÏøüøÏøüøÈøÏøÁ½ÁÏÁø¶ø²«ø¦ž¦øüø—— hHÌhâff hHÌh[h°Òh[6 h[6 hªh[h
GÔ hÄ£h[h¦ hƒ7|h[ hÏQEh[h]Âhò}¬hâff\ hò}¬h] hò}¬hâffhò}¬h[\ hò}¬h[h[hâff8ˆÛ
ÜܶÜwÝLÞÝÞpß¼ßàGà á®á_â†äfå|åwæ…æeç0èWèÛéûéXê‡ê«êúñìçââçâââçâççççâçââìñìçââXgd°[gd[gd[
ÆŒgd[gd[nåzå|å‡åˆå æ æpçrç¾ç†ê‡êªê«ê¬êë9ë:ëJëqëwë¹ëºëÆë&ì5ì6ìíí’ï“ïsðvðËóÌóõó÷ó‡ô“ô”ôšôõ)õxõ¥õ¿õþõÿõâöùòêâòùòùòÞÕÎÞÇÞÀ¼ÀÞ¸±Þ¬¤¬¤ÞÞ™Þ‘Þ™òùòâ‰âòâò‚Þ‚{Þ hÏQEh[ hâdh[hHÌh[>*hXŠh[H*h| 8 hJjh[hÕT5h[6 h[6 hªh[h)Khâff hÄ£h[ hƒ
Mh[ hnM)h[hnM)h[aJh[hHÌh[\hHÌhâff\ hHÌh[ hHÌhâff0«êëJëqëºë6ìmìµìÖì
íˆí¡íîPðOñòÿògóËóâó‡ô”ôõÿõ&öúõðëâðÝúúúúúÝÝÝÝúúÝúÕúúð$a$gd[gd[
Ɛgd[gd[gd[gd[Xgd°[&öãö÷’÷ô÷,øVø0ùˆù¢ùÉùú^ú•úÄú|ýEÿGA+EñöñìççìççÖñÑÈñþ¾¾¾¾¾ìçgd01Œgdâff
Æ{gd[gd[
Æ°„Àü„^„Àü`„gd[Xgd°[gd[gd[
Ɛgd[âöãöˆ÷Œ÷Ñ÷Ô÷¡ù¢ùÉùÏùúúúNú]ú^ú•ú¶ú¸úÃúÄúÓúÔú=û>ûEûIûSûjûzû{û üüüüüüÖü×üÙü6þVþó+,ENRÖØñùõñõñõêõæßõÚÒÚÒõËñËñÄÀÄõÄõÄõÄõĹõÀ¹À¹ÄõÄÀÄÀÄ°ªÄ¦Ÿ—ŸŸ hHÌh01ŒhHÌh01Œ\ hHÌh[hÁ9í
h[aJhXŠh[aJ h°Òh[h01Œ hwCÁh[ hâdhâffh°Òh[6 h[6 h³~šh[h)K h©Göh[hâffh[ hÏQEh[6ñýþ“¢#J¾À  E _ ` f 



T
U
V
W
Ó
Ô
 … † ‡ ¡ È Î % 1 Š ™ š Ñ â ã ä å ê ë õëãÜÕãÕÑÈÂÈÂÈѾÑÈÂÈѷѷѷѳ·¬Ñ¥Ñ¡š••Ñƒ|ƒ|ƒ³
h01Œ\aJh¡{‡h01Œ\aJh~>6h[6 h[6 h³~šh[h)K hÄ£h[ hïK¿h[h01Œ hâdh[h]Â
h[aJhâdh[aJh[ hHÌh[ hHÌh01ŒhHÌh[\hHÌh[>*aJhHÌh[\aJ-ñþ“#JÀF f 

V
Ô
 † ¡ È % š Ñ ë z{ç
'úõõðúçðúúõõõõâðÝÔðÏúúúõõgd01Œ
Æ‚ gd[gd[gd[
Æ{gd[gd[Xgd°[gd[ë ¾
Ä
Ì
Ö
$5äæçõ./„…âçèí‘•ÀÆéìñòóôc…¢§ÅÈÖÙ^z{­²ù!9P[åç8@Ao°± 
õîõîõîõäõäõîõîõîõÝõîõîõîõîõîõîõîõîõîõîõîÖîÍÇÍÇÍÇÍÁÍǽ¶²¶«½«½¤ h›zÐh[ hŠ/õh[hÁ9í h˜*h[h[
h01ŒaJ
h[aJh¡{‡h[aJ
h01Œ\aJ
hür\aJh¡{‡h[5aJ
h[\aJh¡{‡h[\aJ='8@o½$¨µ„«?_-\’«Ò2¬ãúõéààÛÖÛÖÖÑÈÑéÖÖÃѾµÑ
Æ gd[gd[gd[
Æ‚ gd[gd[XgdÒlgd[T¤x¤gdÒl G
& F¤´¤gd[gd°[Xgd°[$+./¨´µ»½¿+-/oƒ„«5678>?_-F[“«ÒØ12>Œ¬ãüý/0÷ïèáè×ÍïèáèïèáèÉÂɼ¶¼¶¼Âɯ«¯¤É¤ÉÉ™’ɍ…É{tÉ« h°Òh01Œh°Òh01Œ\aJh°Òh[6 h[6 hù0øh[h)K hÄ£h[ h›zÐh[h01Œ h~>6h[
h01ŒaJ
h[aJ hÏQEh[h[hHÌh[>*aJhHÌh[\aJ hHÌh01Œ hHÌh[hHÌh[\hHÌh[aJ-ãý«ƒ!!Æ!Ó!Š"%#L#á#V$v$=%ò%P&&¯'9(*½*+k,ã-x1úõõõõðõððëúúëúúúæõõõÜ×õõõgdô3 $¤a$gd0
¢gd[gd[XgdÒlgd[gd01Œ0áã 7B‚ƒ¥¦2 8 !!!$!Ä!Å!Æ!Ò!Ó!Ù!Û!Ý!&"E"u"v"Š"™"¦"¨"È"á"ü"ý"
####$#%#L#U#œ##¡#£#ª#«#­#Á#É#ä#ì#U$V$v$%%1%2%* hHÌh01Œ hHÌh[hHÌh[\hHÌh[aJhJE+h[\aJh]Âh01Œh[Añ%ò%P&&*ž*¹*º*»*¼*½*+C+E+k,t,…,†,õ,ö,--Ó-à-k.ˆ.œ/û/ý/0000æ0ì011¯5°5ù7ùòîæ×Ì»¬×æŸæ—ææ‡æ‡ææ‡æ|æqfqfqæ‡æ‡æ‡æh]Âh]ÂnH tH h]Âh[nH tH h‚:Ãh[nH tH hô3nH tH h]ÂnH tH h–dnH tH hô3hô3CJnH tH jÒôh–Kžh–KžUnH tH  jxúK
h–Kžh–KžUnH tH h–Kžh–KžnH tH jh–Kžh–KžUnH tH h[nH tH h[ hŸX!h[ hŸX!h]Â'x1¨2—3å436ã8h;`?b?‹?¸?Î@B®CEAFcF€F¦FÉFçFüFGnGÈIúõõúúúúîéäßßßúúúõõõõõÚúÕgdï2*gd[Wgd[gd[gd[¤gd[XgdÒlgd[ù7ü7q8r8þ89ù:ü:Ï?
?"?`?a?b?c?‹?¸?;@F@Í@Ò@¤A¥A®CE„E£E¯EPFcF¦FçFüF
GGGGnG…GøðèðàðèðØðàðèðÍɾɷɬ¤¬¤¬¤¬ð˜ðððÉðɆÉulh+*"h[0JVh+*"h[6aJ h©?öh[ huIýh[hšçh[nH tH hšçh[H*nH tH h[CJaJhÛh[CJaJ hÏQEh[hÏQEh[CJaJh[h¢oh[nH tH hHÌnH tH h]ÂnH tH hô3nH tH h[nH tH h‚ÈnH tH *…GH'HHŠHžH¦H·J¸J=KBK K§KN!NGNHNDQMQoQ¼QÝQÞQ˜TÀTóTUUGUnUrUsUtUVªV«V¯VìV"W)W6WžX¥XñXYHY¿YøY$Z0ZùõùñùõùõùñùñùñùíùíæÚÏÇÏí½µÇµªµªžªµªµªµª•ª•ªÏªŽƒí~ h[5h5óh[CJaJ h"
¢h[h©?öh[0JVh©?öh[6CJaJh©?öh[CJaJh[CJaJh©?öh[6aJhï2*CJaJhï2*h[CJaJhï2*h[6CJaJ h©?öh[h[hï2*hô3 h+*"h[1ÈItJÔL¿M¾ODQoQ¼Q˜TÀTóT«VHY€Y¿YøYïZØ[3]‡_Ü_aÉa¥bMc™efúúúúúõðëõæëëááëáááëëëëááððXgdÒlgd[Wgdï2*Wgd[gd[gdï2*0Z7Z:ZJZ3]‡_Ü_`&`g`r`•`›`³`µ`¼`Æ`Ö`Ü`a£aÉa…b™b.cAcMc]cec[ddd™e«ef=f fwhyhÖjßj'k(k¨kªk¼k¾kùklll_lçnén9oYoZo‚oˆo÷ó÷óèßèßè×è×è×è×è×è×èÐÈÐÈÐè×è¼èßèó²è×è×è×è×è×è󲫲èםó–ó’h)K h©Göh[hí"rh[56CJaJ
h[6aJh©?öh[6aJh5óh[5CJaJhï2*h[5 hï2*h[h[CJaJh©?öh[0JVh©?öh[CJaJh[h{h[59f=f f;gzhHjùkl_l^mén9oZo‚oÝo#p[pjpÑq‹rÅs(uúõððððúëðððÚúÕÌúǹ¹¹¹gd‹:½lÆÿgd‹:½
Æ gd[gd[
Æ°„Àü„^„Àü`„gd[gdï2*Wgdï2*gd[gd[ˆoÝoèoppp#p[pjpq q
rr•s˜sŸsªs¹sÄsÎuÖuªv¾vÑvywƒwOxPxQxRxZxjx6y÷zøz¼|À|;}!P!R!T!v!w!Ð!Ñ!e"{"|"‘"“"å"û"ü"(#)#+#D#O#P#Ñ#ü#ý#‘$—$¾$à$á$ÿ$%T%j%k%ª%«% &'&(&Z&l&m&''9':'¸'Ñ')(*(«*¬*¾*>+?+@+Q+Ú+Û+Ü+üõüõüëäÛÕÛëäÛÕÛëäÛÕÛäëäÛëäÛËëÛÅÛÅÛëäÛÕÛëäÛëäÛÕëäÛü¾üµ®¤ü®¤¾® h
 :