La Conduite Du Changement

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.



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.



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



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.4 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT FINANCIER .............................................................. 32



4.3.4.3 RACHAT DE LA SOCIETE.......................................................................................................... 33

4.3.5 LA CONDUITE SUIVIE LORS D’UN CHANGEMENT EN PRODUCTION...................................................... 33



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.4 LES AMELIORATIONS A APPORTER LORS D’UN CHANGEMENT DANS LE MANAGEMENT FINANCIER ........... 46



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.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



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.5 DESCRIPTION DETAILLEE DE LA SOLUTION CHOISIE ............................................................................. 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






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



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.



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



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 :



« 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 :



• 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



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.



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.



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.



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.



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.



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.



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.



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.



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é.



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.



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.



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.



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.



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.



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.



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.



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.



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.


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.



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.



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.


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.


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.



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.


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.




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.


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é.



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.


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.



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.



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.



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 ?



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é.



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.



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.



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.



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.


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.


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.



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.



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.


management commercial

Dans ce paragraphe seront détaillées les améliorations qui peuvent être faites pour faire face


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.


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.



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.


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.




management financier



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.


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.




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



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.




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.


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.



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.



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.



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.



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…



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é.



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.



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.


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é.



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.




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).



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.



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.



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.



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.



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.


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.




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.




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.


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.


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.




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.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é.



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.



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.



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.




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.




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.


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.




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.


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.



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.



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.



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.



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.



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.



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



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.



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

Documents

La Conduite Du Changement