la conduite du changement
TRANSCRIPT
Nom : LEPICOUCHE Prénom : Audrey M2IRT 2007 « TER »
Mémoire 2007
– « Quelle est la conduite à suivre sur
le management du projet, lorsqu’un changement intervient durant un
projet informatique ? »
Version finale
Quelle est la conduite à suivre sur le management du
projet, lorsqu’un changement intervient durant un
projet informatique ?
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 2 / 79
1. Résumé / Abstract et remerciements
1.1 Résumé
Les projets informatiques sont des projets omniprésents dans toutes les sociétés actuelles.
L’informatique est en continuel changement, ou plus exactement en continuelle évolution, ce qui
implique que les sociétés soient amenées à faire évoluer leur système d’information en fonction
des évolutions de l’informatique.
Ces évolutions se font par le biais de projet que soit les sociétés traitent elles-mêmes, soit
qu’elles font sous-traités. Dans les deux cas, la gestion d’un projet reste la même et les conduites
suivies face aux changements également.
Pour chaque projet est nommé un chef de projet qui et en charge de faire la gestion du projet,
autrement dit de faire du management. Ce dernier peut porter sur plusieurs domaines qui seront
évoqués dans ce mémoire, le management humain, technique, commercial, financier et le
management de production.
Chaque domaine de management est spécifique et doit être traité différemment. En effet, un
changement dans le management humain ne se traitera pas de la même manière qu’un
changement dans le management commercial.
Pourtant, cela sera la même personne qui mettra en place la conduite à suivre en fonction du
changement survenant mais aussi en fonction du domaine dans lequel ce changement se fait.
Mais quelle est la conduite à suivre sur le management du projet, lorsqu’un changement
intervient durant un projet informatique ?
Il est donc important d’expliquer dans un premier temps, les différents managements existant
dans la gestion de projet informatiques.
Dans un second temps, il faut faire une analyse de l’existant et mettre en évidence les points
négatifs des conduites suivies pour faire face aux changements.
Par la suite, il faudra évoquer les améliorations qui peuvent être faites et les solutions à mettre
en place pour répondre à ces améliorations.
1.2 Abstract
The IT projects are omnipresent projects in all the current companies. IT is in continual change,
or more exactly in continual evolution, which implies that the companies are brought to make
evolve their information system according to the evolutions of IT.
These evolutions are made by the means of project that either the companies treat themselves,
or which they do sub-contracted. In both cases, the project management remains the same one
like the conduits followed to face the changes.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 3 / 79
For each project is named a project manager which is responsible for the management of the
project. The management can relate to several fields which will be evoked in this memory,
management human, technical, commercial, financial and the management of production.
Each field of management is specific and must be treated differently. Indeed, a change in human
management will not treat same manner as a change in commercial management. However, that
will be the same person who will set up control to be followed according to the occurring change
but also according to the field in which this change is done.
But which is control to be followed on the management of the project, when a change intervenes
during an IT project?
It is important to explain initially, various managements existing in the IT project management.
In the second time, it is necessary to make an analysis of existing and to highlight the negative
points of the conduits followed to face the changes. Thereafter, it will be necessary to evoke the
improvements which can be made and the solutions to be set up to answer these improvements.
1.3 Remerciements
Je tiens dans un premier temps à remercier mon directeur de mémoire, Thierry CRAYE, de
m’avoir guidé et mise sur la bonne voie pour la rédaction de ce mémoire. Je le remercie, de
m’avoir éclairé et de m’avoir aidé à clarifier et précisé le sujet de ce mémoire.
Je souhaite également le remercier pour les différents conseils qu’il m’a adressés et qui m’ont
permis de rédiger ce mémoire et de comprendre les enjeux de ce sujet.
Je voulais également remercier l’ITIN et plus particulièrement Céline VITHE qui a su me
conseiller et me soutenir tout au long de la rédaction de ce mémoire.
Enfin je tiens à remercier les personnes qui ont bien voulu m’accueillir et m’accorder de leur
temps afin de répondre aux questions que j’avais préparer pour traiter ce sujet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 4 / 79
2. Table des matières
1. RESUME / ABSTRACT ET REMERCIEMENTS ............................................................................. 2
1.1 RESUME....................................................................................................................................... 2
1.2 ABSTRACT .................................................................................................................................... 2
1.3 REMERCIEMENTS........................................................................................................................... 3
2. TABLE DES MATIERES............................................................................................................. 4
3. DEFINITION DU SUJET ............................................................................................................ 7
3.1 DEFINITION .................................................................................................................................. 7
3.2 QUESTIONS FONDAMENTALES ......................................................................................................... 8
4. ANALYSE DE L’EXISTANT ........................................................................................................ 8
4.1 ENVIRONNEMENT.......................................................................................................................... 9
4.1.1 QU’EST-CE QU’UN PROJET INFORMATIQUE ? .................................................................................. 9
4.1.2 LES TYPES DE MANAGEMENT...................................................................................................... 10
4.1.2.1 LE MANAGEMENT HUMAIN .................................................................................................... 10
4.1.2.2 LE MANAGEMENT TECHNIQUE ................................................................................................ 11
4.1.2.3 LE MANAGEMENT COMMERCIAL ............................................................................................. 11
4.1.2.4 LE MANAGEMENT FINANCIER.................................................................................................. 12
4.1.2.5 LE MANAGEMENT DE PRODUCTION. ........................................................................................ 12
4.1.3 LES TYPES DE CHANGEMENT....................................................................................................... 13
4.1.3.1 LES CHANGEMENTS DANS LE MANAGEMENT HUMAIN ................................................................. 13
4.1.3.2 LES CHANGEMENTS DANS LE MANAGEMENT TECHNIQUE ............................................................. 13
4.1.3.3 LES CHANGEMENTS DANS LE MANAGEMENT COMMERCIAL .......................................................... 13
4.1.3.4 LES CHANGEMENTS DANS LE MANAGEMENT FINANCIER .............................................................. 14
4.1.3.5 LES CHANGEMENTS DANS LE MANAGEMENT DE PRODUCTION ...................................................... 14
4.2 AUDIT / DIAGNOSTIC DE L’EXISTANT ............................................................................................... 14
4.2.1 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT HUMAIN................................................................. 15
4.2.1.1 LE CHEF DE PROJET ............................................................................................................... 15
4.2.1.2 LE COLLABORATEUR .............................................................................................................. 16
4.2.1.3 LES ARRETS MALADIE ............................................................................................................ 17
4.2.1.4 LES CONGES PAYES ............................................................................................................... 18
4.2.2 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT TECHNIQUE............................................................. 18
4.2.2.1 LANGAGE DE PROGRAMMATION ............................................................................................. 19
4.2.2.2 ARCHITECTURE RESEAUX........................................................................................................ 20
4.2.2.3 SYSTEME D’EXPLOITATION ..................................................................................................... 20
4.2.3 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT COMMERCIAL.......................................................... 21
4.2.3.1 MODIFICATION DE PERIMETRE................................................................................................ 21
4.2.3.2 AVENANTS AU CONTRAT ........................................................................................................ 22
4.2.4 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT FINANCIER .............................................................. 23
4.2.4.1 RESTRICTIONS BUDGETAIRES .................................................................................................. 23
4.2.4.2 DEPENSES IMPREVUES........................................................................................................... 24
4.2.4.3 REORGANISATION OU RACHAT DE LA SOCIETE............................................................................ 24
4.2.5 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT EN PRODUCTION...................................................... 25
4.2.5.1 PRODUIT FINAL NON FONCTIONNEL ......................................................................................... 26
4.2.5.2 ARCHITECTURE CLIENTE MODIFIEE ........................................................................................... 26
4.3 CRITIQUE DE L’EXISTANT ............................................................................................................... 27
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 5 / 79
4.3.1 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT HUMAIN................................................................. 27
4.3.1.1 CHEF DE PROJET ................................................................................................................... 27
4.3.1.2 COLLABORATEUR.................................................................................................................. 28
4.3.1.3 LES ARRETS MALADIE ............................................................................................................ 28
4.3.1.4 LES CONGES PAYES ............................................................................................................... 29
4.3.2 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT TECHNIQUE............................................................. 29
4.3.2.1 CHANGEMENT DE LANGAGE DE PROGRAMMATION..................................................................... 29
4.3.2.2 CHANGEMENT D’ARCHITECTURE RESEAU .................................................................................. 30
4.3.2.3 CHANGEMENT DE SYSTEME D’EXPLOITATION............................................................................. 30
4.3.3 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT COMMERCIAL.......................................................... 31
4.3.3.1 MODIFICATION DE PERIMETRE................................................................................................ 31
4.3.3.2 AVENANTS AU CONTRAT ........................................................................................................ 31
4.3.4 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT FINANCIER .............................................................. 32
4.3.4.1 RESTRICTIONS BUDGETAIRES .................................................................................................. 32
4.3.4.2 DEPENSES IMPREVUES........................................................................................................... 33
4.3.4.3 RACHAT DE LA SOCIETE.......................................................................................................... 33
4.3.5 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT EN PRODUCTION...................................................... 33
4.3.5.1 PRODUIT FINAL NON FONCTIONNEL ......................................................................................... 33
4.3.5.2 ARCHITECTURE CLIENTE MODIFIEE ........................................................................................... 34
5. METHODES ET DEMARCHES UTILISEES.................................................................................. 35
6. DESCRIPTION DES AMELIORATIONS ..................................................................................... 39
6.1 AMELIORATIONS SOUHAITABLES..................................................................................................... 39
6.1.1 LES AMELIORATIONS A APPORTER LORS D’UN CHANGEMENT DANS LE MANAGEMENT HUMAIN .............. 39
6.1.1.1 CHEF DE PROJET ................................................................................................................... 39
6.1.1.2 COLLABORATEUR.................................................................................................................. 40
6.1.1.3 LES ARRETS MALADIES ........................................................................................................... 41
6.1.1.4 LES CONGES PAYES ............................................................................................................... 42
6.1.2 LES AMELIORATIONS A APPORTER LORS D’UN CHANGEMENT DANS LE MANAGEMENT TECHNIQUE .......... 42
6.1.2.1 CHANGEMENT DE LANGAGE DE PROGRAMMATION..................................................................... 42
6.1.2.2 CHANGEMENT D’ARCHITECTURE RESEAU .................................................................................. 43
6.1.2.3 CHANGEMENT DE SYSTEME D’EXPLOITATION............................................................................. 44
6.1.3 LES AMELIORATIONS A APPORTER LORS D’UN CHANGEMENT DANS LE MANAGEMENT COMMERCIAL ....... 44
6.1.3.1 MODIFICATION DE PERIMETRE................................................................................................ 44
6.1.3.2 AVENANTS AU CONTRAT ........................................................................................................ 45
6.1.4 LES AMELIORATIONS A APPORTER LORS D’UN CHANGEMENT DANS LE MANAGEMENT FINANCIER ........... 46
6.1.4.1 RESTRICTIONS BUDGETAIRES .................................................................................................. 46
6.1.4.2 DEPENSES IMPREVUES........................................................................................................... 47
6.1.4.3 RACHAT DE LA SOCIETE.......................................................................................................... 47
6.1.5 LES AMELIORATIONS A APPORTER LORS D’UN CHANGEMENT DANS LE MANAGEMENT DE PRODUCTION ... 47
6.1.5.1 PRODUIT FINAL NON FONCTIONNEL ......................................................................................... 48
6.1.5.2 ARCHITECTURE CLIENTE MODIFIEE ........................................................................................... 48
6.2 SOLUTIONS POSSIBLES .................................................................................................................. 49
6.2.1 LES SOLUTIONS POSSIBLES POUR AMELIORER LA GESTION DE PROJET ................................................. 49
6.2.1.1 LA DOCUMENTATION ............................................................................................................ 49
6.2.1.2 UTILISATION DE LA DOCUMENTATION ...................................................................................... 50
6.2.1.3 GESTION ET STOCKAGE DE LA DOCUMENTATION ........................................................................ 50
6.2.1.4 LES DIFFERENTES REUNIONS ................................................................................................... 51
6.2.1.5 LA COMMUNICATION PAR MESSAGERIE .................................................................................... 52
6.2.2 LES SOLUTIONS POSSIBLES LORS D’UN CHANGEMENT DANS LE MANAGEMENT HUMAIN ........................ 52
6.2.2.1 COMPOSITION DE L’EQUIPE PROJET ......................................................................................... 53
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 6 / 79
6.2.2.2 LA PLANIFICATION ................................................................................................................ 54
6.2.3 LES SOLUTIONS POSSIBLES LORS D’UN CHANGEMENT DANS LE MANAGEMENT TECHNIQUE .................... 55
6.2.4 LES SOLUTIONS POSSIBLES LORS D’UN CHANGEMENT DANS LE MANAGEMENT COMMERCIAL ................. 56
6.2.5 LES SOLUTIONS POSSIBLES LORS D’UN CHANGEMENT DANS LE MANAGEMENT FINANCIER ..................... 57
6.2.6 LES SOLUTIONS POSSIBLES LORS D’UN CHANGEMENT DANS LE MANAGEMENT DE PRODUCTION ............. 57
6.3 CHOIX DES SOLUTIONS D’AMELIORATION ......................................................................................... 58
6.3.1 LA GESTION DE PROJET.............................................................................................................. 59
6.3.2 LE MANAGEMENT HUMAIN ........................................................................................................ 59
6.3.3 LE MANAGEMENT TECHNIQUE.................................................................................................... 60
6.3.4 LE MANAGEMENT COMMERCIAL ................................................................................................. 60
6.3.5 LE MANAGEMENT FINANCIER ..................................................................................................... 61
6.3.6 LE MANAGEMENT DE PRODUCTION ............................................................................................. 61
6.4 ARGUMENTATION ET JUSTIFICATION DU CHOIX ................................................................................. 61
6.4.1 LA GESTION DE PROJET.............................................................................................................. 62
6.4.2 LE MANAGEMENT HUMAIN ........................................................................................................ 63
6.4.3 LE MANAGEMENT TECHNIQUE.................................................................................................... 64
6.4.4 LE MANAGEMENT COMMERCIAL ................................................................................................. 64
6.4.5 LE MANAGEMENT FINANCIER ..................................................................................................... 64
6.4.6 LE MANAGEMENT DE PRODUCTION ............................................................................................. 65
6.5 DESCRIPTION DETAILLEE DE LA SOLUTION CHOISIE ............................................................................. 65
6.5.1 LA GESTION DE PROJET.............................................................................................................. 65
6.5.1.1 LA DOCUMENTATION ............................................................................................................ 65
6.5.1.2 UTILISATION DE LA DOCUMENTATION ...................................................................................... 66
6.5.1.3 GESTION ET STOCKAGE DE LA DOCUMENTATION ........................................................................ 67
6.5.1.4 LES DIFFERENTES REUNIONS ................................................................................................... 68
6.5.1.5 LA COMMUNICATION PAR MESSAGERIE .................................................................................... 68
6.5.1 LE MANAGEMENT HUMAIN ........................................................................................................ 69
6.5.2 LE MANAGEMENT TECHNIQUE.................................................................................................... 70
6.5.3 LE MANAGEMENT COMMERCIAL ................................................................................................. 70
6.5.4 LE MANAGEMENT FINANCIER ..................................................................................................... 71
6.5.5 LE MANAGEMENT DE PRODUCTION ............................................................................................. 71
7. PROCESSUS DE CHANGEMENT ............................................................................................. 72
7.1 DESCRIPTION DU PROCESSUS ......................................................................................................... 72
7.2 MISE EN PLACE DES AMELIORATIONS............................................................................................... 73
7.3 DIFFICULTES RENCONTREES ........................................................................................................... 73
8. SYNTHESE DES RESULTATS ET APPORT DU TRAVAIL .............................................................. 74
9. ENSEIGNEMENTS TIRES........................................................................................................ 75
10. CONCLUSIONS GENERALES ............................................................................................... 76
11. BIBLIOGRAPHIE ................................................................................................................ 77
12. WEBOGRAPHIE................................................................................................................. 77
13. TERMINOLOGIE ................................................................................................................ 77
13.1 ABREVIATIONS......................................................................................................................... 77
13.2 GLOSSAIRE.............................................................................................................................. 77
14. ANNEXES ......................................................................................................................... 78
REPONSES AU QUESTIONNAIRE ELABORE POUR LES INTERVIEWS ..................................................................... 78
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 7 / 79
3. Définition du sujet
Le sujet présenté dans ce mémoire est « Quelle est la conduite à suivre sur le management du
projet, lorsqu’un changement intervient durant un projet informatique ? ».
3.1 Définition
Le point principal de ce sujet est la conduite de changement précisé par la suite avec un certain
type de changement qui est le management, dans une situation précise, à savoir les projets
informatique.
Le management de projets informatique s’exerce dans plusieurs domaines : le côté technique
des projets, le côté commercial, financier, humain et le management au niveau de la production.
La conduite à suivre lors d’un changement de management dans un projet est différente selon le
domaine. La conduite ne sera pas la même si c’est un changement de management au niveau du
personnel ou au niveau technique ; cela ne se gère pas de la même manière. Il est donc important
dans un premier temps de comprendre et d’analyser les différents domaines de management.
De plus, dans ce mémoire il est question de proposer des solutions pour conduire au mieux le
changement de management dans un projet informatique. Pour cela il est indispensable de
s’attarder sur ce que sont des projets informatiques et comment sont gérés de tels projets.
Dans ce mémoire, il n’est pas question de s’attarder sur la conduite du changement pour mener à
bien un projet informatique mais de s’attarder plutôt sur la conduite à suivre lorsqu’un
problème apparaît durant un projet. Pour être plus précis, la conduite à suivre, avant le
commencement d’un projet informatique impactant un changement, est d’obtenir les besoins,
analyser les impacts que cela va avoir sur le système d’information de la société, faire de la
communication auprès du personnel afin que le projet soit accepté du mieux possible … Dans ce
mémoire, nous ne considérons pas toute cette partie « avant projet ». En effet, dans notre cas le
projet a déjà commencé et notre but est de trouver des solutions si un changement, prévu et plus
particulièrement si non prévu, intervient durant le déroulement du projet informatique.
Il est à noter que les conduites à suivre ne sont pas les mêmes selon le type de management ou
même le type de projet. Mais il ne faut pas oublier un point essentiel du mémoire : le
changement. En effet, il existe différents types de changement qui peuvent apparaître dans un
projet informatique comme un changement des besoins du client, un changement de
collaborateurs … Ces différents types de changement composent les types de management
existant, comme un changement de collaborateur entrera dans le cadre du management du
personnel, le changement des besoins du client rentrera dans le cadre du management
technique…
Tous ces éléments vont permettre de trouver des solutions répondant au sujet du mémoire. Il
est donc important d’apporter des solutions pour les différents types de management et
seulement selon certains types de changement et certains types de projets informatiques car ces
derniers sont beaucoup trop diversifiés pour pouvoir tous les étudier.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 8 / 79
3.2 Questions fondamentales
La question fondamentale, dans ce sujet, est « Quelle est la conduite à suivre sur le management
du projet, lorsqu’un changement intervient durant un projet informatique ?»
Cette question est vaste puisque plusieurs réponses peuvent y être apportées. Ce sont
notamment ces réponses qui seront trouvées tout au long de ce mémoire.
En effet, comme il a été expliqué dans le paragraphe de précédent, plusieurs réponses peuvent
être apportées à cette question car elle porte sur des domaines de management différents,
technique, commercial, financier … et il faut donc trouver des solutions pour chacun des
domaines.
Ainsi cinq questions se déclinent de la question fondamentale, chacune de ces questions portant
sur un domaine de management différent comme : « Quelle est la conduite à suivre sur le
management technique du projet, lorsqu’un changement intervient durant un projet
informatique ?», ou « Quelle est la conduite à suivre sur le management financier du projet,
lorsqu’un changement intervient durant un projet informatique ?» …
D’autres questions viennent également préciser la question fondamentale, avec notamment des
précisions concernant les types de changement.
Cela donne comme question : « Quelle est la conduite à suivre sur le management technique du
projet, lorsqu’un changement des besoins du client intervient durant un projet informatique ?»,
ou « Quelle est la conduite à suivre sur le management humain du projet, lorsqu’un changement
de collaborateur intervient durant un projet informatique ?»
Par conséquent, il y a plusieurs questions qui composent la question fondamentale. Chacune de
ces questions porte bien évidemment sur un domaine de management mais aussi sur un type de
management.
Les différentes questions ne sont pas toutes écrites dans ce paragraphe mais les différents types
de management et de changement seront énumérés dans le paragraphe suivant.
Il est donc à noter qu’il y a une question par type de management avec pour chacun d’eux des
questions qui se déclinent par type de changement.
Afin de mieux comprendre cette question fondamentale et de pouvoir mettre des limites au
sujet, il faut expliquer et comprendre le contexte et l’environnement tournant autour de ce sujet.
Il vous sera donc présenté dans le prochain paragraphe une analyse de l’existant dans le
domaine de la conduite à suivre sur le management d’un projet informatique lorsqu’un
changement intervient.
4. Analyse de l’existant
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 9 / 79
Après avoir bien défini le sujet et avoir bien compris les questions fondamentales qui se posent
dans ce mémoire, le travail consiste à faire l’analyse de l’existant en précisant le contexte,
l’environnement du sujet.
4.1 Environnement
A l’heure actuelle, toutes les sociétés sont dotées de l’informatique pour gérer leur système
d’information. En effet, bien que le support papier restent, dans certains cas, obligatoire, ces
derniers sont mis sous formes électroniques afin d’assurer à la société un gain de place et de
temps.
En revanche, l’informatique est en constante évolution et demande ainsi beaucoup de
modifications pour qu’une société soit constamment à jour, c’est l’innovation.
Par exemple, il faut fournir aux employés d’une société, la dernière version d’un logiciel sur leur
poste de travail afin de ne pas se retrouver avec des fichiers non lisibles dû à une version trop
vétuste, il faut également toujours veiller à ce que la sécurité informatique de la société soit
d’actualité, comme mettre à jour les anti-virus ….
Ces modifications peuvent entraîner de grands changements dans le système d’information
d’une société pouvant provoquer dans des cas extrêmes un arrêt total de la production.
Pour éviter ce type de désagrément, il est important que toutes modifications impactant le
système d’information d’une société soient traitées en mode projet permettant ainsi de mettre
en place des solutions préventives face au changement.
4.1.1 Qu’est-ce qu’un projet informatique ?
Plusieurs définitions peuvent être données au terme « Projet ». Dans ce mémoire, ce terme sera
défini selon deux organismes : l’AFNOR qui est l’association française de normalisation et
l’AFITEP qui est l’association francophone de management de projet.
La définition d’un projet selon l’AFNOR* (Norme X50 – 105 / Août 1991) est la suivante :
« Le projet est un processus unique qui consiste en un ensemble d’activités coordonnées
et maîtrisées, comportant des dates de début et de fin, entrepris dans le but d’atteindre
un objectif conforme à des exigences spécifiques, incluant des contraintes de délais, de
coûts et de ressources ».
Cette première définition montre bien, qu’un projet est un événement important au sein d’une
société puisqu’il implique des contraintes ; non seulement des contraintes de coûts mais
également de ressources.
En effet, il faut mettre à disposition du personnel afin que le projet soit mené à bien et dans les
délais. Tout ceci a bien entendu un coût pour la société.
Il est également important de coordonner un projet afin qu’il soit terminé dans les délais et qu’il
soit de plus maîtrisé afin d’éviter l’abandon du projet.
La définition d’un projet selon l’AFITEP* est la suivante :
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 10 / 79
« Le projet est un ensemble d’actions à réaliser avec des ressources données, pour
satisfaire un objectif défini, dans le cadre d’une mission précise, et pour la réalisation
desquelles on a identifié non seulement un début, mais aussi une fin ».
Cette seconde définition fait paraître un autre aspect important du terme « projet », elle montre
qu’il est essentiel de bien préparer un projet, qu’il est important de faire des plans d’actions au
commencement du projet afin que celui-ci aboutisse à ses objectifs.
Un projet est donc innovateur, puisqu’il est unique et consiste à atteindre des objectifs selon les
besoins d’un client ; ces besoins étant bien entendu innovateurs pour le client.
Ce mémoire étant tourné vers le monde de l’informatique, il est important de parler des projets
informatique.
Un projet de type informatique permet de s’assurer, dans la plupart des cas, que les
modifications faites sur le système d’information, par le biais de ce projet, ne provoqueront pas
de soucis sur les activités de la société.
Un projet a pour but d’analyser l’existant et de lister les impacts que peuvent avoir des
modifications sur le système d’information. Ainsi les projets permettent de prévenir des risques
et de trouver les solutions adéquates afin de faire les modifications sans impacts lourds pour la
société.
Mais bien que des précautions soient prises en amont du projet, durant ce dernier, le chef de
projet n’est pas à l’abri d’un changement imprévu. Le chef de projet, devant garantir le bon
déroulement du projet, doit s’assurer d’avoir des solutions pour palier aux éventuels
changements inattendus.
4.1.2 Les types de management
Selon l’encyclopédie multimédia Wikipédia, le management est « la gestion d’un groupe pour la
réalisation d’un objectif ». Cette définition se rapproche très nettement de la définition d’un
projet. Il en ressort donc que le management est au cœur des projets en général.
Le management de projets informatique s’exerce dans plusieurs domaines : le côté technique
des projets, le côté commercial, financier, humain et le management au niveau de la production.
Dans ce mémoire, ces différents domaines seront donc qualifiés comme des types de
management que nous allons expliquer.
4.1.2.1 Le management humain
Le management humain est la base de toute société. Sans ressources humaines, une société ne
peut pas exister. Pour un projet informatique, le problème est le même, sans ressources
humaines, il n’est pas possible qu’un projet prenne forme.
Comme il a été dit précédemment, le management est au cœur des projets. Le management
humain est sans doute un des éléments vital du bon déroulement d’un projet. Sans management,
il n’y a pas de coordination et pas de maîtrise. Sans coordination et sans maîtrise, il n’y a pas de
projet.
Un projet doit être coordonné au niveau humain. Le chef de projet a ainsi plusieurs éléments à
mettre en place :
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 11 / 79
• Il faut qu’il constitue son équipe projet en recrutant des personnes ayant les
compétences requises afin que le projet puisse avancer mais également en tenant
compte du budget qui a été prévu.
• Il faut qu’il prévoie des formations pour ces collaborateurs si ces derniers n’ont pas les
compétences techniques nécessaires en tenant toujours compte du budget.
• Il faut qu’il planifie son projet en tenant compte des soucis éventuels tels que les arrêts
maladies, les congés payés, les incompatibilités d’humeur entre les collaborateurs, les
démissions …
Le moindre changement au niveau du management humain pourrait avoir des conséquences
négatives sur le bon déroulement d’un projet informatique. Les solutions qui seront trouvées
tout au long de ce projet permettront de comprendre comment agir lorsque des changements
interviennent au niveau du management humain durant un projet informatique.
4.1.2.2 Le management technique
Le management technique est présent dans tous les types de projet. En effet quelque soit le type
de projet informatique qu’une société souhaite entreprendre, il y aura obligatoirement une
partie technique pour développer le projet.
Que se soit un projet de type « développement web », ou de type développement d’un progiciel
ou de type migration d’un réseau vers un autre site, il est nécessaire de prévoir dans le projet
une partie technique. Cette partie technique se traduira soit par des langages de programmation,
ou par une refonte du plan d’adressage IP d’un réseau informatique.
Il est donc important pour le chef de projet d’effectuer du management d’un point de vue
technique. C’est à dire qu’il faut que le chef de projet s’attarde sur les aspects techniques afin de
bien déterminer les compétences à mettre en œuvre pour mener à bien son projet. Il faut qu’il
définisse le plus précisément possible les points techniques faciles à mettre en œuvre et ceux qui
peuvent représenter des risques.
Le moindre changement au niveau du management technique pourrait avoir des conséquences
négatives sur un projet. Cela pourrait remettre en cause le planning et par conséquent les délais
du projet. Les solutions trouvées durant ce mémoire permettront de comprendre comment faire
face à ce type de changement.
4.1.2.3 Le management commercial
Le management commercial est un aspect très différent des types de management vus
précédemment. En effet, ce management est très important pour que le projet soit mené à bien
mais ce type de management ne touche pas forcément toute l’équipe projet, il va
particulièrement toucher le chef de projet. En effet ce dernier va avoir un rôle commercial
auprès de son client afin de vendre au mieux les différents aspects du projet.
Après avoir établi pour le client une réponse à l’appel d’offre, il y a toujours des détails
commerciaux à affiner comme par exemple les outils à utiliser qui peuvent coûter plus ou moins
cher. Mais la participation du chef de projet dans la partie commercial va surtout se traduire sur
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 12 / 79
des aspects tels que les pénalités de retard du projet, ou les ajustements des besoins client qui
vont mener à des avenants au contrat …
Cette participation du chef de projet se fera surtout durant le déroulement du projet mais pas
forcément pendant la signature du contrat, bien que cela dépend de l’organisation de la société
ayant décroché le contrat. En effet les sociétés de type TPE*, comparées aux grandes entreprises,
n’ont pas forcément les moyens d’avoir un commercial et un chef de projet. Bien souvent une
seule et même personne endosse les deux rôles.
Le moindre changement au niveau du management commercial pourrait avoir des conséquences
sur le bon déroulement du projet. Cela pourrait notamment engendrer une perte au niveau
financier et ainsi provoquer l’abandon du projet. Ce mémoire permet de présenter les solutions
pour palier à ce type de changement.
4.1.2.4 Le management financier
Le management financier d’un projet est très important. Comme tout management financier,
c’est lui qui permet de faire vivre ou non une société, des projets ...
En effet, le financement d’un projet va permettre au chef de projet de constituer son équipe, mais
également de se procurer les éléments nécessaires à la mise en œuvre du projet comme les
machines, les outils de développement, les supports pour les livrables… Sans financement un
projet ne peut pas exister.
Par conséquent il est important pour le chef de projet, de faire de la gestion des finances attribué
au projet. En effet, il n’est pas judicieux de tout dépenser dès le début du projet, ou même de
vouloir faire des économies au dépend du bon déroulement du projet.
Le moindre changement au niveau financier peut provoquer un abandon du projet dans la pire
des situations. Il faut donc mettre en place des solutions afin d’appliquer une bonne conduite
pour mieux appréhender le changement.
4.1.2.5 Le management de production.
Le management de production est le dernier type de management qui sera présenté dans ce
mémoire. Ce type de management survient durant la phase finale du projet.
En effet la production d’un projet informatique se traduit le plus souvent par la mise en place
chez le client du logiciel développé, ou par le basculement d’un site à un autre du réseau de
l’entreprise. Le management de production consiste donc à mettre en place les éléments
nécessaires afin que cette mise en production de fasse de manière transparente et sans accrocs
pour le client.
Ce management demande beaucoup de préparation mais également de tests préliminaires afin
d’éviter des interruptions totales de services chez le client pour les cas extrêmes. Le chef de
projet est donc en charge de planifier au mieux cette mise en production.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 13 / 79
Un changement intervenant durant la mise en production chez le client du projet pourrait avoir
des conséquences pour lesquelles il faut trouver et mettre en place des solutions permettant de
palier à ce type de changement.
4.1.3 Les types de changement
Comme il a été expliqué dans le paragraphe de définition du sujet (§3.1), les types de
changement composent les différents types de management vus précédemment.
Dans ce paragraphe concernant les types de changement, ces derniers seront présentés en
fonction du type de management auquel ils appartiennent.
4.1.3.1 Les changements dans le management humain
Les différents changements pouvant survenir dans le management humain sont nombreux. Ils
ne seront pas tous évoqués car la liste serait trop longue.
Ce mémoire va donc s’attarder sur des changements tels que le remplacement du chef de projet,
le départ d’un collaborateur ou plus exactement d’une personne de l’équipe projet. Il y a
également des changements tels que les congés payés ou même les arrêts maladies.
Ces changements ont automatiquement des impactes sur le projet et notamment sur le
management humain du projet.
4.1.3.2 Les changements dans le management technique
Dans le management technique plusieurs changements sont connus, ces changements sont bien
souvent à l’origine de dépassement de délai dans un projet informatique.
Ces conséquences négatives, qui peuvent entraîner des pénalités financières voire l’abandon du
projet, sont souvent provoquées par des changements technologiques tels que des changements
de langage de programmation, de système d’exploitation, d’opérateur ou d’architecture dans le
cas de projets basés sur le réseau.
4.1.3.3 Les changements dans le management commercial
Les changements dans le management commercial sont différents des changements présents
dans les autres types de management.
En effet, se sont souvent les changements dans les autres types de management qui vont
provoquer des changements au niveau commercial.
En effet un problème côté humain, technique ou même financier peut causer un retard sur les
délais fixés et ainsi forcer le chef de projet à justifier son retard auprès du client, pouvant aller
jusqu’à un geste commercial de la part de la société en charge du projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 14 / 79
4.1.3.4 Les changements dans le management financier
Les changements dans le management financier sont nombreux et surtout diversifiés. Les
changements qui seront étudiés dans ce mémoire seront les changements tels que les
restrictions budgétaires ne permettant plus, par exemple, d’utiliser les outils les plus
performants.
Il y a également les changements tels que les formations qui peuvent survenir durant le projet
dû à un manque de compétence, voire à un changement des besoins client pour lesquels l’équipe
en charge du projet n’a pas les compétences. Il peut aussi y avoir, mais plus rarement, des
changements tels que le rachat de la société, soit cliente, soit en charge du projet.
4.1.3.5 Les changements dans le management de production
Les changements dans le management de production est souvent dû à un problème dans la
gestion du projet.
En effet, les changements qui seront abordés dans ce mémoire sont des changements comme le
produit final qui est non fonctionnel dans l’environnement client. Un changement de matériel
chez le client qui peut, dans le cas d’un projet de supervision et d’exploitation d’un réseau,
empêcher le bon fonctionnement de la supervision et par conséquence provoquer une mauvaise
exploitation.
Dans ce mémoire, afin de mieux comprendre la conduite à suivre si un changement
intervient lors d’un projet informatique, il va falloir trouver les solutions les mieux adaptées
pour palier à ces changements inattendus et surtout imprévisibles.
Pour trouver ces solutions, il faut, dans un premier temps, faire un audit de l’existant et des
solutions actuellement mises en place pour palier aux changements. L’existant sera étoffé par
des exemples pris sur deux types de projets, le premier projet consiste à mettre en place une
application permettant au client de gérer et unifier la documentation utilisée au sein de sa
société. Le second projet sera un projet d’intégration de système de la société cliente dans la
société en charge du projet avec de la supervision et de l’exploitation.
4.2 Audit / Diagnostic de l’existant
Comme il a été précisé dans le paragraphe précédent, les solutions trouvées au long de ce
mémoire vont être basées sur des exemples tirés de deux projets. Afin de trouver ces solutions
nouvelles, il est important de faire un audit de l’existant.
Cet audit va permettre de comprendre quelle conduite suive les sociétés lorsque des
changements interviennent durant des projets de type informatique.
Pour cela, il sera détaillé ci-après les différentes conduites qui ont été mises en œuvre pour
chacun des changements cités dans les paragraphes précédents.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 15 / 79
4.2.1 La conduite suivie lors d’un changement humain
Après avoir effectué des recherches sur les conduites qui sont actuellement suivies lors d’un
changement humain durant un projet informatique, le constat est que les conduites sont très
variées. Les conduites suivies lors de changement humain vont être exposés dans ce paragraphe
selon quatre cas.
4.2.1.1 Le chef de projet
Le premier cas exposé est celui du changement de chef de projet. Il est important de rappeler
que le chef de projet est la personne qui permet de gérer le projet de bout en bout.
Le chef de projet a la mission de planifier le projet, d’en comprendre et d’en recueillir les
besoins, de faire des réunions de pilotage avec l’équipe projet mais également avec le client…
Ces points sont importants car ils permettent de mieux comprendre la conduite à suivre lors
d’un changement de chef de projet.
Différentes actions sont actuellement menées lorsqu’un changement de ce type intervient
durant un projet informatique.
Dans un premier temps, le ou les responsables du chef de projet actuellement en poste font une
recherche afin de trouver un nouveau chef de projet. Cela consiste bien entendu à effectuer une
fiche de poste décrivant ces fonctions.
Les recherches se font soient en interne, soient en ouverture de poste sur le marché du travail,
soient en faisant appel à une société de prestations.
Suite aux entretiens effectués pour ce poste, le nouveau chef de projet doit répondre à plusieurs
conditions dont la plus important est d’être disponible immédiatement, puis connaître les
technologies utilisées dans le projet en cours.
Une fois, le nouveau chef de projet trouvé, une réunion est organisée entre les deux chefs de
projet, le prédécesseur et le successeur.
Cette réunion a pour but d’effectuer un transfert de compétences sur le projet en question. Cette
réunion n’a pas pour but de faire un transfert de compétences technique mais bien un transfert
de compétences sur la partie gestion de projet, à savoir les besoins exprimés par le client, les
technologies utilisées, l’avancement du projet, le planning prévu, l’équipe projet mis à
disposition…
Cette réunion est organisée le plus rapidement possible afin de libérer au plus vite le chef de
projet sortant.
Suite à ce transfert de compétences, le chef de projet sortant organise une réunion interne avec
l’équipe projet afin de présenter le nouveau chef de projet. Cette réunion permet également de
rendre compte de l’avancement du projet en laissant notamment le nouveau chef de projet
prendre en main la réunion de travail.
Le dernier point que les chefs de projet doivent effectuer ensemble avant d’effectuer le
changement de poste est d’organiser une réunion avec le client afin de lui présenter son nouvel
interlocuteur.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 16 / 79
Cette réunion se fait avec les deux interlocuteurs et comporte dans la plupart des cas deux
points, le premier consiste à présenter le nouveau chef de projet et le second consiste à faire une
réunion de pilotage afin de présenter au client l’état d’avancement du projet.
A la fin de cette réunion le transfert entre les deux chefs de projet est alors effectué laissant ainsi
le chef de projet sortant libre.
Cette conduite est valable dans le seul cas où le chef de projet sortant est disponible. En effet, il
peut y avoir d’autres situations qui pourraient rendre indisponible le chef de projet sortant
comme dans les cas extrêmes le décès de ce dernier.
Dans ce cas, la marche à suivre sera légèrement différente. En effet, toutes les actions faites en
coopération avec les deux chefs de projet n’ont plus lieu d’être ou doivent être plus ou moins
modifiées.
La première action, celle de trouver un nouveau chef de projet, ne change pas. Une fois le
remplaçant trouvé, la réunion de transfert de compétence se fait non pas entre les deux chefs de
projet mais entre le remplaçant et son responsable, en compagnie d’un membre de l’équipe
projet. Ensuite, le nouveau chef de projet est présenté à l’équipe par le responsable.
En dernier lieu, une réunion de pilotage est organisée avec le client pendant laquelle le nouveau
chef de projet se présente et donne un état d’avancement du projet.
4.2.1.2 Le collaborateur
Ce cas de changement concerne le changement d’un collaborateur. Le terme de collaborateur
désigne un membre de l’équipe projet, c’est à dire une personne sous la responsabilité du chef
de projet.
Un membre de l’équipe projet est un technicien dont les compétences sont en concordance avec
les technologies utilisées dans le projet.
Il est important de comprendre que le collaborateur ne pourra partir que lorsque son
remplaçant sera en place au sein de l’équipe projet sauf dans le cas où le changement est dû à un
décès ou tout autre événement empêchant une relation entre les deux collaborateurs, le
prédécesseur et le successeur.
Dans ce paragraphe vont être présentés les différentes actions qui sont menés lorsqu’un
changement de collaborateur intervient durant un projet informatique.
Dans un premier temps, le chef de projet est en charge de trouver un nouveau collaborateur afin
de remplacer le collaborateur sortant.
Tout comme dans le paragraphe précédent, la recherche du nouveau collaborateur se fait dans
un premier temps en effectuant une fiche de poste, puis en recherchant les différents profils
soient en interne, soient sur le marché du travail, soient par le biais d’une société de prestation.
Une fois le nouveau collaborateur trouvé, ce dernier est présenté à l’équipe projet. Puis un
transfert de compétence est organisé entre le collaborateur sortant et le remplaçant. Ce transfert
de compétence a un impact sur le planning du projet.
En effet, il faut que le collaborateur sortant présente au nouveau collaborateur les différents
modules du projet qui ont été développés mais également les modules restant.
Pendant cette présentation, le développement dont le collaborateur sortant est en charge
n’avance pas.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 17 / 79
Ce dernier point oblige le chef de projet à refaire une planification sur l’avancement du projet. Le
chef de projet estime le temps de transfert de compétence puis planifie les modules de ce
dernier en fonction du temps passé sur le transfert de compétence. Si le temps de transfert de
compétence estimé est de deux jours, le projet est également décalé de deux jours.
Si le temps de transfert de compétence met en péril les délais de réalisation annoncés au client,
le chef de projet fait une planification mettant en évidence le retard.
Par la suite, le chef de projet organise une réunion de pilotage avec le client afin de lui présenter
les différents changements, à savoir l’état d’avancement du projet, comme les modules
développés par les collaborateurs « non changeant », puis la replanification des modules du
nouveau collaborateur impliquant donc une replanification du projet.
Comme il a été précisé dans l’introduction de ce paragraphe, le changement de collaborateur
peut être dû au décès ou tout autre événement empêchant un transfert de compétence entre les
deux collaborateurs.
Dans ce cas, le transfert de compétence sera fait par le chef de projet en lui présentant le projet
et les modules restants.
4.2.1.3 Les arrêts maladie
Les arrêts maladies sont des évènements imprévisibles quelque soit le domaine ou le métier
dans lesquels ils apparaissent.
Dans le cas d’un projet informatique, ce type de changement se gère de trois manières
différentes, selon des courtes, moyennes ou longues durées.
Les courtes durées sont définies comme allant de un à deux jours maximum. Les arrêts de
moyenne durée n’excèdent pas une semaine, c’est à dire cinq jours ouvrés. Les arrêts de longue
durée sont des arrêts dépassant cinq jours ouvrés.
Selon les durées d’arrêts maladie qui sont déposés par les collaborateurs, les conduites à suivre
sont différentes et c’est ce qui va être décrit dans ce paragraphe.
Dans le cas d’un arrêt de courte durée, le chef fait un changement sur le planning du projet. Il
décale la durée du projet et plus précisément du module dont le collaborateur malade est en
charge de la durée de l’arrêt maladie. Par exemple, si l’arrêt maladie est de deux jours, le chef de
projet allonge de deux jours le module et décale ainsi toutes les phases du projet dépendantes du
module.
Dans le cas d’un arrêt de moyenne durée, et afin de ne pas mettre en péril les délais du projet, le
chef de projet décide de faire une distribution du travail en cours du collaborateur malade. Il
distribue ainsi les tâches de ce collaborateur vers les autres collaborateurs, seulement si le
travail en cours a des conséquences sur les délais s’il n’est pas effectué en temps et en heure.
Dans le cas d’un arrêt maladie de longue durée, le chef de projet décide de prendre un nouveau
collaborateur dans l’équipe en attendant le retour du collaborateur « titulaire ». Dans ce cas, il
faut se référer au paragraphe précédent dans lequel il est expliqué la conduite à suivre lorsqu’il y
a un changement de collaborateur.
Dans le cas où l’arrêt maladie concerne le chef de projet, les actions prises sont sensiblement les
mêmes.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 18 / 79
Lorsqu’il s’agit d’un arrêt maladie de courte durée, il n’y a pas de remplacement de prévu,
sachant qu’un arrêt de courte durée dure au maximum deux jours, il n’est pas nécessaire de
prévoir de remplaçant. Dans le cas où durant ces deux jours il y a un souci majeur sur le projet,
c’est le responsable du chef de projet qui gère les soucis.
Il en va de même pour les arrêts de moyenne durée. En effet, le projet est alors dirigé par le
responsable du chef de projet ou par un suppléant, membre de l’équipe projet, désigné soit par
le chef de projet, soit par son responsable.
Dans le cas d’un arrêt de longue durée, le responsable du chef de projet fait une recherche d’un
remplaçant. Pour cette démarche, il faut se reporter au paragraphe intitulé « Chef de projet »
dans lequel est expliquée la démarche à suivre lors d’un changement inattendu de chef de projet.
4.2.1.4 Les congés payés
Contrairement aux arrêts maladie, les congés payés sont des évènements prévisibles à plus ou
moins long terme. Il convient, par la suite au chef de projet, de planifier les congés payés de ces
collaborateur afin de faire une planification correcte du projet dès son commencement.
Pour cela, plusieurs conduites sont à suivre selon que le projet est un projet à longue durée ou à
courte durée. Il est entendu par « projet à longue durée », un projet dont la planification dépasse
six mois.
Dans ce cas précis, le chef de projet est en charge de demander à tous ces collaborateurs de
poser leurs congés au début du projet afin que le chef de projet puisse planifier les différentes
phases du projet en fonction des congés de chacun de ces collaborateurs.
Si la planification du projet passe sur l’année suivante, le chef de projet demande alors à ces
collaborateurs de lui donner les futurs congés que ces derniers souhaitent poser.
En ce qui concerne les projets dit « de courte durée », les collaborateurs doivent poser leurs
congés pour la période totale du projet. Tout autre congé posé durant le projet pourront être
refusé pour raison de service sauf cas exceptionnel.
4.2.2 La conduite suivie lors d’un changement technique
Dans cette partie, l’audit va s’appuyer sur des exemples basés sur les deux projets cités en
conclusion du paragraphe sur l’environnement (§4.1).
Pour rappel, les deux projets utilisés comme exemple sont, pour le premier, le développement
d’une application permettant de gérer et d’unifier la documentation au sein d’une société, pour
le second projet, il s’agit d’intégrer les équipements du réseau client sur les consoles de
supervision afin d’en assurer la surveillance et l’exploitation.
Les changements techniques durant un projet informatique peuvent être nombreux et très
variés. Dans ce paragraphe, les différentes conduites à suivre, suivant le changement, vont être
exposées. Les changements étudiés seront au nombre de trois.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 19 / 79
4.2.2.1 Langage de programmation
Les langages de programmation sont des spécialités dans l’informatique. Il y a en effet des
techniciens spécialisés dans un type de langage.
Dans ce paragraphe, il est détaillé la conduite à suivre lorsque durant le projet, il y a un
changement sur le langage de programmation.
Ce type de changement est souvent dû à un changement des besoins du client. Si nous prenons
l’exemple de l’application de gestion de documentation, au commencement du projet le client
souhaité un logiciel à installer sur chaque poste, par la suite il décide que l’application sera une
application de type web accessible par chaque employé à partir de l’intranet.
Cela implique bien entendu un changement de langage de programmation, car une application
web ne se développe pas dans le même langage qu’un logiciel.
Plusieurs actions sont mises en œuvre afin de faire face à ce type de changement.
Dans un premier temps et avant toutes actions des collaborateurs, le chef de projet fait une
analyse du travail déjà effectué et plus particulièrement du temps déjà consacré sur le projet
depuis son commencement.
Suite à cette analyse, le chef de projet organise une réunion de travail avec l’équipe projet afin de
connaître les enjeux et surtout les conséquences d’un tel changement.
Suite aux indications que donneront chacun des collaborateurs sur les conséquences d’un tel
changement, le chef de projet va estimer les conséquences au niveau financier afin de pouvoir
négocier avec le client, il va refaire une planification en incluant les changements.
Il va monter un dossier à présenter à ses responsables mais surtout au client afin de montrer les
conséquences d’un tel changement.
En parallèle, il va faire un état des compétences présentes dans son équipe projet sur le nouveau
langage de programmation. Cet état sera fait durant la réunion de travail.
En fonction de cet état, si tous les collaborateurs sont compétents dans le nouveau langage de
programmation alors aucune action n’est à prévoir.
Par contre si seulement une partie des collaborateurs a les compétences et l’autre partie a
seulement des notions, le chef de projet doit planifier des formations pour ces collaborateurs. Il
doit alors faire un devis sur le prix que vont lui coûter ces formations et mettre à jour le planning
du projet en tenant compte de ces formations.
Dans le cas où des collaborateurs n’ont aucune notion sur le langage de programmation
demandé, le chef de projet doit alors faire des recherches pour des nouveaux collaborateurs. La
démarche à suivre est celle présentée dans le paragraphe concernant le changement de
collaborateur (§ 4.2.1.2)
Dans la plupart des cas, un changement de ce type implique de faire un départ à zéro du projet
avec le recueil des besoins, la recherche de collaborateurs si nécessaire….
Après toute cette analyse, le chef de projet organise une réunion de pilotage avec le client afin de
lui présenter le dossier montrant les conséquences d’un changement de langage sur le projet, les
coûts financiers que cela implique, ainsi que le délai supplémentaire que cela va prendre.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 20 / 79
4.2.2.2 Architecture réseaux
L’architecture réseau est au cœur des toutes entreprises. Elle est souvent complexe et demande
beaucoup de travail. Beaucoup de société veulent se décharger de cette tâche fastidieuse qui est
l’exploitation du réseau de leur société. Pour cela ils font appel à des sociétés spécialisées dans la
supervision et l’exploitation des systèmes et réseaux. Ceci fait donc référence au second projet
qui est utilisé comme exemple dans ce mémoire.
Dans ce paragraphe est détaillée la conduite à suivre lorsqu’un changement sur l’architecture
réseau intervient durant un projet.
Il peut y avoir des changements de ce type dans deux cas, soit un changement côté chef de
projet, soit un changement côté client.
Si le changement est côté chef de projet, ce dernier fait partie d’une société qui elle aussi à une
architecture réseau qui peut être amenée à évoluer.
Si tel est le cas, alors cela peut avoir des impacts notamment sur des projets en cours.
Pour cela, il est important de faire un dossier montrant les changements qui seront effectués et
les impactes techniques que cela peut avoir sur le projet en cours.
Pour monter le dossier, le chef de projet organise une réunion de travail afin de voir avec ces
collaborateurs quelles sont les conséquences que cela peut entraîner pour le client.
Dans ce cas précis, cela n’aura pas d’impact financier pour le client car il ne s’agit pas de son
architecture, par contre cela peut avoir des conséquences techniques comme l’ajout d’adresses
de routage dans son plan d’adressage interne. Il peut également y avoir des changements au
niveau des délais de réalisation du projet.
Une fois le dossier monté, le chef de projet organise une réunion de pilotage avec le client afin de
lui présenter le changement et les conséquences qui en découlent.
Si le changement est côté client, cela a également des impacts sur le projet en cours. Pour cela, le
chef de projet organise une réunion de pilotage avec le client afin de connaître les impacts
techniques de ce changement.
Suite à cette réunion, le chef de projet organise une réunion de travail avec l’équipe projet afin
de présenter les changements d’architecture cliente, faire un point sur les changements que cela
implique au niveau du projet et trouver les solutions pour faire face à ce changement.
Le chef de projet monte alors un dossier afin de présenter les changements que les changements
d’architecture cliente impliquent, les coûts financier à prévoir et refait une planification en
fonction de ces informations. Il organise par la suite une autre réunion avec le client afin de lui
présenter le dossier et les solutions trouvées.
4.2.2.3 Système d’exploitation
Les systèmes d’exploitation sont comme l’architecture réseau, un point essentiel de
l’informatique dans une société. Dès que des modifications sont faites sur un de ces deux
éléments fondamentaux cela peut avoir des impacts négatifs sur une société.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 21 / 79
Un changement de système d’exploitation peut avoir un impact sur le développement d’un
logiciel. Pour illustré ce paragraphe, l’exemple de l’application permettant de gérer la
documentation d’une société sera utilisé.
En effet dans le cas où cette application est un logiciel, il faut s’assurer que ce dernier soit
utilisable et/ou reconnu sous un nouveau système d’exploitation.
Dans ce paragraphe est détaillée la conduite à suivre lorsqu’un changement de système
d’exploitation intervient durant un projet.
Dans un premier temps, le chef de projet organise une réunion de travail avec ces collaborateurs
afin de faire un état des compétences de chacun sur le système d’exploitation que le client met
en place.
En fonction de cet état, si tous les collaborateurs sont compétents dans le nouveau système
d’exploitation alors aucune action n’est à prévoir.
Par contre si seulement une partie des collaborateurs a les compétences et l’autre partie a
seulement des notions, le chef de projet doit planifier des formations pour ces collaborateurs. Il
doit alors faire un devis sur le prix que vont lui coûter ces formations et mettre à jour le planning
du projet en tenant compte de ces formations.
Dans un second temps, le chef de projet doit commander le matériel nécessaire ainsi que le
système d’exploitation utilisé par le client afin que ces collaborateurs puissent développer le
projet sur le bon environnement. Le chef de projet doit pour cela faire un devis pour le matériel.
Par la suite, le chef de projet monte un dossier récapitulant les impacts qu’un tel changement a
sur le projet, comme les impacts financiers (achat de matériel, formations …), les impacts
techniques et les solutions apportées, les impacts concernant les délais.
4.2.3 La conduite suivie lors d’un changement commercial
Le domaine commercial est un domaine très important dans une société, sans ce domaine il n’y a
pas de contrat négocié et/ou décroché, soit pas de projets à traiter.
Lorsqu’un changement de type commercial survient durant un projet informatique cela peut
entraîner des évènements pouvant perturber le bon déroulement du projet comme les retards
sur les délais, ou les changements sur des aspects techniques…
Dans ce paragraphe, il sera détaillé quelles sont les conduites qui sont actuellement suivies
lorsque de tels changements surviennent, comme des changements de périmètre ou des
avenants au contrat.
4.2.3.1 Modification de périmètre
Le domaine commercial est un domaine important durant la phase projet. En effet, le
commercial est, avec le chef de projet, un point d’entrée pour le client. Autrement dit, le client a
uniquement deux contacts durant le projet, le commercial avec lequel il peut discuter des
aspects contractuels du projet, et le chef de projet pour les aspects techniques et fonctionnels.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 22 / 79
Lorsque le client décide de modifier le périmètre qui a été défini lors de la signature du contrat,
il en avise le commercial afin d’établir les éléments nécessaires pour que le changement de
périmètre soit pris en compte dans le contrat.
Le commercial doit alors prévenir le chef de projet qu’un changement de périmètre a été signé
avec le client et qu’il faut le prendre en compte. Le commercial doit également fournir au chef de
projet le nouveau périmètre afin que ce dernier puisse faire un point sur les nouveautés et/ou
les changements apportés au contrat.
Une fois que les informations de changement de périmètre sont parvenues jusqu’au chef de
projet, ce dernier doit dans un premier temps faire un état des modifications qui découlent du
changement de périmètre.
Dans un second temps, il doit établir une estimation de la charge de travail qu’apporte ce
changement de périmètre. Une fois cette estimation faite, le chef de projet doit faire une
planification et voir si ce changement de périmètre apporte des modifications dans les délais
comme du retard ou de l’avance.
Si le changement de périmètre implique un retard sur les délais prévus pour le projet, le chef de
projet doit alors en informer le client en lui demandant une réunion de pilotage de projet dont
l’ordre du jour concernera le changement de périmètre.
Lors de cette réunion de pilotage, le chef de projet doit, premièrement, valider le nouveau
périmètre avec le chef de projet et deuxièmement annoncer au client les nouveaux délais qui ont
été calculés en fonction du changement de périmètre.
Une fois cette réunion terminée, le chef de projet doit organiser une réunion de travail avec ces
collaborateurs afin de les prévenir du changement de périmètre mais également des nouvelles
tâches qu’ils aient à effectuer pour prendre en compte ce nouveau périmètre.
4.2.3.2 Avenants au contrat
Les avenants au contrat sont des documents officiels permettant de mettre à jour le contrat
signé initialement entre les deux parties. Ces avenants peuvent être établis à la suite de
demandes faites par le client, comme un changement de périmètre, ou à la suite d’offre
commerciales faites par le commercial afin de proposer au client d’autres services, comme
proposer de la maintenance ou de l’infogérance en fonction des projets.
Les conduites à suivre lorsqu’il y a des avenants au contrat qui sont signés sont sensiblement
identiques à la conduite suivie lors d’un changement de périmètre.
La différence entre ce paragraphe et le précédent est la chronologie des évènements. En effet
dans le paragraphe précédent, lors du changement de périmètre, les actions se situaient pendant
le déroulement du projet. Dans le cas de ce paragraphe, les avenants au contrat sont signés une
fois que le projet est terminé.
Le commercial annonce alors au chef de projet qu’un avenant au contrat a été établi et il
demande à ce que cet avenant soit traité en mode « projet ».
Par conséquent, un chef de projet est nommé, soit la personne qui été en charge du projet
initialement, soit une nouvelle personne.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 23 / 79
Le chef de projet doit par la suite faire la gestion du projet.
Dans un premier temps, le chef de projet constitue son équipe en fonction des compétences
requises pour le projet.
Dans un second temps, le chef de projet planifie le projet en fonction de la charge de travail et
des différents congés payés déposés par les membres de l’équipe projet à la demande du chef de
projet.
Par la suite, et en parallèle du déroulement du projet, le chef de projet doit établir la
documentation nécessaire à la gestion de projet, organiser des réunions de pilotage et de travail
avec le client et les collaborateurs jusqu’à la fin du projet et la mise en production de ce dernier.
4.2.4 La conduite suivie lors d’un changement financier
Le domaine financier est un domaine qui touche tous les métiers. Dans les projets informatiques,
le domaine financier permet tout simplement de les faire exister et perdurer. Lorsqu’un
changement de type financier survient durant un projet informatique cela peut entraîner dans
des cas extrêmes l’abandon de ce dernier. Dans ce paragraphe, il sera détaillé quelles sont les
conduites qui sont actuellement suivies lorsque de tels changements surviennent. Trois
changements seront mis en avant dans ce paragraphe.
4.2.4.1 Restrictions budgétaires
Les restrictions budgétaires sont des changements qui sont amenés par les responsables des
sociétés et pour lesquels le chef de projet n’a aucun contrôle.
Dès qu’il y a des restrictions budgétaires, le chef de projet est en charge de trouver les moyens
de réduire les coûts pour ces projets en cours. Ces réductions peuvent aussi bien se faire au
niveau matériel qu’au niveau personnel.
Comment un chef de projet gère donc ce type de changement lorsqu’il survient durant un projet
informatique ?
Dans un premier temps, il fait une analyse des différentes parties de son projet, comme l’équipe
projet, l’avancement du projet, les dépenses qu’il reste à faire…
A partir de cette analyse, le chef de projet doit mettre en place des actions permettant de réduire
les dépenses.
Dans l’exemple du développement d’une application, l’équipe projet doit développer différents
modules qui une fois rassemblé forme l’application définitive. Avec cette situation de
restrictions budgétaires, le chef de projet décide que les développeurs ayant terminé leur
module sont remercié et mis en attente d’un nouveau projet, ceci permet donc de faire des
économies au niveau des charges du personnel avec entre autres des personnes en moins pour
l’équipe projet.
En effet, il est important de rappeler que lors de la signature du contrat entre le client et le
commercial, ce dernier a compté dans sa proposition un certain nombre de participants au
projet (nombre de personne qui n’est pas forcément dévoilé au client).
Donc si le commercial a prévu dix personnes pour le projet et qu’il n’y en a plus que sept
maintenant, cela fait donc faire des économies de budget au chef de projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 24 / 79
Dans un second temps, le chef de projet peut organiser une réunion de pilotage avec le client afin
de lui faire des propositions d’améliorations sur le projet.
Afin de préparer cette réunion, le chef de projet doit au préalable organiser une réunion de
travail avec ces collaborateurs afin de trouver des solutions moins coûteuses pour le projet. A la
suite de cette réunion, le chef de projet monte un dossier, qu’il présentera au client lors de la
réunion de pilotage.
Ces modifications vont surtout porter sur le changement de spécifications fonctionnelles, c’est à
dire, non pas la manière dont va être développé l’application qui sont des spécifications
techniques, mais plutôt la manière dont l’application fonctionnera d’un point de vue utilisateur
final.
En effet, moins de pages sont développées moins l’application coûte en terme de temps et de
ressources. Cela entraîne ainsi des économies budgétaires.
4.2.4.2 Dépenses imprévues
Les dépenses imprévues découlent la plupart du temps des changements qui interviennent dans
les autres domaines, comme les changements de type humain, financier, technique …
En effet, lorsqu’il y a un changement de collaborateur ou de chef de projet, cela coûte
financièrement à la société, puisqu’il faut entreprendre des recherches, faire passer de
entretiens, faire des transferts de compétences… Pour cela, il faut du temps et des ressources,
autrement dit de l’argent.
Selon les changements, ces derniers peuvent être causés soient par le client, comme les
changements techniques, soient par l’équipe projet comme les changements humains.
Dans tous les cas, le chef de projet doit faire une analyse des dépenses engendrées par ces
changements afin de trouver des solutions pour éviter ces changements.
Les solutions ne peuvent pas toujours éviter les dépenses, dans ce cas il est important que le chef
de projet trouve la solution la moins coûteuse ou du moins la plus rentable.
Si, par exemple, il y a un changement technique, deux solutions sont possibles. La
première solution est d’organiser une formation pour les collaborateurs, la seconde
solution est de changer de collaborateur. Le chef de projet est alors en charge de trouver
la solution la moins coûteuse, mais la plus rentable.
Si c’est dépenses sont inévitables, le chef de projet doit monter un dossier présentant tous les
arguments nécessaires afin d’obtenir le budget pour assurer ces dépenses imprévues.
4.2.4.3 Réorganisation ou rachat de la société
Le changement qui va être présenté est un changement très rare, il s’agit d’un rachat ou d’une
réorganisation de la société (cliente ou non).
Dans le cas où la société qui est racheté ou qui subit une réorganisation est la société cliente, cela
amène dans la majeure partie des cas à l’abandon du projet.
Dans l’autre cas, à savoir la société subissant le changement est la société qui est en charge du
projet, est un cas bien souvent plus favorable au maintient du projet car pour la société qui
achète, cela fait un client et une rentrée d’argent en plus.
Dans ce paragraphe, il sera détaillé dans les deux cas, les conduites à suivre lors de tels
changements.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 25 / 79
Le premier cas est celui de la société cliente qui subit le changement mais dont le projet qu’elle a
demandé à réaliser est maintenu.
Dans ce cas, le chef de projet doit impérativement et dans des délais très courts, organiser une
réunion avec le client afin de connaître les conséquences d’un tel changement, à savoir en
particulier s’il y aura des modifications au niveau des besoins, si l’interlocuteur côté client sera
toujours le même …
De plus, lors de cette réunion, le chef de projet doit s’attendre à être mis en contact avec de
nouvelles personnes de la société cliente où il sera certainement amené à présenter
l’avancement du projet. Il faut bien entendu que le chef de projet ait préparé sa réunion en
effectuant au préalable une réunion de travail avec ces collaborateurs afin de se tenir informé de
l’avancement du projet.
Le second cas est celui où la société en charge du projet client est rachetée ou subit une
réorganisation et que bien entendu, le projet est maintenu. Le rachat ou la réorganisation de
société entraîne bien souvent des changements humains ce qui peut troubler l’avancement d’un
projet.
Dans ce cas, le chef de projet à plusieurs actions à faire pour faire face à un tel changement.
Dans un premier temps, le chef de projet doit organiser une réunion avec son responsable afin
de se renseigner sur les conséquences que ce changement peut avoir sur le projet, en termes de
budget mais aussi et surtout en termes de ressources humaines. Le chef de projet doit-il
s’attendre à des restrictions de budget, à des changements de ressources …. ?
Dans un second temps, et si sa place en tant que chef de projet est maintenue, le chef de projet
doit préparer un dossier de présentation du projet pour sa direction, dans le cas où cette
dernière souhaiterait avoir des informations sur ce projet.
Ce dossier doit comporter tous les éléments nécessaires au projet, en allant du cahier des
charges, en passant par la composition de l’équipe projet, le planning, les comptes rendus de
réunion ….
Une fois que le chef de projet à toutes les informations nécessaires concernant le projet et son
avancement, le chef de projet doit organiser une réunion de pilotage avec le client afin dans un
premier temps de le rassurer sur le devenir de son projet, puis afin de lui présenter les éventuels
changements concernant le projet, comme le changement de chef de projet par exemple.
En parallèle, avant ou après la réunion cliente, le chef de projet doit également organiser une
réunion interne avec ses collaborateurs afin de les prévenir des changements éventuels dû au
changement de direction.
4.2.5 La conduite suivie lors d’un changement en production
La production est la partie ultime d’un projet puisque la phase de mise en production met, en
quelque sorte, fin au projet. Bien que cette phase annonce le terme du projet, le chef de projet a
tout de même des actions à faire afin de s’assurer que le produit final ou que la mise en
production se passe sans difficulté.
Dans ce paragraphe, deux changements durant la mise en production seront présentés avec le
détail des conduites à suivre pour chacun des changements.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 26 / 79
4.2.5.1 Produit final non fonctionnel
Le premier changement, durant la production, qui est présenté dans ce mémoire concerne le
produit final et plus particulièrement le fait que ce dernier soit non fonctionnel dans
l’environnement client. D’un point de vue client, le produit final étant non fonctionnement cela
implique que le chef de projet n’a pas abouti aux résultats souhaités.
Afin de palier à ce type de changement le chef de projet doit dans un premier temps faire le
relevé des erreurs qui ont été commises, du côté de l’équipe projet, lors de la mise en place du
produit final. Une fois le relevé des erreurs fait, le chef de projet va effectuer une analyse de ces
erreurs afin de comprendre comment elles ont pu arriver.
Cette analyse peut également se faire à l’aide des collaborateurs du chef de projet avec
l’organisation d’une réunion dite ici « de crise ».
A la suite de l’analyse faite par le chef de projet, il convient que se dernier organise une réunion
avec le client afin de comprendre avec lui se qui a pu se passer pour que le produit final ne soit
pas fonctionnel dans l’environnement client.
Le chef de projet devra durant cette réunion, demander au client ci ce dernier n’a pas effectué
des changements, quels qu’ils soient, dans son environnement. Si c’est le cas, le chef de projet
devra faire une liste des changements que le client a effectués.
Une fois cette liste établie, le chef de projet doit organiser une réunion de travail avec ces
collaborateurs afin de trouver ensemble des solutions pour que le produit final devienne
fonctionnel dans l’environnement client.
4.2.5.2 Architecture cliente modifiée
Une architecture cliente modifiée peut être liée au changement vu précédemment, ainsi avec un
changement dans l’architecture cliente le produit final peut ne plus être fonctionnel dans
l’environnement client.
Il est appelé « architecture cliente modifiée », tout changement au niveau réseau, système
d’exploitation … amenant ainsi un impact sur l’architecture actuelle, cela implique des
changements très importants dans une société et pouvant amener des conséquences négatives
sur la production.
Dans ce paragraphe, contrairement au précédent, le projet est en phase final, mais cela n’est pas
le jour de mise en production. Le client prévient le chef de projet d’un changement dans
l’architecture quelques jours avant la date fixée pour la mise en production.
Dans un premier temps, le chef de projet doit avertir ces collaborateurs afin que ces derniers
arrêtent les derniers ajustements en cours sur le projet.
Dans un second temps, le chef de projet doit organiser de manière rapide une réunion avec le
client afin que ce dernier lui fournisse une liste des changements qui ont ou qui vont être
effectués dans l’architecture cliente.
Le chef de projet, avec la liste fourni par le client, doit faire de son côté une liste des impacts que
ces changements vont avoir sur la mise en production du projet dans l’environnement client.
Suite à cette liste, il doit organiser une réunion interne avec ces collaborateurs afin que le chef de
projet puisse avec leur collaboration déterminer la charge de travail restante.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 27 / 79
Le chef de projet doit plus particulièrement effectuer une étude de faisabilité suite aux impacts
que ce changement a sur le projet.
Suite à cette étude, si la faisabilité est vérifiée, le chef de projet doit faire une planification pour
effectuer les changements sur le projet en fonction des changements effectués sur l’architecture
cliente.
En dernier lieu, il faut que le chef de projet convienne avec le client d’une nouvelle date de mise
en production du projet.
4.3 Critique de l’existant
Cette partie consiste à mettre en évidence les aspects négatifs de l’audit fait dans le paragraphe
précédent. De cette critique, nous pourrons, par la suite, mieux cerner les conduites qui ne
permettent pas aux chefs de projet de faire face de manière positive aux changements.
Nous pourrons alors dans un des chapitres suivants donner des solutions pouvant mieux
répondre aux attentes de ces chefs de projet face aux changements.
4.3.1 La conduite suivie lors d’un changement humain
Après avoir détaillés dans les paragraphes précédents, les différentes conduites qui sont suivies
lors de changements inattendus durant un projet informatique, il sera détaillé dans ce
paragraphe les critiques qui peuvent être faites sur ces conduites et plus particulièrement sur
les changements survenant dans le domaine de l’humain.
Comme il a été précisé précédemment, les quatre changements au niveau humain qui sont
étudiés sont les changements de chef de projet ou de collaborateur et les conduites suivies lors
de départ en congés payés ou en congés maladies.
4.3.1.1 Chef de projet
Les critiques qui peuvent être faites sur les conduites suivies lors d’un changement de chef de
projet ne sont pas nombreuses mais ces critiques peuvent amener à trouver des solutions afin
que les changements inattendus n’ait pas d’effets négatif sur le bon déroulement des projets.
La première critique qui est soulevée concerne la transparence des faits vis à vis du client mais
également vis à vis des membres de l’équipe projet.
En effet, les responsables du chef de projet n’ont pas fait de bilan sur le départ du chef de projet,
ils n’ont pas listé les raisons de son départ. Si le client ou un membre de l ‘équipe projet pose des
questions sur le départ du chef de projet, les responsables pourront se retrouver dépassé par la
question montrant ainsi une faiblesse.
Cette dernière pourra alors être interprétée par les différents acteurs comme une angoisse et
ainsi provoquer des incertitudes et des interrogations au sein de l’équipe projet mais également
vis à vis du client. Laisser des personnes avec des sentiments d’incertitudes et d’interrogations
peut avoir des conséquences négatives sur un projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 28 / 79
La seconde critique qui est soulevée concerne la gestion du projet. Cette critique peut être faite
au chef de projet comme à ses responsables.
En effet, la critique est de ne pas avoir mis par écrit les différentes informations qui ont circulées
sur le projet.
En effet, sans ces informations le transfert de compétences ou d’informations prend plus de
temps.
De plus, il est évident que toutes les informations ne seront pas communiquées au nouveau chef
de projet car l’Homme n’a pas la capacité de retenir à 100% les informations qui lui ont été
transmises durant le projet, il y a ainsi une perte d’information entre le prédécesseur et le
successeur.
Cette critique est d’autant plus valable dans le cas où le départ du chef de projet serait dû, dans
le cas extrême, au décès de celui-ci. Dans ce cas, il n’y a pas de transfert d’informations entre le
prédécesseur et le successeur entraînant ainsi une perte de connaissance sur le projet mais aussi
une perte de temps.
4.3.1.2 Collaborateur
Les critiques soulevées dans ce paragraphe sont faites sur les conduites qui sont suivies
lorsqu’un changement de collaborateur intervient durant un projet informatique.
Les conduites détaillées dans les paragraphes précédents montrent des faiblesses à mettre en
avant afin d’éviter toutes conséquences négatives sur les projets.
La première critique est portée essentiellement sur le chef de projet et la gestion de son équipe.
En effet, l’erreur est de ne pas avoir prévu initialement une équipe projet avec un nombre de
personnes plus important. Pour être plus précise, si un collaborateur décide de partir, il faut lui
trouver un remplaçant, le former et attendre qu’il soit opérationnel pour que le projet continu.
Le chef de projet doit initialement prévoir dans ces effectifs des collaborateurs « remplaçants »
qui seront opérationnels plus rapidement évitant ainsi une perte de temps et ainsi un
dépassement de délais.
La seconde critique porte également sur la gestion du projet faite par le chef de projet. En effet,
la faille décelée dans la conduite détaillée précédemment concerne le planning du projet.
Le chef de projet aurait dû prévoir dans la planification de son projet une charge éventuelle de
problèmes humains, tout ceci afin d’éviter des pertes de temps impliquant des retards dans les
délais donnés au client.
4.3.1.3 Les arrêts maladie
Les critiques portées dans ce paragraphe concernent la gestion des arrêts maladie. En effet sur la
conduite détaillée dans le paragraphe sur l’analyse de l’existant, il est mis en évidence certaines
faiblesses.
La critique qui peut être faite est la même que celle faite sur les changements de collaborateurs.
L’erreur du chef de projet est de ne pas avoir prévu initialement une équipe projet avec un
nombre de personnes plus important.
Pour être plus précise, si un collaborateur tombe malade dans le cas d’un arrêt maladie de
longue durée, il faut lui trouver un remplaçant, le former et attendre qu’il soit opérationnel pour
que le projet continu.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 29 / 79
Le chef de projet doit initialement prévoir dans ces effectifs des collaborateurs « remplaçants »
qui seront opérationnels plus rapidement évitant ainsi une perte de temps et ainsi un
dépassement de délais.
4.3.1.4 Les congés payés
Le minimum de congés payés attribué à chacun des employés d’une entreprise est connu de
tous, il est de cinq semaines par homme et par an. Dans ce mémoire, il n’est pas tenu compte des
jours autres que ces cinq semaines.
La critique à faire sur la conduite qui a été décrite auparavant est que le chef de projet n’a pas
tenu compte initialement dans sa planification du nombre total en jour homme qui seront pris
pour des congés payés. Sachant que nous avons 5 semaines minimum et obligatoires de congés
payés par homme et par an. Il est facile de planifier en fonction de ces données.
Cette « non prise en compte » des congés payés dans le planning d’un projet peut mettre ce
dernier en péril au niveau des délais de réalisation annoncés.
4.3.2 La conduite suivie lors d’un changement technique
Après avoir détaillés dans l’analyse de l’existant, les différentes conduites qui sont suivies lors de
changements inattendus durant un projet informatique, il sera détaillé dans ce paragraphe les
critiques qui peuvent être faites sur ces conduites et plus particulièrement sur les changements
survenant dans le domaine technique.
Comme il a été précisé précédemment, les trois changements au niveau technique qui sont
étudiés sont les changements de langage de programmation, les changements d’architecture
réseau et les changements de système d’exploitation.
4.3.2.1 Changement de langage de programmation
Le changement de langage de programmation, comme il a été vu dans l’analyse de l’existant,
amène le plus souvent à une refonte totale du projet, impliquant ainsi de nombreuses
modifications et notamment au niveau de la gestion de projet.
La conduite qui a été détaillée dans ce mémoire lors de ce type de changement montre des failles
qui vont être mises en avant dans ce paragraphe.
La première faille concerne l’analyse du travail demandé par le chef de projet lors de l’annonce
du changement de langage de programmation.
En effet, la critique se porte sur le fait que cette analyse devrait se faire au fil de l’avancement du
projet, de manière régulière entre le chef de projet et ses collaborateurs, tout ceci afin d’éviter
une perte de temps lors de demandes ou lors de changements inattendus, ou afin de permettre
également de répondre immédiatement aux questions des clients lors de réunion.
La seconde critique concerne le chef de projet. En effet, ce dernier aurait dû faire l’état des
compétences des collaborateurs initialement, avant le commencement du projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 30 / 79
Ainsi cela évite au chef de projet de perdre du temps à faire l’état des compétences de ces
collaborateurs au moment où le changement intervient.
Le chef de projet doit connaître parfaitement ses collaborateurs et surtout en terme de
compétences.
La dernière critique, mais non la moindre, qui peut être faite sur la conduite suivie lors d’un
changement de langage de programmation durant un projet informatique concerne la sélection
des membres de l’équipe projet.
En effet, le chef de projet aurait dû lors de la constitution de son équipe, s’entourer de personnes
multi compétentes à la place de personne mono compétentes.
Ainsi lors d’un tel changement, les membres de l’équipe projet n’ont pas forcément besoin d’être
remplacés s’ils sont compétents sur le nouveau langage de programmation.
4.3.2.2 Changement d’architecture réseau
Comme il a été détaillé dans l’analyse de l’existant, les changements d’architecture réseau
peuvent se faire du côté client ou du côté de l’équipe projet. Dans ce paragraphe, la critique sera
faite sur les changements d’architecture côté « équipe projet ».
En effet, les changements d’architecture réseau sont des changements prévisibles puisqu’ils
demandent de nombreux préparatifs avant de pouvoir être effectués afin d’éviter toutes
conséquences nuisibles à la société et plus particulièrement à la production.
Le chef de projet doit donc tenir compte dans son planning des futurs changements à venir, cela
évite des soucis tels que des retards sur les délais annoncés au client.
4.3.2.3 Changement de système d’exploitation
Comme il a été expliqué dans l’analyse de l’existant, les systèmes d’exploitation sont comme
l’architecture réseau, un point essentiel de l’informatique dans une société. Dès que des
modifications sont faites sur un de ces deux éléments fondamentaux cela peut avoir des impacts
négatifs sur une société.
Lors d’un tel changement, le paragraphe sur l’analyse de l’existant a montré quelle conduite est
aujourd’hui suivie pour faire face à un changement de système d’exploitation durant le projet.
Mais cette conduite présente des points faibles qui peuvent conduire à une mauvaise gestion du
projet et ainsi engendrer des conséquences néfastes à l’aboutissement du projet.
La première critique à faire concerne le chef de projet. En effet ce dernier aurait dû faire l’état
des compétences de ces collaborateurs lors de la sélection de ces derniers avant le
commencement du projet. Cette critique a déjà était faite lors du paragraphe concernant la
critique du changement de langage de programmation.
La seconde critique se porte sur le choix stratégique faite par le chef de projet. En effet, il aurait
été judicieux de faire une application fonctionnant avec tous les types d’environnement existant.
Dans le cas où le changement de système ne serait pas intervenu durant le projet, il est possible
que le client décide de changer de système quelques années plus tard impliquant dans ce cas que
l’application ne fonctionnera plus à ce moment là puisqu’elle n’est fonctionnelle qu’avec un seul
type de système d’exploitation.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 31 / 79
4.3.3 La conduite suivie lors d’un changement commercial
Comme il a été expliqué dans l’analyse de l’existant, le domaine commercial est un domaine très
important dans une société, sans ce domaine il n’y a pas de contrat négocié et/ou décroché, soit
pas de projets à traiter.
Le domaine commercial est très important durant la phase projet. En effet, le commercial est,
avec le chef de projet, un point d’entrée pour le client. Autrement dit, le client a uniquement
deux contacts durant le projet, le commercial avec lequel il peut discuter des aspects
contractuels du projet, et le chef de projet pour les aspects techniques et fonctionnels.
Dans ce paragraphe seront détaillées les différentes critiques qui peuvent être faites sur les
conduites suivies lors de changements commerciaux intervenant durant des projets
informatiques.
4.3.3.1 Modification de périmètre
Comme il a été expliqué dans l’analyse de l’existant, lorsque le client décide de modifier le
périmètre qui a été défini lors de la signature du contrat, il en avise le commercial afin d’établir
les éléments nécessaires pour que le changement de périmètre soit pris en compte dans le
contrat.
Pour rappel, dans ce paragraphe, la modification du périmètre se fait durant le projet initial.
La critique qui peut être faite sur la conduite suivie suite à l’annonce par le client d’une
modification de périmètre se porte sur les actions du commercial.
En effet, le client se rapproche du commercial afin de faire sa demande de modification de
périmètre. La critique se porte donc sur le fait que le commercial n’a pas négocié une
modification des délais du projet.
Dans le cas présent, les modifications doivent être faites dans les délais initialement prévus au
contrat ce qui provoquer un retard sur les délais et donc des pénalités à payer au client.
4.3.3.2 Avenants au contrat
Comme il a été expliqué dans l’analyse de l’existant, les avenants au contrat sont des documents
officiels permettant de mettre à jour le contrat signé initialement entre les deux parties.
Il a également été détaillé précédemment, la conduite suivie lors d’un tel changement, autrement
dit lors de la signature d’un avenant.
Cette conduite présente néanmoins des points négatifs notamment sur la gestion du projet.
Dans un premier temps, une critique sur la nomination du chef de projet est à soulever. En effet,
deux cas se présentent, soit le chef de projet ayant travaillé initialement sur le projet est nommé,
soit un nouveau chef de projet est nommé en l’absence de l’ancien chef de projet.
Dans le cas où le chef de projet reste le même, la critique est que ce dernier n’a pas besoin de
refaire tout le travail fait initialement.
En effet, le chef de projet peut tout à fait prendre la documentation faite lors du projet initial et y
apporter les modifications nécessaires. De plus, le chef peut également faire appel aux
collaborateurs qui avaient travaillé sur le projet initialement.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 32 / 79
Ainsi, cela lui permet de faire un gain de temps considérable sur la rédaction de la
documentation mais également la compréhension du contexte du projet.
Dans le cas où il y a un changement de chef de projet, les critiques citées précédemment sont
également valables.
Par contre, il peut être ajouté à cela, le fait que le nouveau chef de projet ne se soit pas renseigné
sur ce qui avait été fait auparavant, soit en organisant une réunion de travail avec l’ancien chef
de projet ci ce dernier est toujours présent, soit en s’imprégnant des documentations qui ont été
faites durant le projet initial.
Dans un second temps, une critique est à faire au commercial. En effet, le client décide de faire
une modification sur le contrat signé initialement.
Lors de cette annonce, le commercial doit préparer les papiers pour l’avenant mais cette action
fait également l’objet d’une nouvelle facturation. Lorsque les papiers sont prêts, le commercial
organise une réunion avec le client afin de lui présenter le devis et les papiers à signer.
L’erreur du commercial dans ce cas là, est de ne pas avoir invité le chef de projet en charge des
modifications à participer à cette réunion.
En effet, cela aurait permis à ce dernier de pouvoir soulever des points administratifs et
techniques sur le projet.
4.3.4 La conduite suivie lors d’un changement financier
Dans ce paragraphe seront détaillées les différentes critiques qui peuvent être faites sur les
conduites suivies lors de changements financiers intervenant durant des projets informatiques.
Dans les projets informatiques, lorsqu’un changement de type financier survient cela peut
entraîner dans des cas extrêmes l’abandon de ces projets.
4.3.4.1 Restrictions budgétaires
Lors de l’analyse de l’existant, il a été expliqué que le chef de projet n’a aucun contrôle sur les
restrictions budgétaires imprévues, par contre c’est lui qui est en charge, par tous les moyens, de
réduire les coûts afin que le projet puisse continuer sans qu’il y ait de conséquences sur son
déroulement.
Suite à ces informations et à la conduite suivie face à ce type de changement, deux points faibles
en ressortent.
La première critique concerne le budget. En effet afin de palier à ce type de changement, le chef
de projet ne doit pas dépenser tout le budget attribué au projet dès le commencement de ce
dernier. Cela conduit à se retrouver sans financement en cas de coup dur comme par exemple
l’achat de nouveau matériel car il y a un changement de système d’exploitation…
La seconde critique qui peut être faite à la conduite suivie face à une restriction budgétaire est
une critique concernant le choix de la technologie.
En effet, il est plus judicieux de choisir des technologies connus et par la force des choses moins
coûteuses que des technologies récentes et par conséquence plus coûteuses et moins fiables.
Cela permet ainsi de faire des économies de budget afin de palier à d’éventuels changements
financiers durant le projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 33 / 79
4.3.4.2 Dépenses imprévues
Dans ce paragraphe va être expliqué le point faible de la démarche suivie lors d’un changement,
tel que des dépenses imprévues comme des formations ou de nouvelles embauches, durant un
projet informatique.
En effet, la critique qui peut être faite au chef de projet, c’est de ne pas avoir tenu compte dans
son budget des éventuelles dépenses imprévues. Il faut toujours prévoir des dépenses comme
une nouvelle embauche si un collaborateur décide de partir, des formations si un changement de
langage de programmation survient durant le projet.
Il n’est, certes, pas facile d’évaluer un montant concernant ces dépenses imprévues mais il est
important de budgéter ce type de dépenses afin de pouvoir faire face aux éventuels changements
humains, technique …
4.3.4.3 Rachat de la société
Dans le cas du rachat d’une société, que se soit la société cliente ou la société en charge du projet,
il est difficile pour le chef de projet de prévoir ce type de changement. En effet, ces changements
sont très rares et le chef de projet tout comme les responsables du projet côté client ne sont pas
maître de la situation.
Les critiques qui pourront être faites ici seront celles qui ont été évoquées dans les paragraphes
précédents.
4.3.5 La conduite suivie lors d’un changement en production
Comme il a été expliqué dans le paragraphe sur l’analyse de l’existant, la mise en production est
la dernière ligne droite au bout de laquelle le projet sera bouclé et clos.
Cette phase est délicate puisqu’elle est le résultat d’un travail long et de la mise en œuvre du
produit au sein de l’environnement client.
Dans le paragraphe de l’analyse de l’existant, il est détaillé quelle conduite est suivie lorsqu’un
changement intervient durant la phase de mise en production du projet.
Dans ce paragraphe, il sera montré quels sont les points faibles à relever dans cette conduite,
dans le cas où le produit final est non fonctionnel et dans le cas où lors de la mise en production
l’équipe projet constate qu’il y a eu des changements d’architecture cliente sans que l’équipe en
soit informée.
4.3.5.1 Produit final non fonctionnel
La conduite suivie, lorsque le produit final ne fonctionne pas dans l’environnement client, qui a
été détaillé dans l’analyse de l’existant, présente de nombreux points faibles. Ces points faibles
contribuent à ce que les mises en production ne se passent pas comme le chef de projet l’aurait
souhaité.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 34 / 79
La première critique qui peut être faite est donnée au chef de projet qui n’a pas prévu de phase
de test sur l’environnement client ce qui aurait permis de palier à des surprises lors de la mise
en production.
Dans ces phases de tests, il ne suffit pas de tester uniquement le produit final mais de le tester
avec les contraintes de l’environnement client afin de s’assurer de la bonne compatibilité entre
le produit et l’environnement client.
La seconde critique est que le chef de projet n’ait pas proposé lors de la réunion d’initialisation
avec le client, que l’équipe projet soit détachée dans les locaux du client afin dans un premier
temps de travailler au sein de l’environnement client écartant ainsi tout incompatibilité entre le
produit et l’environnement client, puis dans un second temps d’avoir le contact direct avec le
client et ainsi éviter toute perte de temps pour les communications entre le client et l’équipe
chargée du projet.
Une autre critique à relever est le fait que le chef de projet n’ait pas préparé la mise en
production.
En effet, le chef de projet aurait dû, afin de préparer la mise en production, faire une réunion de
passage en production avec le client. Cette réunion aurait permis de savoir si le client n’a
effectué aucune modification sur son environnement et surtout de lister avec lui les pré requis
nécessaires à la mise en production.
En dernier point, un autre point négatif, qui peut être tiré des conduites suivies, est qu’il aurait
fallu prévoir ou lister les différents échecs susceptibles d’apparaître durant la phase de mise en
production pour pouvoir trouver les solutions et remédier à ce type d’événement.
4.3.5.2 Architecture cliente modifiée
Comme il a été expliqué lors de l’analyse de l’existant, il est appelé « architecture cliente
modifiée », tout changement au niveau réseau, système d’exploitation … amenant ainsi un
impact sur l’architecture actuelle, cela implique des changements très importants dans une
société et pouvant amener des conséquences négatives sur la production.
Lors d’un tel changement, les paragraphes précédents ont montré quelle conduite est suivie.
Cette conduite montre néanmoins des points faibles pouvant empêcher la bonne conduite à
suivre afin de palier au changement.
Les points faibles à relever sont équivalent à ceux évoqué lors d’un changement de système
d’exploitation.
Dans un premier cas, il aurait été judicieux de faire une application fonctionnant avec tous les
types d’environnement existant. Lorsque le client annonce alors le changement, il suffit
seulement de faire des paramétrages adéquats afin que le produit soit fonctionnel dans
l’environnement modifié.
Dans un second cas, comme dans le projet d’intégration d’équipements réseaux au sein de
plateformes de supervision, lorsque le client annonce un changement d’architecture comme la
refonte du plan d’adressage IP de la société, cela implique des changements à faire au sein de
l’architecture de la société en charge du projet.
Le chef de projet aurait alors dû prévoir une architecture telle que lorsqu’un tel changement
intervient, il n’y a aucune modification à faire du côté de l’équipe projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 35 / 79
5. Méthodes et démarches utilisées
Les méthodes utilisées pour répondre à la question fondamentale sont nombreuses. La première
consistait à suivre un plan bien précis pour le déroulement du mémoire.
La seconde méthode consistait à effectuer des recherches documentaires sur le sujet afin de
mieux comprendre l’existant mais également afin de faciliter les recherches de solutions.
Pour cela il fallait dans un premier temps s’appuyer sur la documentation existante afin
d’expliquer et de bien définir les différents points qui sont au cœur de ce mémoire : conduite de
changement, les différents types de management et de changement et les projets informatiques.
Il fallait donc, pour obtenir des résultats, s’appuyer sur la documentation présente sur internet
mais également sur les livres qui ont été écrits sur le sujet et qui sont accessibles dans les
bibliothèques.
Dans un second temps, une fois l’existant bien détaillé et expliqué, le travail consistait à apporter
les solutions aux problèmes de l’existant.
Autrement dit, il fallait selon les différents contextes, lister les différentes améliorations à
apporter à l’existant, et donner les solutions à ces améliorations.
Il était important à ce moment du mémoire d’apporter des solutions nouvelles. Pour cela, il était
bon de prendre les solutions déjà apportées par des tiers et de comprendre et d’expliquer
pourquoi ces solutions ne sont pas valables.
Cela demandait ainsi une recherche des solutions existantes et surtout une recherche créatrice
pour avoir des solutions nouvelles. Ces recherches se sont faites par le biais de la documentation
présente sur internet mais également sur des livres.
Les différentes pages visitées ainsi que les différents ouvrages utilisés ont été référencés dans la
webographie et dans la bibliographie
Il était important pour les différents points abordés ci-dessus de surtout bien confirmer et bien
vérifier ses sources.
La troisième méthode était de rechercher des informations au sein même de l’entreprise. Ainsi,
afin de bien comprendre et expliquer l’existant, il était nécessaire d’interviewer des personnes
travaillant dans ces différents domaines.
Il fallait donc pour ce mémoire avoir une entrevue avec un chef de projet informatique d’une
société informatique et/ou non informatique.
D’autres entrevues étaient également à prévoir avec notamment une personne des ressources
humaines permettant de comprendre le management humain mais aussi avec un responsable de
production qui peut, dans les cas de projets informatiques, être le client et qui peut également
donner des renseignements sur le management de production.
Une entrevue avec un commercial et un financier pour mieux comprendre leur management.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 36 / 79
Afin d’avoir des résultats pertinents avec ce type de méthode, la démarche a été la suivante.
Dans un premier temps, il a fallu décrocher des rendez-vous afin de faire les interviews. Afin de
décrocher des interviews auprès des sociétés, il a été prévu de faire des demandes de rendez-
vous par mail afin de toucher le plus grand nombre de personnes ainsi que le plus grand nombre
de société.
Le mail qui a été envoyé afin de décrocher des rendez-vous est le suivant :
Objet : interview pour une étude sur la conduite du changement dans les projets
informatiques
Madame, monsieur,
Je fais actuellement une étude sur la conduite du changement. Le sujet précis est
« Quelle est la conduite à suivre sur le management d’un projet, lorsqu’un changement
intervient durant un projet informatique ? ».
Je vous propose à la fin de cette étude de vous faire parvenir les résultats ainsi que les
solutions qui auront été trouvées afin de vous en faire profiter mais également afin de
vous remercier du temps que vous m’aurez accordé pour cette interview.
Je me permets de vous adresser ce courriel afin que nous puissions convenir d’un
rendez-vous pour une interview sur la conduite du changement.
Je vous propose donc de me contacter afin de prendre un rendez-vous d’une durée de
30 minutes selon vos disponibilités.
Je vous remercie et je reste à votre disposition si vous souhaitez avoir des informations
complémentaires.
Très cordialement.
Audrey LEPICOUCHE
Ces prises de rendez-vous par le biais de courriel n’ont pas été fructueuses puisque seul un
rendez-vous a pu être pris sur une quinzaine de demandes faites.
Les difficultés rencontrées concernent plus particulièrement le manque de temps qu’ont les
personnes ou les entreprises vers qui les courriels ont été envoyés.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 37 / 79
Afin de faire au mieux pour ces interviews, un questionnaire a été élaboré et les réponses à ce
questionnaire se trouvent en annexe du mémoire. Voici donc les différentes questions qui ont
été posées lors des différentes interviews :
Cette interview sur la conduite du changement est une des étapes importante d’une
étude faite pour comprendre quelles sont les conduites à suivre sur le management
d’un projet lorsqu’un changement intervient durant un projet informatique.
1. Quels sont les types de projets informatiques qui vous sont confiés,
développement d’applications, mise en place d’architecture réseaux … ?
2. Les équipes projet sont composées de combien de collaborateurs en général ?
3. Quelle est votre démarche actuelle pour gérer les projets de type
informatique ?
4. Une fois que le projet a débuté, vous est-il déjà arrivé de faire face à un
changement inattendu ?
5. Comment gérez-vous des changements de types humains dans un projet
informatique ?
a. Changement du chef de projet ?
b. Changement d’un collaborateur ?
c. Les arrêts maladies ?
d. Les congés payés ?
6. Au niveau technique, comment gérez-vous les changements comme les
modifications des besoins client impliquant bien souvent un changement de
technologie (langage de programmation, architecture réseau …) ?
7. Durant un projet, un chef de projet doit bien souvent rendre compte de son
avancement auprès du client, quelle conduite avez-vous face au client
lorsque vous devez lui annoncer un retard sur les délais ? Prenez-vous alors
un rôle de commercial ?
8. Comment gérez-vous des changements au niveau financier dans un projet
informatique ?
a. Les restrictions budgétaires ?
b. Les formations imprévues, dues par exemple à un changement de
besoin client ?
c. Réorganisation ou rachat de la société, comment gérez-vous la
continuité du projet sans qu’il y ait d’impacte pour le client ?
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 38 / 79
9. La mise en production marque bien souvent la fin d’un projet, comment
gérez-vous un changement durant cette phase ?
a. Le produit final est non fonctionnel dans l’environnement client ?
b. Le client a changé un équipement dans son architecture remettant
ainsi en défaut le projet ?
Je vous remercie de m’avoir accordé du temps pour cette interview. Je vous ferai pars
des résultats de cette étude à la fin de sa réalisation.
Le nombre d’interview s’élève à un. Le rendez-vous a pris une demi-heure environs. Il s’est
déroulés en suivant les questions préparées et présentées précédemment dans ce paragraphe.
La dernière méthode, mais non la moindre, consistait à s’appuyer sur le directeur de mémoire
ainsi que sur les personnes de la société d’accueil pour la formation du diplôme de master en
ingénierie informatique, réseaux et télécoms.
La démarche pour cette méthode a été simple puisqu’il suffisait de demander un rendez-vous
selon la disponibilité des interlocuteurs afin de pouvoir les consulter.
La démarche consistait dans un premier temps d’envoyer la rédaction faite afin que le directeur
de thèse puisse s’en imprégner et apporter les commentaires sur le texte déjà réalisé.
C’est donc le directeur de thèse qui permet de guider la rédaction, et ainsi de savoir si la
rédaction effectuée ne sort pas du sujet évoqué.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 39 / 79
6. Description des améliorations
A ce stade du mémoire, il a été fait un diagnostic de l’existant sur les différentes conduites
suivies sur le management de projet lorsqu’un changement intervient durant un projet
informatique.
Par la suite, pour faire face à cet audit, une critique des solutions actuellement en place a été
exprimé afin, plus particulièrement, de montrer les points faibles des conduites suivies
aujourd’hui et afin de pouvoir y apporter des solutions.
Il a également été détaillé, la manière dont les recherches ont été effectuées afin d’obtenir les
informations présentées dans les chapitres précédents.
L’objectif de ce nouveau paragraphe est de présenter les améliorations qui peuvent être
apportées afin de faire face aux différentes critiques évoquées lors de l’analyse de l’existant.
Afin de faire la présentation des améliorations, il sera exprimé, dans un premier temps, les
améliorations souhaitables à apporter pour faire face aux différents points négatifs présentés
lors de la critique de l’existant. Dans un second temps, il sera mentionné les différentes solutions
possibles pour pouvoir répondre à ces améliorations souhaitées.
Pour finir ce paragraphe, il sera précisé et détaillé les solutions d’amélioration retenues en
argumentant et en justifiant ces choix.
6.1 Améliorations souhaitables
Comme il a été vu tout au long de ce mémoire, les projets informatiques touchent tous les
domaines importants d’une entreprise : les domaines financiers, commerciaux, ressources
humaines, techniques…
Les projets étant très nombreux et surtout très diversifiés, il a été décidé dans ce mémoire de
découper les changements, pouvant survenir durant un projet informatique, selon les domaines
cités auparavant. Par conséquent, plusieurs améliorations sont à apporter dans les différents
domaines.
6.1.1 Les améliorations à apporter lors d’un changement dans le
management humain
Suite à l’analyse puis à la critique de l’existant, plusieurs points d’amélioration sont à apporter
pour faire face de manière irréprochable aux changements dans le management humain. De
plus, ces améliorations sont indispensables afin de ne pas arriver à des points de non retour et
par conséquent à l’abandon des projets.
6.1.1.1 Chef de projet
Lorsqu’un changement de chef de projet intervient durant un projet, il faut que certaines choses
aient été mises en place afin de pouvoir palier à ce changement. Suite à l’analyse et à la critique
qui ont été détaillées dans les paragraphes précédents sur la conduite à suivre face à un tel
changement, plusieurs améliorations sont à apportées.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 40 / 79
Tout d’abord, le chef de projet a pour mission principal de mener à bien son projet, quelque soit
le nombre de changement de chef de projet qui peut y avoir durant un même projet.
Afin que ce dernier puisse mener à bien cette tâche, il faut que de la documentation soit établie
afin de bien recenser et de bien archiver toutes les actions et toutes les informations qui ont été
faites ou qui ont circulées durant le projet.
Ceci évite bien entendu qu’il y ait de la perte d’information et que toutes les personnes
intervenant de près ou de loin sur le projet puissent être au même niveau d’intervention que
chaque membre de l’équipe.
Le chef de projet est doc ainsi tenu pour responsable du bon déroulement du projet et surtout de
la bonne mise en œuvre de la gestion de projet.
Le second point d’amélioration concerne plus particulièrement la communication orale sur le
déroulement du projet entre les différents acteurs.
En effet, il est nécessaire que chaque membre de l’équipe projet se réunisse afin que le niveau
d’information soit identique pour tous.
Ceci permet ainsi, que lorsque le chef de projet change, chaque membre sait ce qu’il a fait et ce
qu’il lui reste à faire, mais chaque membre est également capable de présenter le projet dans son
intégralité au nouveau chef de projet en lui présentant les différents points déjà traités ainsi que
les différents points restants.
Ainsi, ces améliorations sont essentiellement basées sur le travail en amont du changement de
chef de projet. Seul le travail que fournira le chef de projet initial sur la gestion de projet pourra
permettre de faire face à son éventuel changement.
Toute cette préparation permettra de mener à bien le projet sans rencontrer de risques trop
importants.
6.1.1.2 Collaborateur
Lorsqu’un changement de collaborateur intervient durant un projet, il faut que certaines choses
aient été mises en place afin de pouvoir palier à ce changement. Suite à l’analyse et à la critique
qui ont été détaillées dans les paragraphes précédents sur la conduite à suivre face à un tel
changement, plusieurs améliorations sont à apportées.
Dans un premier temps, il faut améliorer la composition initiale de l’équipe projet afin de faire
face au moindre problème de type humain.
En effet, comme il a été détaillé dans l’analyse de l’existant, un changement de collaborateur peut
intervenir pour plusieurs raisons telles que les démissions, les congés maladies, les
incompatibilités d’humeur, les licenciements …
C’est pour ces raisons là, qu’il est nécessaire que le chef de projet, au commencement du projet,
prévoit ce type de changement en ajoutant des personnes en plus dans la composition de son
équipe. Ces personnes seraient des remplaçants capables d’intervenir à n’importe quel moment
du projet afin de faire le remplacement du collaborateur absent.
Il est donc impératif que ces personnes assistent aux réunions de travail et qu’ils soient au même
niveau d’informations que les membres « titulaires » du projet.
Ainsi, cela évite tout retard sur le projet dû à des transferts de compétences pour que le nouveau
collaborateur soit au même niveau d’information que les membres du projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 41 / 79
Dans un second temps, un autre point d’amélioration concerne le chef de projet. En effet, il est
plus courant qu’il y ait des changements de collaborateur plutôt que des changements de chef de
projet.
Il faut donc que le chef de projet améliore son estimation de la charge de travail du projet. Pour
effectuer cette amélioration, il faut que le chef de projet prenne en compte des éléments tels que
la disponibilité des collaborateurs. Ainsi, le chef de projet pourra palier à un changement de
collaborateur sans que ce dernier mette en danger le bon déroulement du projet.
Cette amélioration permet d’avoir une meilleure visibilité sur la charge de travail, sur le temps
passé et sur le temps restant du projet. Par conséquent, le chef de projet à la maîtrise des risques
tels que les délais et les coûts.
Les deux améliorations présentées dans ce paragraphe, qui sont une amélioration concernant la
composition de l’équipe projet et une autre concernant une meilleure estimation des charges,
pourront permettre de faire face plus facilement à un changement de collaborateur. Mais il est
vrai qu’un changement de type humain est imprévisible et doit se gérer sur le fait accompli. Ces
améliorations peuvent remédiées à certains problèmes mais il est impossible de pouvoir prévoir
à l’avance les améliorations à apporter pour des changements de type humain.
6.1.1.3 Les arrêts maladies
Les arrêts maladies sont des évènements imprévisibles quelque soit les personnes. Ces arrêts
peuvent très bien être pris par le chef de projet comme par un collaborateur de l’équipe projet.
Les critiques qui ont été évoquées dans les paragraphes précédents sur les arrêts maladies,
montrent qu’il y a un manque d’organisation de la part du chef de projet. L’amélioration doit
donc se porter sur cet aspect, à savoir la bonne organisation, la bonne planification du chef de
projet sur le projet concernant.
Comme dans le paragraphe précédent sur les changements de collaborateurs, le chef de projet
doit prévoir des membres en plus dans son équipe projet afin de pouvoir palier à ce type de
changement, dans un souci de réagir plus vite au changement imprévus tels que les arrêts
maladie de collaborateur.
Bien entendu, tous ces éléments tournent autour d’une amélioration essentielle à mettre en
place : la communication.
En effet, il n’est pas utile de s’améliorer dans l’organisation et la planification s’il n’y a pas de
communication entre les membres de l’équipe projet. Cette communication est la base du bon
fonctionnement d’un projet et plus particulièrement de la bonne gestion du projet.
Si l’arrêt maladie concerne le chef de projet, l’amélioration à faire sur la conduite suivie face aux
arrêts maladies, concerne l’organisation du chef de projet.
En effet, comme il a été expliqué dans l’analyse de l’existant, il y a différentes types d’arrêts
maladies, les courtes, les moyennes et les longues durées. Dans tous les cas, le chef de projet doit
avoir organisé son projet de telle manière que ces responsables puissent reprendre la gestion du
projet sans difficulté.
La rédaction de documentation, afin de mettre sur papier tous les éléments du projet, est très
importante, cette rédaction est une forme de communication écrite entre les différents membres
du projet et le client.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 42 / 79
Pour résumer, les améliorations à apporter concernant la gestion des arrêts maladies
concernent l’organisation et la planification du projet par le chef de projet, la rédaction de
documentation, et la communication qui est un axe d’amélioration majeure dans ce mémoire.
6.1.1.4 Les congés payés
Les congés payés sont prévisibles, contrairement aux arrêts maladies. Les congés payés
permettent donc de prévoir les absences de chacun des collaborateurs et ainsi de pouvoir
planifier plus facilement un projet.
La planification est donc un point d’amélioration à soulever. En effet, le chef de projet connaît
tous les paramètres nécessaires pour planifier son projet. Il sait le nombre de jours de congés
auxquels ses collaborateurs ont le droit, ainsi que la durée en nombre de jour de son projet.
Ainsi, il est impératif que le chef de projet prenne en compte ces différents paramètre afin
d’améliorer ses planifications, et éviter ainsi tout problème ou tout retard dû à une mauvaise
planification.
Plus la planification sera précise et minutieuse, moins il y aura de risques de retard.
Dans ce paragraphe, il y a également une autre amélioration à apporter. Cette amélioration a
déjà été évoquée dans les paragraphes précédents. Elle concerne la communication.
En effet, le chef de projet doit communiquer et demander à ses équipes de communiquer avec
lui.
Ainsi le chef de projet doit demander à chacun de ces collaborateurs de déposer les dates de
leurs futurs congés au commencement du projet. Bien entendu, cette demande concerne
essentiellement les congés de longue durée, soit les congés excédant une semaine, ceci afin de
faciliter le chef de projet dans la mise en place de ses planifications.
Les deux améliorations à apporter pour des changements survenant durant les projets
informatiques tels que les congés payés sont d’une part d’améliorer la planification du projet de
telle sorte qu’elle soit plus précise et plus minutieuse, d’autre part d’améliorer une fois de plus la
communication entre les différents acteurs du projet afin que dans ce cas précis, les
collaborateurs préviennent très rapidement le chef de projet pour les futurs congés qu’ils
souhaitent poser.
6.1.2 Les améliorations à apporter lors d’un changement dans le
management technique
Dans ce paragraphe seront cités les différents points d’amélioration à apporter pour faire face
aux changements intervenant durant un projet informatique dans le domaine du management
technique. Ces améliorations ont été mises en avant suite au paragraphe sur l’analyse de
l’existant et plus précisément suite aux critiques faites sur les conduites suivies lors de ce type
de changement.
6.1.2.1 Changement de langage de programmation
Les changements techniques tels que le changement de langage de programmation sont des
événements peu ordinaires et peu courants puisqu’ils impliquent dans la plupart des cas une
refont totale du projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 43 / 79
Dans la rédaction des précédents paragraphes, d’une part sur l’analyse de l’existant, d’autre part
sur la critique de cet existant, il en ressort plusieurs éléments qui sont amenés à être améliorés.
La première amélioration qui peut être faite est la même que celle citée précédemment, à savoir
la communication.
En effet, dans le cas d’un changement de langage de programmation, autrement dit un
changement technique, il est important que dès le commencement du projet il y ait une
communication importante et régulière entre les membres de l’équipe et le chef de projet.
Cette communication régulière permettrait ainsi au chef de projet de faire face aux questions
techniques posées par le client lors des réunions de pilotage, mais aussi de comprendre et
d’exposer au client les conséquences d’un tel changement durant le projet.
La seconde amélioration concerne les connaissances du chef de projet sur les compétences de
ces collaborateurs.
En effet, il est important que le chef de projet connaisse les compétences techniques qu’il y a au
sein de son équipe projet, ou qu’il sache les retrouver rapidement. Lorsque le client annonce un
tel changement, le chef de projet doit savoir de manière quasi immédiate si dans son équipe
projet, il y a des compétences sur le nouveau langage de programmation demandé par le client.
Tout ceci, dans un souci de tenir le client informé sur la faisabilité de ces modifications et sur les
différents éléments à prendre en compte pour le financement de ce changement.
En effet, le coût financier sera plus élevé si dans l’équipe projet actuelle, il n’y a pas de
compétences dans le nouveau langage de programmation demandé par le client, car cela
demandera automatiquement l’embauche de nouvelle personne compétentes dans le domaine
souhaité.
La troisième amélioration, qui pourrait être également présentée dans le paragraphe sur le
management humain, concerne le choix des membres de l’équipe projet.
Le chef de projet pourrait, afin de palier à ce type de changement, mais aussi afin d’avoir une
équipe projet multi-compétente, choisir des membres de l’équipe avec des compétences
multiples sur les langages de programmation. Ainsi, et à titre d’exemple, le chef de projet
pourrait décider d’avoir 80% de son équipe avec des compétences multiples en langage de
programmation et 20% spécialisée dans le langage prévu au commencement du projet.
Avec ce type de composition, lors d’un changement de type changement de langage de
programmation, seule 20% de l’équipe serait à changer, permettant ainsi de faire des économies
sur les coûts.
Pour résumer ce premier paragraphe sur les améliorations à faire lorsque des changements
dans le management technique surviennent, et plus particulièrement lors de changement de
langage de programmation, les améliorations relevées sont encore et toujours de mieux
communiquer, d’avoir une meilleure connaissance des compétences de chaque membre de
l’équipe et de faire en sorte de composer une équipe projet pouvant répondre à tous les types de
demandes et surtout tous les types de technologies.
6.1.2.2 Changement d’architecture réseau
La critique qui a été faite au chef de projet sur ce type de changement est de ne pas avoir prévu
dans son planning les changements d’architecture réseau. Ces changements sont prévus et donc
facilement planifiable pour le chef de projet.
L’amélioration se porte une fois de plus sur la planification du projet afin de prendre en compte
dès le commencement du projet tous les paramètres de ce dernier.
Le chef de projet doit prévoir, dans ces actions et dans son planning, du temps afin de préparer
ce changement d’architecture réseau afin que le projet puisse continuer sans avoir de surprises.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 44 / 79
Ce changement doit être pris en compte également dans les délais annoncés au client, que ce
changement d’architecture soit du côté client ou du côté de l’équipe projet.
L’amélioration se porte une fois de plus sur la gestion du projet et plus particulièrement sur le
planning du projet qui doit être le plus complet et le plus précis possible.
6.1.2.3 Changement de système d’exploitation
Dans ce paragraphe, le changement technique concerné est un changement de système
d’exploitation. Les améliorations concernant ce changement ne seront pas toutes détaillées,
puisque certaines ont déjà été expliquées dans les paragraphes précédents comme d’une part
une amélioration la composition de l’équipe projet et d’autre part une amélioration sur la
communication.
L’amélioration qui va être détaillée dans ce paragraphe concerne l’avenir du projet. En effet,
lorsqu’un projet est terminé et qu’il est en production chez le client, il est important que celui-ci
dure dans le temps, tant en terme de qualité qu’en terme d’utilité.
Si le client décide de modifier les systèmes d’exploitation de sa société, il faut que le produit
développé puisse fonctionner dans le nouveau système à mettre en place.
Le chef de projet à donc l’importante mission de présenter au client les différentes manières de
développer son projet mais aussi et surtout la façon la plus pertinente afin que son projet est un
avenir qui dure dans le temps.
L’amélioration concernant ce type de changement est donc essentiellement basée sur
l’amélioration de la réflexion du projet mais aussi la réflexion sur l’avenir du projet afin que
celui-ci dure le plus longtemps possible.
6.1.3 Les améliorations à apporter lors d’un changement dans le
management commercial
Dans ce paragraphe seront détaillées les améliorations qui peuvent être faites pour faire face
aux changements intervenant durant un projet informatique dans le domaine du management
commercial.
Ces améliorations ont été mises en avant suite au paragraphe sur l’analyse de l’existant et plus
précisément suite aux critiques faites sur les conduites suivies lors de ce type de changement.
Ces améliorations ont pour but de faire face plus facilement aux changements de types
commerciaux mais aussi de pouvoir, par la même occasion, améliorer les coûts et vendre mieux.
6.1.3.1 Modification de périmètre
Lors de la critique de l’existant sur les changements tels que des modifications de périmètre, il a
été mis en avant le fait qu’une modification du périmètre nécessite certes un coût
supplémentaire pour le client mais elle doit également amener le commercial à négocier ou
réclamer au client une modification des délais prévus initialement au contrat.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 45 / 79
En effet, une modification de périmètre implique nécessairement un ajout ou une suppression
dans le périmètre défini initialement. Dans les deux cas, cela demande du temps pour effectuer
les modifications demandées par le client. Le temps nécessite de la ressource humaine mais
également de la ressource financière.
De plus, puisque ces modifications demandent du temps, cela implique que le temps prévu
initialement n’est plus bon.
Il est donc nécessaire que le commercial fasse une demande de modification des délais afin, dans
un premier temps, d’éviter les retards sur délais et dans un second temps, afin d’éviter de payer
des pénalités pour cause de retard sur les engagements.
6.1.3.2 Avenants au contrat
Contrairement au paragraphe précédent, les avenants au contrat, autres que les modifications de
périmètre, sont détaillés ici comme des évènements survenant lorsque le projet est terminé et
qu’il a déjà été mis en production chez le client.
Les avenants au contrat signés durant le déroulement du projet ne sont pas étudiés dans ce
paragraphe.
Les critiques faites sur la conduite suivie pour faire face à ce changement concernent
particulièrement la manière dont les personnes, reprenant le projet, se renseignent sur les
différents éléments du projet initial.
Il avait été déjà remarqué dans les paragraphes précédents qu’une amélioration est à faire sur la
rédaction de documentation pour mettre sur écrit tous les éléments nécessaires pour
comprendre le déroulement du projet ainsi que tous les paramètres le concernant.
Dans le cas des avenants au contrat, il est nécessaire que les personnes reprenant le projet se
réfèrent aux documentations qui ont été faites initialement afin de gagner du temps sur la
compréhension d’une part du projet et d’autre part sur la compréhension des nouveaux
éléments demandés par le client.
Une autre amélioration est à apporter dans le cadre d’un avenant au contrat. Il est important,
avant de faire cet avenant, que le commercial établisse une réunion avec le chef de projet, qu’il
soit nouveau ou non.
Il faut impérativement, que le discours soit le même et surtout que le commercial ne mette pas le
chef de projet dans une situation difficile. Il est donc important que le commercial et le chef de
projet soit au même niveau d’information.
La communication entre le commercial et le chef de projet est importante car elle permet d’une
part que le chef de projet détermine sa charge de travail sur les modifications demandées par le
client et ainsi permet au commercial de négocier le délai, d’autre part cela permet au chef de
projet d’apporter de nouvelles idées qui peuvent être vendues au client par le commercial.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 46 / 79
6.1.4 Les améliorations à apporter lors d’un changement dans le
management financier
Dans ce paragraphe seront détaillées les améliorations qui peuvent être faites pour faire face
aux changements intervenant durant un projet informatique dans le domaine du management
financier.
Dans l’analyse de l’existant et dans la critique de celui-ci, les changements qui ont été présentés
sont des changements de types restrictions budgétaires, dépenses imprévues ou rachat de
société.
Il a été vu que plusieurs critiques liées à ces changements et plus particulièrement liées aux
conduites suivies pour y faire face, ont été faites.
Le but de ce paragraphe est donc d’apporter des améliorations afin que qu’il n’y ait plus de
critiques à faire.
Ces améliorations permettront par la suite de trouver des solutions à mettre en place.
6.1.4.1 Restrictions budgétaires
Les deux critiques qui ont été soulignées concernant les restrictions budgétaires concernent
premièrement le budget et plus particulièrement sa gestion, et deuxièmement les techniques
pour le projet.
Les améliorations qui peuvent être apportées face à ces critiques concernent essentiellement le
chef de projet.
En effet, dans un premier temps, concernant la gestion du budget, il faut que le chef de projet
améliore sa gestion.
Il est important de budgéter chaque partie du projet, comme la phase de recherche de
collaborateurs, la phase technique, la phase de test, la phase de mise en production, la phase de
gestion u projet fait par le chef de projet…
Mais il est également important que le chef de projet ne dépense pas tout ce budget car comme il
a été vu tout au long de ce mémoire, différents types de changement peuvent survenir durant un
projet comme un changement de collaborateur ou un changement technique…
Ces différents changements coûtent de l’argent et il est donc important lorsque ces changements
arrivent que le budget ne soit pas épuisé.
Cela obligera le chef de projet à demander à ses responsables un financement supplémentaire
afin de palier à ces changements et ainsi cela réduira la marge que la société pensait faire sur ce
projet.
Dans un second temps, concernant cette fois-ci, le choix technique fait pour le projet, il est
important que le chef de projet fasse ces choix techniques en fonction du budget qui lui a été
attribué mais aussi et surtout en fonction des risques encourus.
Il est essentiel que le chef de projet fasse ces choix en fonction des demandes du client mais
aussi en fonction du budget, des compétences internes, des délais.
Le chef de projet est le garant du bon déroulement du projet en termes de technique mais aussi
en termes de budget et de délai.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 47 / 79
6.1.4.2 Dépenses imprévues
Les améliorations à apporter concernant la conduite suivie lors de dépenses imprévues sont les
mêmes améliorations que celles exprimées dans le paragraphe précédent.
En effet pour faire face aux dépenses imprévues, il faut que le chef de projet ait des moyens
financiers. Ces moyens sont donnés par le budget consacré au projet. Il faut donc que le chef de
projet gère son budget afin de pouvoir tout financer, les évènements prévus comme les
évènements imprévus.
L’amélioration se porte donc sur la gestion du budget par le chef de projet. Comme il a été dit
précédemment, il est le garant du bon déroulement du projet quelque soit le domaine.
6.1.4.3 Rachat de la société
Le rachat d’une société est un événement rare, peu courant. Lors de l’analyse de l’existant et de
sa critique, il en est ressorti qu’il est difficile de faire face à ce type de changement puisque le
chef de projet n’est, d’aucune manière, maître des évènements.
Il a été mentionné, dans le paragraphe sur la critique de la conduite suivie lors du rachat de la
société, que les critiques à faire sont les mêmes que celles faites dans les autres paragraphes. En
effet, lors d’un tel événement tous les domaines étudiés dans ce mémoire sont touchés par ce
type d’événement.
Il en est donc de même concernant les améliorations qui peuvent être faite lors de ce type de
changement.
La seule amélioration qui peut être mise en avant est celle concernant la communication. En
effet, lors d’un tel changement, les différents acteurs sont soucieux de leur avenir, ce qui peut
avoir des effets négatifs sur le bon déroulement du projet.
Ainsi il est très important que les différents acteurs participant au projet communiquent
beaucoup, afin de rassurer mais aussi afin de pouvoir continuer à faire avancer le projet.
6.1.5 Les améliorations à apporter lors d’un changement dans le management de production
Dans ce paragraphe seront détaillées les améliorations qui peuvent être faites pour faire face
aux changements intervenant durant un projet informatique dans le domaine du management
de production.
Les améliorations, qui seront apportées dans ce paragraphe, sont importantes car elles
permettront d’éviter des échecs de mise en production et donc elles permettront d’assurer la
signature des PV de recette entre le client et le chef de projet.
Pour rappel, la mise en production est un événement important puisque c’est l’aboutissement du
projet, ce qui implique que chaque partie obtient son dû, le produit final pour le client, la
récompense pécuniaire pour la société responsable du projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 48 / 79
6.1.5.1 Produit final non fonctionnel
Lors de la critique de l’existant, quatre points négatifs ont été mis en avant. Premièrement, les
phases de test n’ont pas été prévues par le chef de projet.
Deuxièmement, le chef de projet n’a pas proposé au client de mettre l’équipe projet dans ses
locaux.
Troisièmement, le chef de projet n’a pas préparé le passage de mise en production. En fin la
dernière critique est que le chef de projet n’a pas listé les différents échecs susceptibles
d’apparaître.
A l’énumération de ces critiques, différentes améliorations peuvent être apportées afin d’y
palier.
Dans un premier temps, comme dans toutes les améliorations évoquées jusqu’ici, la
communication est l’amélioration la plus important à mettre en place.
En effet, il faut que le chef de projet communique beaucoup avec son équipe mais aussi avec le
client. Un chef de projet qui communique et qui sait s’entourer est un chef de projet qui limitera
les risques dans son projet.
Dans un second temps, et comme il a déjà été évoqué dans les paragraphes précédents, le chef de
projet doit établir de la documentation afin de préparer au mieux, et en limitant les risques, le
passage en production du produit.
Cette documentation doit être riche afin d’assurer au mieux ce passage.
6.1.5.2 Architecture cliente modifiée
Un changement d’architecture cliente durant la mise en production du produit final est
quasiment identique aux changements techniques survenant durant le projet et évoqués dans
les paragraphes précédents.
Les améliorations à apporter sont par conséquents identiques à celles évoquées dans le
paragraphe sur le changement de système d’exploitation
En effet, l’amélioration concernant ce type de changement est essentiellement basée sur
l’amélioration de la réflexion du projet mais aussi la réflexion sur l’avenir du projet afin que
celui-ci dure le plus longtemps possible.
Il faut donc que le chef de projet, aidé par son équipe, mette en place un produit pouvant
fonctionner dans tous les environnements, ce qui assure au produit une durée de vie longue
puisqu’il est adaptable.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 49 / 79
6.2 Solutions possibles
A ce point du mémoire, il a été vu l’analyse et la critique de l’existant ainsi que les améliorations
à apporter face aux critiques faites sur les différentes conduites suivies face aux changements.
L’objectif du chapitre à venir est de mettre en place ces améliorations en trouvant des solutions.
Ces dernières doivent permettre de mieux gérer un projet de faire face aux différents
changements imprévisibles qui surviennent durant un projet.
De plus, ces solutions doivent permettre de minimiser les risques comme les risques de
dépassement de délai, dépassement de budget, d’abandon du projet ….
Les paragraphes qui vont suivre vont donc apporter des solutions concrètes pour mettre en
place les améliorations souhaitées pour chacun des domaines, humain, technique, commercial,
financier et le domaine de mise en production.
6.2.1 Les solutions possibles pour améliorer la gestion de projet
Dans le chapitre consacré aux améliorations, dans chacun des domaines présentés, des
améliorations sont à apporter au niveau de la gestion du projet en générale.
Dans ce paragraphe sera donc détaillé les différentes solutions possibles pour améliorer la
gestion d’un projet.
Tout au long du mémoire, la critique et l’amélioration, la plus souvent évoquée concerne la
communication.
La communication est continuellement présente et se présente sous différentes formes comme
les réunions de travail, les comités de pilotage, les comités de suivi, la documentation…
Afin d’améliorer la communication dans un projet et par conséquent améliorer sa gestion,
plusieurs solutions sont possibles.
6.2.1.1 La documentation
Une première solution consiste à mettre en place différents documents tout au long du projet.
Ces documents sont nécessaires pour effectuer une bonne gestion du projet mais aussi afin
d’assurer le bon déroulement de celui-ci.
Le premier document à mettre en place est l’analyse des besoins. Il est en effet important de bien
analyser le cahier des charges fournit par le client afin de comprendre les différents éléments
qu’il souhaite dans son projet.
Le second document est « un dossier collaborateur ». Ce document, ou plutôt ce dossier,
comporte tous les curriculum vitae des collaborateurs sélectionnés dans l’équipe projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 50 / 79
Le troisième type de document est le planning. Ce document est le cœur du projet puisque c’est
lui qui permettra de gérer le temps et par conséquent de gérer les délais. Il y a deux types de
planning, un planning dit « interne », celui réservé à l’équipe projet et un planning dit « de
pilotage », celui présenté au client.
Le quatrième document est le plan d’assurance qualité (PAQ). Ce document s’assure de la bonne
qualité du déroulement du projet.
Tout le long du projet, des documents sont rédigés comme les fiches des tâches, les comptes-
rendus de réunion (interne et cliente), les fiches de test, les documentations d’installation,
d’administration et d’utilisation, la documentation tout au long du codage.
Le dernier document est le cahier de recette. Ce document est présenté au client lors de la mise
en production de son projet.
D’autres documents peuvent bien entendu être rédigés par le chef de projet selon les besoins.
6.2.1.2 Utilisation de la documentation
Comme il a été vu tout au long de ce mémoire, la documentation est le point essentiel dans la
gestion d’un projet afin que ce dernier se déroule correctement. Mais cela peut également poser
un souci. En effet, il faut connaître l’enchainement de ces documents ainsi que leur utilité.
Pour cela, il faut que le chef de projet mette en place un document qui permettra de comprendre
les différents enchainements entre les documents mais aussi le principe de chacun.
Ce document est une « procédure de gestion de projet ». Elle permettra de lister dans un premier
temps les différentes étapes, les enchaînements entre chacune d’elles et les documents qui y
sont associés ou qui doivent être faits.
Ces documents, tels que les fiches de test, les documents d’installation, etc. seront des
documents dits « applicables ». Il existera également dans cette procédure, des documents dit
« de référence » qui seront le plan d’assurance qualité, le planning, l’analyse des besoins…
Cette procédure devra également signaler où se trouve les différents documents utilisables. Elle
sera accessible à tous les membres de l’équipe projet comme le chef de projet, les collaborateurs,
les responsables hiérarchiques…
6.2.1.3 Gestion et stockage de la documentation
Maintenant, il a été mis en place afin d’améliorer la gestion de projet, différents documents à
rédiger par le chef de projet et par ses collaborateurs, ainsi qu’un document de référence à
rédigé par le chef de projet, permettant de relier ces différents documents.
Mais il faut mettre à disposition de tous les membres de l’équipe projet, de manière simple et
rapide, ces différents documents.
Pour cela, et dans un souci de démarche qualité, il faut mettre à disposition de tous membres de
l’équipe projet un espace de stockage sur lequel chacun des membres pourra accéder aux
documents rédigés pour le projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 51 / 79
Plusieurs solutions sont possibles. La première solution consiste à ce que le chef de projet
demande un espace de stockage sur un serveur de fichier avec des droits spécifiques pour
chacun des membres de l’équipe projet.
Ainsi seules les personnes travaillant sur ce projet pourront y accéder. Tous les documents
devront y être stockés dans leur dernière version afin de s’assurer que tous les membres de
l’équipe projet sont au même niveau d’information.
La seconde solution consiste à mettre en place un outil de gestion électronique des documents
(GED).
Cette solution permet de référencer de manière unique chaque document créé mais également
d’effectuer un cycle de vie d’un document, à savoir la rédaction d’un document, suivi par sa
vérification, son approbation, sa publication et dans certains cas sa révision.
6.2.1.4 Les différentes réunions
Derniers points dans l’amélioration de la gestion de projet, il s’agit des réunions mises en place
par le chef de projet tout au long du projet. Il existe plusieurs types de réunion que le chef de
projet peut mettre en place, les comités de pilotage, les comités de suivi, les réunions de service.
Afin d’améliorer la gestion de projet et surtout la communication, le chef de projet doit organiser
plusieurs réunions qui ont chacune un objectif différent.
Dans un premier temps, le chef de projet doit établir avec le client des échéances pour faire des
réunions appelées « comités de suivi ».
Les échéances peuvent se faire selon les besoins du chef de projet ou selon les besoins du client,
elles peuvent se faire de manière mensuelle, trimestrielles…
Ces comités permettent au chef de projet d’informer le client sur l’état d’avancement du projet.
Ils permettent également de régler des points de détails avec le client sur les détails du projet,
sur les dates clés, sur les aspects commerciaux…
Dans un second temps le chef de projet doit organiser des réunions dites « comités de pilotage ».
Ces comités sont des réunions en présence des responsables hiérarchiques du chef de projet et
permettent de faire un point sur l’avancement du projet.
Ces réunions peuvent être comme celles faites avec le client, soient mensuelles, trimestrielles…
en fonction des besoins de chacun.
L’objectif essentiel de ces comités de pilotage est d’observer plus particulièrement la répartition
du budget tout le long du projet, l’évolution de la marge en regardant bien si la société ne
dépensent pas plus d’argent qu’elle n’en gagne que le projet, de faire la gestion des risques, puis
également de prendre les décisions touchant directement aux finances du projet.
En troisième point, le chef de projet doit organiser avec son équipe projet une réunion
hebdomadaire afin d’assurer un suivi technique de l’avancement du projet.
Cette réunion permet donc à chacun de fournir un état d’avancement des différentes tâches qui
lui sont attribuées.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 52 / 79
Cela permet également au chef de projet de pouvoir donner d’autres tâches à ses collaborateurs,
d’établir des plans d’action pour faire face à des soucis pouvant survenir durant le projet, de
donner les nouvelles directives du projet en fonction de ce qui a été signaler durant les comités
de suivi et de pilotage…
En dernier point, le chef de projet peut, et à la demande de ses collaborateurs, organiser et
surtout planifier des réunions de travail entre les collaborateurs.
Ces réunions ont pour objectif en cas de problème technique, de réunir les personnes ayant les
compétences nécessaires pour résoudre le problème rencontré par l’un des collaborateurs.
Ces réunions peuvent être demandées que dans des cas vraiment critique et où il est important
d’allier toutes les compétences pour avancer le plus vite et éviter ainsi les dépassements de
délai.
6.2.1.5 La communication par messagerie
Dans les paragraphes précédents, il a été expliqué quelles solutions peuvent être mises en place
afin d’améliorer la communication au sein du projet.
Une dernière solution est également à mettre en place. Il s’agit de créer une messagerie
électronique commune à tous les membres du projet.
Ainsi, tous les membres peuvent communiquer par mèls en écrivant à une boîte mèl unique.
Tous les membres peuvent alors avoir le même niveau d’information et peuvent consulter les
mèls consacrés au projet à tout moment.
Il est à noter, que les messageries utilisées dans les sociétés sont des messageries qui offrent des
fonctions supplémentaires comme un calendrier, un répertoire…
Les deux fonctions citées permettent d’améliorer la communication lors d’un projet. Dans le cas
du répertoire, tous les contacts du projet sont mis dans ce répertoire et ils sont ainsi accessibles
à tous les membres du projet.
Le cas du calendrier est identique à celui du répertoire. Le chef de projet peut ainsi mettre à
disposition sur la messagerie commune le planning interne du projet. Cette partie sera détaillée
ultérieurement.
6.2.2 Les solutions possibles lors d’un changement dans le
management humain
Dans le paragraphe du management humain, plusieurs améliorations à mettre en place ont été
évoquées afin d’améliorer la conduite suivie lorsqu’un changement dans le management humain
intervient durant un projet informatique.
Afin de mettre en place ces améliorations, différentes solutions sont envisageables afin
d’améliorer tout d’abord les aspects de composition de l’équipe projet mais également les
aspects des plannings incluant les congés, les dates clés ainsi que leur mise à disposition aux
différents acteurs…
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 53 / 79
6.2.2.1 Composition de l’équipe projet
En premier point, la composition de l’équipe projet est faite par le chef de projet en fonction des
compétences des personnes, et des différentes technologies qui seront utilisées tout au long
projet.
Ainsi le chef de projet doit, en fonction de la charge de travail estimée ainsi que des délais prévus
pour le projet, faire une estimation sur l’effectif dont il a besoin sur le projet.
Le choix des membres de l’équipe projet se porte principalement sur leurs compétences. La
composition de l ‘équipe peut se faire de différentes manières et ce choix en revient au chef de
projet.
Premièrement, le chef de projet peut choisir de prendre des personnes spécialisées dans leur
domaine permettant ainsi d’avoir des compétences fortes avec des possibilités d’avancées
importantes. Chacun des membres se verra alors attribuer les modules dont les technologies
sont dans leur spécialité.
Deuxièmement, le chef de projet peut décider de choisir des personnes multi-compétentes sur
les technologies utilisées durant le projet. Le chef de projet peut alors attribuer la plupart des
modules du projet à tous les membres de l’équipe.
Par contre, comme il a été vu dans les paragraphes précédents, afin de palier à certain
changement de management humain, il est essentiel que le chef de projet prévoie du personnel
supplémentaire.
Ce personnel serait susceptible de remplacer les différents membres de l’équipe en cas
d’absence comme les congés maladies, les congés payés, les démissions…
Il existe différentes manières d’aborder le nombre de remplaçant à prendre pour chacun des
projets.
Une solution serait que le chef de projet choisisse de prendre une personne en plus par
technologie utilisée. Ainsi, si le projet utilise, par exemple, deux langages, le chef de projet doit
alors prendre deux personnes supplémentaires pour assurer les remplacements.
La seconde solution serait de prendre un pourcentage de personnes en plus. Par exemple, si le
chef de projet estime que l’équipe projet doit être constituée de dix personnes et qu’il a établi
que le pourcentage de remplaçant pour son projet s’élève à 10%, le chef de projet doit alors
prendre une personne de plus pour effectuer les remplacements.
En dernier point, le chef de projet doit imposer que les remplaçants participent à toutes les
réunions pour lesquelles les collaborateurs sont concernés. Cette présence est nécessaire et
obligatoire afin de s’assurer que les remplaçants soient au même niveau d’information que les
autres membres de l’équipe.
Le temps durant lequel le remplaçant ne participe pas au projet, à savoir le temps en dehors des
réunions ou des remplacements, est utilisé pour le travail au quotidien de la société.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 54 / 79
6.2.2.2 La planification
La planification d’un projet est un point essentiel pour le bon fonctionnement de celui-ci. Comme
il a été expliqué au §6.2.1.1, il existe deux types de planning, celui dit « interne » et celui de
« pilotage ».
Le planning détaillé dans ce paragraphe sera celui consacré aux collaborateurs, à savoir le
planning interne, puisque les améliorations à apporter concernent les changements survenant
dans le management humain durant le projet. Le planning de « pilotage » n’est donc pas
concerné dans ce paragraphe.
Dans un premier temps, le chef de projet doit s’attacher à détailler de manière très précise
le planning interne en indiquant les différents membres avec pour chacun les différents modules
à traiter ainsi que les dates de début et de fin pour chacun de ces modules.
Le chef de projet doit également faire apparaître sur ce planning les dates de congés payés prises
par chacun ainsi que les dates de formation, s’il y en a.
Derniers points à faire apparaître sur le planning, sont les dates clés du projet afin que chacun
des membres soient au même niveau d’information que le client.
Concernant les congés payés, le chef de projet doit mettre en place un système lui permettant de
connaître dès le commencement du projet ou suffisamment tôt, les dates de congés de chacun de
ses collaborateurs.
Pour cela, plusieurs solutions s’offrent à lui. Premièrement, en fonction de la durée du projet, il
peut demander à ces collaborateurs lors de la première réunion, celle d’initiation, que chacun
d’eux lui donne ces congés payés dans un délai d’une semaine ou à la demande du chef de projet
dans le cas de projet de longue durée. Cela permet ainsi de pouvoir planifier tout le projet dès
son commencement.
Deuxièmement, le chef de projet peut demander à ce que ces collaborateurs lui donnent leurs
congés au minimum deux mois avant la date souhaitée, ceci permettant au chef de projet de
pouvoir replanifier le projet en fonction de ces nouvelles données.
Cela permet de laisser plus de liberté aux collaborateurs, et le délai de deux mois permet
également au chef de projet de pouvoir se retourner et de ne pas se retrouver en défaut face à ce
type de changement.
Dans un second temps, le chef de projet doit mettre à disposition le planning à tous les membres
de l’équipe projet afin que chacun puisse le consulter à tout moment. Pour cela, le chef de projet
a deux solutions.
Premièrement, il peut faire son planning par le biais d’un tableur comme l’application Excel. Ce
fichier serait alors stocker sur un serveur de fichier au même endroit que le reste des documents
du projet.
Deuxièmement, le chef de projet peut utiliser une application présente pour chaque membre du
projet, la messagerie. En effet, les messageries utilisées dans les sociétés sont toutes dotés d’un
calendrier personnel qui peut être partagé. Il est également possible comme il a été vu
précédemment de créer une boîte générique à laquelle tous les membres ont accès. Cette boîte
contient elle aussi un calendrier qui est donc accessible par toutes les personnes autorisées à
utiliser cette boîte générique.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 55 / 79
Ainsi, comme il a été vu dans le §6.2.1.5, le planning interne du projet peut être mis à disposition
sur le calendrier de la messagerie commune entre les différents membres du projet. Ils ont donc
accès à tout moment aux informations nécessaires sur les travaux qui leurs sont confiés.
6.2.3 Les solutions possibles lors d’un changement dans le
management technique
Dans le paragraphe consacré aux améliorations à faire dans le management technique, plusieurs
améliorations ont été évoquées afin que la conduite suivie, lorsqu’un changement dans le
management technique survient durant un projet, soit améliorée.
Dans ce paragraphe, vont être évoquées les différentes solutions pouvant répondre aux
améliorations évoquées auparavant.
La première solution est un complément d’une solution évoquée dans le paragraphe sur la
gestion de projet, le « dossier collaborateur » (§6.2.1.1). Ce dossier permet d’avoir toutes les
informations nécessaires sur les membres composant l’équipe projet.
Pour compléter cette solution, détaillée dans le paragraphe sur la gestion de projet, et afin
d’améliorer le management technique, il faut que les informations concernant les compétences
techniques présents dans chacun des dossiers collaborateurs soient intégrés dans une base de
données.
Cette intégration permettra de ressortir uniquement les compétences techniques en cas de
changement dans le domaine technique.
De plus cette base de données sera accessible par toutes les personnes de la société, et pourra
donc être utilisée pour constituer d’autres équipes sur des nouveaux projets ou pour embaucher
de nouvelles personnes ayant des compétences non répertoriées dans la société.
La seconde solution présentée dans ce paragraphe concerne les changements d’architecture
réseau qui ont été évoqués tout au long de ce mémoire.
Dans un cas comme celui là, et comme il a été précisé dans le paragraphe sur les améliorations,
le chef de projet doit impérativement planifier ce type de changement et plus particulièrement
lorsqu’ils sont prévus.
Pour ce faire, le chef de projet doit mettre en place une documentation montrant comment
effectuer la bascule entre l’ancienne architecture réseau et la nouvelle, ce sont les modes
opératoires.
Ces documents doivent être préparés et testés plusieurs fois afin de s’assurer qu’il n’y a pas
d’erreur. Une fois ces modes opératoires rédigés, le chef de projet doit planifier des phases de
tests de bascules avant d’effectuer la migration définitive.
Deux possibilités s’offrent à cette solution, soit l’équipe projet rédige le mode opératoire et le
chef de projet prévoit deux phases de tests. Si ces deux phases sont validées alors le mode
opératoire est approuvé.
Soit le mode opératoire est découpé en plusieurs modules qui sont testés au fur et à mesure. Une
fois tous les modules testés, le chef de projet planifie une phase de test globale. Si cette phase est
validée alors le mode opératoire est approuvé.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 56 / 79
Dans les deux cas, après chaque phase de tests qu’elles soient globales ou non, le testeur doit
remplir une fiche de test permettant de lister toutes les anomalies rencontrées lors des tests.
6.2.4 Les solutions possibles lors d’un changement dans le management commercial
Dans ce paragraphe seront détaillées les solutions qui peuvent être mise en place afin de
répondre aux améliorations qui ont été évoquées dans les chapitres précédents sur le
management commercial.
Dans les chapitres précédents, l’analyse et la critique de l’existant ainsi que les améliorations ont
été fait pour deux changements, les modifications de périmètre et les avenants au contrat.
Concernant les modifications de périmètre, les solutions à apporter concernent essentiellement
les procédures à suivre, par le commercial et le chef de projet, face aux demandes de
changement de périmètre faites par le client.
Premièrement, lorsque le client annonce son souhait de modifier le périmètre prévu
initialement, il a été vu dans les améliorations à apporter, qu’il faut impérativement que le
commercial négocie un changement des délais prévus initialement afin de prendre en compte ce
changement de périmètre.
Pour cela, et afin de faciliter le travail du commercial, il faut écrire des pré-requis lorsqu’un
changement de périmètre survient durant un projet. Ces pré-requis doivent être applicables
quels que soit le projet.
Dans ce pré-requis doivent apparaître que pour tout changement de périmètre, la société
responsable du projet se donne un délai de sept jours maximum pour donner au client le temps
nécessaire dont l’équipe projet a besoin pour répondre à sa demande. Ce délai est alors accepté
ou non par le client. Une négociation doit alors se faire le cas échéant.
Deuxièmement, et dans le cadre des avenants au contrat, les solutions à mettre en place sont
équivalentes à celles évoquées dans le §6.2.1.
En effet, afin d’améliorer la conduite suivie lorsqu’un avenant au contrat est annoncé, il faut
améliorer la communication.
Ce sont donc des solutions telles que la rédaction de documents tout le long du projet initial, le
suivi du projet… qui doivent être mises en place afin que lors de l’apparition d’avenants au
contrat, les futurs collaborateurs et responsables de projet aient un niveau d’information assez
important afin de pouvoir répondre à cet avenant.
De plus, comme dans la première solution évoquée dans ce paragraphe, il faut, lors de la
signature de l’avenant avec le client, que le commercial négocie un délai afin d’informer le futur
chef de projet de la signature d’un avenant, et lui laisser le temps de prendre connaissance du
projet et pouvoir définir la charge de travail qu’il faut pour répondre à la demande du client.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 57 / 79
6.2.5 Les solutions possibles lors d’un changement dans le
management financier
Dans le paragraphe sur le management financier, plusieurs améliorations à mettre en place ont
été évoquées afin d’améliorer la conduite suivie lorsqu’un changement dans le management
financier intervient durant un projet informatique.
Afin de mettre en place ces améliorations, différentes solutions sont envisageables afin
d’améliorer tout d’abord la conduite suivie lorsque des restrictions budgétaires interviennent
durant un projet informatique, mais également la conduite suivie lorsque le changement
intervenant durant le projet est le rachat d’une société.
Premièrement, concernant les restrictions budgétaires deux solutions sont envisageables afin de
faire face à un tel changement.
La première solution consiste à ce que le chef de projet, à l’initial du projet, mette par écrit la
répartition prévue du budget qui lui a été accordé. Une fois cette répartition faite, le chef de
projet le fait valider par sa hiérarchie afin que, d’une part ses responsables soient au courant de
la répartition du budget, d’autre part que les responsables assurent au chef de projet par leur
validation que le budget ne changera pas. Cette validation permet ainsi de protéger le budget
prévu quelques soient les restrictions budgétaires qui sont mises en place.
La seconde solution consiste à ce que le chef de projet lors de l’initialisation du projet inclus
dans son budget une partie sur la gestion des risques et donc le budget correspondant à ces
risques. Ainsi dans son projet, le budget est composé du budget prévu pour mener à bien le
projet puis le budget prévu pour les risques qui peuvent survenir de manière inattendu durant
le projet.
Par conséquent, le chef de projet demande à ses responsables un budget supérieur au budget
nécessaire ce qui lui permet ainsi de pouvoir faire face aux restrictions budgétaires qui sont
comprises dans le budget dans la partie risque.
Deuxièmement, concernant le rachat de société, il n’y a pas de solutions spécifiques
supplémentaires à mettre en place pour faire face à ce type de changement mises à part les
solutions évoquées précédemment.
6.2.6 Les solutions possibles lors d’un changement dans le management de production
Dans ce paragraphe seront détaillées les solutions qui peuvent être mise en place afin de
répondre aux améliorations qui ont été évoquées dans les chapitres précédents sur le
management de production.
Deux types de changements ont été évoqués dans l’analyse de l’existant consacré aux
changements dans le management de production, un changement de type « produit final non
fonctionnel » et un second de type « architecture cliente modifiée ».
Les solutions qui peuvent être mises en place concernant le premier type de changement, à
savoir le produit final non fonctionnel, sont les mêmes solutions que celles citées précédemment
sur la gestion de projet (§6.2.1).
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 58 / 79
En effet, afin d’améliorer la communication, pour palier à ce type de changement, il faut que le
chef de projet fasse le nécessaire, comme expliqué dans le §6.2.1, pour que de la documentation
soit rédigée sur tous les aspects du projet. La solution consiste, dans ce cas, à beaucoup
communiquer, vers les collaborateurs mais aussi vers le client, afin de pouvoir éviter des échecs
lors de la mise en production de produits finaux.
La solution passe donc essentiellement sur de la gestion de projet avec de la rédaction de
documentation, de l’organisation de réunions…
Dans le paragraphe détaillant les améliorations à apporter, il a été clairement évoqué que le chef
de projet doit lorsqu’il est nommé sur un projet, faire en sorte d’établir un produit final qui
puisse vivre dans le temps. Par conséquent, le produit final doit pouvoir fonctionner, moyennant
des modifications minimes, dans tous les environnements, puis il doit pouvoir répondre aux
éventuels besoins futur du client.
Ainsi, le chef de projet s’assure de pouvoir faire face aux changements de type « architecture
cliente modifiée ».
Pour cela plusieurs solutions peuvent être mise en place afin de palier à ce type de changement.
La première solution consiste à faire un point avec le client sur les souhaits d’avenir de son
projet. Ce point permettra au chef de projet de constituer les différents modules de telles sortes
que ces derniers soient maintenables et par conséquent modifiables en fonction des nouveaux
besoins.
De plus, le chef de projet doit également se renseigner auprès du client sur les éventuels
changements d’architecture qu’il pourrait faire, à savoir si le client a projeté à court, moyen ou
long terme des modifications d’architecture. Si tel est le cas, le chef de projet doit demander au
client de lui fournir les informations nécessaires sur ces modifications afin de pouvoir en tenir
compte pour le projet.
La seconde solution consiste à ce que le chef de projet prenne contact avec les constructeurs
matériels utilisés par le client.
En effet, le client a dans sa société du matériel provenant d’un ou plusieurs constructeurs.
L’objectif du chef de projet est de prendre contact avec ces constructeurs afin de se renseigner
sur les évolutions à venir du matériel utilisé par le client.
Ainsi, le chef de projet peut prendre en compte les évolutions futures et faire en sorte que le
produit soit compatible avec ces évolutions.
6.3 Choix des solutions d’amélioration
Dans le chapitre précédent, il a été détaillé les différentes solutions qui peuvent être mise en
place afin d’améliorer les différentes conduites suivies face aux nombreux changements qui
peuvent survenir durant un projet informatique.
Toutes les solutions présentées sont toutes des solutions exploitables mais certaines de ces
solutions sont plus pertinentes.
Par conséquent, c’est dans ce paragraphe que vont être mises en avant les solutions retenues
afin d’améliorer les conduites suivies, durant les projets informatique, face au changement.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 59 / 79
6.3.1 La gestion de projet
Comme il a été expliqué tout au long de ce mémoire, les différents changements pouvant
survenir durant un projet informatique, mettent dans la quasi totalité des cas, la gestion de
projet en défaut.
Les solutions retenues afin d’améliorer la gestion d’un projet et ainsi pouvoir faire face aux
différents changements vont être sélectionnées dans ce paragraphe.
Il a donc été choisi de prendre la totalité des solutions évoquées dans le §6.2.1. Par conséquent,
concernant la partie documentation, il est retenu de mettre en place les documents essentiels
qui sont l’analyse des besoins, les dossiers collaborateurs, les plannings, le plan d’assurance
qualité, le cahier de recette, les fiches de tests, les fiches des tâches et les documentations
d’installation, d’utilisation et d’administration.
Bien entendu, ces documents peuvent être accompagnés d’autres documents en fonction des
besoins sur le projet.
Il a été également retenu de faire une procédure permettant de mettre en relation tous les
documents faits pour le projet et durant le projet.
En troisième point, il a été choisi de mettre en place la solution de l’outil de gestion électronique
des documents (GED), concernant la gestion et le stockage de la documentation.
En dernier point sur la gestion de projet, il a été retenu pour améliorer la conduite suivi pour la
gestion de projet face aux changements, d’organiser plusieurs type de réunions quelque soit le
projet.
Ainsi, chaque semaine, une réunion de travail sera organisée par le chef de projet afin de faire
un suivi sur l’avancement du projet, mais aussi afin d’avoir des remontées de problèmes
rencontrés par les différents collaborateurs.
Chaque réunion doit au final aboutir sur un plan d’action et devra être suivie par un compte-
rendu envoyé à chacun des participants, plus d’autres personnes en fonction des besoins.
Chaque mois, un comité de suivi devra être organisé par le chef de projet avec le client afin de
faire un point sur l’état d’avancement du projet, et de pouvoir remonter les différents problèmes
ou besoin de part et d’autre.
Pour terminer, un comité de pilotage devra être organisé par le chef de projet avant chaque date
clé du projet afin de faire l’état d’avancement du projet avec les responsables hiérarchiques du
chef de projet.
6.3.2 Le management humain
Sur les aspects de management humain, il va être détaillé les solutions qui ont été retenues pour
améliorer les conduites suivies face aux changements dans ce type de management.
Concernant la composition de l’équipe projet, les solutions choisies sont les suivantes.
Premièrement la composition de l’équipe projet doit se faire avec des personnes multi-
compétentes afin de pouvoir attribuer n’importe quel module à n’importe quel membre de
l’équipe projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 60 / 79
Deuxièmement, concernant le nombre de remplaçant, la solution choisie est de prendre le
nombre de remplaçant en fonction d’un pourcentage fixé par le chef de projet au
commencement du projet, comme expliqué dans le §6.2.2.1.
Enfin, les remplaçants doivent impérativement participer aux réunions d’avancement du projet.
Concernant la planification, les solutions choisies sont les suivantes.
Premièrement, le chef de projet doit demander à chacun de ces collaborateurs de lui fournir les
dates des congés payés qu’ils souhaitent prendre, hors journées occasionnelles, dès le
commencement du projet ou à la demande du chef de projet dans le cas de projet de longue
durée. Ainsi cela permet au chef de projet de pouvoir planifier le projet dès son commencement.
Deuxièmement, le planning sera mis à disposition de chacun des membres par le biais du
calendrier d’une messagerie commune. De plus, toutes les communications écrites concernant le
projet devront être faites à partir de cette messagerie commune. Chaque membre de l’équipe
projet aura donc accès à tous les messages concernant le projet ainsi qu’au planning.
6.3.3 Le management technique
Les solutions proposées pour des changements intervenant sur le management technique ont
été sélectionnés afin qu’il en ressorte les plus pertinentes.
Afin d’améliorer les conduites suivies face à un changement dans le management technique
durant un projet informatique, les solutions à mettre en place sont les suivantes.
Tout d’abord, la première solution retenue est la constitution d’une base de données sur les
informations administratives et les compétences techniques de chaque employé de la société.
Cette base de données permettra d’avoir un panel des compétences existantes au sein de
l’entreprise mais également de pouvoir constituer des équipes projet plus rapidement en
fonction des compétences de chacun.
De plus, la seconde solution retenue, concerne la préparation de la bascule d’une architecture à
l’autre. Pour cela, il a été retenu que le mode opératoire de la bascule sera découpé en plusieurs
modules qui seront tous testés séparément. Une fois tous ces tests effectués, une phase de tests
globale sera planifiée par le chef de projet afin de s’assurer que le mode opératoire est valide.
Chaque test effectué sera suivi d’une fiche de test à remplir permettant de lister toutes les
anomalies rencontrées lors des tests.
6.3.4 Le management commercial
Dans ce paragraphe vont être détaillées les solutions choisies pour améliorer les conduites
suivies lorsque des changements dans le management commercial interviennent durant des
projets informatiques.
La première solution choisie concerne les modifications de périmètre. En effet, il a été retenu de
mettre en place et par écrit des pré-requis lors de changements de périmètre.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 61 / 79
Ces pré-requis permettant d’une part au commercial de pouvoir négocier plus facilement des
délais, et d’autre part au chef de projet de pouvoir planifier « sans pression » le travail à
effectuer pour répondre à la demande du client.
La deuxième solution retenue concerne les avenants au contrat. Cette solution a déjà été
évoquée auparavant. En effet, les solutions à mettre en place sont celles détaillées dans le
paragraphe sur la gestion de projet (§6.3.1).
6.3.5 Le management financier
Dans le paragraphe sur le management financier, plusieurs solutions ont été trouvées afin de
pouvoir améliorer les conduites suivies face à des changements intervenant dans ce type de
management durant un projet informatique.
Les solutions qui ont été retenues afin de mettre en place ces améliorations vont être détaillées
dans ce paragraphe.
La première solution qui a été retenue concernant les restrictions de budget est que le chef de
projet fasse l’estimation de son budget en prenant en compte la gestion des risques comme le
changement de personnel, le changement de technologie…
Concernant le rachat de la société et comme il a été expliqué dans tous les paragraphes traitant
ce changement, toutes les solutions évoquées dans ce chapitre sont à prendre en compte, ou plus
exactement à mettre en place lorsqu’un tel changement intervient durant un projet.
6.3.6 Le management de production
Dans ce paragraphe vont être évoquées les solutions qui sont retenues afin d’améliorer les
conduites suivie face aux changements dans le management de production.
Premièrement, comme pour tous les autres types de management, la première solution est celle
évoquée dans le paragraphe 6.3.1 sur la gestion de projet.
Il est en effet nécessaire de mettre en place les moyens nécessaires pour améliorer la gestion de
projet et la communication durant un projet.
Deuxièmement, concernant l’évolution dans le temps du projet, les solutions évoquées dans le §
6.2.6 sont toutes les deux retenues, à savoir que le chef de projet doit s’entretenir aussi bien avec
le client qu’avec les constructeurs afin de connaître pour chacun d’eux quelles sont les
évolutions futures qui vont être mises en place.
6.4 Argumentation et justification du choix
Il a été vu tout au long de ce mémoire les différentes conduites qui sont aujourd’hui suivies pour
faire face aux changements. De cet existant, il a été effectué une analyse critique de l’existant,
puis il a été apporté les différentes améliorations qui pouvaient être faites.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 62 / 79
De ces améliorations il en est ressorti des solutions qui ont été sélectionnées afin de garder
essentiellement les solutions les plus pertinentes.
Dans ce paragraphe, il va être expliqué pourquoi les solutions citées dans le chapitre précédent
ont été retenues.
6.4.1 La gestion de projet
Concernant la gestion de projet, il a été décidé de garder la solution concernant les différents
documents à rédiger car c’est la base pour effectuer une bonne gestion de projet.
En effet, même si les informations sont connus de tout le monde, il est important que ces
informations soit retranscrit de manière manuscrite afin dans un premier temps d’en garder une
trace écrite et ainsi d’avoir des justificatifs en cas de problème.
De plus, un projet terminé peut très bien être amené à être modifier par des avenants au contrat,
plusieurs années après sa mise en production. Par conséquent, il est important de tout mettre
par écrit afin de pouvoir récupérer toutes les informations qui ont circulées durant le projet
initial.
Il est également à noter, que la documentation fait partie des livrables qui peuvent être réclamé
par le client. Certes tous les documents ne sont pas forcément à fournir au client comme les
comptes-rendus des réunions internes mais la plupart des documents peuvent être réclamés. Il
faut donc les rédigés pour pouvoir les fournir au client.
Concernant la procédure à mettre en place pour faire la liaison entre les différents documents
présents dans le projet. Il est important de la faire car ce document permet d’organiser la
documentation liée au projet mais également ce document permet de centraliser les
informations au même endroit.
Au sujet de l’outil de gestion électronique des documents, ce choix s’est porté sur la GED car c’est
un outil qui permet de gérer automatiquement les versions de document.
De plus cet outil est doté d’un système de workflow qui permet de faire passer chaque document
rédigé dans un processus de validation.
Cela permet ainsi d’avoir un suivi qualité de la documentation projet. Enfin avec un outil comme
la GED, les membres du projet ont un endroit unique pour consulter et déposer des documents
liés au projet, ce qui évite de se poser des questions sur la validité des documents.
Enfin, concernant les réunions organisées par le chef de projet, il est important d’en faire autant
par soucis de communication. Il est important que chaque acteur lié au projet, comme les
collaborateurs, le client ou les responsables hiérarchiques, soient au même niveau d’information
sur l’état d’avancement du projet.
Par contre, il est important de faire des réunions différentes car l’ordre du jour de chaque
réunion sera différent en fonction des personnes assistant à la réunion.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 63 / 79
6.4.2 Le management humain
Le choix concernant la composition de l’équipe projet s’est porté sur des membres tous multi-
compétents.
La justification de ce choix est, qu’il est important que chaque membre de l’équipe projet puisse
travailler sur un module ou qu’il puisse prendre le module d’un de ces collègues.
De plus, cela permet à chacun des membres du projet de pouvoir étoffer ses domaines de
compétences techniques et d’acquérir ainsi plus d’expérience professionnelle et plus d’expertise
sur les technologies utilisées durant le projet.
Enfin, d’un point de vue financier, un expert coûte plus cher qu’une personne multi-compétente
puisque cette dernière n’ira pas aussi loin qu’un expert dans son développement ou elle mettra
plus de temps qu’un expert pour trouver des solutions.
Par contre en cas de changement de technologie, une personne multi-compétente saura
s’adapter ce qui n’est pas le cas d’un expert.
Le choix de la seconde solution retenue pour la composition de l’équipe s’est porté sur le
nombre de remplaçant choisi en fonction d’un pourcentage choisi par le chef de projet sur
l ‘équipe initiale.
Cette solution a été choisie car elle est moins coûteuse que de prendre un remplaçant par
technologie utilisée. Dans ce dernier cas, il faudrait prendre des experts et comme il a été
expliqué juste avant, un expert coûte cher et il n’est plus compétent en cas de changement de
technologie dans un domaine qui n’est pas le sien.
De plus, prendre un nombre de remplaçant sur un pourcentage de l’équipe initial permet d’avoir
un nombre plus ou moins important de remplaçants en fonction de la taille du projet et par
conséquent de la taille de l’équipe projet.
Concernant les choix faits sur la planification du projet, ils ont été faits par soucis d’efficacité. En
effet, de posséder les dates de congés de tous les membres de l’équipe projet au commencement
de celui-ci ou à la demande du chef de projet dans le cas de projet de longue durée, cela permet
au chef de projet de pouvoir s’engage de manière sûre et quasi définitive sur les dates clés du
projet.
De plus, en fonction des congés de chacun, le chef de projet peut attribuer les modules en
fonction des périodes d’absence et en fonction de la charge de travail prévue pour chaque
module.
Concernant le choix fait pour la mise à disposition du planning aux membres de l’équipe ainsi
que pour la communication durant le projet, il s’est porté sur la messagerie de groupe car à
l’heure d’aujourd’hui toutes les sociétés sont en possession d’une messagerie de groupe qui
permet de communiquer mais aussi qui permet de planifier ces journées.
C’est donc une solution pratique connue de tous les membres de l’équipe mais c’est également
une solution peu coûteuse puisqu’elle est déjà utilisée par la société. Il n’y a donc pas de
dépenses à faire.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 64 / 79
6.4.3 Le management technique
Les solutions choisies pour améliorer les conduites suivies face au changement dans le
management technique durant un projet informatique concerne premièrement la mise en place
d’une base de données unique sur les informations administratives et les compétences
techniques de chaque employé et deuxièmement l’organisation des phases de tests d’un projet.
Dans le premier cas, le choix qui a été fait s’est essentiellement basé sur l’utilité et l’efficacité de
mettre en place une base de données. Elle permet d’avoir un historique et un panel des
compétences présentes au sein de la société.
De plus elle permet de faciliter le travail des chefs de projet lors de la composition de leur
équipe.
Par ailleurs, cette base de données est un pont d’entrée et de recherche unique pour toutes les
personnes ayant besoin de renseignements sur les compétences techniques qui existent au sein
de la société.
Concernant l’organisation des phases de tests, il a été choisi de tester séparément chaque
module car cela permet de faire ces tests de manière rapide et non fastidieuse.
En effet, il suffi de demander à chacun des membres de tester le module qui a été développer et
cela évite ainsi qu’un seul membre test tous les modules. Cela permet donc un gain de temps et
par conséquent un gain d’argent.
6.4.4 Le management commercial
Dans ce paragraphe, il va être expliqué pourquoi le choix de la solution s’est portée sur la
rédaction d’un document annonçant les pré-requis lorsqu’un changement au niveau du
management commercial intervient.
Ce document permet au commercial mais aussi au chef de projet de pouvoir informer le client
sur les méthodes utilisées par la société pour mettre en place les modifications de périmètre
tout comme les avenants au contrat.
Ce document permet donc de pouvoir négocier plus facilement avec le client les délais
d’exécution et ainsi éviter les dépassements de délais et par conséquent éviter le paiement de
pénalités pour non respect du contrat.
6.4.5 Le management financier
Il va être abordé dans ce paragraphe l’explication du choix qu’il a été fait pour constituer un
budget de départ.
Il a été choisi de budgéter dans le projet la part de risques. Ce choix s’explique tout simplement
par le fait qu’il vaut mieux prévoir un budget plus important au départ au risque qu’il reste de
l’argent à la fin du projet plus que de prévoir au plus juste et risquer de se retrouver à financer
des éléments qui n’étaient pas prévus au budget.
Cela permet donc d’éviter ou plutôt de minimiser les risques de diminution de marge sur les
contrats signés.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 65 / 79
6.4.6 Le management de production
Le paragraphe concernant le choix des solutions pour le management de production est
composé de toutes les solutions qui avaient étaient proposées dans le §6.2.6.
Ce choix s’explique par le fait que le client ou le constructeur sont deux entités complètement
différentes et qu’il est important de les consulter quelque soit le projet.
En effet, lorsque le client aura décidé de faire évoluer son architecture, il s’adressera
automatiquement à son ou ses constructeurs afin de savoir et de comprendre comment il peut
faire évoluer son architecture.
Il est donc important pour l’équipe projet de connaître d’une part les évolutions souhaitées par
le client, et d’autre part les possibilités d’évolutions que le ou les constructeurs peuvent
proposer au client.
6.5 Description détaillée de la solution choisie
Dans ce paragraphe vont être détaillées de manière plus précise les solutions choisies dans les
paragraphes précédents.
6.5.1 La gestion de projet
6.5.1.1 La documentation
Les documents choisis dans le paragraphe 6.3.1 vont être détaillées ici afin d’en comprendre
clairement leur utilité mais aussi quand ces documents doivent intervenir dans un projet
informatique.
Le premier document choisi est l’analyse des besoins. Ce document est le premier document
rédigé par la société en charge de faire le projet. De plus cette analyse est faite par le chef de
projet de manière grossière afin, dans un premier temps de comprendre les besoins du client
puis dans un second temps de bien lister les technologies qui seront utilisées durant son projet
afin de pouvoir choisir ces collaborateurs.
Ce document est donc le fruit de l’analyse du cahier des charges fournit par le client et permet de
comprendre les différents éléments que le client souhaite avoir au final de son projet.
Ce document permet également au chef de projet à la fin du projet de s’assurer que tous les
éléments qui étaient détaillés dans le cahier des charges ont bien été développés.
De plus, ce document sur l’analyse des besoins fera l’objet d’un comité avec le client afin de
s’assurer que tous les besoins de ce dernier ont bien été pris en compte.
Le second document est « un dossier collaborateur ». Ce document, ou plutôt ce dossier,
comporte tous les curriculum vitae des collaborateurs sélectionnés dans l’équipe projet.
Ces CV sont formatés selon une trame unique, celle de la société, ce qui permet d’avoir les
informations uniquement nécessaires à la société.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 66 / 79
En effet, dans le cadre du « dossier collaborateur », certaines informations comme les sociétés
dans lesquels ont travaillés les collaborateurs auparavant, ne sont pas nécessaires.
Le but de ce dossier n’est pas d’embaucher des personnes mais simplement de sélectionner des
collaborateurs en fonction de leurs compétences.
Le troisième type de document est le planning. Ce document est le cœur du projet puisque c’est
lui qui permettra de gérer le temps et par conséquent de gérer les délais.
Comme expliqué auparavant dans le mémoire, il y a deux types de planning, un planning dit
« interne », celui réservé à l’équipe projet et un planning dit « de pilotage », celui présenté au
client.
Le planning interne entrera dans les détails et présentera les différents modules du projet, le
temps imparti pour chaque module et les personnes sélectionnées pour travailler sur chacun
d’eux.
Seront également présents sur le planning interne, les congés, les formations ainsi que les
différentes réunions de travail organisées par le chef de projet.
Le second planning, celui dit de « pilotage » est utilisé pour montrer au client le déroulement
prévu pour le projet. Dans ce planning apparaîtra essentiellement les dates importantes, comme
le commencement du projet, les phases de test, la recette, la mise en production, les comités de
pilotage….
Le quatrième document est le plan d’assurance qualité (PAQ). Ce document s’assure de la bonne
qualité du déroulement du projet mais aussi et surtout ce document est le fil conducteur du
projet, c’est un référentiel commun.
Il et mis à disposition de tous les acteurs du projet permettant d’assurer ainsi la qualité du projet
ainsi que la qualité du suivi.
Tout le long du projet, des documents sont rédigés comme les fiches des tâches permettant de
détailler les différents modules et le travail à effectuer pour chacun, les comptes-rendus de
réunion (interne et cliente), les fiches de test pour chaque module finalisé, les documentations
d’installation, d’administration et d’utilisation, la documentation du codage lorsqu’il s’agit du
développement d’un produit.
Le dernier document est le cahier de recette. Ce document est présenté au client lors de la mise
en production de son projet. Ce document l’informe des éléments qui ont été fait et ceux qu’il
reste à faire si c’est le cas.
Il comporte également les différentes fiches de test permettant de prouver au client que les
différents modules attendus fonctionnent.
D’autres documents seront bien entendu rédigés par le chef de projet ou ces collaborateurs
selon les besoins et en fonction du déroulement du projet
6.5.1.2 Utilisation de la documentation
La solution qui a été retenue concernant l’utilisation de la documentation est « la procédure de
gestion de projet ».
Comme il a été vu dans le paragraphe 6.2.1.2, la procédure de gestion de projet permet de lister
dans un premier temps les différentes étapes, les enchaînements entre chacune d’elles et les
documents qui y sont associés ou qui doivent être faits.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 67 / 79
Ces documents, tels que les fiches de test, les documents d’installation, etc. seront des
documents dits « applicables ». Il existera également dans cette procédure, des documents dit
« de référence » qui seront le plan d’assurance qualité, le planning, l’analyse des besoins…
Les documents applicables sont des documents qui permettent de détailler de manière très
précise les actions à mener sur tel ou tel élément du projet.
Les documents de référence sont des documents qui permettent d’expliquer de manière globale
les actions à mener pour le projet. Les documents de références font appel aux documents
applicables.
Cette procédure devra également signaler où se trouve les différents documents de références et
les documents applicables.
De plus il devra également y avoir dans ce document la liste et les contacts des différentes
personnes liées au projet.
Ainsi, seront présents les contacts clients mais aussi les contacts des personnes référents du
projet comme le chef de projet, le responsable qualité, le commercial, le responsable de
compte…
Cette procédure sera accessible à tous les membres de l’équipe projet comme le chef de projet,
les collaborateurs, les responsables hiérarchiques… et sera mis à disposition de chacun par le
biais de l’outil de gestion des documents (GED).
6.5.1.3 Gestion et stockage de la documentation
La solution retenue, pour gérer et stocker toute la documentation du projet, consiste à mettre en
place un outil de gestion électronique des documents (GED).
Cet outil permet de référencer de manière unique chaque document créé mais également
d’effectuer un cycle de vie d’un document, à savoir la rédaction d’un document, suivi par sa
vérification, son approbation, sa publication et dans certains cas sa révision.
Ces différentes étapes sont faites à l’aide d’un workflow* incluant différents acteurs. Par
exemple, un collaborateur rédige un document qui est ensuite vérifié par le responsable qualité,
puis approuvé et distribué par le chef de projet.
Le document est à la fin de cycle de création dit « applicable ». Mais le cycle de vie du document
n’est pas terminé, car le cycle de vie d’un document se termine que lorsque le document est dit
« périmé ».
L’outil GED permet de faire le cycle de vie d’un document de A à Z. En effet, une fois que le
document est applicable, il peut subir des étapes de « version », autrement dit lorsque des
informations à l’intérieure du document doivent être changées, il faut par le biais de l’outil GED
créer une nouvelle version du document.
Cette nouvelle version permet d’une part de lister les changements qui ont été faits dans le
document et d’autre part elle permet de commencer un nouveau cycle de vie pour le document.
Ainsi le document en version 1 devient périmé, une fois que la nouvelle version du document,
soit la version 2 ou 1.1, est applicable.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 68 / 79
Enfin grâce au système de workflow, l’outil GED permet de faire un suivi sur les différents
acteurs qui sont intervenus dans la vie d’un document avec les dates et les heures précises des
modifications.
6.5.1.4 Les différentes réunions
Concernant les différentes réunions que le chef de projet doit organiser, il n’y a pas réellement
de détails à donner mis à part le fait qu’à la fin de chaque réunion, le chef de projet doit
impérativement rédiger un compte-rendu de réunion et le distribuer aux participants et aux
éventuels acteurs cités durant la réunion.
6.5.1.5 La communication par messagerie
Dès le commencement du projet et de la composition de l’équipe projet, le chef de projet doit
faire créer une messagerie électronique commune à tous les membres.
La messagerie commune doit alors être paramétrée sur chacune des messageries des membres
de l’équipe projet afin qu’ils puissent avoir accès aux messages mais aussi avoir accès au
calendrier partagé.
L’adresse de cette messagerie doit être communiquée au client afin que ce dernier puisse
communiquer avec les membres de l’équipe projet si besoin notamment pour des problèmes
techniques.
Cette messagerie est gérée essentiellement par le chef de projet, c’est ce dernier qui met à jour le
calendrier. De plus, c’est le chef de projet qui doit organiser de manière claire la messagerie en
créant des dossiers en fonction des besoins. Il peut ainsi créer un dossier par module par
exemple.
Tous les messages envoyés par un membre de l’équipe projet concernant le projet doit se faire
obligatoirement par la messagerie commune afin qu’il n’y ait aucune perte d’information.
A l’inverse, toute communication externe concernant le développement du projet doit arriver
dans la messagerie commune afin que tous les membres de l’équipe puissent en prendre
connaissance.
La messagerie commune permet également de pouvoir gérer des droits. Ainsi, le chef de projet
peut demander à ce que les différents membres de l’équipe projet soit interdit de supprimer les
messages présents dans la messagerie commune.
Le chef de projet peut également, demander à ce que les membres de l’équipe ne puissent pas
créer de nouveau dossier.
Tout ceci permet au chef de projet de pouvoir gérer seul la messagerie commune et ainsi de
pouvoir en contrôler son contenu et son organisation.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 69 / 79
6.5.1 Le management humain
Concernant les aspects du management humain, deux points sont importants. Le premier point
concerne essentiellement la composition de l’équipe projet au commencement de celui-ci, le
second point s’attarde plus particulièrement sur la planification du projet et notamment
comment gérer les aspects congés payés et les aspects de mise à disposition du planning.
Dans les solutions choisies évoquées précédemment, il a été décidé de constituer l’équipe projet
de personnes multi-compétentes avec un pourcentage de remplaçant défini par le chef de projet.
Pour détailler, de manière plus précise, la composition de l’équipe est en fait basée sur de la
multi-compétence, autrement dit, le chef de projet ne recherche pas de personnes spécialisé d’un
un seul domaine.
Ainsi, dans un projet, il y a de multiples technologies qui sont utilisées entre le système
d’exploitation, le langage de programmation ou l’architecture, le matériel utilisé par le client…
Il est donc important pour un projet, de trouver des personnes qui sont non seulement
compétentes sur les technologies utilisées durant le projet mais aussi sur des technologies
susceptibles d’être utilisées pour l’avenir du projet.
Ainsi les collaborateurs peuvent amener leurs compétences afin de pouvoir imaginer quel avenir
peut avoir le projet et par conséquent quelles est la manière la plus judicieuse de développer le
projet afin que celui-ci puisse vivre dans le temps.
Par contre, le chef de projet n’est pas dans l’obligation de trouver des personnes ayant des
compétences dans toutes les technologies utilisées durant le projet. Ces personnes peuvent très
bien être compétentes dans seulement deux ou trois technologies utilisées.
Il en va de même pour les remplaçants. Ces derniers doivent être choisis de la même manière
que les membres « titulaires ».
Concernant, la planification, le but est d’avoir toutes les informations nécessaires sur le planning
du projet au commencement de celui-ci. C’est pour cela qu’il a été choisie comme solution que
tous les membres de l’équipe projet fournissent au chef de projet leurs dates de congés dès le
commencement du projet ou à la demande du chef de projet dans le cas de projet de longue
durée.
Suite à ce recueil, le chef de projet est en mesure de planifier le travail de chacun de ses
collaborateurs mais aussi de pouvoir planifier les dates clés du projet et par conséquent de
pouvoir faire le planning de pilotage qui sera à présenter par la suite au client.
Les plannings internes et de pilotage seront alors mis à disposition des collaborateurs et du
client par le biais des solutions de communication évoquées dans ce mémoire.
Autrement dit, le planning interne sera mis à disposition des collaborateurs par le biais du
calendrier commun présent sur la messagerie de chaque membre de l’équipe.
Le planning de pilotage sera mis à disposition du client lors des comités de suivi organisé par le
chef de projet, puis sera enregistré dans l’outil GED afin qu’il soit référencé et que le chef de
projet puisse faire des versions de ce planning en fonction du déroulement du projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 70 / 79
6.5.2 Le management technique
Dans les paragraphes précédents, deux solutions ont été retenues concernant l’amélioration des
conduites suivies lorsque des changements dans le management technique surviennent.
La première solution concerne la création d’une base de données qui permet de collecter toutes
les informations sur les personnes faisant partie de la société. Cette base de données sera une
source unique de recherche de personnes et plus particulièrement de compétences dans la
société.
Cette base devra comporter les informations administratives et civiles de chaque employé, les
informations sur le poste ou les postes occupés dans la société, des informations sur les
compétences techniques et enfin cette base devra mentionnée pour chaque employé sur quel
projet ils ont travaillé.
Cette base de données devra par ailleurs être accessible par tous les responsables d‘équipe de la
société et elle devra être accessible par le biais d’une interface graphique. Cette interface devra
permettre à chaque utilisateur de pouvoir faire des recherches par compétence, par poste, par
nom, et par projet.
De plus, cette base sera alimentée uniquement par le service des ressources humaines, dans un
premier lors de l’embauche de chacun des employés et dans un second temps par demande de
chaque responsable d’équipe suite notamment aux formations que chaque employé a pu suivre.
La seconde solution concerne la préparation d’un basculement d’une architecture à une autre.
Comme il a été expliqué auparavant, cette bascule se fera à l’aide d’un mode opératoire. Ce
dernier, pour être rédigé, sera découpé en plusieurs modules qui seront tous testés séparément
les uns des autres. Après chaque test, une fiche de test est rédigée.
Une fois que chaque module aura été testé et validé, le mode opératoire sera alors rédigé en
rassemblant chacun des modules les uns derrière les autres afin d’avoir le mode opératoire final.
Le mode opératoire est alors testé en son intégralité afin de s’assurer qu’il n’y a pas d’anomalie
dans son déroulement.
6.5.3 Le management commercial
Dans ce paragraphe, va être détaillée la solution concernant l’établissement d’un document
listant tous les pré-requis nécessaires pour répondre à une modification de périmètre d’un
projet.
Dans ce document, qui est présenté au client, apparaît comme le périmètre existant suivi du
temps passé ou estimé pour ce périmètre.
Par la suite est évoqué le changement de périmètre et ce qu’il comporte. Le chef de projet doit
alors donner une estimation de la charge de travail pour prendre en compte ce nouveau
périmètre.
Enfin, il apparaît dans ce document, la date à laquelle la modification pourra être réalisée et le
coût financier.
Ce document doit alors être fourni au client pour qu’il le valide ou non.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 71 / 79
6.5.4 Le management financier
Dans ce paragraphe, la manière de budgéter un projet va être évoquée. En effet dans les
paragraphes précédents, il a été évoqué de choisir la solution d’inclure dans le budget le
financement concernant les risques liés au projet.
La sélection des remplaçants des membres « titulaires » du projet fait partie de cette partie des
risques et sera donc budgétisé non pas dans le budget nécessaire au projet mais dans le budget
des risques. Bien entendu, ces deux budgets sont assemblés afin d’en faire qu’un seul qui sera
présenté aux responsables hiérarchiques du chef de projet.
Chaque module est donc budgétisé mais pour chacun d’eux le chef de projet va surévaluer le
budget afin d’avoir un budget plus large et ainsi pouvoir palier aux risques pouvant survenir
dans n’importe quel domaine à n’importe quel moment durant le projet.
6.5.5 Le management de production
Il a été évoqué dans les paragraphes précédents, qu’il est très important que le chef de projet
pense à l’avenir du projet afin de pouvoir garantir la durée de vie et la bonne qualité du projet.
Dans les solutions évoquées dans le paragraphe 6.2.6 et qui ont toutes été retenues, il est
expliqué que le chef de projet doit se rapprocher du client mais également des constructeurs
auxquels le client fait appel afin de pouvoir obtenir toutes les informations nécessaires pour
savoir quel avenir ce projet pourrait avoir.
Le chef de projet doit s’atteler à obtenir ce type d’information dès le commencement de ce projet
car il est important de prendre ces informations en compte avant que le travail technique ne
commence.
Le chef de projet doit lors d’un comité de suivi demander au client la liste des constructeurs
avec qui il travaille, puis lui demander quel avenir il voit pour son projet.
Par la suite, le chef de projet doit prendre contact avec chacun des constructeurs susceptibles de
pouvoir l’aider à construire un avenir pour le projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 72 / 79
7. Processus de changement
A ce point du mémoire, les solutions, pour améliorer les conduites suivies face aux changements
durant un projet informatique, ont été évoquées et expliquées.
Maintenant l’objectif est d’expliquer comment ces solutions vont être mises en place afin qu’elles
soient prises en compte le plus rapidement possibles
Dans un premier, il sera expliqué par quel processus les solutions évoquées vont être mise en
place. Dans un second temps, il sera détaillé la mise en place de ces solutions et en dernier point
seront évoquées les difficultés qui ont été rencontrées lors de la mise en place des solutions.
7.1 Description du processus
Le processus de changement est un processus simple mais très long à mettre en place car il
demande un changement d’habitude des personnes concernées et ce genre de changement est
dur et surtout long à faire accepter puis à mettre en place.
Dans un premier temps, tous les changements évoqués tout au long de ce mémoire doivent être
évoqués et expliqués avec chaque employé de la société qui est concerné, de près ou de loin, par
ce changement. Cette mission de communication est donnée à chacun des responsables d’équipe
assistée par les personnes qui sont en charge de faire appliqué ces changements.
Ainsi sur une période plus ou moins longue, la communication sur le changement va se dérouler.
Le but est de présenté ces changements comme une évolution positive de la vie de la société. Ces
changements doivent pouvoir aider chacun des employés dans leur travail, mais aussi doivent
pouvoir amener de nouveau client et donc de meilleurs résultats pour la société, soit un meilleur
intéressement pour chacun des employés.
Cette communication doit également permettre à chacun des employés de pouvoir participer à
ce changement et ainsi de pouvoir donner leur opinion et leurs idées pour mener à bien ces
changements.
Une fois la communication passée dans toute la société, le chantier peut alors commencer. Ce
chantier est entièrement mener par les différents chefs de projet en poste dans la société car
ceux sont eux les éléments principaux du changement.
En effet, les différents chefs de projet ainsi que leurs responsables doivent se réunir afin de
mettre en place ensemble des trames de documents uniques, des fonctionnements identiques. Il
est important que tous les chefs de projets travaillent ensembles afin qu’ils aient tous le même
langage et surtout tous la même méthode.
Ainsi, les collaborateurs n’auront pas de soucis d’adaptation à l’un ou l’autre des chefs de projet.
L’adaptation se fera qu’au début du chantier et si tout le monde parle le même langage et utilise
la même méthode alors l’adaptation se fera de manière très rapide.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 73 / 79
Une fois tous les documents ainsi que tous les outils comme la messagerie, l’outil GED… mis en
place, l’objectif est qu’à chaque début de projet, les chefs de projet présentent la nouvelle
méthode et les différents outils à chacun des membres.
Les chefs de projet ont pour objectif de vérifier si la nouvelle est bien comprise et surtout si elle
est bien utilisée par tous les employés concernés.
7.2 Mise en place des améliorations
Comme il a été évoqué dans le paragraphe précédent, la création des modèles des différents
documents de gestion de projet à mettre en place est faite en collaboration avec tous les chefs de
projet de la société ainsi que leurs responsables.
Ils ont pour objectif de mettre en évidence et par écrit l’utilité de chacun des documents et de
leur donné une forme selon une charte graphique unique qui sera défini par eux.
Concernant la mise en place des outils, seul l’outil GED est à acquérir, à installer et à expliquer.
En effet, cet outil une fois installé devra être expliqué à tous les employés de la société sous
forme de formation. Il pourra y avoir deux types de formations, une première concernant
l’utilisation générale de l’outil, c’est à dire comment rechercher un document et comment le lire,
et une seconde formation concernant l’utilisation poussée de l’outil, commente créer un
document, le modifier, le supprimer …
En ce qui concerne la messagerie, la création des différentes messageries communes se fera au
fur et à mesure de l’acquisition de projet.
7.3 Difficultés rencontrées
Les difficultés rencontrées pour mettre en place ces changements sont surtout la réaction des
employés et plus particulièrement la mauvaise volonté de ces derniers.
En effet, une minorité est toujours réfractaire au changement se qui ralenti le processus de
changement. En effet, il est important pour la société que tous les employés adhèrent au
changement.
Par conséquent, cela implique aux personnes chargées du chantier, de trouver des arguments
pour faire accepter ce changement mais aussi et surtout de rassurer continuellement les
employés sur l’avenir et le travail qu’ils pourront faire avec ces changements.
De plus, une autre difficulté se situe au niveau du temps, en effet, il est important qu’une fois que
ce changement est mis en place, qu’il soit adopté et utilisé de manière rapide et sans accros.
Pendant ce temps d’adaptation, les personnes chargées du chantier sont très sollicitées et ne
peuvent pas répondre à tous les employés en même temps. Ce qui provoque des tensions et par
conséquent des risques de rejet du changement.
La difficulté est donc de mettre beaucoup d’employés de son côté afin d’aider les employés ayant
des soucis suite aux changements.
Enfin, il faut que les responsables soient beaucoup plus présents afin de rassurer les employés
mais aussi afin de les encourager.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 74 / 79
8. Synthèse des résultats et apport du travail
Ces changements sont des évènements très bouleversants pour les employés, il est difficile de
changer les habitudes des gens. Mais les changements mis en place sont des changements
permettant de mieux gérer les projets et ainsi perdre moins de temps et par conséquent moins
d’argent.
Le fait de rédiger toutes les informations circulant sur un projet permet à tous de pouvoir suivre
ou reprendre un projet sans trop de difficultés. Par ailleurs, ces différents changements
permettent à chacun de bien comprendre quel est l’enjeu mais aussi quelle est la plus-value de
chacun dans un projet.
Les collaborateurs se sentent entourés et aidés, et le chef de projet a beaucoup moins de soucis
concernant la gestion de son projet, la gestion de ses collaborateurs et il peut ainsi s’occuper
beaucoup plus de son client et tenter de lui proposer d’autres prestations pour lesquelles il n’a
pas souscrit.
Tout ceci permet donc de finaliser des projets en temps et en heure et ainsi de pouvoir fidéliser
le client. Cela permet également de pouvoir décrocher de nouveau contrat et ainsi d’augmenter
le nombre de clients dans la société.
Ces changements amènent systématiquement les employés à changer leur méthode de travail,
ainsi la gestion du temps de chaque employé est améliorer. Cela donne un nouveau souffle à la
société et évite à chacun de s’ancrer dans une routine qui peut engendrer une baisse de
motivation pour chacun.
Ces changements consacrés essentiellement aux projets informatiques peuvent également être
mis en place pour d’autres types de projets. Cela peut également amener la société à revoir les
différents processus qui sont actuellement en place dans la société et qui demanderaient à être
améliorés.
Tout le travail effectué pour mettre en place ces changements est bénéfique puisqu’il permet à
chacun de pouvoir apprendre une nouvelle méthode de travail mais aussi et surtout de pouvoir
unifier la façon de travailler dans toute l’entreprise.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 75 / 79
9. Enseignements tirés
Les enseignements retirés de ce mémoire sont qu’il est difficile de faire accepter aux employés
d’une société le changement.
Il faut prendre au sérieux les avis de chacun et surtout leurs sentiments et leur motivation. Les
employés ont un fort pourcentage dans les risques puisqu’ils ont le pouvoir de faire échouer un
chantier d’une telle ampleur.
De plus, il est évident que ce genre de changement est long, très long à mettre en place. Cela
demande beaucoup de patiente et beaucoup de rigueur. Le fruit d’un tel travail ne peut pas
s’observer au bout de quelques semaines mais plutôt au bout de quelques mois voire au bout de
quelques années.
Les autres enseignements qui peuvent être tirés de ce mémoire sont que les différents
changements qui peuvent survenir durant un projet ne peuvent pas être listés puisque ces
changements sont différents en fonction des projets. Or tous les projets sont différents puisqu’ils
sont uniques.
C’est pour cela qu’il est important d’être organiser et d’avoir une bonne gestion de projet, cela
permet de pouvoir faire face plus facilement à des nouveaux changements qui bien entendus
peuvent survenir à n’importe quel moment du projet.
De plus, dans ce mémoire, il paraît évident que tous les domaines sont importants dans un
projet, que se soit le domaine humain comme le domaine financier ou tout autre domaine.
Chaque domaine a besoin d’un autre domaine et c’est les relations entre ces différents domaines
qui permettent de faire exister les projets.
Cela implique, par conséquent, que toutes les personnes travaillant sur un projet est essentiel,
certes chaque personne peut être remplacée mais aucune d’elle ne peut être enlevée.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 76 / 79
10. Conclusions générales
Quelle est la conduite à suivre sur le management du projet, lorsqu’un changement intervient
durant un projet informatique ?
Le mémoire commençait par cette question qui a enfin trouvé une réponse ou plus exactement
plusieurs réponses.
Comme il a été évoqué tout au long de ce mémoire, ce dernier donne des réponses sur des
changements connus, mais les projets sont des événements uniques, qui sont amenés à
découvrir d’autres changements qui demanderont alors à être étudiés afin de trouver des
solutions à ces changements.
Dans ce mémoire, le changement se gère plus facilement si le projet est correctement géré. En
effet il ne faut pas que la gestion de projet soit un frein car tous les changements qui
surviendront viendront s’additionner aux problèmes et ne pourront donc pas être réglés. Ce qui
par conséquent provoquera des abandons de projet et dans certains cas des pertes de contrats.
Il est important de faire de la gestion des risques car c’est cette gestion qui va permettre d’aller
au devant des changements et par conséquent de pouvoir y faire face sans difficultés et sans
risques pour le déroulement du projet. Cette gestion des risques est l’élément essentiel pour
faire face aux changements.
Les conduites suivies face aux changements de management durant des projets informatiques
sont des conduites qui doivent devenir intuitives et pour lesquelles il y a une solution claire pour
chaque conduite.
Ces conduites sont des conduites qui peuvent être utilisées dans d’autres cadres que le projets
informatiques, ces conduites peuvent être utilisées dans tous les types de projets car les
domaines de management humain, technique, financier, commercial et le management de
production sont des domaines présents dans tous les types de projet et dans toutes les sociétés.
Certes au niveau du management technique et du management de production certaines
conduites vont sensiblement changées mais cela reste quand même identique aux projets
informatiques.
Les nouvelles solutions mises en place dans ce mémoire vont maintenant permettre de pouvoir
identifier de nouveaux changements et par conséquent de pouvoir refaire tout le travail
d’analyse, de critique et d’amélioration sur ces nouveaux changements.
Ainsi, de nouvelles solutions pourront être trouvées et pourront venir agrémenter les solutions
de ce mémoire afin de renforcer les gestions de projet des sociétés.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 77 / 79
11. Bibliographie
Fernandez, Alain. Le chef de projet efficace – 2e édition. Editions d’organisation, 2005. 168 pages.
Ferrandon, Benoît. Comprendre le management – 1e édition. Edition Les cahiers français, 2004.
96 pages.
12. Webographie
http://www.google.fr/
http://www.afnor.org
http://fr.wikipedia.org/
http://www.journaldunet.com/management/dossiers/040538changement/conseils.shtml
http://www.anfh.asso.fr/fonctioncadre/cadre/gmweb/Cadre_GM_Conduite%20du%20change
ment.htm
http://www.commentcamarche.net/conduite-changement/conduite-changement.php3
13. Terminologie
13.1 Abréviations
AFITEP : Association francophone de management de projet
AFNOR : Association française de normalisation
TPE : Très petite entreprise
PAQ : Plan d’assurance qualité
13.2 Glossaire
Workflow : flux d'informations au sein d'une organisation, comme par exemple la transmission
automatique de documents entre des personnes. Il décrit le circuit de validation, les tâches à
accomplir entre les différents acteurs d'un processus, les délais, les modes de validation, et
fournit à chacun des acteurs les informations nécessaires pour la réalisation de sa tâche
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 78 / 79
14. Annexes
Réponses au questionnaire élaboré pour les interviews
Premier questionnaire
1. Quels sont les types de projets informatiques qui vous sont confiés, développement
d’applications, mise en place d’architecture réseaux … ?
Je suis en charge de projets de développement en tant que sous-traitant. Ceux sont des
projets basés sur du Java J2EE ou du .NET
2. Les équipes projet sont composées de combien de collaborateurs en général ?
Cela dépend de l’ampleur du projet, on tourne bien souvent par équipe de 5 personnes
plus un chef de projet.
3. Quelle est votre démarche actuelle pour gérer les projets de type informatique ?
Nous n’avons pas réellement de démarche bien spécifique. La plupart du temps le chef de
projet fait une réunion d’initialisation avec le client pour discuter de ces besoins et par la
suite, l’équipe fait l’analyse des besoins puis le développement.
4. Une fois que le projet a débuté, vous est-il déjà arrivé de faire face à un changement
inattendu ?
Le plus souvent, le client rajoute des fonctionnalités dans son projet. On a parfois des
collaborateurs qui changent. Sinon on n’a pas vraiment eu de gros changement.
5. Comment gérez-vous des changements de types humains dans un projet informatique ?
a. Changement du chef de projet ?
Pas de réponse.
b. Changement d’un collaborateur ?
Soit on fait appel à un collaborateur qui est en inter-contrat et donc qui n’a pas de projet
en cours, soit on embauche quelqu’un sur projet.
c. Les arrêts maladies ?
Pour des courtes durées de moins d’une semaine on ne fait rien sinon on prend une autre
personne en attente de son retour. Comme pour avant cette personne peut être en inter-
contrat.
d. Les congés payés ?
Les employés ont obligation de donner leurs congés payés avec un minimum trois
semaines avant la date lorsqu’ils sont sur un projet.
Audrey LEPICOUCHE 2007
La conduite de changement de management de projets informatique Page 79 / 79
6. Au niveau technique, comment gérez-vous les changements comme les modifications des
besoins client impliquant bien souvent un changement de technologie (langage de
programmation, architecture réseau …) ?
Cela ne nous ait jamais arrivé d’avoir ce genre de changement
7. Durant un projet, un chef de projet doit bien souvent rendre compte de son avancement
auprès du client, quelle conduite avez-vous face au client lorsque vous devez lui annoncer un
retard sur les délais ? Prenez-vous alors un rôle de commercial ?
On présente face au client les problèmes rencontrés et le temps que ca prend pour
résoudre ces problèmes, ensuite on leur annonce qu’il faudra décaler la mise en
production du produit. On essaie également de leur montrer les solutions aux problèmes
que nous rencontrons si nous avons déjà trouvés les solutions bien entendu.
Nous ne faisons jamais de commercial, généralement on prévient le commercial quand on
sent qu’il y a des éléments qui peuvent être vendus au client
8. Comment gérez-vous des changements au niveau financier dans un projet informatique ?
a. Les restrictions budgétaires ?
On fait avec les moyens qu’on nous donne mais on essaie de trouver les arguments
nécessaires face à nos responsables pour pouvoir garder notre budget d’origine
b. Les formations imprévues, dues par exemple à un changement de besoin client ?
On essaie de les faire facturer au client dans le meilleur des cas, sinon c’est nous qui
finançons
c. Réorganisation ou rachat de la société, comment gérez-vous la continuité du projet sans qu’il
y ait d’impacte pour le client ?
Pas de réponse
9. La mise en production marque bien souvent la fin d’un projet, comment gérez-vous un
changement durant cette phase ?
a. Le produit final est non fonctionnel dans l’environnement client ?
On essaie de résoudre le problème dans l’environnement client en laissant sur place un ou
plusieurs collaborateurs en fonction des problèmes
b. Le client a changé un équipement dans son architecture remettant ainsi en défaut le projet ?
Idem que précédemment